Destroying an object isn't destroying it

Hiya

I can't get something simple to work.

I want to destroy an instance, then immediately check and do other tidy-ups if there are none of the objects left now.

After destroying the object, the rest of my function seems to act like I have not actually destroyed the object.

<img src="http://i.imgur.com/O3BBZHB.png" border="0" />

It's causing me so many headaches. It's looking like I'd have to write a new function to "tidy up" on next tick which is horrible and dirty.

Why does it work like this, surely I should be able to , in one function, add/destroy objects and do things as a result of that action.

Have you tried using containers to link the objects together? That way when one is destroyed, the others will automatically be destroyed along with it.

scirra.com/manual/150/containers

silkc2

You're probably running into something similar to what Ashley stated about objects not being completely created until the tick is completed and started again. I'm assuming that the same probably holds true for the destroy action as well, since I know for a fact that I can still access variables and properties of objects after they are given a destroy action.

If you pull your clean up events out from under the destroy and make them their own events, they'll work as you expect them to, as they'll check the count every tick, and thus the first tick after the destroy, once everything is actually gone, they'll fire.

mike can you create containers at runtime?

theubie - In the end I had to set a flag to indicate when a "tidy up" is to be done, and do it at the start of the sheet. It works, that's the main thing. :)

I did try having them as separate events but the whole function was only being fired one per sec, which meant I had a second event for "once per second" and having two "once per second" events didn't work as I expected. I think it did one, waited a sec, then did the other, but not sure.

I'm not sure but I don't think so. But it sounds like your solution with the flag is a good one.

Not sure why you would even need a flag.

System Compare Web.count <= 0 should be enough to figure out if your clean up needs to run for all joints. If that is true, then run your clean up code. Yes, it check ever tick, true, but your other events will only fire one time and will then be false until you spawn other webs.

And the others will continue to be false unless a web was destroyed in the previous tick...then will be false again on the next tick.

Same amount to checks as with a flag without the variable, which IMO is a better practice. Less is more.

There are tidy ups to be done any time a web is destroyed, regardless of whether there are now 0 webs left.

1, If no webs are left, just destroy ALL joints

2, If a web was destroyed, look for and destroy "Orphan" joints i.e. those which were attached to the web that is now destroyed.

In order for either to work I need c2 to recognize that the web in question no longer exists, which it wasn't doing coded as per original screenshot.

If there's a way to "fix" my code so it works like this without needing a flag to force it to execute on the next tick, I am all ears. I do not want to make any checks every tick that don't need to be every tick, as that goes directly against c2 coding principles (only use every tick if you HAVE to) - and in this case destroying a web is a fairly infrequent thing.

You already have the right event in place, as long as it's a top level event and not a sub event.

System -> For Each "Joint"

Joint -> Is Overlapping "Web" (inverted)

When that one is run, it will pick all joints that aren't overlapping a web. This will pick no joints unless a web has been destroyed, in which case on the next tick after a web is destroyed the joints that were overlapping it will now no longer be overlapping.

Here's a capx (R120.2) with just the clean up code in action.

The use of every tick only applies to running actions every tick. An event that is a top level event does it's check every tick, but if it doesn't evaluate to true then no actions are run. Speed wise, you're not going to take a hit evaluating your event over checking a single variable unless the event is a very complex one.