Stable goto

[hexagonrecursion]

• fixes goto() doesn't report reaching to destination point in 32-bit binaries. #844

Make goto numerically stable on 32 bit targets

• Gcc handling of float on 32 bit platforms has some quirks
• I think CTask::IsEnded() should not be modifying instance variables because we rely on CTask::IsEnded() to not change its return value if called twice in a row. This is a small step in that direction - fixing one cause where modifying an instance variable caused a different value to be returned on a subsequent call.

Test case

Completed mission 4-3 (System Failure) on a 32 bit platform with CMAKE_BUILD_TYPE=RelWithDebInfo

Fix goto orbiting

goto(position, altitude, 1, 1) used to instruct the bot to apply full forward thrust even if it is facing more than 90 degrees away from the destination. This resulted in the bots sometimes endlessly orbiting the destination.

Fix: apply the same forward speed reduction that several other parts of CTaskGoto use.

Test case 1

extern void object::New()
{
    point pos = this.position;

    goto(pos, pos.z, 1, 1);
}

Test case 2

extern void object::WingedBot()
{
	point pos = position;
	pos.x += 10;
	turn(direction(pos));
	pos = position;
	pos.x -= 6;
	message("goto(");
	goto(pos, pos.z, 1, 1);
	message(")");
}

Add a cheat to simulate low frames per second

• Added a new cheat code fps <number> to enable testing how the game handles low frames per second
• fps 10 caps the frames per second at 10
• fps 0 uncaps the fps

Restore 5 meter margin for flying bots

When fps is low a bot may overshoot the destination and double back. This no longer gets the bot stuck in an infinite loop because I fixed the orbiting, but this makes the bot in the mission 4-3 (System Failure) run out of battery before completing the program if the game is running at 4 frames per second.

Fix: re-introduce the 5 meter margin for flying bots

Test case

Completed mission 4-3 (System Failure) with 4 fps