Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Aerospace units and map height/altitude limits
#1
I'm not sure if it's a bug, a feature, something for house rules, or simply working as intended ... So I figured it would be better to ask here first.

Yesterday I created a 160x160 canyon map in MegaMek 0.40.1 for my group, consisting mostly of hilly, rugged terrain at the bottom (height levels -3 to +8) and a bunch of plateaus way above it (height levels +90 to +95), with sheer wall-like cliffs. The idea was to recreate the environment in Emmerich's Moon 44, essentially, with air superiority being only partially useful and prone to accidents, given the environment (as well as planetary conditions). As much as it is possible, anyway - recreating the different wind conditions inside the canyons as opposed to above them would require me to change the coding of the client a bit.

Height level +90 should be about 540m above zero, in other words restricting aerospace units at altitudes 1 to 5 to "inside" the canyons (altitude 5 is defined as "251 to 500 metres", if I remember correctly). This is particularly important for strafing and direct attacks made on ground units for those fighters; they need to watch out for the cliffs. Imagine my surprise when after a failed manoeuvre at altitude 5 one of the aerospace fighters ended up inside solid rock ... and kept on flying. This worked even down at altitude 3, which should be hundreds of metres below surface level, as one unlucky Transit pilot found out after losing control of their fighter.

I'm still scratching my head about how this all works out, in particular since I didn't find any explicit conversion table between aerospace "altitude" and BT's ground map "height level", so just naturally assumed they would be converted by dividing the limits by the height level (six metres). It would certainly be the case if I played the game on a normal map, the impracticability of having a 160x160 hex big map on your table notwithstanding ...
Reply
#2
Actually you have it wrong. Your changes are for elevation not altitude. What you are trying to do would affect VTOL. Love the idea and miss that cheesy movie.
Reply
#3
(08-10-2015, 07:34 AM)pheonixstorm link Wrote: Actually you have it wrong. Your changes are for elevation not altitude. What you are trying to do would affect VTOL. Love the idea and miss that cheesy movie.

The question is then, how would I restrict altitude ranges in the same way playing on a low-altitude map would, where each hex corresponds to about a single BattleTech board? Is there some attribute I can set to a hex to record its altitude in addition to elevation?

For now, we can just play it on a honour-based system (every unit which would be destroyed will be deliberately crashed into ground instead), but I'd really love to know how to do it "properly".
Reply
#4
You can play a high-altitude ground map, where terrain features can affect ASF - however, you can't also have ground forces at the same time.

On a low-altitude map, there are no rules in battletech (and as a result, Megamek) for hills to affect aerospace movement on a low-altitude map.
Reply
#5
So it's house rules time then? Eh, it's not that bad, the code is clean enough. I might even get a nice alternative "ASF only" map mode out of it, since they can ignore almost all of the usual terrain features.
Reply
#6
Well, there is an aerospace-only map type already (two technically).

But yes, for what it sounds like you're looking for, it would require house rules.
Reply
#7
Getting the ASFs to care about terrain elevation turned out to be simpler than I thought; the full patch for 0.41.5 is attached.

Still got a bit of things to do for LOS calculations (I need to find them first), making it correspond to some game rule setting, displaying the altitude information to the players, making sure they crash at the right altitude when losing control, and possibly making the AI aware of the new game rule.

As a side note (and this has little to do with the actual idea I'm working on), the field of fire/range display for aerospace fighters on ground maps seems bugged. For example, the "short" range seems to be just 6 hexes instead of 96. Might be already fixed in trunk, but I prefer to work on a somewhat-stable revision, so I can't check.


Attached Files
.patch   MegaMek-BT_Altitude_v1.patch (Size: 2.43 KB / Downloads: 1)
Reply
#8
(08-10-2015, 05:53 PM)Akjosch link Wrote: As a side note (and this has little to do with the actual idea I'm working on), the field of fire/range display for aerospace fighters on ground maps seems bugged. For example, the "short" range seems to be just 6 hexes instead of 96. Might be already fixed in trunk, but I prefer to work on a somewhat-stable revision, so I can't check.

It's fixed, but not committed.  There's an issue with commiting to the SVN right now (which SF is working on... I guess); once I can commit again, I will be committing a fix for this.
Reply
#9
svn is borked again???
Reply
#10
Yea, can't commit since last Thursday. It's specific to the MM repo.
Reply
#11
Sourceforge must hate you for some reason  :o
Reply
#12
Next step: Adding a "View > Aerospace altitude" menu point to the board view. This proved to be rather easy, with one exception: HexTileset doesn't seem to have an easy access to the Game object, so the original shading remains. I'll have to think about how to solve that; possibly by creating a special subclass of HexTileset just for the aerospace altitude map display.

Patch for 0.41.5 is attached in case anyone else's interested in hacking their MegaMek to include this functionality.

ToDo: Line of sight, game rule implementation, crashing into terrain at the right altitude.


Attached Files
.patch   MegaMek-BT_Altitude_v2.patch (Size: 16.58 KB / Downloads: 1)
Reply
#13
Ok, new patch.

* Crashing, landing and lifting off the ground happens at the right altitude. Aero.java#land(...) method gets an argument for this case, the altitude to land at. (TODO: Sanity check when loading save games created without the game rule)
* Deployment is forbidden when the flying altitude would put the units inside the terrain (TODO: Check if when deployed *at* the right altitude, they properly end up as "landed")
* LoS calculations (hopefully correctly) done

The game rule is still unimplemented (I had no time to even check where to put those in code), but it should be easy enough and I plan to do it after today's test game with a bunch of friends. Essentially, it'll be a check in Hex#minAltitude() to see if the game rule is in effect, and if not simply always return "1".

This also changes the confirmation message when you want to eject from an aerospace fighter from "Are you sure you want to abandon this mech?" to "Are you sure you want to abandon this vehicle?" (or something to that effect). Just a nice little bit of personalised stuff, I just couldn't be bothered to exclude it from the overall patch.

Attached: The current version of the patch, and the test map I'm using to see if it works (never mind that it's slightly broken, the terrain works).


Attached Files
.patch   MegaMek-BT_Altitude_v3.patch (Size: 30.63 KB / Downloads: 2)
.zip   crazycanyon_build.zip (Size: 53.08 KB / Downloads: 0)
Reply
#14
What you are trying to do is totally against the rules as written and would create a host of problems that are difficult to resolve. Altitude does not equal elevation. You can use the maps as low-altitude maps if you want the hexes to correspond to altitude and not elevation change. IMO its not an issue that can easily be patched nor should it be.
Reply
#15
(08-16-2015, 01:16 PM)Taharqa link Wrote: What you are trying to do is totally against the rules as written and would create a host of problems that are difficult to resolve. Altitude does not equal elevation. You can use the maps as low-altitude maps if you want the hexes to correspond to altitude and not elevation change. IMO its not an issue that can easily be patched nor should it be.

The rules as written actually provide a conversion from the "low-altitude map" altitude to real-world metres of height (Low-Altitude Table, TW 81). Which is exactly what I'm using to convert elevation to altitude.

As to "can not be easily patched" ... our test game is currently running, and the patch I provided above works just fine so far.
Reply
#16
Looking at the section you refer to in that table it is already a part of MM.

Quote:Each hex of the low-altitude map roughly corresponds to one Classic BattleTech ground mapsheet.

When loading up MM use Atmosphere instead of Ground for the map.
Reply
#17
and on pg 91
Quote:Aerospace units operating on ground maps ignore all terrain features for movement
Reply
#18
(08-16-2015, 10:33 PM)pheonixstorm link Wrote: and on pg 91
Quote:Aerospace units operating on ground maps ignore all terrain features for movement

... and that's exactly why I'm considering using the table as a guideline for an unofficial house rule. I never claimed it was official, I was just unsure about it.

Test game looks good so far, we only had issues with NPEs which seems to have stemmed from loading a game started in 0.40.1 in a (modified) 0.41.5 client. I doubt that's even supported (on the other hand, it was easily enough fixed with a few "if (null == someVariable) { someVariable = new VariableType(); }" here an there), so I'm not too worried.
Reply
#19
Is this patch finished?  I feel like this needs to be a game option and not a client option if it effects how the game is played.  I haven't really looked at the patch in-depth but have glanced at it.  Really, this should probably be on the MM patch tracker (I have a tendency to lose track of forum posts).  I think there may be some confusion as to what precisely you want to cover, so putting it on the patch tracker with a solid description of what it's trying to accomplish and why might be a good idea.
Reply
#20
It's not finished yet; I made sure it works for 0.41.6 this week, fixed the aerospace altitude view mode not working in the map editor, and right now I'm hunting a few possible resource leaks, checking what the rules have to say about actions like "fly at altitude 5 over a target, raise to altitude 6 before the end of the movement so as not to crash into a cliff" - MegaMek seems to consider this as being "too high" for air-to-surface strikes -, and looking at how well Princess deals with it all. And yeah, I plan to put it to the patch tracker once I have the corresponding game option implemented, along with a detailed instruction on what it does and a few "extreme canyons" example maps I use for testing.

There are also side items I'd like to have fixed which have nothing directly to do with this patch, but are also occupying my time: My players are begging me to implement an "undo" functionality for movement (especially important when you're trying to fly just right through some narrow canyons) and Princess seems to prefer to stall out in place instead activating hover mode for some reason ...

Though I'm not sure if I should bother with an "official" patch request before the 0.42 "stable" release, frankly. Wasn't there a feature freeze for the 0.41 branch?

Right now, the patches are here so people who want to modify their games can try them out.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Aerospace units allowed a free turn every 8 hexes, regardless of velocity #63 TigerShark 1 633 03-05-2016, 07:55 PM
Last Post: TigerShark
  Aerospace Units on Ground Maps Option - Question jimw3st 4 1,310 02-21-2012, 12:27 PM
Last Post: jimw3st

Forum Jump:


Users browsing this thread: 1 Guest(s)