#Creep with no MOVE parts generated fatigue on itself when being pulled by a dying creep

15 messages · Page 1 of 1 (latest)

static vine
median sigil
#

could be a history bug. Can you reproduce it?

static vine
static vine
#

This is reproducible.

ornate cedar
#

I think a bit more info for reproduction would be lovely. Clearly, that's not supposed to happen, but having a description of what's going on would help — I'm not even sure what's going on there…

static vine
#

That's it I think. Another dying creep came and pulled, and added 12 more fatigue to the harvester before it died on the next tick.

#

The replay seems like that:
#T: Carrier pulls harvester. Fatigue is added to the carrier and was cleared. All good.
#T+1: Carrier becomes TTL=1, and pulls harvester again. Now the fatigue is added to the harvester, not carrier. Since the harvester does not have MOVE parts, its fatigue remains like that.
#T+2: Carrier tries to pull the harvester, but dies of TTL.
Not sure if the time sequence is correct in the replay, but pretty sure that this WILL happen when a dying carrier pulls a harvester.

solar anvil
#

Yes, confirmed this with some testing, it is dependent on whether the carrier or harvester are inserted into the room-object first which affects their run time.

#

Setup in an owned room:

  • carrier at (25, 25), body [MOVE, MOVE], ticksToLive: 2
  • harvester at (25, 26), body [WORK, WORK]
#

Both ticks run the same code:
carrier.pull(harvester);
carrier.move(TOP);
harvester.move(carrier);

#

Tick T: pull resolves, both move, fatigue=0. carrier TTL drops to 1
Tick T+1: carrier dies of TTL. harvester ends at (25, 24) with fatigue=4 — stuck forever (no MOVE parts to clear).

#

Same setup with harvester spawned/older than carrier (so it iterates first in the room loop): harvester ends at fatigue=0. Order-dependent. In practice the puller is the older creep, so the stuck case fires reliably.

solar anvil
ornate cedar
#

#1250190905386991646 is running that code if you wanna try it out @solar anvil?