Bug in for each loop? r92

0 favourites
  • 12 posts
From the Asset Store
SynthWave Loop Pack includes 68 seamless loops, founded on 11 original melodies. For use in game and custom works.
  • Hi there,

    I seem to have hit a bug in r92 for the for each loop. My code is as shown below:

    <img src="http://valkyriegames.net/c2bugscreens/youapp_problem.png" border="0" />

    From the code I would have expected if I spawned another instance of the GiverUnit object that the new object would also move. This is not the case. Only the original object that was on the screen (the first object is not spawned with a system.spawn()).

    It appears that the line of code with GiverUnit.SetX is only setting the X for the original object.

    Any help would be much appreciated.



  • Please see how to report bugs. I'm afraid this is not enough information for me to comment on the problem at all. Can you share your .capx?

  • Hi Ashley,

    I'm hesitant to link the capx, but I can send it to you via email. Is there an email I can send it to?


  • : try to reproduce the issue in a new capx with the least elements (and just placeholder graphics) possible.

    It will allow to make sure it's a C2 bug and not an issue in your events/logic related to your project.

    Edit: Also you dont need the parent condition "on every tick", it's implicit.

  • Kyatric Okay I've reproduced the issue now with very little events. The capx is linked below. Thanks for coming to help, and the tip. Cheers!

    Download the capx here! Ashley

    Edit: Btw to spawn another instance of the object to see the bug, just click on the screen. Cheers!

  • Apparently, the faulty is the "For each GiverUnit" in event 2.

    If you disable it, all should work as intended.

    "For each" is implicit there, and checking "For each" and "For each interval" is kind of double function that cancels itself.

  • Hi Kyatric. Thanks for that! That helps heaps. But I don't quite understand why an explicit "for each" on line 2 would affect the logic in line 5 since it's on the same level, or why we should avoid an explicit "for each" if there already is an implicit "for each". Perhaps it's just a little inconsistency with construct 2, but certainly confusing! Thanks Kyatric!

    Oh one question though: Is the implicit "for each" always there? If so, why is there an explicit "for each" in construct 2? Thanks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hi again Ashley, Kyatric,

    Upon further testing, bounds checking to make sure the units don't fall off the sides of the screens don't seem to work. I'll attach the new capx at the bottom of this post once again. It appears that construct thinks I keep referring only to the original unit again (I commented out the "for each" on line 2 as Kyatric suggested). Also both commenting out and commenting in the explicit "for each" on line 5 doesn't seem to work.

    Download the new capx here!

    Any suggestions?

    Thanks again!

  • valkyriegames - that last .capx seems to work OK, what's wrong with it? Why not use the 'Bound to layout' behavior anyway?

    You should read How Events Work to understand how events normally work and why your use of 'For each' is probably redundant.

  • Ashley Thanks for taking your time to help me, it really is much appreciated! I completely forgot about the bound to layout behaviour so that helps heaps, but in relation to the .capx, as it is it actually doesn't work correctly. The bug can only be seen when you create a few instances of the object. Load the .capx and then click on the page about 10 times to create some instances. Then wait and watch. Eventually a few of the units will move off screen when they shouldn't. I read through the How Events Work sections carefully and it explains the way that events work in the way that I expected them to (edit: although by bad habit I use the explicit "for each" events on and off). Perhaps it is a bug?

    Thanks for your help once again!

  • When you mirror a sprite it's width becomes negative so you'd want to check

    GiverUnit.X - abs(GiverUnit.Width)/2 < 0.

  • Oh wow that's something I didn't know. Thanks ramones that's really helpful. That solves the mystery! I guess I didn't know all the underlying implementation details. Thanks for that! It wasn't a bug after all. Cheers!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)