setPosition sometimes leaves parts of the particle behind

[MrChoke]

I am starting to use my copy/move code where you can specify an area of the map to copy or move. I came across what is clearly a bug of some kind.

Simple test, try to move a castle_door with pull chain. The pull chain by default is a castle_door_button. By move, I mean call setPosition() on each game object in the square where the castle_door is. You will move the door and one of the buttons (the other button is in the next square, no weirdness there).

You will see two odd things:

1) The new castle_door_button will flicker now. About every 4 seconds it will flash out and come back on.

2) Where the old button used to be will be a faint blue glow. It will not go away.

Anyway, this is bugged for sure. I cannot imagine any work around other than maybe call destroy on the castle_door_buttons and then re-spawn them. Ugh.

[Isaac]

The setPosition() call ~unless they've radically fixed it, comes with crash risks in certain situations. The risk is usually related to moving the party around, but in your code's case I would suggest checking things very carefully long after it all seems to work.

What happens if a door is opening or closing during a move?

*And the torch holder, the torch, and the glow effect are three separate objects.

https://www.dropbox.com/s/04a8rx73ir67q ... h.avi?dl=0

[MrChoke]

The setPosition() call ~unless they've radically fixed it, comes with crash risks in certain situations. The risk is usually related to moving the party around, but in your code's case I would suggest checking things very carefully long after it all seems to work.

What happens if a door is opening or closing during a move?

*And the torch holder, the torch, and the glow effect are three separate objects.

https://www.dropbox.com/s/04a8rx73ir67q ... h.avi?dl=0

I didn't try the move while the door is in motion. I have used setPosition quite a bit especially on the party and never had an issue. To me it looks like part of the particle system doesn't move. I think there is a "glow" definition. It looks like the glow is left.

[minmay]

2) Where the old button used to be will be a faint blue glow. It will not go away.

Well this part is definitely not a bug, the only problem here is you. The glow particles aren't emitted to object space, so of course they won't follow the object when it is moved. If you want them to move with the object them emit them to object space ("objectSpace = true" in the emitter definition) instead of world space.

[MrChoke]

2) Where the old button used to be will be a faint blue glow. It will not go away.

Well this part is definitely not a bug, the only problem here is you. The glow particles aren't emitted to object space, so of course they won't follow the object when it is moved. If you want them to move with the object them emit them to object space ("objectSpace = true" in the emitter definition) instead of world space.

OK, I guess I see what you are saying. I had no idea what the objectSpace flag was. It is quite inconsistent in that parts of the particle definitions have objectSpace = true and parts do not. Hence, setPosition() definitely does not work for some objects without the creation of modded particle systems for them. Maybe there is a technical reason for this. But maybe not. To say its "me" is not true because I am using the default particle systems here, not custom ones. As said above, I'll need to use custom ones to get it to work correctly.

[minmay]

OK, I guess I see what you are saying. I had no idea what the objectSpace flag was. It is quite inconsistent in that parts of the particle definitions have objectSpace = true and parts do not. Hence, setPosition() definitely does not work for some objects without the creation of modded particle systems for them. Maybe there is a technical reason for this. But maybe not. To say its "me" is not true because I am using the default particle systems here, not custom ones. As said above, I'll need to use custom ones to get it to work correctly.

There's nothing inconsistent about it. For example, consider the fireball particle system. You want the inner "nucleus" of fire and the glowing effect to follow the fireball as it travels, so you emit them to object space. You don't want the smoke particles to follow the fireball, so you emit them to world space.

In the case of castle_button the objects it is used on (castle buttons) don't move, so object vs. world space doesn't matter unless someone calls setPosition, setWorldPosition, setWorldRotation, etc. on the button, which is an unusual use case and not performed in the original game. I don't think the developers should be under an obligation to make all the standard assets impossible to misuse. You can crash the game by spawning 100000 twigroots but the problem there is not the twigroot asset, it's spawning 100000 of them. It's not surprising that you get odd behaviour from moving an object that clearly wasn't originally expected to move.

Also, I looked at the flickering behaviour that you describe. The light does not flicker, only the particles, and they flicker only when the original glow particles are not visible. This legitimately does seem like a bug.
Anyway, you can fix both problems without changing the particle system definition if you want: simply do

Code: Select all

castle_door_button_1.particle:restart()

after moving it.

[MrChoke]

[quote="minmay]There's nothing inconsistent about it. For example, consider the fireball particle system. You want the inner "nucleus" of fire and the glowing effect to follow the fireball as it travels, so you emit them to object space. You don't want the smoke particles to follow the fireball, so you emit them to world space.

In the case of castle_button the objects it is used on (castle buttons) don't move, so object vs. world space doesn't matter unless someone calls setPosition, setWorldPosition, setWorldRotation, etc. on the button, which is an unusual use case and not performed in the original game. I don't think the developers should be under an obligation to make all the standard assets impossible to misuse. You can crash the game by spawning 100000 twigroots but the problem there is not the twigroot asset, it's spawning 100000 of them. It's not surprising that you get odd behaviour from moving an object that clearly wasn't originally expected to move.

Also, I looked at the flickering behaviour that you describe. The light does not flicker, only the particles, and they flicker only when the original glow particles are not visible. This legitimately does seem like a bug.
Anyway, you can fix both problems without changing the particle system definition if you want: simply do

Code: Select all

castle_door_button_1.particle:restart()

after moving it.[/quote]

Good example of how objectSpace and worldSpace are used for moving objects like fireballs. That does make sense. The button does not move though so it may be more of an oversight to have part of the particle defined in world space and part in object space.

I did take the "BUG" reference off this post off because an oversight or easily fixable solution to this is definitely not a bug. At first it sure looked like one.

I will keep a cal to restart() in mind for the particles. Thanks.