It is not really a bug, but a warning of potential bugs.
Testing 3.1.0. My modded ruleset adds a unit with the flag "Coast" and fuel > 0.
If I use the effect Action_Success_Actor_Move_Cost with the value 65535 (as many other effects in 3.1 default rulesets) and the action "Unit Move", then when the AI tries to move that unit, it causes an assertion error:
"in pf_fuel_map_iterate() [path_finding.c::2753]: assertion '1 << (8 * sizeof(node1->cost_to_heredir)) > cost + 2' failed."
There is no error when I use Action_Success_Actor_Move_Cost with a lower value like 600.
I understand that creating an effect that consumes the whole movement of a fuel unit is not a good idea, and an error is somehow expected, but I'm afraid the use of this high value 65535 in current rulesets could cause other similar errors if the AI has to use them as input for further calculations.
We should use some smaller value that is still well higher than max possible move points. Also to avoid cases where another effect of the same type causes overflow; 65535 + 1 = 0.
It is not really a bug, but a warning of potential bugs.
Testing 3.1.0. My modded ruleset adds a unit with the flag "Coast" and fuel > 0. If I use the effect Action_Success_Actor_Move_Cost with the value 65535 (as many other effects in 3.1 default rulesets) and the action "Unit Move", then when the AI tries to move that unit, it causes an assertion error: "in pf_fuel_map_iterate() [path_finding.c::2753]: assertion '1 << (8 * sizeof(node1->cost_to_heredir)) > cost + 2' failed."
There is no error when I use Action_Success_Actor_Move_Cost with a lower value like 600.
I understand that creating an effect that consumes the whole movement of a fuel unit is not a good idea, and an error is somehow expected, but I'm afraid the use of this high value 65535 in current rulesets could cause other similar errors if the AI has to use them as input for further calculations.