Closed aziogroup closed 9 months ago
Remarks: Since LatentActionManager is processed in the order of registration, the problem seems to be caused by the fact that the resumption process of the external coroutine is not called until the next frame after the internal coroutine has finished.
WhenAll, WhenAny, etc. were registered and processed after the internal coroutine, so they behaved as intended.
This behavior is by design and documented. Latent coroutines are fundamentally owned and controlled by the latent action manager and can only complete when it processes them on its own tick. This matches BP and most existing Latent
UFUNCTIONs from the engine, which is the primary focus of this mode of execution.
In some situations that I encountered, I managed to skip the extra tick by return
ing an inner TCoroutine instead of co_awaiting it.
Thank you for your response, Sorry for the inconvenience,
In some situations that I encountered, I managed to skip the extra tick by returning an inner TCoroutine instead of co_awaiting it.
If you don't mind, I would appreciate it if you could tell me what exactly you did in response.
@aziogroup Instead of
TCoroutine<> Fn1();
TCoroutine<> Fn2()
{
DoStuff();
co_await Fn1();
}
it's
TCoroutine<> Fn1();
TCoroutine<> Fn2()
{
DoStuff();
return Fn1();
}
Thank you very much! It seemed difficult to apply it to my case, but in a simple case this seemed to be the way to get around it.
Hello, I'm currently using UE5Coro to perform various tests. When I call a coroutine from within another coroutine and wait for it, I've noticed that there's a 1-Tick delay before the internal coroutine finishes and the external coroutine resumes processing. It turns out that I can avoid this delay by using
co_await WhenAny(TCoroutine<>)
instead of a simpleco_await TCoroutine<>
. Is this behavior intentional?If it is intentional, is there a way to achieve the same behavior as WhenAny without using WhenAny when simply using co_await TCoroutine<>?
Thank you.
Result