codah's Forum Posts

  • Hi KYATRIC. The fix you suggest doesn't seem to fit with the explanation in that link. Could you help me to understand how this works. I have created a capx based on the OP's, reproduced here.

    [attachment=1:3lv3lwuv][/attachment:3lv3lwuv]

    Without the wait(0) at event 4, the log output is as follows, showing that only 9 sprites are destroyed (the 9 in the initial layout, and not the 10th created in the function).

    (9) created a sprite

    createObject()

    created a sprite

    destroyObject()

    (9) destroyed a sprite

    With the wait(0) the output is as follows:

    (9) created a sprite

    createObject()

    created a sprite

    destroyObject()

    (10) destroyed a sprite

    Which shows all 10 sprites being destroyed. However, we have not altered any events, just added a wait. This doesn't fit with the statement that newly created sprites are "... not picked ... until the end of the next top-level event".

    In the above case the 'next top-level event' after event 4 (in which the object is created--via function call) would be event 5.. which we do not reach between the two function calls. So the wait(0) is actually a 'yield' which allows the next tick to occur, and so running subsequent top-level events.

    Finally, if you agree with the above, then perhaps the wait(0) is actually a reasonable solution?

  • Have a variable that is set when all objects have been created and check for that in another event. Trying to sequence events in c2 is tricky and when using functions even more so. As you said, using a wait doesn't usually do what you want.

    And as previous poster mentioned you don't need for each there

  • Ha. I had to leave, good you have a solution.

  • I'm probably missing something, but how can any collisions ever happen when there's only one sprite on the layout?

    Edit: oh wow I thought it was a tiled background

  • Try the System:Once on true condition. However it will still not be exactly equal to 500.000000. You could have a range check 499.99 <= X <= 500.01 instead.

  • Yes for sure. I would also give the group a better name.

  • Why would you need to? Just store the selected character in a global variable then spawn that character when you go to your game layout (or via many other options).

  • Make a Group "functions". Drag the function under it as a 'sub event'. You can then enable and disable the group as you please with "System:Enable group".

  • You already asked the question and then ignored the 2 people who took the trouble to answer.

    https://www.scirra.com/forum/viewtopic.php?f=147&t=110871

  • I have no idea what that tutorial says, but if you read the drag-drop manual info and do some experimenting, you should be able to do this. I guess what it boils down to is dragging a sprite and dropping it on another sprite, then checking it was dropped onto the correct sprite. So, on the 'dropped' event, check which sprite the dropped object is overlapping (as one suggestion). Just break it down and try one part at a time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks will play with this a little. I wanted to have a collection of small puzzle type games in the one app (i.e. one game per layout) and with a menu to choose between the games (no problem just like choosing between levels or whatever) but if their orientation is different...

  • I did something similar once. When my Turret acquired a target, I would check if there was also line-of-sight.. if yes, then I would fire a bullet using 'spawn sprite', not 'Turret:On Shoot'. I'm sure I had a reason for doing it that way.. but maybe you could just put a line-of-sight check in the On Shoot event.

  • Just add 'line of sight' behaviour as well as Turret.

  • You cannot store an instance of an object (e.g. sprites) as with traditional OO languages (like have an array of them or something)... I believe there are third party plugins like 'instance bank' or something but I'm not sure if they do what you want. Usually the UID is stored, which can then be used to 'pick' the instance. But it's not the same thing.

    Bottom line is no, you're not thinking the C2 way yet

  • I fail to see, if you *need* to move 200 sprites onscreen, how groups could help.