I can't help you with the array, but there is an addon that does the same on a tilemap.

https://www.construct.net/en/make-games/addons/252/tilemap-flood-fill

Tilemaps are essentially 2D arrays. So you can copy array values on a tilemap, flood fill it, then copy back to the array. Since this is for a jam, it could be a quick and easy solution.

I think I saw that addon before but never concidered that I could use it for my project; I'll try it out. Thanks for the tip!

I think you are thinking about this the wrong way, because collisions won't take place in the middle of the loop, they either happen before or after, so you won't be able to stop the loop mid way.

I think you want to do a few things:

1. When a collision happens, stop all the tweens. This should stop all movement that is taking place.
2. Check there is a collision before even starting the loop, if there is don't even start.

It's very hard to figure out what is happening from looking at a screen shot, but I have a feeling that your continue variable doesn't have the value you want it to have, so every time the loop starts, new tweens are created.

Just trying to help from glancing at the screen shot of your events, so don't take everything I write too seriously :)

I found my own solution by calling a function repeatedly instead; Thanks for the help though!

Just realised what you are trying to do, I don't think that will ever work.

If I understand correctly continue will be set to false when a tween finishes, but the for loop will always end before any of those tweens are completed.

Perhaps it would be better for you to explain what you are trying to do before anyone can help.

Ah, I see. As I said above I am basically trying to do collision detection for the RedUnits so if they overlap they stop moving down a path (a series of Marker sprites). Right now I am using Tween for said movement. I don't think I can share the file to the project right now, but I should be able to in a few hours if necessary.

It's hard to tell what is going on from the screenshot, what is setting the continue variable to false?

Thanks for the response. It is set false when the RedUnit's isPaused bool is true, which happens when RedUnit collides with another RedUnit.

That's my main goal: make the loop stop when RedUnit collides with another.

I know that this seems like a pretty easy task, and I thought it would be too, but for some reason no matter what I do, the loop keeps running. Stop Loop action? Nothing. Pause movement behavior? Nothing. Disable movement behavior? Well, it works temporarily but reenabling it shows that the loop continued in the background. Destroy player? Nothing. Burn it all down and close the browser? for some reason, nothing.

It's actually a bit funny just how much the loop is resistant to being stopped, but I really need it to be stopped for the sake of the project. Any suggestions?

Changing the timescale wouldn’t do anything about making it run faster, and ideally you wouldn’t use any waits. Wait 0 is a handwavy way to address a quirk with the picking system related to when stuff is actually destroyed or when created objects are generally pickable. It’s not that it takes time to happen, it’s more that the objects are actually added/removed from the object lists in between top level events (events that aren’t sub events of anything).

Anyways another benefit of using an array is you avoid all the nuance when dealing with picking.

Yeah it actually makes sense that it's a picking problem. I don't see another way around this so I suppose now I have to use the array method.

> I just mean instead of creating all those sprites in grid positions and then picking them later, you could just set values in a 2d array and be able to access grids directly without picking. Its main con is it’s less visual than using sprites.

> Other than that the general logic should be the same. Updating only the parts that change instead of the whole thing is a decent idea to make it perform better.

> I don’t have much input about what may be amiss with your event logic though. It’s kind of a more hands on thing and I presently don’t have a whole lot of time for that.

I see... thanks for the response! Edit: after looking into it more it doesn't seem to be a performance issue anyway. I think my code is just busted.

Hmmm... okay, so the issue seems to be caused by multiple things:

1) I had it wait a seemingly insignificant time before calling the DrawLine function, but forgot that I set the time scale way lower since then. Making it wait 0 seconds makes the stuttering problem way better.

2) It actually does seem to partially be a performance thing. Lowering the time scale more helps a bit, but still doesn't completely eradicate the issue.

By now it doesn't seem to miss any points, but it can still stutter for a second. Good enough I suppose.

You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

https://www.dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p?rlkey=x69nftupmwepk22idoycmf8vj&st=uhxgwm1i

That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

Ok so it works and runs great now with only 1 unit attacking, but with multiple attacking at once it seems to glitch out a bit and not show them properly. I can only think of 2 reasons for this; Either running the function twice at once is problem for some reason or it is a performance thing. Assuming it is the latter, do you mind elaborating a bit on your array idea, (assuming it is compatible with my update box technique) R0J0hound?

Well, I found a fix. Let us never speak of this again.

Now to write an algorithm to connect the dots...

> > You could do it with an array. That would avoid the overhead of picking. Beyond that you could do it with js to be a bit faster. Finally, you could do it with a few effects which is faster still:

> > dropbox.com/scl/fi/ircvqkuu0p86ako11h34u/frontline_w_effects.c3p

> >

> > That works great as purely a visual. If you wanted to access those edges you'll probably need to do one of the other methods.

>

> Thanks for the tips. I might try some of those out too, but I just found another way as well; I just pinned a box to the player and used some code and parameters to only update the frontline in that box. It's a huge improvment already.

>

>

>

>

>

>

It seems that this optimisation causes a bunch of points around the edge of the square to not appear properly. I'm not sure what could be causing that, but I'm working on a fix.

I still haven't found a solution to this. Could anyone help me out? I can upload the file if you need it.