and I could write a correct pathfinding function myself in minutes.
Increase it to 256, and I'm not sure I'd ever reach that except in a genuine infinite loop,
I'd need to have ways to access the relevant game data provided for me, which... now that I think about it, Thinker mod might actually have publicly available. OpenSMACX might even have the hooks needed to make it be used, but I'm not sure how far along it is. In either case, I'd need to familiarize myself with the existing code first. I'll consider it.and I could write a correct pathfinding function myself in minutes.
You should then! Nothing like a pull request for getting what you actually want out of Open Source.
And you should test it. Which will not take "minutes".
If it's an actual long distance trip, then the player should see the unit rapidly blinking along the mag tubes, periodically interrupted by the map getting recentered to keep it in view. If it's a loop, 256 mag tube moves without recentering the map would take a few seconds at most, and then the prompt would pop up. Even for players with the "move units with orders quickly" option turned off, I just checked and goto movement on mag tubes is still just as fast. No other movement mode is relevant because mag tubes are the only way to reach even the current limit for that prompt.QuoteIncrease it to 256, and I'm not sure I'd ever reach that except in a genuine infinite loop,
But what about players who aren't you who think their game is freezing up? It's all about how long such things go on.
1) The pathfinder is not actually a path finder, but a path guesser. 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. Worst of all, I've had a unit repeatedly move back and forth between the same two squares until it ran out of movement, never actually getting closer to the destination!Okay, let's chime in on this...
On top of this, it doesn't check for zone of control restrictions, and gets stuck, unable to execute a goto order, when it reaches a point where the next step it tries to take is blocked by ZoC.
For the AI it would be much easier if it could move anyway, but maybe taking a little bit of damage for passing an enemy ZoC.
Also, I don't recall ever patching terraforming code in that way. I'm not certain off hand how to fix this issue. There are some core terraforming functions I haven't worked on yet. Maybe some kind of check/refresh when square/map gets modified. I've added it into my bug tracking notes for future reference.It could also be fixed in order resolution - when a former attempts to do something that's already done, skip consuming movement, and only clear the order. Or... this is speculation, but I'm guessing that resolving a former order is done by first doing the work and then checking whether it's done. If so then this could be fixed by invoking the check both before and after the work, instead of only after.
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.
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.
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.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.
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.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.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.
if you don't give a needlejet orders it won't use its fuel.