Check out our new "Community Passport" Feature!
Just click the brand new Community Passport tab to register your serials and get easy access to all of the latest product downloads in one place.

We'd like to know about your workflow in Fusion!
Do you storyboard, work on visuals first? Maybe you focus on the code/logic right from the start - we'd love to know!CLICK HERE to take part in our poll/discussion when you have a moment!

If I have too many loops in open groups, could this relate to a crash?

I believe I've read somewhere that every time a loop is called, the program has to find said loop, which involves parsing through each loop written (and not in closed groups or whatever) and then executing the one that matches. So that being the case, would forcing the program to find the loop in an event list that contains hundreds or potentially over a thousand loops written become an overload/bottleneck for the program?

So bizarrely enough I can't replicate the crashes. All the upgrade loops are done, and all working with the array and everything, so no idea why it was crashing last night. I'm thinking it may have something to do with the fact that Chrome is a huge resource hog, so trying to run the MFA and a multi-tabbed Chrome browser at the same time might be too much for my little computer sometimes.

Or maybe, since I was half-asleep, I was doing something I stupid which I deleted before bed.

Lesson learned here; If running ~2000 loops from a single instance, don't!

I was getting a reliable hanging error if I was selecting too many upgrades on the units, due to the fact that the upgrade loops themselves can be quite complicated (in addition to writing a value to the array to represent the purchase, upgrades would also change some existing array values, resulting in a lot of work-per-loop in jumping all over the array and changing numbers). So instead of running 100 Upgrade loops from a single event, I broke it down to a system where it runs a single upgrade loop, iterates a counter, then runs the loop again, only stopping the system when it iterates a counter to 100.

And now, with the boring work done, I can boot into the actual game frame with zero pre-game overhead events clogging up my engine, with my array (ie army details for both players) pre-loaded, and just requiring some events to create player objects from the values given.

Exciting Friday night at the 4burner Manor!

Also, as an aside, I set up my array-writing system so well that by simply changing a single counter, the events work for both player 1 and 2. It in fact worked so well that I spent over an hour looking for a bug that didn't exist. Don't know whether to be proud or embarrassed. Probably both.

In my testing, closing off all fastloops into groups (thereby preventing Fusion wasting time searching through them all for the correct loop) actually made a huge difference. I can't remember specifics, but I gave the specifics of my test setup in the recent optimisation thread.

I wouldn't expect having lots of unhidden loops to cause a crash. But it could certainly cause a noticeable fps drop

Thanks Vol - I don't think it was the optimisation thread (which is very interesting, btw) in which I read about the looping search, but I do recall it was in one of your posts that I did initially read about it.

Regardless, it feels like best practice to close off groups that contain unused events/loops. I kinda gut-feeled onto that a while ago, but to have it confirmed is great. Especially when said groups could contain hundreds of events.