Someone knows why when managing player’s input in tick (of pawn) there is more input lag than managing it in input events?
I tried all tick groups but the lag is always the same.
For example, in First Person template, the default code for mouse input is:
Deleting that and adding the following results in input lag:
I need to know the value from both axis when managing input in my game. Is there an event somewhere (even c++) that is late enough so that all new input for the current frame is available, but early enough so that operations done in it don’t get that input lag?
This is the tick group to use if your actor is intended to interact with physics objects, including physics-based attachments. This way, the actor's movement is complete and can be factored into physics simulation.Physics simulation data during this tick will be one frame old - i.e. the data that was rendered to the screen last frame.
TG_DuringPhysics
Since this runs at the same time as physics simulation, it is unknown whether physics data during this tick is from the previous frame or the current frame. Physics simulation can finish at any time during this tick group and will not present any information to indicate this fact. Because physics simulation data could be current or one frame out of date, this tick group is recommended only for logic that doesn't care about physics data or that can afford to be one frame off. Common cases might be updating inventory screens or minimap displays, where physics data is either entirely irrelevant, or displayed coarsely enough that the potential to have a single frame of lag does not matter.
TG_PostPhysics
Results from this frame's physics simulation are complete by the time this tick group runs.
A good use of this group might be for weapon or movement traces, so that all physics objects are known to be in their final positions, as they will be when this frame is rendered. This is especially useful for things like laser sights in shooting games, where the laser beam must appear to come from the player’s gun at its final position, and even a single frame of lag will be very noticeable.
TG_PostUpdateWork
This runs after TG_PostPhysics. Historically, its primary function has been to feed last-possible-moment information into particle systems. TG_PostUpdateWork happens after cameras are updated. If you have any effects that rely on knowing exactly where the camera is pointed, this is a good place to put the actors that control those effects.
This can also be used for any game logic that is intended to run after absolutely everything else in the frame, such as resolving two characters trying to grab each other on the same frame in a fighting game.
Sorry, but how this relates to my question? As I said, changing the tick group has no effect. It seems pre physics is already too late to avoid the input lag.
