not planned or correct for version Stinger, Sidewinder or other air-to-air missiles

[3WA]

Lol, yes, the Attack Helicopter we've had since 2008 that has seen 13 years of endless bitching about why doesn't it carry iglas.  And now, finally, in BS3 we will get them.

So it makes NO SENSE why the Apache wouldn't get stingers, when many countries have their Apache's carry them.

Edited April 21, 2021 by 3WA

[Mad_Shell]

6 minutes ago, 3WA said:

 And now, finally, in BS3 we will get them.

 

 

Someone didn't read ED plans for 2021...
"Note: Due to new Russian Federation laws pertaining to the gathering of information of Russian military equipment, we have had to reconsider our plans to add new systems to the Ka-50. We continue to update the cockpit, as well as a highly detailed updated external model. "

Edited April 21, 2021 by Mad_Shell

[Northstar98]

4 minutes ago, 3WA said:

Lol, yes, the Attack Helicopter we've had since 2008 that has seen 13 years of endless bitching about why doesn't it carry iglas.

 

Oh no, how did anybody cope?

 

4 minutes ago, 3WA said:

And now, finally, in BS3 we will get them.

So it makes NO SENSE why the Apache wouldn't get stingers.

 

Ha ha, what?

 

How does a completely different module getting Iglas make it make no sense for an aircraft which let me remind you, isn't fitted for stingers, not getting stingers?

 

Quote

when many countries have their Apache's carry them.

 

Which isn't really relevant given that we're getting an American one...

[3WA]

11 minutes ago, Mad_Shell said:

 

Someone didn't read ED plans for 2021...
"Note: Due to new Russian Federation laws pertaining to the gathering of information of Russian military equipment, we have had to reconsider our plans to add new systems to the Ka-50. We continue to update the cockpit, as well as a highly detailed updated external model. "

 

Lol, somebody doesn't listen to podcasts, etc.

[DaemonPhobos]

The version ED intends to model have the CMWS EOMS sensors at the wingtips, therefore, mounting double ATAS racks would be impossible.

I have lots of documentation showing that the US army Apache's WPs don't have air to air missiles as a valid option, ranging from 2002 up to 2011 , ATAS missiles require uncaging controls and seeker LOS cueing via helmet display in foreign Apaches.

Any implementation of the system would rely purely on speculation and an unrealistic integration of the weapon system.

 

[Kev2go]

Guess we will need a Super cobra or Zulu Viper to have a American attack helo with a2a capability.

Edited April 22, 2021 by Kev2go

[Fangs Out]

7 hours ago, Kev2go said:

Guess we will need a Super cobra or Zulu Viper to have a American attack helo with a2a capability.

 

Super cobra would be my prefered as the one I'd like to see as its the most capable, the AH-1W could carry Aim-9Ls AGM-122 SIdearms, Tows, Hellfires , rockets and the glorious M-197 20mm cannon

[DaemonPhobos]

hace 4 horas, Bravelink03 dijo:

Super cobra would be my prefered as the one I'd like to see as its the most capable, the AH-1W could carry Aim-9Ls AGM-122 SIdearms, Tows, Hellfires , rockets and the glorious M-197 20mm cannon

 

An according to NATOPS, it can also carry CBU-55 fuel air explosives with the power of roughly 3 mk-82 bombs each.

https://digital.library.unt.edu/ark:/67531/metadc1011989/

 

That said, I still see the Apache as the ultimate air- to- ground helo, most powerful cannon, 27 grs PBXN-5 per round, K/N/M hellfires, radar assisted, inertially guided Lima hellfires, multiple rocket warheads, automatic Countermeasure dispensing upon missile detection, radar jammer, etc.

You will have to depend on the Kiowa with it's ATAS missiles.

[Reticuli]

Hah hah... more from the ultra-realism crowd.  They don't field them because Apaches haven't been operating in areas with enemy aircraft.  Simple.  DCS often has enemy aircraft, thus the stingers make sense.

Edited May 1, 2021 by Reticuli

[3WA]

Unfortunately, if we really want stingers, we'll have to get an export variant of the Apache, because the US is mounting it's CMWS system on the wingtips ( where the stingers would normally go ).

[Northstar98]

16 hours ago, Reticuli said:

Hah hah... more from the ultra-realism crowd.

 

Why do you pick up something that is advertised as offering "the most authentic and realistic simulation of military aircraft possible", (or at least that's the goal) if you have a problem with them actually being so?

 

Quote

They don't field them because Apaches haven't been operating in areas with enemy aircraft.  Simple.  DCS often has enemy aircraft, thus the stingers make sense.

 

This is purely a mission editing issue.

 

It's a US Army Apache, with CMMWS in the wingtips, thus the stingers do not make sense.

 

Would I like an export Apache with stinger capability? Absolutely! I'd also rather just get that variant, instead of making our Apache something it's not. And before anybody talks about liveries for other nations - they're fictional liveries, with no bearing on what the aircraft is trying to represent. It ultimately doesn't matter what livery you put on it, because the aircraft still represents a US Army Apache. 

Edited May 2, 2021 by Northstar98

[Tippis]

2 hours ago, Northstar98 said:

Why do you pick up something that is advertised as offering "the most authentic and realistic simulation of military aircraft possible", (or at least that's the goal) if you have a problem with them actually being so?

The problem is that if they want to be that, they need to actually simulate the full capabilities of the airframe rather than arbitrary doctrinal and procurement choices.

[Northstar98]

4 minutes ago, Tippis said:

The problem is that if they want to be that, they need to actually simulate the full capabilities of the airframe rather than arbitrary doctrinal and procurement choices.

 

Do they?

 

If they specify that's it's supposed to represent an aircraft as operated by xxxx operator, circa xxxx year, then it should be accurate for that, and I'm afraid what was actually operational at the time with that operator is the king pin here.

 

I am going to predict where this is going to go though...

Edited May 2, 2021 by Northstar98

[Tippis]

Just now, Northstar98 said:

Do they?

Yes.

It's the only way to create actual full authenticity and realism in the simulation.

 

They'll still have the excuse of being restricted to available data if they want to shy away from some specific capability, but that's also all it is: a part if that is explicitly (and deliberately) missing in the simulation. Full authenticity and realism is an unobtainable goal, but that doesn't mean you need to obfuscate the fact that you're short of the target, nor that you can't have a good and open discussion about what compromises have to be made and why.

 

Doctrine and procurement is the domain of the scenario maker; it is not something that should ever be enshrined in the platform.

[Northstar98]

27 minutes ago, Tippis said:

Yes.

It's the only way to create actual full authenticity and realism in the simulation.

 

I disagree if it's going to be representative of an aircraft as operated by a specific operator at a specific point in time.

 

You don't have to go for everything under the sun, it just needs to be accurate for that operator at a specific point in time.

 

Quote

They'll still have the excuse of being restricted to available data if they want to shy away from some specific capability, but that's also all it is: a part if that is explicitly (and deliberately) missing in the simulation. Full authenticity and realism is an unobtainable goal, but that doesn't mean you need to obfuscate the fact that you're short of the target, nor that you can't have a good and open discussion about what compromises have to be made and why.

 

Fine.

 

Quote

Doctrine and procurement is the domain of the scenario maker; it is not something that should ever be enshrined in the platform.

 

Again, if we are to be simulating an aircraft, that is supposed to accurately represent one as operated by a specific operator at a specific point in time, then it should actually reflect that.

 

In the case of Stinger ATAS - the operator doesn't have it fitted, and instead fits something else where it goes, it's physically incompatible without modification. It doesn't satisfy the 'accurate for specific operator'

In the case of APKWS - it didn't exist until significantly after the stated timeframe - it doesn't satisfy 'accurate for a specific point in time'.

 

Not sure what you mean by doctrine and procurement, if you're talking tactics I agree, but I sense you're using it to handwave away 'specific operator' referring to it as arbitrary doctrine, to which I'll say again - if it is supposed to represent an aircraft as used by blah, it should accurately represent an aircraft as used by blah - in this case stinger ATAS is not present, and would require modification if it were to be fitted.

Edited May 2, 2021 by Northstar98

[Tippis]

1 minute ago, Northstar98 said:

I disagree if it's going to be representative of an aircraft as operated by a specific operator at a specific point in time.

…then that can be set in the mission editor to fit the specific operator in the mission at the specific point in time where the mission takes place.

 

1 minute ago, Northstar98 said:

Again, if we are to be simulating an aircraft, that is supposed to accurately represent one as operated by a specific operator at a specific point in time, then it should actually reflect that.

And that doesn't mean that you need to hobble the airframe. Rather, it means that you should be able to filter fitting options by year and possibly nation so as to set it up as accurately as possible. Again, that's not something that is inherent in the airframe — it's something that, as you obliquely point out, determined by the operator and point in time. Two things you set up in the mission editor. Therefore, that is where the capability restrictions should be set, not in the airframe.

[Northstar98]

8 minutes ago, Tippis said:

…then that can be set in the mission editor to fit the specific operator in the mission at the specific point in time where the mission takes place.

 

The date of the mission editor is completely up to you, I don't know why you keep bringing it up. If I make a mission right now, making it as realistic or as fictional, or as hardcore or casual as I like, I can set the date to whatever and practically change nothing significant at all, anywhere from before the first manned, powered aircraft ever flew, to 2100.

 

It doesn't matter what country you're flying for, what your livery is, or what the date is set to. The aircraft is still representative of a US Army Apache, circa whatever.

 

If it was supposed to cover the feature set, facilitating Apaches from all different operators and fits - firstly fantastic, but that's not what we're getting.

 

Quote

And that doesn't mean that you need to hobble the airframe. Rather, it means that you should be able to filter fitting options by year and possibly nation so as to set it up as accurately as possible. Again, that's not something that is inherent in the airframe — it's something that, as you obliquely point out, determined by the operator and point in time. Two things you set up in the mission editor. Therefore, that is where the capability restrictions should be set, not in the airframe.

 

But the aircraft is exclusively set up to be one as operated by a specific operator at a specific point in time. It is not some generic, universal Apache, that caters for whoever country and whatever point in time - it's something specific and exclusive.

 

It is inherent to what the aircraft is supposed to be a representation of. It isn't a 'hobble' - it's accurate to what's been specified. Just as it isn't a 'hobble' for an RAF Typhoon to not have IRIS-T, or a US Phantom II to not have Skyflash or Aspide.

 

If I fly the Apache for the British Army, the engines don't get swapped out for RTM322s.

 

Y'know, if I take our F-16CM into a late 80s mission (i.e pre CCIP), it doesn't magically become a baseline F-16C Block 50, with monochromatic green MFDs, mechanical HSI, with the JHMCS and MIDS switches removed. If I fly for an operator who fits there F-16s with Harpoons or parachutes, it doesn't magically get them - it's still very much a USAF/ANG F-16CM Block 50 circa mid-to-late 2000s.

 

Now it most certainly would be fantastic if we could get the required functionality to be able to have more or all the different variations available, unfortunately the world we live in is is far from ideal, and it just means extra work on top of extra work, for something that's probably going to spending the next few years in EA. 

Edited May 2, 2021 by Northstar98

[Tippis]

Just now, Northstar98 said:

The date of the mission editor is completely up to you, I don't know why you keep bringing it up.

I keep bringing it up because people keep using that whole “…at a specific point in time” as a qualifier for what capabilities an airframe should have. If the specific point in time matters, then guess what, the date in the mission editor should matter too since that is exactly what determines at what specific point in time a mission takes place.

 

Just now, Northstar98 said:

It doesn't matter what country you're flying for, what your livery is, or what the date is set to.

It should.

It specifies what operator we're talking about, and what specific point in time we're dealing with. You know, those two things that are apparently so critical to determining the capabilities of an airframe.

 

Either that matters, or it does not. If it doesn't matter, then the whole about simulating a specific operator at a specific time goes out the window. You can't have it both ways. If you want specific operators and time frames to matter, then let them matter, properly, in a way the game actually largely already supports. If you don't want them to matter, then good news: they don't have to matter. But it becomes a bit hypocritical to say on the one hand that, oh no, this specific operator and time frame selection is really really important, but that specific operator and time frame selection doesn't matter at all.

 

Just now, Northstar98 said:

But the aircraft is exclusively set up to be one as operated by a specific operator at a specific point in time. It is not some generic, universal Apache, that caters for whoever country and whatever point in time - it's something specific and exclusive.

And the point is (and I don't understand why this is so difficult to grasp): setting a specific operator at a specific point in time are things you already do in the mission editor. So that's where that restriction should belong, and if anything more tools and options should be made available to make those settings matter even more than they already do.

 

Thus, if you want to have some generic everything-to-every-man version flying around, turn off the restrictions; if you want a specific version used by a specific operator at a specific time, restrict availability to what that version, operator, and time frame allowed for. But realise that those are the variables that determine those restrictions, not the airframe itself. An accurate and realistic simulation of the airframe is a separate matter to an accurate and realistic simulation of a timeframe and end user.

 

Hard-coding that an airframe can't use a specific system when in actuality it can, is to hobble it. That is not a problem, since it is a decision that procurement procedures always involve: picking and choosing what capabilities to use and not. And that this is separate to the implementation issue of getting the data needed to simulate the full capabilities. That is a good excuse for not adding some specific features — but let's not kid ourselves: it is an excuse. It's a deliberate choice to limit exactly how accurate and realistic the simulation can be, because such limitations always exist. But as you point out: the main goal should be the most accurate and realistic portrayal, which in turn means that limits set by doctrine and procurement (and time, although both of those are time-dependent anyway) should be kept separate from the actual capabilities of the airframe. And the game already has a framework to make that separation happen, so there is no need to foolishly add them where they don't belong.

[Northstar98]

49 minutes ago, Tippis said:

It should.

It specifies what operator we're talking about, and what specific point in time we're dealing with. You know, those two things that are apparently so critical to determining the capabilities of an airframe.

 

No it doesn't, because precisely none of those things in DCS influence anything about systems, or weapons capability. They can be made completely separate from each other, and I've already given you an example of it, nice to it get completely ignored, as is the usual.

 

Quote

Either that matters, or it does not. If it doesn't matter, then the whole about simulating a specific operator at a specific time goes out the window.

 

Except it doesn't though does it?

 

You want it to be tied to the mission editor? Fine, and in an ideal world I would to. But guess what? ED aren't delivering a universal Apache representing every Apache variant under the sun, so it can be edited as you desire in the ME. They're developing something intended to be specific.

 

If we were able to develop something that can be applied accurately that is more universal (i.e multiple Apache variants).

 

Quote

You can't have it both ways. If you want specific operators and time frames to matter, then let them matter, properly, in a way the game actually largely already supports. If you don't want them to matter, then good news: they don't have to matter.

 

Look it's really simple - what Apache are ED developing?

 

If it's supposed to be an AH-64D as used by the US Army, circa xxxx, why should it be anything other than precisely that?

 

You seem to think it's supposed to be something universal, or at least that's what it should be - in an ideal world I agree, but it doesn't quite line up with what the reality is, does it?

 

Quote

But it becomes a bit hypocritical to say on the one hand that, oh no, this specific operator and time frame selection is really really important, but that specific operator and time frame selection doesn't matter at all.

 

Erm, what? 

 

What's so hard about ED saying 'look, we're giving you specifically x', and it actually ending up as x?

 

Quote

And the point is (and I don't understand why this is so difficult to grasp): setting a specific operator at a specific point in time are things you already do in the mission editor. So that's where that restriction should belong, and if anything more tools and options should be made available to make those settings matter even more than they already do.

 

It isn't difficult to grasp Tippis... You really need to calm down.

 

The thing is, ED aren't 

 

Quote

Thus, if you want to have some generic everything-to-every-man version flying around, turn off the restrictions; if you want a specific version used by a specific operator at a specific time, restrict availability to what that version, operator, and time frame allowed for. But realise that those are the variables that determine those restrictions, not the airframe itself. An accurate and realistic simulation of the airframe is a separate matter to an accurate and realistic simulation of a timeframe and end user.

 

But we're not getting a generic everything-to-every man version are we? It would be great if we were, and it would be great if ED could do as many aircraft variants as possible, and in which case I would agree with you completely.

 

But we're not.

 

Quote

Hard-coding that an airframe can't use a specific system when in actuality it can, is to hobble it.

 

*can't as said before, for an aircraft accurate to a US Army Apache, the CMMWS and its associated wiring is installed, so it doesn't have Stinger ATAS. You wouldn't be able to equip Stinger ATAS without  

 

If it was generic and universal I agree, but it's not, so it isn't - very simple stuff.

 

Quote

That is not a problem, since it is a decision that procurement procedures always involve: picking and choosing what capabilities to use and not. And that this is separate to the implementation issue of getting the data needed to simulate the full capabilities. That is a good excuse for not adding some specific features — but let's not kid ourselves: it is an excuse. It's a deliberate choice to limit exactly how accurate and realistic the simulation can be, because such limitations always exist.

 

I really don't understand how planning specifically a US Army AH-64D circa xxxx, and the module being an accurate depiction of one, is somehow limiting the realism, because it doesn't have the full range of capabilities across all Apache D variants, from other operators.

 

So maybe you can help me out here, as I'm clearly too thick to understand; why should an accurate representation of a US Army AH-64D circa xxxx, be anything other than a US Army AH-64D circa xxxx?

 

Quote

But as you point out: the main goal should be the most accurate and realistic portrayal, which in turn means that limits set by doctrine and procurement (and time, although both of those are time-dependent anyway) should be kept separate from the actual capabilities of the airframe.

 

Which, if it was universal, I'd agree - but it isn't, is it?

Edited May 2, 2021 by Northstar98

[Dragon1-1]

This is just another argument for the AH-64A - forget ATAS, that thing could mount Sidewinders.  

 

Not that this capacity was used much beyond testing, but I believe it was available on operational airframes (although they'd have to pilfer some Sidewinders from USAF to use it).

[Tippis]

5 minutes ago, Northstar98 said:

No it doesn't, because precisely none of those things in DCS influence anything about systems, or weapons capability.

They do if you click the button that makes them do so…

Again, the framework is already there. It's just not being used to its fullest because limitations keep being added in the wrong place.

 

5 minutes ago, Northstar98 said:

Except it doesn't though does it?

It apparently does since that's what this demand for restrictions always come down to: “oh no, can't have that for this operator at this time!” It keeps being brought up as an argument, and now here you come saying that it doesn't matter when it comes to the ME, where it actually does already matter (there's a restrict by year button already; GPS availability is set by the date; warehouse limits can be set, but it's not tied into the system because reasons).

 

5 minutes ago, Northstar98 said:

ED aren't delivering a universal Apache representing every Apache variant under the sun, so it can be edited as you desire in the ME. They're developing something intended to be specific.

That's just it: they can still do that. Both can happen at once. The specifics just need to be tied into the restriction frameworks already in place, and then they can deliver every Apache variant under the sun (subject to data availability) and develop something specific. Thus, all aspects of accuracy and realism would be fulfilled.

 

5 minutes ago, Northstar98 said:

Look it's really simple - what Apache are ED developing?

 

If it's supposed to be an AH-64D as used by the US Army, circa xxxx, why should it be anything other than precisely that?

It isn't that, for one. It's already been made quite clear that they're adding a mish-mash of things that they can get their hands on, and calling it a specific version that it is not. It should be anything other than precisely that because it already is, and because they have already demonstrated in other modules that this kind of supposed specificity is only a feigned excuse for not implementing things they have no data on. And that's ok, or would be if they could just be a bit more honest about the reasoning behind it. Data availability is an excellent excuse because there's just no arguing against that: you do what you can do; you leave out what you can't.

 

If we want to talk about simple, let's try this on for size: I'm simply tired with this whole edifice of fake accuracy and arguments from “realism”, when the fact of the matter is that completely different considerations and reasons are what decide what we get. And if we tear down that edifice and just accept what ED does and why, there's very little reason not to include all kinds of things and let the players decide what to use and not. Give them the tools to make that decision more easily, and let's all stop with this self-deception about what the game offers.

 

5 minutes ago, Northstar98 said:

Erm, what? 

Basically,

On the one hand: timeframe and operator matters (it's a US Army variant circa 20xx).

On the other hand: timeframe and operator doesn't matter (I've given it to Cuba in 1965).

 

Either it's really important and the operator and timeframe should dictate everything, or it's not that important and we can do whatever. But suggesting that the former must be preserved at all cost and the latter is fine is… incongruous.

 

5 minutes ago, Northstar98 said:

What's so hard about ED saying 'look, we're giving you specifically x', and it actually ending up as x?

The part where it actually ends up as y, and the reasons given is that it's somehow more realistic that way, when there are far more intelligent, credible, and transparent reasons why that's the end result.

 

5 minutes ago, Northstar98 said:

If it was generic and universal I agree, but it's not, so it isn't - very simple stuff.

Almost as simple as making it generic and universal, and letting the framework to restrict specific fitting (and entire airframe) options do its thing. Again, there is really no conflict between the two.

 

5 minutes ago, Northstar98 said:

I really don't understand how planning specifically a US Army AH-64D circa xxxx, and the module being an accurate depiction of one, is somehow limiting the realism, because it doesn't have the full range of capabilities across all Apache D variants, from other operators.

Because you're limiting the capabilities of the airframe to something that is determined by doctrine and procurement. The airframe is realistically capable of more. It is realistically the operator (and time frame) choice that should impose the limit. And the game already supports that additional level of realism just fine.

[Northstar98]

4 hours ago, Tippis said:

They do if you click the button that makes them do so…

Again, the framework is already there. It's just not being used to its fullest because limitations keep being added in the wrong place.

 

There's GPS and weapons and that's completely it, it absolutely does not change an aircraft variant into being something else. And ultimately a whatever circa whatever as used by whatever that normally has GPS, but has it turned off is still representative of whatever it is - it doesn't change anything.

 

Quote

It apparently does since that's what this demand for restrictions always come down to: “oh no, can't have that for this operator at this time!” It keeps being brought up as an argument, and now here you come saying that it doesn't matter when it comes to the ME, where it actually does already matter (there's a restrict by year button already; GPS availability is set by the date; warehouse limits can be set, but it's not tied into the system because reasons).

 

None of which change an aircraft into being another variant.

 

If I take our mid-ish 2000s USAF/ANG F-16CM Block 50 into a fictional scenario, where I fly as Denmark set in the 80s, take away its AMRAAMs and GPS guided munitions, disable its GPS and don't allow JHMCS etc it's still a USAF/ANG F-16CM Block 50 circa mid-ish 2000s. What I haven't done by doing that is turn into a Danish F-16A... 

 

Now I can try and approximate other variants, by weapon restricting and basically turning things off, but it's exactly that - an approximation, and how well the approximation works depends on which aircraft you're trying to approximate; in the case of the F-16CM however, it's very difficult to approximate anything other than a post CCIP F-16CM Block 50.

 

Quote

That's just it: they can still do that. Both can happen at once. The specifics just need to be tied into the restriction frameworks already in place, and then they can deliver every Apache variant under the sun (subject to data availability) and develop something specific. Thus, all aspects of accuracy and realism would be fulfilled.

 

Well, if they can provide everything under the sun so be it, but then they might as well just do multiple variants.

 

The thing is, they aren't providing something intended to be universal, everything variant, they're doing something specific. I take the view that if they're going to (at least try) and do something specific, they should stick to it where they can.

 

Quote

It isn't that, for one. It's already been made quite clear that they're adding a mish-mash of things that they can get their hands on, and calling it a specific version that it is not. It should be anything other than precisely that because it already is, and because they have already demonstrated in other modules that this kind of supposed specificity is only a feigned excuse for not implementing things they have no data on.

 

But a lack of stinger ATAS, is accurate to the Apache variant they're doing! It hasn't got anything to do with data, it isn't realistic for the aircraft they're doing.

 

Quote

And that's ok, or would be if they could just be a bit more honest about the reasoning behind it. Data availability is an excellent excuse because there's just no arguing against that: you do what you can do; you leave out what you can't.

 

But then if there's no other option, if there is a lack of data available, what are they to do? They can still pick a project and have it be something specific, just because it isn't 100%, it doesn't invalidate it. But this is also a brilliant highlight that it's supposed to be 'as realistic as possible' - it's almost a near certainty that something will be inaccurate - the solution should be to correct the inaccuracy, where we can.

 

I don't know, I just don't see it in this all or nothing way, where if it isn't 100% pure, it being specific is somehow invalid. Though I agree they should be more honest about these things, and the reasons why xxxx was left out, and they should be consistent about the rules.

 

Quote

If we want to talk about simple, let's try this on for size: I'm simply tired with this whole edifice of fake accuracy and arguments from “realism”, when the fact of the matter is that completely different considerations and reasons are what decide what we get.

 

How is a US Army Apache, which doesn't have Stinger ATAS, getting ATAS, realistic?

 

You can go on about doctrine and politics etc, but the only thing is relevant is what's accurate for a US Army Apache, for whatever timeframe it's supposed to be.

 

And I'm sure you're correct about the decisions being made for whatever reason (though a lack of documentation, does seem to be a pretty reasonable one), but if we're to get a US Army blah blah blah, then the realism argument absolutely holds.

 

Quote

And if we tear down that edifice and just accept what ED does and why, there's very little reason not to include all kinds of things and let the players decide what to use and not. Give them the tools to make that decision more easily, and let's all stop with this self-deception about what the game offers.

 

If ED delivers a universal Apache where we can swap out anything and everything (which includes the engines for UK Apaches) then I agree. But they're not doing that, they intend to deliver something specific, at least where they can so why should it be anything other than that?

 

I'm worried that we'll have a Hornet situation, where things the aircraft actually should have are left out (Nite Hawk and VS mode to name just a couple), and things it shouldn't have get added in. 

 

Quote

Basically,

On the one hand: timeframe and operator matters (it's a US Army variant circa 20xx).

On the other hand: timeframe and operator doesn't matter (I've given it to Cuba in 1965).

 

Either it's really important and the operator and timeframe should dictate everything, or it's not that important and we can do whatever. But suggesting that the former must be preserved at all cost and the latter is fine is… incongruous.

 

This entirely relates to the design of DCS.

 

The assets and maps - the building blocks if you will, are to be as realistic as possible where feasible.

 

The scenarios you make out of said building blocks however, are completely sandbox; they can be as fictional or as realistic as you like (though there will always be something missing, so in a way they'll always be some element of fiction in there). How you operate and use the building blocks and what building blocks you use for a mission, is completely up to you.

 

What's the problem? I personally think that's the best way of going about it - it isn't all or nothing.

 

You can have an asset or map be realistic, but the mission be fictional, and the mission can be fictional even if it is somewhat grounded in reality. I disagree that it's incongruous, I think it's fine to enforce one thing and not the other, in this instance. If you enforce the latter what are you left with? Shall ED delete or restrict the mission editor?

 

I never said that the operator and timeframe should dictate everything, my whole argument is solely if you're going to provide something specific, then it should be that specific thing, as accurately as possible.

 

I honestly couldn't care less what missions you build, it's your mission, your scenario, you build it and fly it however you please. I think that's the best compromise between offering something realistic, and providing a sandbox. The assets and maps should be as realistic as possible, but the mission is a sandbox. 

 

Quote

The part where it actually ends up as y, and the reasons given is that it's somehow more realistic that way, when there are far more intelligent, credible, and transparent reasons why that's the end result.

 

But here not getting Stinger ATAS is more realistic. It getting Stinger ATAS would facilitate x being made into y. And so far what's made it y to you is some inconsistency, that's present due to a lack of data... 

 

Quote

Almost as simple as making it generic and universal, and letting the framework to restrict specific fitting (and entire airframe) options do its thing. Again, there is really no conflict between the two.

 

So essentially this whole thing boils down to the fact that you essentially don't want a US Army Apache and it represent one as it was circa xxxx, at least in regards to these elements?

 

You instead want an all encompassing Apache, that can be tailored to whatever operator at whatever time.

 

I agree, and that is a much more preferable option, and it avoids this whole debacle in the first place. However, ED are not providing a universal Apache, they are stating that this is to be a US Army AH-64D blah blah blah, you know the rest. It might not be 100% but the intention should be there. 

 

Quote

Because you're limiting the capabilities of the airframe to something that is determined by doctrine and procurement. The airframe is realistically capable of more. It is realistically the operator (and time frame) choice that should impose the limit. And the game already supports that additional level of realism just fine.

 

Which would be true if we were to get something generic and universal, with all the different fits available. But we aren't getting that, we're getting something intended to be specific. And even if it is a hodge-podge of years (which is subject to change - again inconsistencies should be corrected where possible), it still isn't accurate for a US Army Apache.

Edited May 2, 2021 by Northstar98

[Reticuli]

On 1/18/2021 at 5:54 AM, Cunctator said:

I've only seen images of Japanese AH-64Ds carrying the wingtip mounted Stingers. Obviously not a capability that was necessary for real world conflicts in the last decades, but it would be very nice to have in DCS were things are more balanced.

ED are decent sim-makers and poor game-makers.

[Tippis]

4 hours ago, Northstar98 said:

There's GPS and weapons and

…aircraft and ground units and ships. It's a reasonably new feature, and it's still obscure enough that it occasionally confuses mission makers who wonder where all their planes when, but it's there. It's an existing framework that works, and which is the appropriate mechanism and methodology to limit what's available based on time frame and parties involved.

 

Oh, and turning GPS off by setting the (in)appropriate date changes a whole lot with quite a few aircraft and carried systems. They get mightily confused if they no longe have that signal to align and navigate by.

 

4 hours ago, Northstar98 said:

None of which change an aircraft into being another variant.

But it should. Or rather, it should change what that variant can carry, same as it could IRL if we were to look at the appropriate date rather than narrowly stare at whatever state it was when it rolled off the factory floor… which, as mentioned, ED isn't even doing to begin with. So it has already been changed into a different variant, and the basic idea of doing a specific batch number or whatever is right out the window from the very start — it's just a fabrication to avoid the much more reasonable “we can't get the data” excuse.

 

4 hours ago, Northstar98 said:

Now I can try and approximate other variants, by weapon restricting and basically turning things off, but it's exactly that - an approximation, and how well the approximation works depends on which aircraft you're trying to approximate; in the case of the F-16CM however, it's very difficult to approximate anything other than a post CCIP F-16CM Block 50.

And, once again, the point is that we're already getting such approximations. Because almost without fail, we always get an aircraft that doesn't actually match the stated variant it is supposedly built around.

 

4 hours ago, Northstar98 said:

The thing is, they aren't providing something intended to be universal, everything variant, they're doing something specific. I take the view that if they're going to (at least try) and do something specific, they should stick to it where they can.

But they aren't sticking to something specific. And in many cases, the additional capabilities that would let them do multiple specific things are in the game — in fact, the thing that is missing the most in making that specific thing happen is a lack of mission-editor tools to restrict availability. What I'm arguing for here would achieve the goal you're after better than the way ED has historically (and by all accounts with the Apache as well) chosen to implement that specificity.

 

4 hours ago, Northstar98 said:

But then if there's no other option, if there is a lack of data available, what are they to do?

They can say so.

They can also do that and not have to rely on all kinds of logical acrobatics to justify the lack of some systems (that might be appropriate) while also including others (which might not). Drop the pretence of doing something specific since that's not what ends up being delivered anyway, and instead use (and maybe even expand) the existing framework and mechanisms available in-game to be specific if you want to be an absolute purist as far as what version can carry what.

 

This requires a very tiny amount of extra work; a whole heaping of extra honesty; and it leaves everyone much happier since all their disparate wishes are fulfilled at once.

 

4 hours ago, Northstar98 said:

How is a US Army Apache, which doesn't have Stinger ATAS, getting ATAS, realistic?

It isn't. But having it be restricted by the operator you choose rather than by the simulation of an airframe that can indeed carry that system is.

 

But they're not doing that. Instead, they're adding a version that has capabilities beyond what that version should have. And if they're already going down that route, the whole notion that some other system that it also doesn't have is somehow what tips it over into being unrealistic, is bunk.

 

This is a critical point that needs to be reiterated: the idea that they're doing a specific version is not actually true.

Now, this may indeed be seen as a kind of reverse slippery-slope argument: instead of saying “don't do X, because they'll do Y next!” I'm basically saying “they're already doing X, so they might as well do Y”. It's just that I want both X and Y in this case to be fitted into the mechanics and frameworks the game has on offer to let the mission-designer decide whether either X or Y should actually happen.

 

4 hours ago, Northstar98 said:

This entirely relates to the design of DCS.

 

The assets and maps - the building blocks if you will, are to be as realistic as possible where feasible.

 

The scenarios you make out of said building blocks however, are completely sandbox; they can be as fictional or as realistic as you like (though there will always be something missing, so in a way they'll always be some element of fiction in there). How you operate and use the building blocks and what building blocks you use for a mission, is completely up to you.

 

What's the problem? I personally think that's the best way of going about it - it isn't all or nothing.

But that's just it: the game doesn't actually fully allow for those building blocks to be built with in a good way.

 

It shouldn't be all or nothing — I agree with you there — but the way they're doing it, it is exactly that. The modules are wholly monolithic. With the exception of some weapon restrictions (and this feature is brittle as all hell and regularly breaks in all kinds of curious ways), what a module comes with is that it has. All or nothing. And yet, there are multiple features that could loosen up that restrictiveness (ironically, by letting us be more restrictive) if they were just made more stable, universally applied, and even expanded upon.

 

4 hours ago, Northstar98 said:

So essentially this whole thing boils down to the fact that you essentially don't want a US Army Apache and it represent one as it was circa xxxx, at least in regards to these elements?

No. It boils down to me wanting them to let the existing functionality to restrict availability of [whatever] be the thing that restricts availability to [whatever and its dog]. Because it's already there, and it's already appropriate for dealing with the mish-mash of functionality we're getting for all kinds of different airframes.

 

It is also a matter of wanting ED to be more honest and transparent in what goes in and why, rather than rely on the trite and often clearly untrue “not realistic for this version”.

 

4 hours ago, Northstar98 said:

Which would be true if we were to get something generic and universal, with all the different fits available. But we aren't getting that, we're getting something intended to be specific.

Except we're not getting something specific either, and this is a pattern we've seen with a whole bunch of recent developments — the Hog2, the Viper, BS3, and now the Apache. Intent is cute and all, but it is wholly divorced from the reality of what we're getting.

 

[Northstar98]

3 hours ago, Tippis said:

…aircraft and ground units and ships. It's a reasonably new feature, and it's still obscure enough that it occasionally confuses mission makers who wonder where all their planes when, but it's there. It's an existing framework that works, and which is the appropriate mechanism and methodology to limit what's available based on time frame and parties involved.

 

It controls availability, but it doesn't change an aircraft variant at all...

 

Quote

Oh, and turning GPS off by setting the (in)appropriate date changes a whole lot with quite a few aircraft and carried systems. They get mightily confused if they no longe have that signal to align and navigate by.

 

And it still doesn't change the aircraft variant.

 

An F-16CM Block 50 is still an F-16CM Block 50 even if its GPS is turned off...

 

Quote

But it should. Or rather, it should change what that variant can carry, same as it could IRL if we were to look at the appropriate date rather than narrowly stare at whatever state it was when it rolled off the factory floor.

 

Okay, so we don't care about variants at all anymore, and it only relates to payloads and nothing else?

 

You seem to be doing a lot of picking and choosing here, it sounds like such a thing would make it even more inconsistent, and less realistic.

 

Like giving an 80s Tornado GR.1 brimestone to turn it into a GR.4, though with none of the GR.4s other upgrades. 

 

Quote

which, as mentioned, ED isn't even doing to begin with. So it has already been changed into a different variant, and the basic idea of doing a specific batch number or whatever is right out the window from the very start — it's just a fabrication to avoid the much more reasonable “we can't get the data” excuse.

 

So far it only looks like the years maybe aren't matching up... I've seen nothing to suggest it's something other than at least a US Army Apache, which still doesn't have ATAS unless it's an AH-64E.

 

And what on earth are you talking about? Something being specific being used as a scapegoat, for a lack of data?

 

How about the radical idea of we'll pick a specific variant, to limit project scope and to keep it consistent, and if we can't get the data on it, then we either A.) have an inconsistency (e.g the LITENING on the F/A-18C, using Spanish documentation), B.) not include it at all.

 

Quote

And, once again, the point is that we're already getting such approximations. Because almost without fail, we always get an aircraft that doesn't actually match the stated variant it is supposedly built around.

 

No, it just doesn't match it with absolute purity, no deviations at all.

 

Quote

But they aren't sticking to something specific.

 

They (hopefully) are sticking to something specific, where possible. You keep ignoring those 2 last words...

 

Quote

And in many cases, the additional capabilities that would let them do multiple specific things are in the game — in fact, the thing that is missing the most in making that specific thing happen is a lack of mission-editor tools to restrict availability. What I'm arguing for here would achieve the goal you're after better than the way ED has historically (and by all accounts with the Apache as well) chosen to implement that specificity.

 

But you'd need a universal variant to begin with that can be tailored to whatever specific. And you seem to only be in favour of keeping the payloads universal, to fit any variant, but not things like the avionics, or even engines (in the case of the WAH-64D).

 

Quote

They can say so.

They can also do that and not have to rely on all kinds of logical acrobatics to justify the lack of some systems (that might be appropriate) while also including others (which might not).

 

Why can't the solution be, fix the inconsistency?

 

If it is a lack of documentation, or some other infeasibility problem, then it isn't logical acrobatics

 

Quote

Drop the pretence of doing something specific since that's not what ends up being delivered anyway, and instead use (and maybe even expand) the existing framework and mechanisms available in-game to be specific if you want to be an absolute purist as far as what version can carry what.

 

I'm honestly just repeating myself at this point...

 

Quote

It isn't. But having it be restricted by the operator you choose rather than by the simulation of an airframe that can indeed carry that system is.

 

But it's supposed to be operator specific in the first place! So no, it isn't realistic.

 

Quote

But they're not doing that. Instead, they're adding a version that has capabilities beyond what that version should have.

 

I haven't seen anything to suggest something incongruent to a US Army Apache, so Stinger ATAS still isn't accurate.

 

Quote

This is a critical point that needs to be reiterated: the idea that they're doing a specific version is not actually true.

 

No, they (at least should), be going for whatever variant they're supposed to be delivering and if there are inconsistencies, fix them where possible. If it isn't possible, then we can make a concession, because there isn't much in the way of alternatives, if they do want to stick to some specific variant.

 

Quote

Now, this may indeed be seen as a kind of reverse slippery-slope argument: instead of saying “don't do X, because they'll do Y next!” I'm basically saying “they're already doing X, so they might as well do Y”. It's just that I want both X and Y in this case to be fitted into the mechanics and frameworks the game has on offer to let the mission-designer decide whether either X or Y should actually happen.

 

So essentially, if it isn't 100% pure, any specificity is invalid and therefore it should be open to basically everything, at least where the payloads are concerned.

 

Quote

But that's just it: the game doesn't actually fully allow for those building blocks to be built with in a good way.

 

Yes... But that's mainly due to a lack of reasonable/feasible coherency among maps and modules. Which was part of a wider issue discussed here.

 

Quote

It shouldn't be all or nothing — I agree with you there — but the way they're doing it, it is exactly that. The modules are wholly monolithic. With the exception of some weapon restrictions (and this feature is brittle as all hell and regularly breaks in all kinds of curious ways), what a module comes with is that it has. All or nothing.

 

I don't understand - the explicit goal is that the modules, assets and maps should be as realistic as possible, but the scenario is up to you. That's what I was referring to...

 

Quote

And yet, there are multiple features that could loosen up that restrictiveness (ironically, by letting us be more restrictive) if they were just made more stable, universally applied, and even expanded upon.

 

But that would require getting a unicorn variant to begin with, right now you've highlighted that something specific isn't 100% pure whatever specific thing and therefore it is a universal variant. 

 

Quote

It is also a matter of wanting ED to be more honest and transparent in what goes in and why, rather than rely on the trite and often clearly untrue “not realistic for this version”.

 

Except the "not realistic for this variant" is almost exactly accurate, it just applies to whatever specific variant they're doing, where it is actually true.

 

You just seem to think that because it's not 100% pure, the specific variant is invalid, and therefore the "not realistic for this version" is untrue. 

 

Only, if we are trying to get something specific, then it absolutely isn't wholly untrue.

 

Quote

Except we're not getting something specific either, and this is a pattern we've seen with a whole bunch of recent developments — the Hog2, the Viper, BS3, and now the Apache. Intent is cute and all, but it is wholly divorced from the reality of what we're getting.

 

No idea about the Hog 2 or F-16CM, though it might look like we'll be getting M5.1 instead of M4.2/4.3 - will have to see what SMEs think. BS3 is entirely hypothetical anyway, so I don't think we can hold it to the same standard, and the Apache isn't released yet...

Edited May 2, 2021 by Northstar98