I was wondering about the order of execution concerning ticking and inputactions.
Specifically I have an input action that causes the recalculation of a motor vector.
This motorvector is added to the movementvector and the movement is then applied, each tick.
Is it possible that the tick continues doing whatever it’s doing without ever waiting for whatever the inputaction does to finish? I don’t know much about threading but does tick have its own thread possibly?
Ticks are executed asychronically (if multithreading is on) in groups called tick groups, here you got list of them (saddly this enum dissapered from API refrence so link is to github):
As for input i’m not sure, it probably updated before ticking is started. There function that let you check if specific button is pressed at the moment:
Are you able to point to documentation or code that supports the claim that “ticks are executed asynchronously (if multithreading is on)”?
Writing code/blueprints to support that scale of multithreading is relatively advanced. Every access (read or write) to anything shared must be protected by a mutex to be threadsafe.
I’m pretty sure that the ticks in each tick group are run in serial on the main thread (though nothing prevents a tick from firing off some work to be done in parallel).
So I’m not an expert with the codebase, but I’m fairly certain that the tick groups are run in serial (though not on the main thread. which is contrary to what I said in my first reply).
What appears to run asynchronously is the dispatch of the tick groups. Specifically, the main thread will pass off the execution of a tick group to another thread allowing the main thread to chug along and do something else (I’m pretty sure the main thread just moves on to preparing the next tick group for execution).
The ticks in the tick group appear to be executed serially on the other thread.
This is an old question - but the order of input delegate events vs actor ticking has been bugging me for a couple of days now and I think I found the answer by simply attaching the debugger to a compiled version of the engine (4.22 in this case), and checking the callstack when a bound input delegate is called:
APlayerController has a tickgroup of TG_PrePhysics:
(more on tick groups)
During the APlayerController tick, ProcessPlayerInput is called, which fires off all the bound delegates for registered InputComponents
So, bound input delegates are called during TG_PrePhysics - here’s the callstack:
UE4Editor-DASH.dll!ADASHPlayerActor::OnBeginDash() Line 123 C++
[Inline Frame] UE4Editor-Engine.dll!TBaseDelegate<TTypeWrapper<void> >::Execute() Line 561 C++
UE4Editor-Engine.dll!FInputActionUnifiedDelegate::Execute(const FKey Key) Line 252 C++
UE4Editor-Engine.dll!UPlayerInput::ProcessInputStack(const TArray<UInputComponent *,FDefaultAllocator> & InputComponentStack, const float DeltaTime, const bool bGamePaused) Line 1306 C++
> UE4Editor-Engine.dll!APlayerController::ProcessPlayerInput(const float DeltaTime, const bool bGamePaused) Line 2473 C++
UE4Editor-Engine.dll!APlayerController::TickPlayerInput(const float DeltaSeconds, const bool bGamePaused) Line 4461 C++
UE4Editor-Engine.dll!APlayerController::PlayerTick(float DeltaTime) Line 2134 C++
UE4Editor-Engine.dll!APlayerController::TickActor(float DeltaSeconds, ELevelTick TickType, FActorTickFunction & ThisTickFunction) Line 4601 C++
UE4Editor-Engine.dll!FActorTickFunction::ExecuteTick(float DeltaTime, ELevelTick TickType, ENamedThreads::Type CurrentThread, const TRefCountPtr<FGraphEvent> & MyCompletionGraphEvent) Line 164 C++
[Inline Frame] UE4Editor-Engine.dll!FTickFunctionTask::DoTask(ENamedThreads::Type) Line 285 C++
I do agree that asynchronous ticking are a bit of an overstatement. Too much of a hassle, really. However, I’ve found that internal PhysX physics processing is actually parallel. At least it seems so, providing some synchronization structures.
If your project isnt BP only, you can use FWorldDelegates::OnWorldTickStart on your custom actor class, which will essentially “tick” super-early in the World tick group.