#4544 Airborne WiGE movement blocked by level 1 buildings

[Klaus Mittag]

It looks to me as though airborne WiGE movement currently doesn't account for buildings in its path quite correctly. A level 1 building should be treated the same as a level 1 hill for purposes of passing overhead and sideslips, right? At the moment, such buildings simply block a flying WiGE's path in the same way that level 2 and higher ones legitimately do and sideslips into them result in crashes as for non-WiGE units...

(If I'm correct, we may also want to make sure again that a building passed over by an "overweight" WiGE doesn't collapse underneath the latter as long as it doesn't actually land there and put its weight on the roof, just in case. I seem to recall that having been an issue with jumping units before.)

[Nicholas Walczak]

In my very brief test, I also found that WiGEs don't use the "Elevation Changes" rules on pg 55 of TW. I had a WiGE that went from level 0, to 1, to 2, but MM seems to think that going from lvl 2 to 0 is illegal (which it isn't).

I didn't check, but I'm also pretty sure we have no mechanism for the WiGE to expend 2 MP to maintain elevation when "jumping off hills."

[Klaus Mittag]

Hm. I can't confirm that first part for myself at the moment...going down any number of levels (and at no cost in MP at that) appears to work for me.

However, it's true that there's no obvious way to maintain elevation at the moment. I seem to recall that we were using the "Climb Mode" button for that at some point, but right now that's always greyed out.

[Klaus Mittag]

Okay, tickled the behavior out if hiding now. Apparently MM won't let WiGEs do the "descend any number of levels" act specifically on a turn in which they just launched. If they start the turn already airborne, there's no problem and they follow the rules as I understand them.

[Klaus Mittag]

Re: Climb Mode button, we're apparently globally turning that one off for WiGEs in general in megamek.client.ui.swing.MovementDisplay.updateButtons() -- the if clause in lines 679 - 690 lists WiGE movement as one of the modes to do that for. Commenting out the relevant test in specifically line 684 seems to restore the intended behavior, and a WiGE can launch and move across a hex it could otherwise not descend into at the moment in this fashion as long as it has the MP to do so (tested on the box canyon map).

[Sebastian Brocks]

Yes, WiGEs should use climb mode for that. Here's the original note in history.txt for the WiGE implementation I made 7 years ago:
+ WiGEs can spend 2 MPs to stay at current flight level when moving over a down-
wards level change
WIGEs need to start their movement with a "Go Up" step to start, this costs
5 MPs. To use the "spend 2 MP to keep altitude when going over a cliff"
rule, climb mode needs to be activated and be in the "keep elev" setting.
In the hex before you again reach terrain of the original height and/or if
you don't want to spend the extra 2 MPs per hex moved to keep the elevation
anymore, click "climb mode" again to use the normal movement rules for
elevation and spend only 1 MP per hex moved.

[Nicholas Walczak]

In [r11863], I fixed the elevation dropping issues for WiGEs that took off in the same turn.

It was a very similar issue to [#4540]: Entity.getMaxElevationsDown uses the Entity's elevation to determine if a WiGEs is in-flight, and the Entity's elevation state isn't updated until the MovePath is executed, not during, so Entity.getMaxElevationsDown was thinking the WiGE wasn't yet airborne. I fixed this by creating a new signature for Entity.getMaxElevationsDown that can take the current elevation.

[Nicholas Walczak]

The building issue is in Tank.isLocationProhbitied. WiGEs are prohibited from entering hexes that contain woods and buildings. The woods one is correctly, as they can only enter Woods if traveling along a road (and that is handled properly). The buildings one is going to be based upon elevation I think, so I'll have to update Entity.isLocationProhibited to take in the elevation.

[Nicholas Walczak]

Fixed in [r11865] (and [r11866] since I missed a file).

I updated the function signature for Entity.isLocationProhibited so that it takes an elevation. This only ends up mattering for Tank and SupportTank, which use it to determine if a WiGE is airborne or not. If the WiGE's elevation is greater than or equal to the buildings elevation, then then the building isn't prohibited, otherwise it is.

I also had to update Entity.calcElevation, since there wasa case that should be ignored for WiGEs with buildings.

[Klaus Mittag]

Still doesn't quite work, I'm sorry to report.

-- First, there's another "not if you just launched this turn" issue. If the WiGE was already airborne at the start of the turn, it can fly over a level 1 building just fine; if it starts its move going up, it's still blocked.

-- Second, in treating buildings like terrain, I'd expect to be able to climb successive levels like hills if the buildings are arranged just right. Yet if I actually try that, such as in the SE corner of the buildings/city_suburb map which does feature a level 1 and level 2 building right in succession if I point my nose in that direction...I can fly into and over the level 1 hex but not the level 2 one.

[Klaus Mittag]

Also just noticed: the new call to getElevation() in isLocationProhibited(Coords) can result in an IllegalStateException for Entities that don't know their own position yet. I just had a game frozen by that when Princess decided to have an immobilized tank's crew abandon their vehicle.

[Nicholas Walczak]

More fixes in [r11869].

I was running out of time before, and I had hastily committed my fixes before, and clearly it was premature.

To fix the IllegalStateException, I changed from using the getter to using the state variable directly. It's not the best fix, but it's not unreasonable.

I also found a few problems with what I had committed before. First, I forgot to update Tank.isLocationProhibited to use the new function signature, plus there were a number of calls in MoveStep to Entity.isLocationProhibited that was using the 1 argument version instead of the 2 argument version.

Also, I noticed that I had inadvertently allowed airborn WiGEs to enter buildings. I actually need to check the specific elevation of the WiGE vs the building, so a WiGE isn't allowed to enter a building whose elevation is greater than 1 level above the WiGEs current elevation.

There's still an outstanding issue though: WiGEs still can't gradually climb up buildings like steps (ie, lvl 1 to lvl 2, to lvl 3).

This is because building "elevation" is different from hex elevation. Entity.elevation measures how many levels off the top of the hex a unit is. Elevation also gets used to keep track of what level within a building a unit is on. So, I've got to do more to adjust the WiGEs elevations for buildings.

[Nicholas Walczak]

Alright, I think I've got this fixed in [040049] and [10d3bc].

The first commit is mostly refactoring. I made it easier to get the elevation of terrain features for a given hex (and now terrain feature elevations are encoded in Terrains).

For the WiGE stuff, basically it comes down to how we deal with WiGE elevations. Previously, we basically assumed that WiGEs were always at elevation 1, when they really need to be 1 elevation above the underlying terrain. So, I added code to consider the elevation of terrain features (woods elevations, building elevations, etc). So now, if a WiGe flies over a 1 elevation building, it's now at elevation 2 (ie, it is 2 elevations above the surface of the terrain, or 1 level above the underlying terrain).

I think that this takes care of this bug. I did do some rudimentary testing, but there could definitely be more testing done. I'm going to mark the bug as fixed, but will certainly reopen it if over issues crop up.