I am using an event tick for my movment… How can I Use another event tick for other things?
Is it possible to have multiple ticks for one event? I can’t fork an event tick.
any thoughts?
You can’t have multiple tick events and you cant multithread it aspecially in blueprint. There is Sequence node which will call one segment of the code after another, but you need to decide the order of execution
You can create multiple tick events by creating custom events like so:
I 't know if that’s the most efficient way to do it, but it does the trick!
Good luck!
4 Likes
which leads (in my case, building this character controller through blueprint) systems, where I need to replace event tick input with ALL possible results of calculations. Looks messy, but works 
Well you can move some things in to functions.
I am trying to have multiple tick events and it isn’t working. Can you help?
I have 3 meshes that I would like to spawn over different time spans (a range between 1-3 seconds). Each mesh should spawn at a random different time than the other meshes while spawning at the current location of the boss which is moving back and forth. The image I posted works somewhat: all 3 meshes spawn but they all spawn at the same time. How do I get them to spawn at different times? Thanks!
Noooooooo!
Not only should you not want 2 Ticks, you should never want ANY Ticks.
Check out Timelines. These are what you use when you need a perpetual process. Why? They can be started and stopped at any time, meaning you can save processing when their corresponding functions aren’t needed.
Also, they’re AWESOME! You can set the length of the Timeline you create to anything, or you can set it to loop so it goes until it’s stopped. You can even create graphs and set specific times for new events to fire off within the Timeline editor and output those values from it! If that’s not enough, you can stop and start again where it left, start from the beginning, reverse it from the point it stopped, or do a pure reverse from the beginning. They’re incredibly useful.
Save your Tick for printing string values of input and stuff like that. Even when you’re testing new mechanics, though, use Timelines instead of Tick. It’ll be more frustrating to go back later and change your systems when you’re optimizing for performance. Do it now, learn it now, and build everything with solid foundations.
Trust me on this. We gained huge performance boosts by eliminating literally all instances of Tick and replacing them with event-triggered Timelines.
Here’s a link to the Timeline documentation:
1 Like
Sorry this is an old post, i know, but your spawning your actors off of event tick, and event tick uses only the one delay. if you want to get them to spawn at different times you need to have the event setup to spawn the character at a random time within your specified range three different times. Use a sequence on an event (like begin overlap on a trigger) that triggers the three events or the same event three times. The key being to generate the random number for the delay as many times as you want to spawn the demon.
Hope that makes sense.
While I agree with having control over Event Ticks is nice, and to be honest about it, it’s very easy to implement.
I cannot for the life of me figure out, how using a timeline, can be more efficient than using a “call” which is all a “Event Tick” is, it boils down to a scheduled call on a timed basis, if the time is missed, then the “next” scheduled time is given a priority boost. This is built into the infrastructure of the engine, and I can only imagine, it’s one of the most watched code flows in the whole system, because everything is going to derive from that. If Tick fails, the whole system fails (at least for that tick).
Your code, that is to be executed, per tick, or via a timeline (which I would imagine the timeline actually uses event tick processing, just putting a different message in the queue to execute) is going to be the same, and the amount of overhead, is going to be less with Tick Event, than having another system, in this case timeline, essentially running a timer for you, with the code path, flowing right back to the Tick Event processing, even though it won’t be calling the blueprint node of Event Tick.
It sounds to me like, what has really been done, using timeline, is to clean up your code, via a timeline, so that there is more “implied” knowledge of the “state” that the code is in, and what it should be done, via the timeline call.
Just some thoughts, but saying one shouldn’t use Event Tick, is something I cannot agree with.
You could also use a Sequence node that you connect to (the single) tick. It can execute multiple things one after the other. So you 't have to do ugly things like connecting them one after the other or using custom events, which will have the same effect as a simple sequence node.
From my experience, with any complex operations, Timelines offer more control and a performance increase. The latter of which was measured and confirmed. Obviously, wth a simple, independent operation, the difference is negligible and personal preference can take the win.
You sound knowledgeable. I’d like to know what your solution would be in a scenario where you need a complex tick-based operation, but only active based on certain events and criteria. Specifically, if you are needing to output values that correlate with the operation and stop/start it either during the point of its operation or reset it. While I say specifically, this is not an uncommon need by any means. Timelines seem like the obvious choice here, but I am eager to learn from what you have to say in order to develop a broader set of options for these scenarios.
While we use C++ when necessary, such as mobile online functionality or engine modifications, we prefer Blueprints when it offers a more concise construction and implementation.
Tick is for per frame operations, so everything you place there you are sure it will be applied for every frame. Problem with tick on blueprint is that blueprint is around 10 times slower, where variable changing in timelines are driven fully by native code, thats why you got preference boost on it and thats why it is recommend to move massive Tick to C++. Problem with Timeline is you can’t do proceduraly generated changes, but if you want to apply static predictible changes, timeline is indeed better in performance in blueprint, C++ it would not be a difference, in fact most actors and components got tick code,as physics need to be updated on every frame
Hello DC, and a pleasure to meet you,
From my viewpoint as an old system IBM 370 assembler (we never give up those things that forge us) programmer, this is how I see things, where nothing is complex, and yet everything is, it only depends on our point of view. With that said, any sufficiently complex system, is inherently less complex as we break it down into subunits/subsystems. So with this “attitude”…
I would probably approach your question and set up state machine(s). Where by when the Event Tick fired, it would immediately execute a “switch on int” node in the blueprint (i’m assuming this is the environment, and really makes no difference), by pulling the “int” from a queue of operations to be performed. If the queue is empty, then there is nothing to do, as the final step of the EG (Event Graph), I would have it toss into the “queue” (really just an array in blueprints), the state that on the next iteration, on the next Event Tick, would be to execute the “start” state of the machine, which would then be doing nothing more than examining the state of the entire machine, and queuing up the states, that needed to be done, at that moment. Because I would be attempting to keep each portion of the code as “dumb” as possible, and only doing that portion which it needed to do. If the “function/graph/whatever” needed more processing done, I would have it queue, the work to be done up, via placing a “state” into a queue, that would be executed on the iteration of the switch. Hence my Event graph would be as dumb as all get out, but taken from the global view the outcome would/could/maybe quite complex.
continued…
This gives us several advantages, we have one “switch” point instead of following spaghetti all over the place, building a “state machine” inherently makes us start considering all possibilities that can happen, it allows us to have a nice “trace” facility inside, as in the event graph we can examine the queue at entry, we can also trace as each “state” is taken from the queue, and then “dispatched” out via the switch. Each and every function can be kept very independent of the others, only calling directly another function, if it’s known that it has too, and still have the ability to place new states into the queue. We 't have some huge sequence, or a cascading series of IF (branch nodes) statements firing off, that we have to blunder through after the programmer that originally wrote it, and has left the company.It’s going to be fast, there is no way around it, that switch on int node, is going to boil down to nothing but a “switch” statement as defined by “C” if you will (which was in assembler, decades before K&R was released). It’s only going to access one node in order to determine what to do, the “get” from the array, immediately flowing into the “switch on int node”. Prior to executing the first “switch” we could queue our own “state” forcing the switch to fail, and fall out, at which point, we can exit the event graph, or if we wish we can look at the queue to see it’s depth, etc. This kind of processing could be done even with a timeline. To where when the time line fires, it would do nothing more than queue the states needed (so that the state machine could “remember”), thus allowing us to avoid “race” conditions, as we are forcing every thing to flow back to the event graph, and to be “single threaded” (granted, there is really no Nway threading in a blueprint, but there can be race conditions that will approximate problems that crop up with Nway threading).
continued…
we have also implemented a system, where by it’s easy to extend (define a new variable to be queued, of a new state, and we are in business),
there are other advantages as well, but no doubt you get what i’m getting at by this time.
Disadvantages:
Well it’s going to take longer to set up, why? Because a state machine will force us, to consider a lot of possibilities that can “potentially” occur, whether they occur in reality or not is something to consider by itself. Now some think this is a disadvantage, I have always considered it an advantage, because it does force the issue of considering, “what if”. If it’s proven that state cannot exist, etc. That’s good, we have considered it, found it’s not a issue, and moved on, others would say it’s a waste of time. In my life, this is not a waste of time, lol, because it will invariably come up, at some time. The programmer has to understand what a state machine is, but it’s not likely this is a disadvantage, as the programmer has to understand some kind of structure, so it may as well be a state machine (and in truth, cascading IF statements is nothing more than a state machine. each IF statement, is just a new conditional state). In truth I think it could be successfully argued that all programs are state machines, so again, i’m not sure this is a disadvantage, just depends on the readers point of view.
continued…
This is how I would approach it, adjusting what I was doing from the “philosophical level” which I’m writing from, to the practical level, when a design spec was in front of me (and of course arguing like hell in the meetings that produced the design spec! lol).
But what I am really after is, something very simple, something that will inherently exit out (hence no form of infinite loop can develop), and that if the producers of the “states” that are going into the queue, are thought to be causing an “infinite” loop can easily be monitored. I.E. Function X is called because of State A, and upon return from the function call, it is found that the only state in the queue, is a call to Function X again, which should be theoretically impossible, then we can easily short circuit, and not make the call, empty the queue, set it up for the next Event Tick, dump out debug information, etc. and continue on our merry way.
The idea’s conveyed in “object oriented” methodologies, are nothing more than the old Top down decomposition of a problem, into it’s most basic elements, and then having the compiler enforce it. Whether I call a function a function, or a method, whether I “hide” data or not, it’s just variables that are either used or not used by all functions/methods, etc. There’s no magic, it’s a computer, nothing more, nor less.
Anyway, just my thoughts!
As a side note, I used “int” for simplicity, actually it would be a structure that would be “queued up” in the array, so that all the state information that a subsequent function would need, could be saved, and then when the “structure” was dispatched in the event graph, the entire state could be passed to the function with one parameter, of which the structure, would have one variable, that would be the “int” for the switch statement. In this fashion, we can capture all the information we need, retain it, pass it to the interested functions, and off we go.
Good stuff man! Thanks for taking the time to explain your process. A little experimenting with that should certainly broaden my approaches. I appreciate the concept of dumbing every process down as much as possible. I also find your thinking on the idea of a state machine being more encompassing really interesting and an arguably valid perspective.
More than welcome sir. You may find this of interest, as I think it applies as well.
I was working at Monsanto, as a computer operator, teaching myself assembler in 1984, using PoP (IBM System 370 Principles of Operation). And was having a heck of a time, writing a program my boss had asked me to do. He took a look at the code, and said. your on the right track… and I looked at him, and went well gosh that’s HELPFULL!
lmao
He laughed and said, when your writing in assembler, you have to have discipline, and you remember this, “Think of programming in assembler, as building a house, and every instruction, is a unique kind of brick, that you can use any way you wish…”. Now build me a D*mn house, and stop taking so long! lol
but that analogy has stuck with me, and he was correct for assembler, BUT that simple analogy, can be applied to so darn many more things in computers than just 1 language.
Thank you for the conversation, enjoyed it, and have a great day!
what that function called
in the top pict…
i want to create Tick > for new 2 tick…
what the function??