Feel vs Real

[Tank50us]

Now, before people grab their pitchforks, let me explain my meaning. Yes, DCS is a study level sim. Yes, the aircraft are real birds. Yes, I'm going to buy many of these planes eventually anyway. My point is that I think that companies should aim for the idea of making the general feel of a plane, rather than the exact model of one.

For example, many of us know that the AH-64D can mount Stingers on the wing-tips, but ED has stated that they do not intend to add that feature, because the specific model of AH-64D doesn't use them, and the same with the F-16. Foreign buyers have bought equipment to mount weapons like Harpoon and Sparrow, but the version of the Viper we have won't ever get it, because that specific block doesn't use it.

My proposal is basically to do more of what Heatblur is doing with the EF-2000, get the general feel of the aircraft, and leave out the specific blocks (sort of). How would this work? Well, let's use the often requested F/A-18F as the prime example (no, I'm not requesting it here, I'm just using it as a primary example).

The F/A-18F comes in several blocks, and externally, most of them look very similar (easily close enough that the average person can't tell the difference), and thus, certain blocks could be simulated by changing out certain systems in the mission editor. Sure, you have your defaults and presets, but with the right changes, you can have an almost completely customized Super Hornet that might not be in service in the real world, or you might be able to simulate a specific buyers Super Bugs with the right equipment added or removed. You could even swap the gun for jamming equipment and turn it into a F/A-18G. Obviously this will affect the flight model of the aircraft, but these things can be accounted for during the production, and refined as time goes on.

Done right, this could make it easier to have different cockpits out the gate. For example the F-15C could be easily 'converted' into an F-15J by swapping out the American pit for a Japanese one (both in terms of language, and the JASDF specific modifications), and maybe even allow for certain player cockpit mods (like sticking your fatal family photo somewhere on the dash).

What do you guys think? Would you buy a module if it was open to some customization options? Or would you prefer that only very specific versions of the aircraft get added. I would prefer the former myself, but that's just me.

[LucShep]

That's an interesting and tricky conumdrum. And I'd imagine it's one that most developers (ED or 3rd parties) considered to some extent in the past.

Personally, I wouldn't pass a purchase or criticize a module if it was a more "get the general feel of the aircraft, and leave out the specific blocks (sort of)", as you mention.

But............... and ignoring the rivet counters "ubber realism natzis" in the crowd, you really have to draw the line somewhere. And this is where things can get very complicated.
Not doing a specific block, when there can be drastic differences, even beyond armament and such, likely will cause more problems than doing a specific single one.

One example I'll use to ilustrate my point is, for instances, the F-14 Tomcat. So, we got the A and B. And there's the D that we're missing, the more modernized version (and last to fly in service with the US Navy).  Each of them has major differences.
How'd one aproach the F-14 Tomcat as a DCS module in the way you suggest would be complicated and, most likely (just my guess), also very controversial, really divisive. 
And one could use pretty much every module we have to present the same problem.

It's problematic and, to be frank, I admire the developers because they tend to lock themselves pretty bad into a small corner when chosing a specific version/block. Chosing the right one isn't easy, because there'll always be someone that would want "that other one" instead, maybe even criticize the devs for that.

I like the aproach that AERGES has used for the Mirage F1. There's more than one version of the aircraft, and it can then encompass different "tastes" (of interested buyers), making it a more "democratic" product for more people, more potential missions/campaigns and use cases.
The problem here is, I guess, higher overall cost, be it in time and work on development, and final price for the customer.

Think about it, it's a "damned if you do, damned if you don't" situation, isn't it?

My suggestions is not an easy one either.
I think that it is at this point when the top modders should step in, better if with some sort of "semi-official" support (off the record) for quality control.
That would go a long way for the benefit of the respective module and its public/users, as it would also make such mod(s) easier on their "adoption" for module users.  Making everybody happy as a result.

I'm not affiliated by them in anyway but, merely as an example, check what the IDF Mods Project are doing with the F-16I Sufa and the F-15 Baz. Both are interesting aproaches for different versions of two popular aircrafts that, I presume, many of its module users will feel atracted to at least have a look (on youtube or a test after downloading).
And there are many other really tallented modders (single or group) worth of attention out there. These are the guys that can try to do what the devs can not.

Edited August 24, 2022 by LucShep

[cfrag]

6 hours ago, Tank50us said:

ED has stated that they do not intend to add that feature, because the specific model of AH-64D doesn't use them, and the same with the F-16

I've always felt that this rationale was a little bit too convenient. But the fact is that adding these or other things make the product more complex: to create, to maintain, to document, to integrate. So I understand when ED prefers to keep the rise of investments in check and try to avoid feature creep (which is the death of all software).

On the other hand, there are the customers who wish for more, and who (like I do) would just *love* to have (insert favorite feature here) for DCS. Beside cost, there is no argument to be made against adding these to a software product as long as the additions are optional. That way purist can choose not to use Stingers on the Apache, or auto ARA for the Hog, while other people enjoy some greater QoL or a spike in fun. 

In the end, it's ED's game, and they are the sole arbiters of what they include in their game. There are many things that I wish they include in their products. And I wish that if they decide not to include something, they'd be more straightforward about it: simply say 'No.' - They have a great product line and they don't need to justify their choices. Trying to shift the blame to some (in software terms) irrelevant "it's not there in the real world" seems a bit out of place for a company like ED and begs for an immediate comeback along the lines of 'So? Neither is a three-minute repair'. 

Do I want Stingers on my Apache? Yes. Do I accept if ED says "no"? Yes. Do I accept their rationale for not including them? Hell no. I prefer a straight answer 'Not planned.' Fair enough: your product, your rules. 

[Northstar98]

I think that picking something specific means we should get a much more clearly defined scope that's easier to research, develop, check and finish. If I develop a unicorn version, I have to find out how to develop all of its features, which means taking the amount of work I'd need to do to research and develop it and then just multiplying it.

By sticking with a specific aircraft from a specific operator at a specific point in time, it vastly simplifies the research and development involved and reduces the work needed to complete a product. If you can do a unicorn variant and limit it to be something representative of something specific or there's an aircraft where doing more of a unicorn variant actually probably better represents the real fleet of whatever aircraft (as is exactly the case with the Eurofighter) then fine.

We already have plenty of trouble just getting features these aircraft should have as it is. Worse, there are also items that are perfectly accurate to the specific scope, that have either been taken off of the list of planned features or aren't planned at all. The last thing we need here is to massively increase the scope of modules.

And personally, the solution here is to do what Aerges is doing: offer more variants. I'd much rather get my preferred variant than try to fudge a module into being something it's not and ultimately end up with a more of a mess that isn't really accurate to anything.

Here I'm firmly in the real camp rather than feel. I want DCS to give me building blocks that are as representative of their real life counterparts as possible while keeping the scenarios I build sandbox and completely up to me. Fortunately this is more-or-less the mission statement of DCS and while some might say "that's just marketing" I don't see why we would want products that purposefully go against their marketing rather than products that try to better conform to them.

Quote

And I wish that if they decide not to include something, they'd be more straightforward about it

They aren't straightforward about it? the roadmap threads make it very clear what they're intending to develop. When threads inevitably come up asking for things outside the scope, they say "not planned or realistic for version".

Quote

They have a great product line and they don't need to justify their choices.

Nah, I'd rather they justify their choices than not, especially for items that fit within their limited scope. In those cases it makes it look like they either bit off more than they can chew, or didn't know what they were getting into.

Quote

and begs for an immediate comeback along the lines of 'So? Neither is a three-minute repair'.

Which then begs for the immediate comeback along the limes of: And?

I'm sorry but as common as this argument is, it's just specious whataboutism and all it does is appeal to perceived hypocrisy without actually addressing the argument being made. Especially when far more often than not, it compares examples that are completely unrelated, like the examples you just gave.

[cfrag]

31 minutes ago, Northstar98 said:

They aren't straightforward about it?

Not if they justify a decision with "because the real thing doesn't have it". That's a cheap cop-out, and we all know it. I have no beef with a straight "No", and actually prefer it because it won't lead to discussions like this.

35 minutes ago, Northstar98 said:

And?

That's entirely my point: their product, their rules. No beef.

 

[Hiob]

When I read the title, I assumed, the topic would revolve more around things like exaggerated sounds to compensate for a lack of haptic feedback e.g. (I would totally support that!)

Regarding the discussion about stretching the scope of the simulated aircraft to incorporate more or different weapon systems and such, I'm more on the "their product, their rules" and "love it or leave it" side.

18 minutes ago, cfrag said:

That's a cheap cop-out, and we all know it.

That's a bold claim... I certainly don't support that statement.

[Northstar98]

36 minutes ago, cfrag said:

Not if they justify a decision with "because the real thing doesn't have it". That's a cheap cop-out, and we all know it.

Is it though? Or is it completely inline with the stated scope of the module, which more often than not, is exactly the case?

If the stated scope is aircraft version x, as operated by y, circa z timeframe and a wishlist thread comes up asking for a feature that is outside that scope, then the answer is no for precisely the reason that "the real thing doesn't have it". There's no cop-out about it - saying something isn't accurate for the module your making when it isn't is absolutely true and valid.

Now I will say that ED should be more straight forward about what they're planning to deliver on the store page where you buy the module, instead of being just a wikipedia-ish overview of the aircraft in general. That way it's clearer to customers exactly what they're buying and what they can expect.

36 minutes ago, cfrag said:

I have no beef with a straight "No", and actually prefer it because it won't lead to discussions like this.

So, you're okay with the answer, you just take issue when you're told why.

I mean, you do you, but seems a little odd.

36 minutes ago, cfrag said:

That's entirely my point: their product, their rules. No beef.

Yeah, but that's not what that argument implies.

[Evoman]

Your best realistic option is going to be for multiple variants. That way you can chose the variant that's your particular cup of tea for the mission at hand.

With the the new Mirage F1 plans of there being future variants, it should prove to be a very interesting strategy that might be popular enough to show that its worth doing multiple variants for the developers if the variants are not too drastically different.

Edited August 24, 2022 by Evoman

[Exorcet]

This is similar to the issue of having experimental weapons, etc.

ED/3rd party/whoever should model an exact plane. Then in the ME we should have options in the form of checkboxes to enable features to simulate other models or experimental versions.

Example, the F-14 as modeled by HB should have no AIM-120's unless there is a tickbox option for. A normal historical mission would have the tickbox unchecked, but if someone wanted to do alternate history or a campaign involving a modified test Tomcat, they'd check the box to enable AMRAAM carriage.

[upyr1]

On 8/23/2022 at 7:55 PM, Evoman said:

Your best realistic option is going to be for multiple variants. That way you can chose the variant that's your particular cup of tea for the mission at hand.

With the the new Mirage F1 plans of there being future variants, it should prove to be a very interesting strategy that might be popular enough to show that its worth doing multiple variants for the developers if the variants are not too drastically different.

 

The ideal solution. ideally a module should be a highlight reel 

[upyr1]

On 8/24/2022 at 5:59 PM, Exorcet said:

This is similar to the issue of having experimental weapons, etc.

ED/3rd party/whoever should model an exact plane. Then in the ME we should have options in the form of checkboxes to enable features to simulate other models or experimental versions.

Example, the F-14 as modeled by HB should have no AIM-120's unless there is a tickbox option for. A normal historical mission would have the tickbox unchecked, but if someone wanted to do alternate history or a campaign involving a modified test Tomcat, they'd check the box to enable AMRAAM carriage.

As long as something has been tested, a what-if load out might be fine. Though I would prefer to keep to what was fielded 

[Tank50us]

21 hours ago, upyr1 said:

As long as something has been tested, a what-if load out might be fine.

Yeah, that's how I feel about many things in DCS. If an aircraft has been tested with a certain weapons load, then that weapons load should be available, but disabled by default and capable of being enabled in the Mission Editor. For example, the F-16C Block 50 has been tested with the AGM-84 Harpoon, and a couple buyers did get that equipment. But ED says no, because the version they made is a USAFNG bird, and doesn't have it.

[Evoman]

In my opinion it would be better if other weapons were available through a different variant that actually used them. A good example of this is the F-15I. There have been recent mentions by RAZBAM of them possibly doing a F-15I variant of the Strike Eagle which is a very unique Israeli version.  In this case it would make better sense to just have the different weapons systems available through a different variant that actually employed them since there weapons systems were epitomized to use them.