Some MOVE() bugs

[derpfish]

So I spent some time hacking at my fleet script this weekend (ok,
let's face it; I forgot how addictive this game was and I spent almost
all of my weekend hacking on it) and I found myself repeatedly
besieged by quirky MOVE() behavior. Incidentally I think I've always
found this to be true, but never thought much of it in the past. I
finally decided to dive into the code and found a couple things worth
mentioning.

The move function has the following code:
-- If their distance is less than their speed, override it
IF (distance < final_speed) THEN
IF (distance < 2147483647) THEN
distance = CAST(distance AS integer);
ELSE
distance := 2147483647;
END IF;
END IF;

Now I'm not *totally* sure, but I think this piece of code is meant to
address a problem I've been encountering in which a fast-moving ship
will reach its destination, but then because it's going so fast it'll
actually go past it. Then in the next tic, it will turn 180 degrees
and fly back, but it hasn't slowed down so it overshoots it again.
This repeats indefinitely with the ship oscillating around its
destination. I think was this code block is *supposed* to do is
correct for this problem by replacing final_speed with distance in the
event that the speed given to the function would have caused the ship
to overshoot. I think the code block is just missing a "final_speed =
distance" between to two final END IF; statements.


Since I'd seen this problem before I'd built some logic into my fleet
script to handle it by calling MOVE on effected ships (at that point I
wasn't sure if that was simply the intended behavior of MOVE and we
were supposed to compensate manually), but I've since realized that my
fleet script code wasn't actually working. Digging around I finally
figured out the reason for this is that tic.pl calls MOVE on all
moving ships before any fleet_scripts get called. Consequently, all
MOVE calls within a fleet script (on already moving ships) will fail
since those ships have already been moved that tic. So you can't
command your ships to slow down or speed up (from with a fleet_script
at least) once they've started moving. I'm not sure if this was an
intentional design choice, but I suspect not.

The simplest fix would of course be to just have fleet_scripts called
first and then do movement in tic.pl (unless this causes some other
problem I'm not aware of). However, you could consider making the
whole thing slightly cleaner by instead making MOVE a privileged
function (only callable in tic.pl) and instead have users use some
sort of SET_SPEED to effect movement which more or less eliminates the
need for the MOVE_PERMISSION_CHECK and list_move_tick (since ships
would then *only* be moved during the tic and not in the middle of a
round whenever MOVE happens to get called).


Assuming all that makes sense, since I've been staring at this since
last evening I'd be happy to write up a patch on github and issue a
pull request; let me know.

-derpfish

[MassConfusion]

derpfish,
I have to agree with you completely on this one, this is the same odd
behavior I was experiencing back in Sept.
It'd be nice if a patch would allow it to work as it was intended,
after much hair pulling I finally resigned myself to storing the
planet destination and every turn having the script re-calculate a
destination for a single hop toward that goal in an attempt to remove
control from tic.pl/move() altogether. Unfortunately, that means that
my ships will never reach a speed higher than half max fuel per hop,
and the script has to plow through multiple calculations every single
tic, but I haven't had the oscillation issue since.