When using delays inside macros, if the same macro is used in two places (A nad B) and B is executed while A is waiting for delay to end, then B is ‘canceled’ as soon it gets to the delay node.
I’m not sure but i think this problem did not happen to me in 4.12.
I made a youtube video to better show the problem.
Hello dzarafata,
Thank you for reporting this issue. I do believe this behavior is intended due to the way delays work but I placed a bug report in seeing as the behavior is different from 4.12.5. You can find the bug report here and track it for updates.
Have a nice day!
Hi,
I saw in bug report that it states that delay was reset. If I understand correctly, that means that only second macro call will be completed.
In my case it was only the first one. It’s seems more like second call is blocked/canceled.
In example i posted, I’ve started one printing ‘B’ first and then one printing ‘A’ later and maybe that could lead You into mistake, as only ‘END B’ was printed.
Have a nice day to!
I have the same problem. While A(pressed) is waiting for delay to finish, then when B is executed, at the same time A delay is canceled and executed. Also, B won’t execute anymore.
It’s working like a charm in 4.13.1. Thanks a lot!
Hi Matthew, I’ve been experiencing the same issue in v4.14 as well. When a ‘for loop with delay’ macro is being called multiple times, only the first one keeps looping, while all subsequent ones stop after the first iteration of their loops. It was working perfectly fine in v4.13.1 & the issue has been marked fixed. Do you know if it’s getting a fix in the upcoming 4.14 updates?
Hello Stormrage256,
The fix was originally entered directly into the 4.13 release branch so that it could be included in the 4.13.1 hotfix. It was never added into the other branches however so the issue showed up again in 4.14 since it’s a separate branch. I’ve already reported that the fix needed to get merged over and verified that it’s in the stream now. It will be fixed in 4.14.1.
While beeing flagged as fixed in 4.14.1 I still experience this Issue, or a very similar Issue. I have a delay macro, and if I execute it, while another instance of the macro is still running, all following macros won’t finish.
Hello AlexW88,
Using the reproduction steps that I had written up when entering this bug, I’m not seeing the issue in 4.14.1. Could you please upload some screenshots of the macros you’re using or a small project that reproduces the issue?
Just load the test level and hit play, it should print A,B,C,D after some time, but it does only print A.
Thank you for that reproduction project. I can reproduce the issue with what you gave me but after messing with it, I’m confused as to how this was even set up. Where did you add the delay node that you have inside of your OBJ_Macro_Lib’s Delay macro? If it’s deleted and you attempt to add it back, it’s not available even with Context Sensitivity disabled. Was this node copied from another blueprint?
I remade the reproduction with a macro created in the Level Blueprint, as macros in function libraries aren’t meant to have delays, other than a Task Wait Delay which is related to AI functions. After doing that, it works without an issue.
The node was first collapsed within another BP and then copied to the Library. This is the “official” workaround for a “(terrible)designchoice” in 4.7 - you can read about it here: 4.7 preview 3 - Delay not available in standard macros - Blueprint - Epic Developer Community Forums
Delays in Macro libraries (for the object class - so one doesn’t have to make 101 instances of the same Macro for various classes) are quite Important. It would be great if this Issue could be fixed.
The problem is that, since Delay nodes must be called on something that exists in the level as it needs to have a World Context Object, this won’t work correctly in most cases without one.
As mentioned, it’s a work around that is basically fooling the editor into letting you place the node here. The bug report itself that was entered for that user’s issue (UE-7819) is marked as By Design as delays are not intended to be used in these types of macros.
If the macro is created on the blueprint class itself rather than being created in a function library, UObject, or the StandardMacros library, it should work without any issues.
I can put in a feature request to have them be available if you wish but with the resolution of that bug report, I’m not sure if it would come to fruition.
No, I don’t need a new feature.
This workaround used to “work”, if you test the same setup I sent you in version 4.12 of the engine, you will see everything works flawless.
But since 4.13 it shows the exact same behavior as described for UE-35609
So UE-35609 is only fixed partially with 4.14.1.
As stated previously, this was a workaround that is “hacky” as mentioned by the person who provided it. This is not intended functionality so the fact that it was working was a bug in and of itself. The fact that the workaround doesn’t work anymore in 4.14.1 is not a bug.
I’m seeing this exact issue in 4.14.3.
It only prints the last macro executed after the delay.
It seems this bug keeps getting fixed and cut after each update?
Edit: Also verified this is happening in 4.15 as well.
Hello Redsett,
I’m not seeing this issue in neither 4.14.3 or 4.15. I can’t see what event’s you’re using to call this function but remember that if you’re using the same input, and therefore calling the same macro call, this is expected as you’re only resetting the delay. You need to be using two separate macro calls if you want two of them to be running at once.
