dMZX Forums: Duplicated Robots Inherit Status From Source Robot -> Archived MegaZeux Bugs -> Tracker

And now for something completely different.

Issue: When Duplicating a Robot, the Duplicate Inherits Several Different Statuses from the Source Robot
Versions Affected: v1.00g onward (wowie… this one's an oldie)
Introduced in Version: v1.00g (at the very least!)
Operating System: All

Further Details
While messing around with making Robots that shoot unique projectiles, I decided to try and put the coding for the projectile within the Robot. My experiment was mostly successful, but I noticed a couple of rather odd quirks.

• The newly-spawned duplicate inherits the currently-active "walk" command of the source Robot.

I was monkeying around with a side-scroller engine when I discovered this. I wanted my Robots to shoot Robot bullets and I couldn't figure out a reliable way to have them copy the robot from a coordinate. So, instead, I embedded the "bullet" code into the "attacker" Robot, make it change its character and color for a partial cycle, duplicate itself, then send the duplicate the "turn into a bullet" code. I'm actually really proud of myself. Trouble is… since this is on a side-scrolling stage and the "attacker" Robot can move about, it generates its own gravity with a "walk SOUTH" command at the start. No amount of cycle-squeezing can make the bullet stop going one tile south before it goes on its merry way…

In this example, I created a robot that, once again, starts in an unlocked state and sits idle. Once "A" is pressed, it starts walking in a random direction and duplicates itself 5 tiles to the east. The duplicate also starts walking in the very same direction despite not being explicitly instructed to do so.

Here's my example robot:
When the robot spawns, there's apparently a one-cycle delay before it can act on its own. Despite that, it will move for that one cycle. The initial "walk IDLE" will stop the duplicate from moving… but only after that unavoidable delay. This means that whenever it spawns, it will move one space in whatever random direction the source Robot was moving, then stop. I haven't found a way around this.
--

• The newly-spawned duplicate inherits the "lock" status from the source Robot.

I discovered this later on when trying to troubleshoot the other problem. No story here, I was just experimenting to see what duplicates did and didn't inherit. (Short story: they inherit everything.)

In my example robot, I start it in an unlocked state I made it so that when I press "A", it locks itself, spawns a copy of itself, then immediately tries to destroy the copy by sending it to "B_Go!". If the duplicate were unlocked, it would spawn and blow up immediately. However, it spawns locked despite the fact that the source Robot does not.

Here's my example robot:
Like before, there's an unavoidable one-cycle delay. The "unlockself" command will make the duplicate unlock itself after that one-cycle delay, and putting a "wait 2" command before the "send" allows the source Robot to auto-nuke the duplicate correctly. That's about the best that can be done.
--

02/11 Edit: I found a new one. This one has to do with pre-zapped or later-restored labels.

• The newly-spawned duplicate inherits the "zap" status of all labels from the source Robot.

While tinkering further with my "attacker-and-bullet" 'bot, I noticed that during that one-cycle window, if the player was right next to the duplicated 'bot and touched it on the cycle it's duplicated, it will still allow the ":touch" event to happen. So, I thought if I pre-zapped ":touch" and had the base Robot restore it while idle, everything would work out fine. Imagine my surprise (though, should I really be, at this point?) when I tested it and, yep, the "bullet" 'bot still reacted to :touch despite the fact it's pre-zapped.

Here's my example robot:
Again, that unavoidable one-cycle delay means there's a tiny window of opportunity for the 'bot to get messed up. The work-around for this is to simply have the 'bot temporarily zap (or restore, if necessary) any relevant labels before duplicating itself, so there' that.
--

It's also worth mentioning that duplicated Robots also inherit the character of the source Robot (but strangely not the color). I'm reasonably sure that's intentional whereas inheriting the "lock", "walk", and "zap" statuses probably isn't. I could be wrong on this, of course. It's been like this since the very first versions. It just seems… inconvenient… for a robot to spawn locked and/or already moving before it's supposed to be – especially since the duplicate can't do anything for one cycle after creation.

This post has been edited by Joseph Collins: 28 February 2024 - 07:50 PM

Updating status to: Working As Intended
Updating version to: None

Moving to: Archived MegaZeux Bugs