Apparently you can't collide two segment shapes together??

is this a bug R0J0hound ?

edit: I checked the chipmunk docs, and apparently segment shapes can't collide with other segment shapes.. I guess I'll have to try and find some alternative.. maybe a thin polygon- I'll try that.

edit: I tried a thin polygon, but I get an error stating that the moment of inertia must be positive and non-zero. line 52 (col 3).

That looks really useful rexrainbow , do the instance groups get updated automatically if an instance is destroyed?

edit: figured it out- tilemap was set to box instead of poly.. not the polygons are working per tile.

Ashley , How does the current method increase performance?

Is there some kind of code example you can show to help illustrate the issue? I'm just interested in understanding it.

oh yea.. the on flash end would be simpler.

My guess is that it gets to the first Wait, and waits however long, then it starts monster flashing and initiates the second Wait. So if monster is destroyed, that second Wait is still being processed. When the second Wait continues it doesn't spawn any (am I correct?), and then tried to do the other events but picks all other bullets instead.

You could try using the Timer behavior instead of Wait. The Timer will allow each monster to have their own timer, and if the monster is destroyed, it's timer won't fire.

He doesn't- he already state that.

There could be other ways though. Just because something is difficult to fix, doesn't mean it shouldn't be attempted.

On occasion I run into situations where I undo/redo stuff and events that shouldn't be removed get removed while events that should be removed don't get removed.

Anyone else experiencing this? I'm wondering what might be causing it.

It's annoying because it can end up screwing up a lot of stuff if I don't realize it happened.

It's not about exploiting anything, newt. It's about expecting some logic to work. If I want to pick everything that is created, I don't want to wait because it isn't fully available when I create it.

"When you develop intricate processes that aren't just simple events like these examples, the order of every single step through the process matters- you can't afford to break away and assume it will work with everything else."

What if a user destroys that object in the same event? What if a user destroys some other instance in the same event?

What if it's created from a family? What if a user creates yet another instance in a subevent?

If everything was accounted for, and objects that should be considered created are created and objects considered to be destroyed are destroyed, then that would be no problem. The logic would follow a consistent pattern and you would easily make sense of the events.

You can already add a Tilemap to a family.

You might be trying to add a Tilemap to a family of a different Object Type. You can't have different objects types in the same family.

Ashley , if I understand correctly, the reason we can't pick newly created objects within nested subevents is because loops would attempt to reference indices that don't exist within the instance list (because the new objects aren't merged with it until top-level event)?

And if you wanted to reference an instance that isn't in the instance list, there'd need to be a way to know that it is in the new object list instead- and this is an engineering issue that would require a lot of work?

Edit: couldn't you give new objects a "would-be" index number, that corresponds to what their index would be when they get added to the instance list. And then when checking instance list, cycle through the would-be indices- if they are greater than the instance list length, then check the new object list instead?