Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Aerospace units and map height/altitude limits
#21
(08-19-2015, 09:21 AM)Akjosch link Wrote: 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.

You will not find much. The rules are notoriously vague regarding aerospace units. I have had to seek personal clarification on a lot of rule from TPTB and many of those clarifications have never made it into errata. Dropship death from above is one example. The rules never clarified whether units could move and take off/land in the same turn, but doing so would have allowed spheroid dropships to instal-kill any units on the map that they wanted to because they can move 16 hexes per MP and then just land on them.

In this particular case, the rules just vaguely say that the aerospace unit must be "flying at" X altitude or lower. However, if you allow that altitude to be the one the ASF was at when it flew over the ground unit then you create more advantage for the already advantaged ASF. It could fly over at altitude 5 and then go up a couple of altitudes. This creates two advantages. First, each altitude is considered 2 hexes for range purposes, so the ASF is harder to hit. Second, the ASF could avoid the possible lawn dart crash where if it is hit it could fail its PSR, go out of control, and lose enough altitude (1d6) to crash. If the ASF can gain two altitudes then it can insure that it will never have a lawn dart crash. This is why, after consultation with TPTB it was decided that "flying at" meant the end of turn altitude, so that the disparity between ground and air units is not even greater.
Reply
#22
Yeah, I have to sleep on it. On the one hand, implementing that house rule would make it easier for aerospace fighters. On the other hand, the altitude map changes I'm making for my group along with the often rugged terrain they find themselves in (Or, worse: urban terrain. Skyscrapers can easily be 50 or more height levels, which translates to 3 or 4 altitude levels with the default mapping.) mean that dropping down to altitude 5 can already be a fatal crash.

And in the end, one side having CAS while the other doesn't should generally be a very one-sided affair ...
Reply
#23
So you want a house rule that combines the altitudes used for the Low Altitude rules on the ground map?

Don't forget on a ground map asf have to travel 8 hexes before they can turn.
Reply
#24
(08-19-2015, 07:45 PM)pheonixstorm link Wrote: So you want a house rule that combines the altitudes used for the Low Altitude rules on the ground map?

Don't forget on a ground map asf have to travel 8 hexes before they can turn.

That's pretty much what my patch is doing, yes. Right now it calculates the ground altitude bands using the "Low-Altitude Table" (TW 81), which end up being height level 8 or lower = altitude 0, 9 to 16 = alt 1, 17 to 25 = alt 2, 26 to 41 = alt 3, 42 to 83 = alt 4, 84 to 125 = alt 5, 126 to 166 = alt 6, 167 to 333 = alt 7, 334 to 833 = alt 8 and everything at or above 834 = alt 9 (so that you can always fly above the terrain, as long as you're cruising at altitude 10).

My test maps tend to have a (BattleTech) height of 90 and above wherever I want to limit the Aerospace fighter's ability to fly at heights used for strike and strafe attacks. This obviously only limits those for targets in the valleys below; anyone foolish enough to be on the top can still be attacked (the maximum altitude for those attacks is calculated as the maximum difference of altitude between the target and the attacker).

The turn radius just means that some canyon and skyscraper landscapes are impossible for an Aerospace fighter to fly through (I guess they could stop, hover or vertically land, and turn, even though that's slow). That's a feature, not a bug. In our test game, it already forced our Aerospace guy to abort a few strike attacks and pull up or turn away early instead, to avoid crashing into the cliffs.
Reply
#25
(08-20-2015, 03:04 AM)Akjosch link Wrote: [quote author=pheonixstorm link=topic=2196.msg14517#msg14517 date=1440027903]
So you want a house rule that combines the altitudes used for the Low Altitude rules on the ground map?

Don't forget on a ground map asf have to travel 8 hexes before they can turn.

Ultimately, the rules say "yea, elevations are about this high and that equates to about this elevation, but we're going to throw that out and not really use it for game purposes."  So, elevations never effect Aeros, for simplicity.  Really, this probably isn't much of a problem as people don't end up using things like 90level hexes on an actual table.  For MM, it could make sense because we handle ridiculous maps.

That's pretty much what my patch is doing, yes. Right now it calculates the ground altitude bands using the "Low-Altitude Table" (TW 81), which end up being height level 8 or lower = altitude 0, 9 to 16 = alt 1, 17 to 25 = alt 2, 26 to 41 = alt 3, 42 to 83 = alt 4, 84 to 125 = alt 5, 126 to 166 = alt 6, 167 to 333 = alt 7, 334 to 833 = alt 8 and everything at or above 834 = alt 9 (so that you can always fly above the terrain, as long as you're cruising at altitude 10).

My test maps tend to have a (BattleTech) height of 90 and above wherever I want to limit the Aerospace fighter's ability to fly at heights used for strike and strafe attacks. This obviously only limits those for targets in the valleys below; anyone foolish enough to be on the top can still be attacked (the maximum altitude for those attacks is calculated as the maximum difference of altitude between the target and the attacker).

The turn radius just means that some canyon and skyscraper landscapes are impossible for an Aerospace fighter to fly through (I guess they could stop, hover or vertically land, and turn, even though that's slow). That's a feature, not a bug. In our test game, it already forced our Aerospace guy to abort a few strike attacks and pull up or turn away early instead, to avoid crashing into the cliffs.
[/quote]
Reply
#26
Added a patch to the bug tracker, Patch #500.

I wonder, would a pull request on GitHub work as well? I'm not sure how to create one for SourceForge, or if it's even possible ...
Reply
#27
(08-27-2015, 08:19 AM)Akjosch link Wrote: Added a patch to the bug tracker, Patch #500.

I wonder, would a pull request on GitHub work as well? I'm not sure how to create one for SourceForge, or if it's even possible ...

A pull request on GitHub will work in the future when we have fully set up cross commits to both repos. For now the GitHub repo is simply a backup to the SF repo, and I believe I'm the only one committing to it [my setup commits to both repos at the same time]. So, while my commits keep it relatively up to date, it isn't perfect.

Things are taking longer to set up than originally planned due to my move, and the fact that my damn power company wont turn on the power for us. We've been without electricity since we moved in on Monday.
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 645 03-05-2016, 07:55 PM
Last Post: TigerShark
  Aerospace Units on Ground Maps Option - Question jimw3st 4 1,319 02-21-2012, 12:27 PM
Last Post: jimw3st

Forum Jump:


Users browsing this thread: 1 Guest(s)