Printable View
I've been using "On Each Loop"s, to multiple instances of a enemy, to stop one even affecting all the instances of it. I've used it, so that when the enemy lands on the ground, the one that is hitting the ground stops and not the ones in the air. I know that "Fast Loops" can cause your game to strain, but I was wondering if the same applies to "On Each Loop"s?
Thanks!
Many of them, or lots in complex situations can, but it usually takes considerably more foreach loops to cause a notice-able slowdown than it does fastloops. You shouldn't have to worry about them, I think.
I noticed/tested a couple things,
and recall hints by Snail, ProdigyX and other forum members,
that may be worth mentioning:
-scoping a Foreach already on launch wil scope down inspected objects already (this will save Fusion from iterate through the same objects again onloop)
-always>foreaching becomes a bad practice when additional different loops are performed on the same objects
-^ following from above, better stuff most actions you can, for the same objects, in the same "on each one of" condition
-scope down the loop at best you can, and always put the most "scoping" filters in higher places on the conditions list
As for speed, it may also significantly depend on the use you do,
if you iterate through objects, foreach will generally do a better job.
(this is all worth inspecting/tweaking in a crowded situation with many actions performed onloop, otherwise just leave it go XD)
Thanks for the answers! I'll make sure to use them sparingly, and try to avoid using them in an "Always" event.
Just as a clarification,
(from what I can tell with own testing)
always - foreach is not a bad practice on its own (I'm myself an always-foreach addicted XD)
it becomes dangerous when you perform more of these on the same objects
i.e.
always --> count - foreach one of "glue", loop name "stick"
always --> count - foreach one of "glue", loop name "drop"
always --> count - foreach one of "glue", loop name "sink"
Thanks for clearing that up Schro. That's definitely a good bit of knowledge to have whilst using them :)
For this kind of testing I highly recommend that you use behaviours. Applying logic through behaviours allows you to test each individual instance of an object in isolation, automatically, simply by attaching the events you need as a behaviour. Fusion then automatically filters these down so that they apply to only the objects affected by your conditions on the behaviours.
These are one of Fusions least well understood tools but can offer an enormous amount of power and flexibility without bogging the main event loop down with lots of for...each or fast loops.
Simon: It is too bad the interface for behaviors is so unfriendly. Otherwise they might be more popular and useful. It also doesn't help that you have to change your coding logic to deal with them at the end of the event loop, something I find very tricky to deal with.
Using logic from the top event in this screenshot, the spawner (the default triangle) should begin adding to it's spawn timer when none of the 3 objects are overlapping it. However when one instance of the object meets those conditions, nothing happens. That event will only work if all instances of the spawner don't have any objects over them. Could you tell me why this might be the case?Quote:
Originally Posted by Simon
Attachment 17795
Can you elaborate on your thoughts about the interface? How is it unfriendly in your opinion?Quote:
Originally Posted by mobichan
Also could you elaborate on what you mean about changing coding logic, perhaps with a simple written out example?
Are these events in the main event loop, or in a behaviour?Quote:
Originally Posted by Enchantainment
Possibly one of the biggest problems with using behaviors is the lack of qualifiers (I understand the cause of that, but it's a reason most people don't use them (as far as I know)). If they were to be available in behaviors, then they could potentially be a lot more useful (though I understand that may be unlikely to be implemented).
Oh, they also can make it hard to tell what events are in what objects (especially when somebody has a problem, they upload their MFA file (or an MFA file to demonstrate the issue), and all their code is in behaviors, and there's exactly ONE line of code that is causing the problem, and it's in an object that is seemingly unrelated to the issue), which is the other (or at least one other) reason most people don't use them (as far as I know).
I unfortunately can't think of much of a solution to the second problem I mentioned, either, other than maybe being able to view code from behaviors in the event editor (e.g. viewing the events the way CF2.5 views them, though also with some kind of indicator to say what lines of code are from what behaviors (huh, that could also be used to solve the issue of being unable to control the order of events with behaviors, come to think of it, as long as the user can then re-organize the code from within the event editor in addition to viewing/editing it, and, if a similar thing were to be done for global events, then that could solve some of the problems that global events have as well)), and I understand how difficult that would probably be to implement, it's just the best I can think of.
Sure, behaviors can have their uses, but sadly those uses are few and far between because of the flaws they have (even if, from a coding perspective, those flaws are quite possibly very hard to fix, and I can therefore at least understand why they have the issues that they have).
I can't speak for mobichan's thoughts on the matter of behaviors having an "unfriendly interface", but those are my own thoughts on the matter.
Sure. :) Basically, you need to work in a separate event list that doesn't allow you to see your main event list at the same time. This makes it tedious to go back and forth and see how the main game logic interacts with the behavior's logic. Also, Alterable Values use generic names (unless this changed) for qualifiers in the behavior editor. And it is not very obvious which objects even have behaviors without individually clicking them and checking their properties.
As for code logic, if you need (for example) enemies to interact with main game code in the middle of the event list, it is kind of hard to do so. My initial thought is to toggle a flag on the enemies that are effected by the main event list and then they are managed when the list is finished processing based on who's flag is toggled. But say you have logic that requires the player interaction an with enemy to run a loop that has to check a number of things in the game environment. If that loop is run at the end of the event list, then the check might fail on other objects that are updated first in the main event loop. This also causes you to make all objects with any interactions use behaviors, which causes a lot of complexity when trying to follow your code logic and debug later. Also, the order of object behavior processing is not editable (at least it used to be based on order of object creation in the editor... sigh) so trying to get any complexity between objects becomes unnecessarily complex, IMO. And finally, you can't use the Event List Editor in a behavior. T_T
I don't mean to be too harsh, but behaviors sound good in theory yet falls short in practice. I feel like this is too ingrained in MMF to be fixable, but I have hopes for it in CF3. :)
EDIT: happytreefrog's thoughts are spot on as well. Well said. :)
OK there are a couple of corrections to make here on stuff you guys said:
Behaviours can access the values of objects by name now, this was fixed a while back now.
You can view both main events and behaviours at the same time (shift click on one of the editor buttons to open a new window view)
You can see these demonstrated in the image below:
Attachment 17796
Behaviours do not support qualifiers, that is true. I personally do not use qualifiers very much, although they can be handy at times.
It's hard to comment on your example without something concrete to actually look at, but behaviours are not so much lacking as just a different way of thinking about how to code your logic in Fusion. Yes it may require more objects to contain behaviours but that is a different way of working, not a failure of behaviours. As for where they come in the event loop, this is about designing the timing of things as much as anything else. You are also able to activate a fastloop which is contained solely within behaviours (or both in main events and behaviours), on demand, which runs those behaviours when required, but as behaviours - with careful triggering of such loops so as not to overburden the main event loop with them, this can be as powerful as calling a programmed function in a traditional programming language.
As regards behaviours being difficult to see when someone is helping you or whatever, whilst they are obviously another level away from the main even loop, it only requires you to say "objects x, y, z have behaviours" - I think that is a familiarity thing more than anything else, but I liken it to having code in an external library or extension in a way.
I should have said "falls short in practice for the way I have learned to use Fusion over the years". I have seen people do amazing things with and without behaviors, but I honestly couldn't follow the behavior logic easily and never got the hang of them. As with MMF in general, there are lots of quirky rules you run into and behaviors just added more quirks to have to remember for my taste. I noticed you didn't mention the Event List Editor being unsupported and that is my number 1 reason to not use the feature. I just can't go back to doing anything in MMF in the Event Editor.
To each their own, but I hope there is more user testing on MMF3's "behavior" functionality before it is set in stone. I feel like lots of things could have been improved with behaviors to make them easier to use.
I primarily use the event editor myself, I guess I just have a good memory for where things are when I am programming and like the more overview nature of the event ticks, so that doesn't really cause me any issue. Horses for courses there!
There won't necessarily be behaviours in F3, at least not how you're thinking of them. I can't say more than this, but rest assured that things are handled in a better way there anyway.
The events in the screenshot are in the main event loop.
The left side is the event editor, the right side is a behaviour event editor for the green active object.
That was in response to the screenshot I posted, asking about why my duplicate instances aren't behaving individually :P
Ah I see. Try to use the quote function where possible, it helps to keep a thread readable :)
I tried to quote, but for some reason, certain posts don't have a "Reply with quote" option on them.