Jump to content

Limiting helicopter altitudes


MDF
 Share

Recommended Posts

I am trying to think of ways to prevent (or at least deter) players from employing helos at "unrealistic" altitudes. SB models some SHORAD systems (2S6, ZSU-23, RBS-70), which will force at least some degree of caution on the opposing player. But once these assets are destroyed, the opposing player is free to send his helos to higher altitudes, even though -- in real life -- the other side may well have other medium-range AD assets (Patriot, Tor M1, Buk, etc.) that would make this hazardous to the point of unthinkability.

So, I'm trying to think of ways to prevent this tactically unrealistic behavior given the absence of these medium-range AD systems from the SB arsenal. I can only think of two approaches so far, which have significant drawbacks.

Method 1: make all helos computer-controlled, but give them an abundance of routes and BPs to which the player can direct them using triggers. This way, the mission designer can limit all routes to low altitude or less. Disadvantage is that the player will be limited in his tactical options, or the mission designer will have to place a large number of potential routes and BPs (which makes mission creation even more laborious, clutters the map with superfluous routes, and potentially exhausts the available triggers).

Method 2: place a number of OPFOR units of a kind unique to OPFOR's OOB in the rear of the OPFOR's forces or even on the whitespace portion of the map view. Try to ensure that these units have no LOS to any portion of the mission battlespace which could be occupied by a BLUEFOR helo at low altitude or below. Then, create conditions or events that would damage or destroy any BLUEFOR helo that can see these special OPFOR units for period of time approximating tracking, engagement, and missile-flyout time. This method avoids the artificial constraints on tactical options and avoids clutter. However, it is extremely tedious to find suitable places for these SAM proxies. Most likely, there will be undiscovered areas to which the "SAM" has LOS to units at above "low" altitude, and the BLUE player will lose aircraft even though not at excessive altitudes. Also, if OPFOR has units in all available categories (tank, OC, troops, helo, etc.) recognized by the logic editor, this method is unworkable. It is also limited by visibility distance.

I'm wondering if anyone can think of any other methods to accomplish this.

Link to comment
Share on other sites

I suppose a vertical penalty "ceiling" would be an option, but this would need to be developed.

Yeah, I had actually suggested this to Volcano a few weeks back. A limit on above-ground-level altitude specifiable in the mission editor. Crude, but reasonable interim (:clin:) solution which should be fairly easy to code.

Edit: actually, I misread your post. You're talking about a penalty zone. I meant something even cruder: just let the mission designer specify the maximum attainable altitude above ground level. Your suggestion is better but (I assume) somewhat more complex to implement.

Edited by MDF
Reading comprehension fail
Link to comment
Share on other sites

Are you a programmer?

I must admit to thinking the same thing whenever I read:

"which should be fairly easy to code"

"how hard can it be"

"this would be easy to implement"

If it were easy I guess it would be there already. :)

Of course an opportunity to quote a "dead guy"

"Everything in war is very simple," "but the simplest thing is difficult." Clausewitz

Link to comment
Share on other sites

Sometimes, code changes are not very difficult but there are so many awaiting your attention that you don't get around to them. Also, when you first tackle a problem (e.g., adding helos to the sim), it's hard enough to get the fundamentals correct that you overlook some of the easier things that become apparent over time, or forgo them in the expectation that you'll revisit the issue in a subsequent iteration. I suppose this is true of projects in many different areas of human endeavor.

Link to comment
Share on other sites

Keep in mind that eSim is still a relatively small company. Awesome as they all are, they can only do so much at a time. Also, the wishes of this community necessarily take a backseat to the demands of their primary customers: the various defense agencies for whom this sim was designed. (Unless of course those two happen to agree. ;) )

Link to comment
Share on other sites

As far as my suspicion that the altitude limit change would not be difficult to implement....

I am assuming (perhaps incorrectly, obviously) that because there is already a hard limit on the altitude a helo may attain (helos don't just continue to climb until the program crashes), this limit is determined by a constant value in their code.

If this is the case, then it is not a very difficult task to initialize that value based on an input from the .sce data rather than a compile-time constant. Certainly, you would have to add an item to one of the Mission Editor menus and an associated dialog box (or use some other UI mechanism), and related Windows message handlers, and a few additions to the serialization code and the constructors for helicopter class(es). I'm sure there are a few wrinkles I'm overlooking. This shouldn't impact the network code, for one thing, since everyone gets the .sce.

"Easy to implement" is obviously relative. I don't pay eSim developers' salaries. Compared to adding a new vehicle, for instance, or new particle effects or AI behaviors or bouncing roadwheels, this is trivial, though.

Again, I could be completely wrong in my assumptions concerning their code in this regard and would be most interested to learn the truth.

Link to comment
Share on other sites

Are you a programmer?

*BBZZZZZZTTTT* 5 minutes in the penalty box for unnecessary use of Appeal to accomplishment. :P

A better argument might be:

It may seem (or even be) simple to add, but remember they don't have a large team working on the sim and that we're not their primary customers. If they're busy adding, fixing, or otherwise doing something for a military customer, for example, they simply may not have the free time right now to try to change something that isn't explicitly broken.

[edit]Apparently I left this post sitting un-posted so long Lt DeFault ended up saying almost the same thing... :D[/edit]

Link to comment
Share on other sites

*BBZZZZZZTTTT* 5 minutes in the penalty box for unnecessary use of Appeal to accomplishment. :P

A better argument might be:

It may seem (or even be) simple to add, but remember they don't have a large team working on the sim and that we're not their primary customers. If they're busy adding, fixing, or otherwise doing something for a military customer, for example, they simply may not have the free time right now to try to change something that isn't explicitly broken.

I understand that eSims is a small company and, more importantly, was not chartered specifically to cater to PaladinSix's whims. :) I was actually discussing this exact thing (well, the former, anyway) with DarkAngel after the UK Armour mission last Sunday. Still, there is a 2,700-post wish list thread, so I don't think it's terribly presumptuous to state my own preferred development items, even knowing that eSims, like any company, has limited resources and perhaps different opinions about what is a worthy or correct addition to SB.

I understand your point about "explicitly broken" things. I will say, however, that given the ability of the AH-64A to loiter at 1,000 ft after the 2S6s are destroyed, I will not use it in any NATO-WP mission I create unless I can find some workaround along the lines in my original post (which are both ugly kludges). At least for me personally, that's pretty close to broken. Also sad, because I think Apaches are really cool.

Link to comment
Share on other sites

  • Moderators

I understand your point about "explicitly broken" things. I will say, however, that given the ability of the AH-64A to loiter at 1,000 ft after the 2S6s are destroyed, I will not use it in any NATO-WP mission I create unless I can find some workaround along the lines in my original post (which are both ugly kludges). At least for me personally, that's pretty close to broken. Also sad, because I think Apaches are really cool.

Well, I don't understand why this keeps coming up as if something is broken here. It comes down to scenario design really, and whether or not the scenario is broken or not. Perhaps the Apaches are in an area where there are no medium range SAMs in numbers? It can happen, but the point is this:

If an Apache is in a scenario, follow these rules:

1) Do not give that side supply trucks. I made this mistake recently as you know, because I forgot the trucks were present. If there are no trucks present, then at least the Apache can only kill 8 vehicles will Hellfires, who cares if they fly 1000 ft before or after that. It really only matters if they fly 1000 ft after they continue to reload again and again.

2) If worried about meager air defense, then add more 2S6s or a butt load of ZSUs. Yes ZSUs are useless, but they can keep the Apache honest if they operate in pairs, and are on the front lines.

3) Do not put ADA assets where the enemy can see them with ground forces. In the scenario we played weeks ago where the Apaches kept resupply (violation of rule #1), their two 2S6s were killed by ground fire, very quickly too.

4) Give a lot of RBS70 MPADS. These will keep attack helicopters honest, and if you give each infantry company and two or so, and maybe another platoon of them mounted, then the Apache has no way knowing if they are all dead. My scenario also violated this rule (there were no MPADS), which I have also fixed.

-------------------

Anything beyond this is due to bad scenario design (I admit I screwed up that scenario in particular, but have since improved it -- my scenario violated all of these rules ;)), OR maybe the scenario designer wants them to fly at 1000 ft, as long as they don't reload. Otherwise, yes, of course we would like to have height related penalty zones, or ROE style altitude caps on specific scenarios, or medium ranged SAMs (or IR MPADS), but again, it all comes down to time and the lack there of at the moment.

Anyway, you don't have to take a stance that you will totally avoid adding Apaches to scenarios if you just follow the above rules. ;)

Link to comment
Share on other sites

I'd like to clear up something about this as I feel that I'm the one that instigated Paladin's concerns by using the Apaches in that manner.

I used them like that because I had played on a team that received that same unending rain of doom from the sky on a previous TGIF and just assumed the other side would do the same given the opportunity. That still doesn't make it right, and it was rather terrible thing to make Paladin have to deal with on his first go at being a CO, so please accept my apology.

As far as future scenarios go:

I wouldn't automatically remove supply trucks from scenarios with attack helicopters, I'd think just prominently mentioning it in the briefing (or even on the map itself off to the side) that 'choppers are not to be rearmed would be sufficient, as it'd be pretty hard to break the rule, if someone were so inclined, without it getting noticed in the AAR afterwards.

Link to comment
Share on other sites

I'd like to clear up something about this as I feel that I'm the one that instigated Paladin's concerns by using the Apaches in that manner.

I used them like that because I had played on a team that received that same unending rain of doom from the sky on a previous TGIF and just assumed the other side would do the same given the opportunity. That still doesn't make it right, and it was rather terrible thing to make Paladin have to deal with on his first go at being a CO, so please accept my apology.

As far as future scenarios go:

I wouldn't automatically remove supply trucks from scenarios with attack helicopters, I'd think just prominently mentioning it in the briefing (or even on the map itself off to the side) that 'choppers are not to be rearmed would be sufficient, as it'd be pretty hard to break the rule, if someone were so inclined, without it getting noticed in the AAR afterwards.

No apology necessary. Actually, I participated in the previous TGIF you mentioned in which Apaches reigned supreme as well (I was on the "giving" side instead of the receiving side that time, but I do remember the serious reservations raised by the other side). In another prior mission, a Chinook hovered at high altitude dishing out intel like a JSTARS (again, I was on the benefiting side). I hadn't used Apaches (or any other helos) in any of the missions I designed to date, and they seem appear only infrequently in TGIF. The recent mission you're referring to was only an unpleasant reminder of the potential for misuse.[*]

However, lest anyone think that this was brought on in a fit of pique at losing (badly), my suggestion is driven by simulation concerns, not competitive ones. That's why I'm looking for methods to avoid unrealistic Apache employment in missions I design. I don't want anyone to be using helos in this manner in any of my missions.

[*] By "misuse," I'm not suggesting cheating, exploits, or bad sportsmanship or anything like that by REDFOR. I mean "use in a tactically unrealistic manner."

Link to comment
Share on other sites

Well, I don't understand why this keeps coming up as if something is broken here. It comes down to scenario design really, and whether or not the scenario is broken or not. Perhaps the Apaches are in an area where there are no medium range SAMs in numbers? It can happen, but the point is this:

If an Apache is in a scenario, follow these rules:

1) Do not give that side supply trucks. I made this mistake recently as you know, because I forgot the trucks were present. If there are no trucks present, then at least the Apache can only kill 8 vehicles will Hellfires, who cares if they fly 1000 ft before or after that. It really only matters if they fly 1000 ft after they continue to reload again and again.

2) If worried about meager air defense, then add more 2S6s or a butt load of ZSUs. Yes ZSUs are useless, but they can keep the Apache honest if they operate in pairs, and are on the front lines.

3) Do not put ADA assets where the enemy can see them with ground forces. In the scenario we played weeks ago where the Apaches kept resupply (violation of rule #1), their two 2S6s were killed by ground fire, very quickly too.

4) Give a lot of RBS70 MPADS. These will keep attack helicopters honest, and if you give each infantry company and two or so, and maybe another platoon of them mounted, then the Apache has no way knowing if they are all dead. My scenario also violated this rule (there were no MPADS), which I have also fixed.

-------------------

Anything beyond this is due to bad scenario design (I admit I screwed up that scenario in particular, but have since improved it -- my scenario violated all of these rules ;)), OR maybe the scenario designer wants them to fly at 1000 ft, as long as they don't reload. Otherwise, yes, of course we would like to have height related penalty zones, or ROE style altitude caps on specific scenarios, or medium ranged SAMs (or IR MPADS), but again, it all comes down to time and the lack there of at the moment.

Anyway, you don't have to take a stance that you will totally avoid adding Apaches to scenarios if you just follow the above rules. ;)

I suppose it just comes down to a manner of personal taste. If I have to give a battalion the regiment's entire complement of 2S6s in order to counterbalance the Apache issue, that is (generally) unrealistic and inconsistent with my personal preferences in designing missions. If I have to omit supply trucks, that's also a blow to realism. Aviation units create FARPs specifically so that attack helos can rearm quickly and rejoin the fight within the timelines of typical SB battles. Of course there would be instances when FARPs wouldn't be there, but if I can't use them at all, that precludes a significant class of scenarios for aviation employment.

Additionally, loading up on SHORAD assets would not fully fix the problem. The Apaches could still hover at high altitudes 4km or so behind the FLOT. They can still savage the enemy from there and issue a stream of SPOTREPs, with nothing to fear except Assassin7 and his MPATs. :clin:

Again, I want to stress that this is merely my personal preference in designing missions and not intended as a criticism of Volcano or anyone else. To each his own. But if I'm going to spend 60-100 hours designing a mission, I want to do so consonant with my own vision of things.

Link to comment
Share on other sites

  • Moderators

As far as future scenarios go:

I wouldn't automatically remove supply trucks from scenarios with attack helicopters, I'd think just prominently mentioning it in the briefing (or even on the map itself off to the side) that 'choppers are not to be rearmed would be sufficient, as it'd be pretty hard to break the rule, if someone were so inclined, without it getting noticed in the AAR afterwards.

Well, I think when you boil it down, most TGIF scenarios don't really need supply trucks, the action is over too quickly, or there is plenty of tanks to go around, or the tanks die before they need resupply. If that is the not the case then you can have other options but I dislike the honor system of simply mentioning not to resupply.

In that particular scenario, I now have the options that give helicopters not give supply trucks, and the options that give the plethora of tanks will also give supply trucks. To me it makes sense because the tank horde is what needs supply trucks anyway, but usually there is plenty of stuff in Symmetrical Attack that no one ever bother resupplying in the first place. :)

I suppose it just comes down to a manner of personal taste. If I have to give a battalion the regiment's entire complement of 2S6s in order to counterbalance the Apache issue, that is (generally) unrealistic and inconsistent with my personal preferences in designing missions. If I have to omit supply trucks, that's also a blow to realism. Aviation units create FARPs specifically so that attack helos can rearm quickly and rejoin the fight within the timelines of typical SB battles. Of course there would be instances when FARPs wouldn't be there, but if I can't use them at all, that precludes a significant class of scenarios for aviation employment.
Yes, but I believe most of this to be exaggerations.

1) I never said you had to give a regiment's compliment of 2S6s, you could simply give them +1 more and that makes a HUGE difference. The point is, I think that most scenarios give an inadequate amount of ADA to begin with.

2) My point about supply trucks was that they are usually given in excess anyway. 99.999% of the time they are not needed because the scenario is too short to be useful. Do you recall how many ground vehicles needed to resupply at the trucks in that particular scenario where the Apaches flew back to resupply three time? The answer is none IIRC. ;)

But fine, if you feel that is more realistic to leave out attack helicopters in all the scenarios you create, then by all means do so. I just dislike the apparent panic that everything to do with helicopters is flawed simply because we don't have altitude limits, or medium range SAMs. The Tiger has existed for years without all these things and as long as the scenario is designed properly, it isn't much of an issue. Really the "I won't use the Apache" seems more like an attempt to lean on the developers to add desired feature X (but that is just how it comes off to me). :heu:

Additionally, loading up on SHORAD assets would not fully fix the problem. The Apaches could still hover at high altitudes 4km or so behind the FLOT...
No, one thing you may not realize is that the RBS70's range is NOT 4km, it is 7km. This is nearly as much as the 2S6, and I don't think you can consider that a true short range SAM (SHORAD being predominantly in the 4km range). So, it really isn't valid to say that RBS70 would not address the situation, because it is only 1km shorter range than the Hellfire. If you have, like I suggested, a realistic amount of RBS70s in the scenario to the degree that every organization has one or two of them then certainly the Apache would not be able to fly at 1000 ft unless it was far in their own rear area where it would be mostly useless doing that. Also the RBS 70s could easily be brought up to the front line and kept hidden from the enemy, and because of that the other side will like lose the Apache before they know what hit them, or they will do the smart thing and stay low to avoid them. (I know of several scenarios with RBS70s in them that killed Apaches and no one never knew where it came from until until the team was spotted later by ground forces.)

So really, to me, it is more about putting adequate ADA in the scenario that includes Apaches in the first place. If all such 2S6 and RBS70 MAPADS and any ZSUs are killed off, then well the Apache of doom really does deserve free reign at that point, which is where the backstop of not putting excess supply trucks comes in.

As I said, I think everyone wants more ADA in SB and more restrictions on helicopter height, but the point I am trying to make is that you can certainly play with the tools that are there and still keep it realistic if certain scenario design rules-of-thumb are followed. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...