Hanging issue with nesting loops

Hi team,

So, I have a very, very annoying problem.

I'm working on the army builder section for my current wip, which involves a lot of loops, many of which are cozily nested within each other. In a nutshell, the player can select from a range of units, they get values written to an array, then a series of loops runs through the array and moves data to a different array, and extrapolates and writes some additional values based on what is present.

Blah blah blah.

My problem is occurring when I'm expanding all this data to what it needs to look like in the game. When I click the button to execute it all, the following loops happen;

On Mission Select button clicked:
-> Start Loop "2 Player Local Start"

On Loop "2 Player Local Start"
-> Start Loop P1 Army (X) (where x is equal to a value based on which army the player selected, at the moment always 1)

On Loop "P1 Army 1
-> Activate Group [Orderguard Loops] (container to hold all the loops)
-> Start Loop "Orderguard Prewrite" 1 time
-> Start Loop "Orderguard Division Write" 5 times
-> Start Loop "Orderguard Unit Write" 5 times
-> Start Loop "P1 Array Shift" 100 times
-> Start Loop "Orderguard Unit Populate" 100 times
-> Start Loop "Orderguard Mob Populate" 1 time
-> Start Loop "Orderguard Special/Upgrade" 1 time


Briefly; Prewrite runs 5 different loops 20 times, that writes values 1-5 through a column in the InGame array.
Division Write runs a loop 20 times (so, 5x20=100) that copies a value from Pregame array to InGame array.
Unit Write does the same thing, with each of the 20 loops also running an additional loop another 20 times (2000 loops total), copying a Unit ID and up to 20 upgrade option ID's from Pregame array to InGame array.
P1 Array Shift moves all the data in InGame array to the left, occupying all the blank columns (100 loops, with each loop potentially running up to 99 times (10,000 loops)).
Orderguard Unit Populate runs 100x, writing values to the InGame array based on Unit ID's
Orderguard Mob Populate runs a loop 100x, which in turn runs a loop 20x, each of which runs another loop (4000 loops), writing values to cells based on the Loadout IDs already written in the Unit Write loops.
Orderguard Special/Upgrade runs loops that picks up other values prewritten in Unit Write, writing values to the InGame array using the same loop logic as Mob Populate.


Soooooooo. It was all working fine, until I was writing the 10th upgrade loop. Suddenly everything started hanging when I'd click the initial button to the start the loop, so, working backwards, I tried to figure out what I did that broke the loop logic. Everything looked fine. I then ran the Orderguard Special/Upgrade loop 0 times, trying to revert back to where it still worked, but alas, no luck, it still hangs.
Deleted the Orderguard Special/Upgrade loop, and all the conditions related, and it worked.
Started writing the Upgrade loops again, and it hangs again. Now, even after deleting the loops and the events pertaining to Special/Upgrade, it hangs, despite none of the seemingly problematic loops or events existing anymore. Fortunately I have a backup, so everything up to the Special/Upgrade section is working, but I'm afraid if I start adding more loops it will weirdly corrupt again.


TL:DR (skim the above paragraph hah)
So, is this a known bug? I had thought maybe I'm trying to do too much in a single frame, or giving the program too many loops to cycle through to fire the right one, but it was working fine until suddenly it didn't when I added a certain event, and it just seems odd that even deleting these events still causes the program to hang when I click the Mission Select button to fire it all.

Sorry the wall-o-text, but any idea where to start investigating this would be appreciated.

Is most of the in a single event? You may need to break it up into multiple smaller events.

I don't think it has anything to do with the amount of loops it's running. Mostly because even when I cut back on the number, it still hangs, and it was working perfectly prior to that. Also, I went back, added a different event to fire the next loop sequence, and it still hangs.

Hrmm...

So, looking at the loop sequence, we are potentially this deep in nesting;

2 Player Local -> P1 Army Set -> P1 Set 1 -> Orderguard Mob Populate -> Orderguard Mob Populate Pt2 -> Orderguard Mob Populate Pt3 -> Orderguard Mob Populate Pt4 ( value ) -> Orderguard Veteran Rifleman with Beamer


8 levels of nesting. It seems extreme, looking at it like that, but as I mentioned, it was working until I started the next section, which itself was working up until a certain loop, and then the whole thing seemed to become corrupted.

Attachment 22920Attachment 22921

For clarification. Adding the last loop now makes the whole program hang when the button is clicked. Going back and deleting that last loop will not restore the frame to working order either.

https://www.dropbox.com/s/jgnyrq9ehd...e2017.mfa?dl=0

Dropbox link to the file. I don't expect anyone to comb through the MFA, but I get really inconsistent results when simply running the mfa.

My basic testing runthrough is -> 2 Player Local, Select Army Orderguard, Add Division, Infantry Battalion, double click done. 2nd player, again select army Orderguard, infantry battalion, double click done. This brings up the mission select screen, of which there's only one option, and clicking that button is what triggers the good stuff.

Now, sometimes this will work, sometimes this will hang. Does this inconsistency point to a resource bottleneck? Because if nothing changes from one runthrough to the next, then it's clearly the environment that it's running in, right?

Would really appreciate a couple of people clicking through the army select screen and telling me results of if/when it hangs, and the options they went with.

About to put a boot through the screen, that's for sure.

It would take some time to go through it all. When I added 2 divisions on a 2 player game it just hung. It didn't crash instantly (which would indicate that its stuck in an infinite loop) so suspect it just running too many loops.

I'd recommend adding to the loop events adding to a value so that you can see how many loops get run. When you get into 10's of thousands of loops it will become extremely slow.

I would also recommend looking over all of the loops to see if you can simplify them. For example The "Orderguard Pre-Write X" loops. Five loops Each run 20 times and update a value located at current X array position. Maybe just have ""Orderguard Pre-Write" run 20 times and have 5 actions in the event and have them set the value based index rather than current position. The index can be set using the loop index: X : Index/Index + 20/Index + 40/Index + 60/Index + 80.

So if you are able to write the data you need in an already running loop I'd try to do that instead of running another loop.

Was going to suggest the same as danworth, this is one hell of a looping app! XD
700 lines of nested loops - one of the most inextricable hard to debug mfas ever seen
(that goes as a compliment to your dedication and mind sharpness in keeping track of everything, of course :))

No chance you could simplify some of the tasks?

So, mainly posting to report 1 crash and 4 safe runs
(at least 2 of the safe had same options picked as the 1 crashing,
the 1 crashing was the first run)

and a little suggestion that could help debugging,
in addition to the total loopcount suggested by danworth,
you could also add a list object (with "scroll to new line" ticked) and "add line" with loop name for every loop fired,
so the last one you'll see in the list, should be the one actually crashing
(it indeed gives the impression of a too-many-fastloops crash, but who knows..)

If the final loop is always the same, *might* indicate something specific to that loop,
otherwise, it could likely be the total number being too high

Great suggestions, both of you, and thanks for taking a look, I really appreciate it.

I'm leaning toward total loops being too high, based on gut feeling and the fact that it sometimes works, and sometimes doesn't. I'm going to try splitting the main event trigger so that the loops (IE Pre-Write, Unit Populate, Mob Populate etc) are run off a counter/value, which will increment upwards at the close of each loop set. So each loop will run to conclusion before starting the next loop, and it won't be as intense as trying to run them all in the same tick. Also going to put some debug options in with having values added per loop so I can keep track of what's happening - this wasn't needed when it was all working fine though hah!

Also, you are both correct in that it could be simplified a bit. This is not 'elegant' coding, but very procedural and step-by-step. I went for simple and brute force rather than tricky and intricate, because with something this large and modular I didn't want to confuse myself overly. As it stands, this is pretty simple to follow for myself, though I can definitely see someone else looking at this and completely freaking out haha.

Appreciate the eyes, both of you! Will hopefully get some time later today between shifts and be able to split the trigger event and see how that turns out. Will update.

So, did what I was going to do, and instead of one trigger event launching all the different loop sequences, each loop sequence is now separated into it's own event, triggered when two counters equal certain values, one of which increments at the close of the previous loop sequence.

Working flawlessly.

Much appreciated again, chaps!

Semi-related question;

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?

This usually cause very little overhead,
I think it's more likely the things you "do" on loop are the issue

...but it's just speculation, so maybe you can try and see,
if deactivating some of the biggest loops before/after run makes any difference?

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.

Perhaps both.

SO.

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.

Proudbarrassed.

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.