Two bug reports

[Induktio]

From a game design standpoint I predict that to be a complete fail, at least in this game.  "Formers getting themselves killed" is a typical problem of many Civ-style games.  Allowing units to continue to move while taking wounds, is likely to be a quick death in many circumstances.  If you think you can work "throttling code" into such a decision, have fun with that... but game design-wise I think you'll be walking into a genre of AI misbehavior that players do not want to see in their games.

Not sure what's your motivation to keep commenting on this kind of stuff if you refuse to use all patches anyway.

[Douglas]

1) ... Way too many times, I've had it ignore obvious mag tube routes, sometimes even when the mag tube is an utterly trivial single square deviation from the direct line path. I've even had it go off the mag tubes for a single square, only to move right back on one square later, when there's another mag tube square connecting them without even requiring a greater number of steps...

To my knowledge, this behavior occurs when underlying road is destroyed, rendering intact magtube unusable. Hope this helps.

Much more sad behavior demonstrate needlejets, flying aimlessly back and forth, sometime crashing in process.

No, I check the route it's going to take before releasing the button, and when I see it ignoring a mag tube I cancel giving that order and manually move it step by step past the trouble spot. Doing this gets the unit through with 0 movement spent every time; I've never had this fail.

That needlejet behavior is an example of the last point from that paragraph in my post. I haven't had it happen to me, but I've seen an AI do it. Yang was trying to fly across my territory, and couldn't find a way through all the crawlers I had. I watched about a dozen needlejets move back and forth until they crashed that turn.

This reminds me of another bug. In the incident with Yang flying across my territory, I saw an opportunity to try to force those needlejets to crash, and surrounded them completely with units so they couldn't move without declaring vendetta and attacking. Nothing happened to them. They just sat there doing nothing, and not crashing, for a few turns until I gave up on it and moved the units back. Then they moved in a loop until they crashed. Apparently the fuel check is part of the movement/orders logic, and if you don't give a needlejet orders it won't use its fuel.

[PvtHudson]

1) ... Way too many times, I've had it ignore obvious mag tube routes, sometimes even when the mag tube is an utterly trivial single square deviation from the direct line path. I've even had it go off the mag tubes for a single square, only to move right back on one square later, when there's another mag tube square connecting them without even requiring a greater number of steps...

To my knowledge, this behavior occurs when underlying road is destroyed, rendering intact magtube unusable. Hope this helps.

Much more sad behavior demonstrate needlejets, flying aimlessly back and forth, sometime crashing in process.

No, I check the route it's going to take before releasing the button, and when I see it ignoring a mag tube I cancel giving that order and manually move it step by step past the trouble spot. Doing this gets the unit through with 0 movement spent every time; I've never had this fail.

Apparently, the requirement for a road beneath magtube is part of pathfinding logic, but not of actual movement mechanic. Typical result of duplicating program code.

[L to the P]

if you don't give a needlejet orders it won't use its fuel.

This reminds me of another behavior I observed, which was upgrading bombers that were ordered to hold with grav and a better reactor caused them to consider themselves to have moved (ie will crash if I moved them without "landing" (hitting space)) with their fuel never refilling while "holding" because they no longer had full fuel tanks, because the capacity had increased. To check if I was right, I attacked with one and sure enough it crashed despite being at that base for years.

[scient]

hex_cost() logic used by Path class if anyone is interested:
https://github.com/b-casey/OpenSMACX/blob/master/src/veh.cpp#L668

I'm going to start working on breaking down Path class soon.

[scient]

Some initial work on the Path class. There is a map continent struct that I need to do more analysis on to continue further. Will see about finishing it for next release.

https://github.com/b-casey/OpenSMACX/blob/master/src/path.h
https://github.com/b-casey/OpenSMACX/blob/master/src/path.cpp

[scient]

More progress on Path class. Definitely gave me some insight into how continents and world is being built out.

Just the three largest functions left (find, move, sensors). There is a draft version of sensors on repo but I haven't gone through testing it yet. Ran into some issues with the way I've been doing automated regression tests for the last few completed Path functions. Ended up having to manually go through assembly and compare to original. I generally do this as a last step after automated tests catch most things. I'm going to work on some of the save game and game data IO code. I figured I can hook into these for better and more reliable regression tests. Planning on wrapping up last three Path functions for next release.