For example, I have several plain "Always" conditions under different event groups for better readability. This is only a visual representation, and these won't actually be checked separately every step, right?
It's better practice, I suppose, to only have one "Always" event, but I wouldn't worry about having more. Sometimes it's and necessary, and it won't effect the performance.
There's nothing wrong with it - it's not going to make the slightest bit of difference to performance, and like you say, it makes code more readable (especially with the lame way the event list scrolls).
It's not really a big deal at all, especially for what OMC mentioned. Sometimes it's highly necessary for order of events. Just remember, the more events you have, the longer it takes for a whole loop to be processed. The amount of time reduced is beyond minuscule, however if you make a habit of having like 50+ duplicate events over the process of making a complex game, you're going to notice an unnecessary impact on slower systems.
Still not much at all, but an impact that wouldn't even be there if it weren't for those additional events.
It's actually good practice. These days, it's much better to have many lines of code that are easy to read, than tiny improvements in processing time. Especially with MMF! Programming languages are quite easy to read on the spot.. MMF's event system is easy to learn and compact, but can get tough to read, any small bit helps.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Advertisement
Post Reply
Edited by noahsummers
Order of events is a pain in the pastoogus.
