SoupOrWorm's Forum Posts

  • 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?

    Tagged:

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • > 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.

  • 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.

  • 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.

  • > 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.

  • 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.

    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.

  • You're probably on the right track for a way to do that. Basically, drawing to a 2d grid and then looping over it to find the edges.

    Your screenshotted events aren't working because you first pick one point, but you can't pick the second point when the first is already picked. A quick fix would be to add a "pick all point" condition after the finding if the point was blue.

    It seems to be working; Thank you! The only issue now is that it is insanely laggy. Any ideas on how to optimize this?

  • Ok so I got s'more progress. I tried writing the algorithm that places the line points, but it doesn't seem to be doing anything. I have a hunch that it is because of the "pick" command, because I don't really know how to use that. Please let me know if you see any potential bugs (the code runs when the player moves into a blue area, changing the point to red and thus updating the line. also, the bottom 2 lines are copy pasted and altered beneath the screenshot so it also checks and places above, below, and down, in theory at least.)

  • Update: I've been thinking about this for a while and I think that the best way would be to use loops to put a bunch of points on the screen and then use some sort of algorithem to check what color the point next to it is and create a "line point" between them if it is diffrent. Then, I draw lines (streched sprites) between the points.

    I need to implement the second half of that idea still but the first half is done.

  • This is pretty hard to explain but I am making a game that is loosely inspired by this animation:

    Subscribe to Construct videos now

    The part that I am concerned with right now is the quite literal front line. The main two parts of this that I need to figure out are #1 how do I make it so a sprite moving into it shifts that part of the line backwards? and #2 how can I make encirclement manuvers work (if the line intersects itself, it connects creating an encircled area in the process). Any ideas?