Creating Objects On destroyed upon Restarting Layout

0 favourites
  • 7 posts
From the Asset Store
Welcome! I-Spy (Hidden objects) is an educational puzzle that is more than just seek-and-find activities.
  • Problem Description

    ____ "On Destroyed" - Create Object, runs on "Restart Layout" because it destroys the object upon "Restarting Layout", causing "On Destroyed" to create the object in the new Layout, or restarted Layout. ____

    Attach a Capx

    ____ https://www.dropbox.com/s/jok0oh6zts45fgc/RestartLayout_Duplicatation_Bug.capx?dl=0____

    Description of Capx

    ____ Reproduces the bug "On destroyed", Spawn new object after restarting the layout. Obj Count shows that the new object is being created after restarting. ____

    Steps to Reproduce Bug

    • Click the "Restart" text.

    Observed Result

    ____ Restarting the layout, creates a new object from the "On destroyed", "Spawn Object" condition/action after restarting. ____

    Expected Result

    ____ "On Destroyed" - Create Object does not run upon restart layout. ____

    Affected Browsers

    • Chrome: (YES/NO)
    • FireFox: (YES/NO)
    • Internet Explorer: (YES/NO)

    Operating System and Service Pack

    ____ Win 7 Pro ____

    Construct 2 Version ID

    ____ 200 ____

  • On a side note, we fixed this problem by using a Function "DestroyGarbage" before running "Restart Layout", which destroys all our objects. The problem looks to be that the event sheet runs one last time through the code which it should most likely just stop everything and restart.

    That or a Destroy all needs to be implemented BEFORE the Restart Layout fires, not after. Anyways thank you for your hard work Ashley, and Construct! Thank you.

  • Closing as by design: restarting a layout first destroys everything on the layout, and naturally that creates anything you create in "On destroyed". What should happen if you create an object half way through destroying everything because the layout is ending is a question with no clear answer in IMO, and the C2 engine happens to leave them there for the next layout which I think is reasonable. If it went back and destroyed the newly created objects too, it could easily end up hanging, because it could get stuck in an infinite loop as the new objects are destroyed, which creates new objects, which are destroyed, which creates new objects...

    Workaround: set a "don't create objects" flag just before restarting the layout, and don't create anything if that flag is set.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • So, that would only be a problem if someone was creating the same Object A upon "On Destroy" of Object A.

    ie, "On destroyed" (Object A) - Create Object A.

    Where as I am saying, "On Destroyed" ( Object A) - Create Object B.

    Object B does not have an "On Destroy" - "Create" condition/action, there for it would not be stuck in an infinite loop. More over why does the event sheet scan through everything on Restart Layout? Would that not fix it, if it were to say, do not run the entire event sheet one last tick rather just run the "Restart" function?

    Thank you for your patience, trying to wrap my head around this, anyways thank you again, and for the workaround.

  • Actually, if this is only an implication of an object creating itself upon destruction, could it not be fixed by disabled the action "Create"/"Spawn" when it is an object creating itself by checking for objects that create themselves after destruction before Restarting?

    ie, Disable "Create object" when it is an action of the condition "On Destroyed" only when its creating the same object.

  • Closing as by design: restarting a layout first destroys everything on the layout, and naturally that creates anything you create in "On destroyed". What should happen if you create an object half way through destroying everything because the layout is ending is a question with no clear answer in IMO, and the C2 engine happens to leave them there for the next layout which I think is reasonable. If it went back and destroyed the newly created objects too, it could easily end up hanging, because it could get stuck in an infinite loop as the new objects are destroyed, which creates new objects, which are destroyed, which creates new objects...

    Workaround: set a "don't create objects" flag just before restarting the layout, and don't create anything if that flag is set.

    Hi Ashley,

    Thanks for your constant presence on the forum.

    I hope I can change your mind on something, or at least begin a dialogue about it.

    I think we're all stuck in this mindset where the only possible way to remove an object is to 'destroy' it. The problem here is that 'destroy' comes with the option to have conditions of "on destroyed" triggers.

    This is great, but obviously becomes problematic when going to a new layout. I think destroying all objects on layout change is a mistake, and a new term should be invented within Construct 2. The term should be "remove". Add a "remove" feature to Construct 2 and don't give users the option to have "on remove" triggers.

    Remove should be the same as 'destroy' but now it simply removes or deletes the object instead of destroying the object, which can lead to unintended consequences on layout change.

    Once a "remove" feature is put into place, then make C2 "remove all objects" upon layout change, instead of "destroy all objects."

    --

    I think this is important because errors can occur with the current set-up. For example, if you have a chain of on-destroy triggers, and you do two consecutive layout change with different layer quantities or set-ups, an error will occur and functional gameplay will cease.

    Example:

    1. On BigShip destroy, spawn two ShipHusk.

    2. On ShipHusk destroy, spawn Rubble.

    Layout 1 has 7 layers, Layout 2 has 1 layer, Layout 3 has 7 layers.

    Change from layout 1 to layout 2, Bigship is destroyed, two ShipHusk are created on Layout 2.

    Change to layout 3, the two ShipHusk are destroyed and Rubble is created on Layout 3-- but it's not sure what layer to put it on, resulting in an error.

    Yes, this can be worked around by adding a variable to all On Destroy triggers. But that means you're asking users to use a workaround for something you won't consider a bug. What is it a workaround for? A lack of a feature?

    --

    I hope this post finds you in a good mindset and open to ideas. Thanks for your time!

  • I'm sure some people actually need it the way it currently works, and they're not here on the bug report forum because it works. So I don't want to change or remove what is already there for starters.

    Secondly there are much more subtle hangs by trying to clean up created objects when the layout ends: object A could create B which creates C which creates D which creates A. Alternatively A could create B which is in a container with C and therefore creates that as well, and destroying C creates D which is in a container with E, which when destroyed will randomly create an A. Then your game randomly hangs when changing layout, instead of every time, which is even more annoying since it's that much harder to pin down.

    Also the engine is actually doing the same thing as the Destroy action when the layout ends or is restarted, so it is logical that it also fires 'On destroy' as well.

    The workaround is pretty simple too - if it comes to it just put all your 'On destroy' in a group and disable the group before restarting/changing layout.

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