Produced in a r20677 server on x86_64 Linux Mint 19.
I charmed monsters in /pup_land/nurnberg/storehouse. This resulted in me having a demon, and a demilich fighting my demon, among other things. When the demon had slowness applied to it, it would move exceedingly quick. When the slowness wore off, it would return to normal speed.
This would be at newly visible due to the change I made to the slowness code a while back (May 31, 2018, about r20575). While the increase may have occurred before, it used to be limited to exp -1. Since that is no longer the case, such symptoms appear in an amplified (and noticable) fashion.
My first guess is that it has something to do with most monsters having their speed defined as a negative number. Thus, when additional slowness is applied, their speed become more negative, and thereby increases speed.
Do you want to take this one?
It appears to be the case that the handling of negative speed in common/loader.l from the monster's definition allows for a random amount of time left before its next move. This appears to be the only place where negative speed is relevant, but it is still stored as the negative speed upon load.
Then, when fix_object is called in common/living.c, op->speed is affected by a negative stats.exp in the slowness (and other forces) arch, causing the speed to become more negative.
It appears that process_events in server/server.c correctly adjusts the speed to be non-negative for every update the object receives (using FABS). The problem is the value it sees in this scenario is not correct.
Since we seem to store speed_left after an initial load (on map saves and player saves, for example), it seems the best course of action is to FABS(op->speed) when it is loaded from file in loader.l.
patched in r21260.
patched the patch in r21271. It turns out I made custom monsters on random maps unable to move.