This relates to Unreal Engine 4.1.0 via the Launcher.
I can add Delay Nodes to any Event Graph, even the Animation Blueprint. I can not however add it to construction scripts and functions used in the Event Graph.
Reproduce (using both right click and D-shortcut):
Create any Blueprint.
Open Event Graph.
Add Delay Node. OK
Add Function.
Try add Delay node inside Function. NOT OK
Is this a limitation by design or a bug? I find it odd that delay nodes doesn’t work inside functions while timers do. I’ve tried searching the AnswerHub, and the documentation, but I can’t find any information about this.
I’m just thinking that there could be situations where you could have a behavior with delays that you may want to reuse as part of a function. For example, function does: Do X, wait, then Y.
If it is by design I would appreciate a basic rundown of the technical aspects to better understand how Blueprint is structured. Thank you!
This is a limitation by design. In a function or macro, you can not have a latent node or anything that takes time, like timelines and delays. We have attempted to implement delay and timelines into functions and macros before, but it is only causing other issues to arise. This may be reopened and looked into at a later time.
Thank you for responding to this issue. I reached for additional information and here is a bit of the information that I got back:
This feature is a design constraint that will not be changed. The reason is that functions have return values, and can be called from native code. Because things can be relying on the return value of a function, we don’t want to break the game thread waiting for that code to finish delaying.
Event Graph has shared state, and is re-entrant. That allows a degree of flexibility, because we’re saying nothing depends on the result of anything. That’s why events don’t have return values, and allow for delays and other latent functions.
In short, the contract is: if you have a return value, then someone is depending on your code to return as fast as possible, so no delays. If you’re an event, you don’t have a return value, so you’re free to do what you want.
It seems pretty feasible to let people call an output-less delayed node in a function or macro if it’s an issue of not wanting to let a function or macro wait for the delay / break the timeline. Or add special rules to the outputs so they can’t be part of the default return, like color the output wires different than white and/or with dashes or something…or ideally make them have depth since that’s what’s really going on with the timeline at that point.
The issue stems from too many systems and features (and people) thinking flat and “2D” instead of having “3D” / an extra depth in mind. Imagine Blueprints in 3D, and if you break from the default flat timeline then it’s popped front or back, and could be visualized as such easily thanks to it already being in 3D. I have a theory that when the majority of our workstations transition to VR and AR and holograms and more software / OSes are VR-ready (aka 3D), everything and everyone will start thinking with 3D in mind and limits like no delays in functions/macros will vanish. Then you stop limiting yourself to 3D and it gets even wilder.
native Loops also don’t have the option to lose delay or time operations between loop cycles.
i have made a macro library of alternative loops that do have option for delay, if enough people here are interested i will submit it to marketplace for free later on. let me know
You can break the function into two functions. Where you’re currently calling the function (for instance from a trigger), Call function 1. Call Delay. Call function 2. Make sure the delay includes execution time for function 1. Works for me.
One solution I found for my case was to call a custom event which held the delay node. The problem with this, of course, is that the rest of the function will not wait, but this is a muzzle flash in my case so that is irrelevant.
Here is a another simple solution for delay in function:
Lets say you want to switch between 2 cameras every 5 seconds.
In event graph add SetTimerByFunction, Create 2 functions (State1 and State2). In each State Function add Sequence (as HitEmUp posted). In Sequence in pin 1 add what to do and pin 2 add SetTimerByFunction calling opposite Function (state) with delay of 5 seconds. Back on Event Graph. In SetTimerByFunction call State 1 function and mark Looping.
Why not just add a concept of private functions that are meant to be used by the current graph only? The functions are nice because you don’t have to create massive graphs. Coming from a programming background (and someone how has always used Visual Studio), I find these massive graphs to be clumsy.
I recreated ForEachLoop macro in to a collapsed node by looking at sidebyside screens, it worked. I’m trying to create a slideshow to background. In the image below, you should check carefully where I put delay function.
I didn’t read the whole thread so sorry if this has been mentioned before. What you can do is add a sequence pin and execute your function from there. On the second pin you can add a delay and use it to set a boolean variable to true. Add a branch in your function to check if the boolean is set true or not. This worked for me when I was using a single function to fire multiple weapons, with the function having inputs to change values such as muzzle flash and projectile type wrt the weapon in hand.
I needed a way to add a cap to the number of times the player can spam the fire key cause it would create a rapid fire which is at a much higher rate than the automatic fire anim notify i was using to trigger the function again and again.
Hope you can use this trick to adjust it to your code.
This is a really bad idea. Literally nothing is gained by making it 3d, it sounds cool and futuristic, but super hard to read. You’ll have to be constantly moving the nodes around shifting perspective, and angles just to find the things you need. What advantage will this actually bring? Also, how would things even turn directions in the third space, nodes will still only have one exec wire, so its totally possible to rearrange them to be flat plane. If you need more space, just use collapsed nodes, functions and macros, ffs.
This just seems like building a language all around it being hard to visualize for it looking cool and advanced like the movies or something, but seriously, what is the point? Portals let you travel two points instantly (kind of like a node does) adding a dimension isn’t always the answer.
