Wed Sep 22, 2021 4:01 am
What's the simplest way (preferably via DECORATE, though ZScript would be OK too) to get one actor to update its position and stay on top of another actor?
I have an enemy who, during his attack phase, spawns a protective shield around him (a spherical model attached to a simple non-blocking actor) so that he doesn't get killed by his own rockets and the player cannot kill him while he is attacking. The shield is purely decorative, the invulnerability of the actor is handled within the enemy's DECORATE itself.
During the attack phase, the actor is able to move, so the shield needs to be able to move with him. As long as he can see the player, the enemy stays in this loop but when the player breaks line of sight, the enemy goes back to his normal see state and drops his shield. So, the shield needs to be able to appear and disappear depending on whether the enemy is in his attack (missile) loop or his see loop.
At present, I have the enemy constantly spawning a new shield actor every tic in his attack loop, and the shield itself only lasts a tic. So it works and looks like it's always the same shield (much to my surprise), even though it is constantly being spawned, replaced with a new one and vanishing. It just strikes me, however, that there is probably a more efficient way of doing this.
Wed Sep 22, 2021 5:07 am
A yes, I think I've used that in the past. I'll see if I can get it to do what I want. Thanks.
Wed Sep 22, 2021 9:57 am
It took me a little while to wrap my head around converting my mess of repeated spawnings into a functionin A_Warp implementation. I first started trying to use A_Warp on the enemy rather than the spawned protection shield. (Trying to get him to call the shield to him, rather than the shield jumping to him under its own control.)
However, once I had it figured out, the enemy spawns the protective shield in a master/child relationship at the start of his missile loop, the shield calls A_Warp repeatedly with master as its pointer (and therefore stays on top of the enemy) and if the enemy goes into a state where the shield isn't required, he calls A_RemoveChildren at the start of the state sequence.
The code is now much cleaner, the in game effect is smoother and I was able to clean up another couple of minor mistakes that I hadn't spotted before because things were so messy.
Wed Sep 22, 2021 10:04 am
Good to hear. :) Sorry I wasn't able to provide a runnable example - but glad to see that you managed to figure it out. :D