Question about picking instances C2 R47-2

0 favourites
  • 13 posts
From the Asset Store
Pick Up Items Sound effects for your game, Take them for a ride right now and you will worry no more.
  • Hi,

    I wanted to know more about the picking methodology for Construct2.

    In CC I used to keep an instance variable "index" that I could use for "picking by comparison".

    C2 seems "only" to offer the "pick by Nth instance".

    My trouble is how do I get to find what N is an instance ?

    .capx

    In this .capx I'm trying to have a main sprite being covered by another sprite (colored sprite).

    So each frame, I position the colored sprite over the main one. To do this I used a "for each" main sprite loop and to pick the nth instance of colored sprite, I refer to loopindex.

    This seems to work to some extent. (both sprites move along nicely)

    My trouble is when a pair of sprites is destroyed (main and color when they get out of the layout).

    I still use a "loopindex" reference, but that seems quite ackward.

    Plus, when a pair is destroyed, I create a new pair of sprites (main with a new color).

    Nevertheless it seems that some other pairs already on the screen gets affected by the color changing (like if the "for each main sprite" loop executed the code color changing).

    Is there a more elegant way to pick a single instance based on an index or a value we gave it to be identified ?

    What am I missing there ?

    I searched on the forum for answers, but I didn't find much about picking in C2.

    The "for each" and loopindex does the work when I need to apply actions "massively" (on each instances) but so far for picking a peculiar instance I'm lost and haven't found a nice way yet.

    Thanks in advance for any answer.

  • Picking in C2 generally works just like CC. Your problem seems to be you're just missing the "pick by comparison" condition. That's no worry - it's pretty much identical to "For each" followed by "Compare values". For example:

    Pick by comparison Sprite.X + Sprite.Y < 100

    -> some actions

    is essentially the same as

    For each Sprite

    Compare values: Sprite.X + Sprite.Y < 100

    -> some actions

    Just a heads up - if you ever can, it's much better to make a blank .capx file showing the problem with as few objects and events as possible. Your project probably makes sense to you, which is fine, but it's very difficult and time consuming to get to grips with an entire problem just to end up looking at one small problem! Thanks.

  • Capx with only the relevant objects and actions as well as comments in english

    I've tried your solution Ash, which seems ok since the debug part works (telling me the informations about the sprite RunnerZ or Couleur I click, and its associated sprite's informations too).

    Nevertheless, I'm still having differences between expected and actual results.

    So, on creation of a Runnerz sprite, followed in the same block by the creation of a Couleur sprite, I'm now having the color determined as a Runnerz's variable, and then applied to Couleur (the value of Runnerz.Color correspond with an animation frame of Couleur).

    As in CC, I expect the newly created sprite (and only this one) to get "picked" to have the new values set (index and color).

    But still, it looks like on creation of new sprites, all the instances are ran through, all the instances seems reseted to a new color (as long as the creation process is going on).

    Also, I seem to get more Couleur sprite created then I need. This can be worked around/tidied too, but honestly, I don't see in my code where it is made able/asked to the soft to act in such way.

    To make this issue more visible I removed the effect on the sprite Couleur. The problematic sprites stand on the left side of the screen (not moving, because having no Runnerz sprite to be "set position to")

    At each creation I only expect one object Runnerz and one object Couleur "associated". How come I get (far) more Couleur than Runnerz ?

    Is it in my code ? Is it an issue in my FireFox ? In C2 ?

    Any response/evaluation will be appreciated.

  • Are the two sprites created in the same event ? If so, I guess it's a bug... otherwise, I'd need to take a look at yours events, but I don't have C2 installed on this machine and the download link seems down <img src="smileys/smiley19.gif" border="0" align="middle" />

    Maybe you can post some screenshot of your event sheet ?

    By the way, I'm french too, albeit Canadian. Feel free to PM me in french ! <img src="smileys/smiley2.gif" border="0" align="middle" />

  • Link to 0.i.capx

    Link to the screenshot of the event sheet (little screens warning)

    Yes the two sprites are created in the same event (first block "System compare two value -> Runnerz.count <= 14)

    The download link appears fine to me, maybe you have some blocking on urls linking to box.net ?

    EDIT: If so you won't be able to access the screenshot so here it is hosted on imageshack:

    Uploaded with ImageShack.us

  • Your two bugs come probably the same source. However, I fail to see why it does as you described.

    If you disable everything but the the creation and the debug, are the counts still off ? Are the sprites correctly associated ?

  • If I disable moving and destruction of the paired sprites, the cycle can't work (as Runnerz.Count stays equal to 14 constantly no destruction so no new creaction hence no issue, but still my app is not doing what I want = Runnerz moving horizontaly on the screen, disappearing when leaving the screen on the right, reappearing on the left).

    I guess I could make it work otherwise (using only the 15 runnerz created and repositionning them instead of destroy/create new ones).

    Yet it wouldn't help knowing where is the issue in the current code.

  • You still seem a little confused about how these events work. Most of your events are redundant. I made some changes, try this project. You're just trying to match a Color object with a random frame for each Runnerz, right?

    Remember ordinary events have a for-each built in to them. The event:

    Every tick

    -> Set runner X to runner.X + 1

    is run by C2 like this:

    Every tick

    -> For each runner instance: set X to self.X + 1

    See there's no need for a 'for each' condition - 'every tick' does the job fine.

    Conditions also have a built in for each. The event:

    Runner: X < 400

    -> Set runner X to runner.X + 1

    is actually run by C2 like this:

    For each runner: if X < 400, remember this instance

    -> For each remembered instance (all of the ones with X < 400): set X to Self.X + 1

    You only ever need 'For each' when this built-in behavior isn't enough. One of those rare situations is when you're using the "Compare values" condition, because it does not pick anything for you. For example:

    + Compare values: Runner.X < 400

    -> Set runner X to runner.X + 1

    C2 runs the event like this:

    Evaluate Runner.X. I'll just grab the first one because I don't know which one to use. Is Runner.X < 400? Yes. (note no objects have been remembered)

    -> For each runner instance: (I haven't remembered any, so I'll run on all of them) Set Runner X to Runner.X + 1

    Despite the event, all the runners move right. You could add a for-each to fix it - but it would be better just to use the "Compare X" condition!

    Finally, to pair up objects, a neat trick is just to use

    Every tick

    -> Set colour position to (runner.X, runner.Y)

    This pairs each colour with a runner. This is because C2 runs the event like this:

    Every tick

    -> For each colour instance: find a runner object paired with me. Now set my position to that X and Y.

    This doesn't work with the 'set position to object' action! That's a bug, I'll see if I can fix for the next build.

    In short, C2 is trying to do for-eaches and pairing everywhere for you. You just need to know how it works under the hood to take advantage. Hopefully the .capx above helps!

    The containers system in Classic also fixes this issue, because it forces instance pairing. Destroying the objects is a bit of a hack in my example, but I guess it works. I'll add unique IDs (UIDs) for the next build - that enables another workaround.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • How does the pairing works ? If you just set up an event with "Set object1 position to (object2.X, object2.Y)", every instance of object1 and object2 are going share the same position in pairs ? What happens if the count of object1 and object2 are not the same ?

    Maybe if I could check the capx it would help, but like I said, the download link for C2 seems down !

  • You still seem a little confused about how these events work. Most of your events are redundant. I made some changes, try this project. You're just trying to match a Color object with a random frame for each Runnerz, right?

    Remember ordinary events have a for-each built in to them. The event:

    Every tick

    -> Set runner X to runner.X + 1

    is run by C2 like this:

    Every tick

    -> For each runner instance: set X to self.X + 1

    See there's no need for a 'for each' condition - 'every tick' does the job fine.

    Conditions also have a built in for each. The event:

    Runner: X < 400

    -> Set runner X to runner.X + 1

    is actually run by C2 like this:

    For each runner: if X < 400, remember this instance

    -> For each remembered instance (all of the ones with X < 400): set X to Self.X + 1

    You only ever need 'For each' when this built-in behavior isn't enough. One of those rare situations is when you're using the "Compare values" condition, because it does not pick anything for you. For example:

    + Compare values: Runner.X < 400

    -> Set runner X to runner.X + 1

    C2 runs the event like this:

    Evaluate Runner.X. I'll just grab the first one because I don't know which one to use. Is Runner.X < 400? Yes. (note no objects have been remembered)

    -> For each runner instance: (I haven't remembered any, so I'll run on all of them) Set Runner X to Runner.X + 1

    Despite the event, all the runners move right. You could add a for-each to fix it - but it would be better just to use the "Compare X" condition!

    Finally, to pair up objects, a neat trick is just to use

    Every tick

    -> Set colour position to (runner.X, runner.Y)

    This pairs each colour with a runner. This is because C2 runs the event like this:

    Every tick

    -> For each colour instance: find a runner object paired with me. Now set my position to that X and Y.

    This doesn't work with the 'set position to object' action! That's a bug, I'll see if I can fix for the next build.

    In short, C2 is trying to do for-eaches and pairing everywhere for you. You just need to know how it works under the hood to take advantage. Hopefully the .capx above helps!

    The containers system in Classic also fixes this issue, because it forces instance pairing. Destroying the objects is a bit of a hack in my example, but I guess it works. I'll add unique IDs (UIDs) for the next build - that enables another workaround.

    Wow, C2 is even more powerful than I thought.

    Ashley you got it all covered. I will need to read this a couple more times, but this explanation + the capx should do the trick.

    That's what I needed, an update to the way C2 works.

    Thanks for the enlightment. :)

    EDIT: Magistross: http://www.scirra.com/construct2/releases/r47.2

    Does not work for you ?

    or http://www.scirra.com/downloads/releases/construct2-r47-2.exe

    Direct link to the executable (hoping it is not messing with Tom's site)

  • That's weird, the page for the r47.2 release has the following download link on my end : http://www.scirra.com/downloads/construct2/construct2-r47-2-setup.exe

    Your direct link works just fine though !

    edit : It's fine now, I erased all my cache. The site was behaving very strangely too, don't know why the files weren't getting updated correctly in the cache...

  • Link whatever pages you want, don't worry about it! We want to get as many people downloading it as possible so feel free to distribute the direct link anywhere you want.

  • Tom regularly tweaks the site and I think recently fixed a bug in the latest release page, so there might be a few hiccups.

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