#Creep with no MOVE parts generated fatigue on itself when being pulled by a dying creep
15 messages · Page 1 of 1 (latest)
could be a history bug. Can you reproduce it?
The fatigue remained that way permanently, and it broke my code. It's definitely not a display issue.
This is reproducible.
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…
I think it is that when a dying creep pulls another creep.
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.
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.
#1250190905386991646 is running that code if you wanna try it out @solar anvil?