Menu
▾
▴
1 Attachments
#4286 Maneuvering Ace causing bad MP expediture
MegaMek version 0.39.2 from Raligth r1993 build
Maneuvering Ace doesn't apply shortest path.
See Attached... no... the gravity doesn't change things. It is already broken. It should cost 8 MP for the 5/8/5 PXH to face the Thunderbolt directly. But bad MP use because of Maneuvering Ace causes the final facing change to generate a Gravity Error.
Just thinking about this for a moment seems to indicate that any moves of 3 or so hexes will screw things up for any pilot with Maneuvering Ace.
I've been seeing something similar. It's like the movement calculator is giving MA too high of a priority.
Instead of turning once and then moving forward a bunch, it prefers to crab walk the entire way.
giving crabwalk a higher priority is a necessity with current gui - currently user cannot specify the ending orientation. Fortunately he can force turning manually, whereas he wouldn't be able to force shifts.
to clarify: you state that your phoenix hawk, when ordered to move to 3313, proposed route RRFF[CrabWalkRight], but you expect him to take route RRFFRF (the one presented in the screen capture)?
Low gravity is in effect in this game. It is a modified PXH (5/8/5 normal) back up to 6/9/6 because of the low gravity. Every time I tried moving him so that he would use 8 MP to face the TDR I would get the warning about max movement PSR because of gravity (because MM was counting 9MP expended). It isn't overheated and has no leg damage.
Just to make absolutely certain, the bug isn't about the path being chosen (that's fine), but instead that the chosen path costs more MP than it should (because of maneuvering ace).
That sums it up Arlith. Yes. Every attempt at getting the PXH into 3113 facing that TDR ended with 9MP used and it should only cost 8.
After trying to reproduce this issue and talking to Hammer, I'm pretty sure the last two comments are wrong. I think Saginatio had it correct.
There are two possible movement paths, one path that costs 8 MP and doesn't use the lateral shift, and one that costs 9 MP and does use a lateral shift. The pathplanner is (incorrectly) choosing the path with the lateral shift.
Hammer did point out that MA allows biped 'mechs to make a lateral shift like a quad 'mech, however it does not confer the 1MP bonus that quad 'mechs get. I wonder if this is causing the issue. The cost of the path accounts for this 1MP but the path planner doesn't, so the planner thinks the path costs 8MP, when in reality it costs 9.
I have problems reproducing the bug (or understanding it).
When I order a mech to move to 3313 it chooses RRFF[CrabWalkRight]. This path costs 7mp and is one of the two shortest paths to 3313 hex. The second one is obtainable by going to 3314, turning right and moving forward to 3313.
Last edit: saginatio 2014-11-07
Bipeds with MA can perform a lateral shift just like a normal quad. Quads with MA should need 1 less MP for each lateral shift than normal quads. There's no way of automatically fixing this, becase we don't know where the user wants to face. There's a way to make it work, though. Click on hex 3314, manually change facing towards 3313, and then click on 3313 and shift click 3412 to face there. In short, there's no bug here.