zerO_crash

Nice work, STONE SKY! Quality stuff, no doubt! One question with regards to the skins included in the campaign: I noticed that the campaign comes with a multitude of liveries for, chief amongst, Mi-24P and Ka-50. I am, however, not finding them in the mission editor (under any Redfor country). I am specifically looking for the modern (digital) liveries. You know anything about that? Thanks in advance!

It would have to be a gradual implementation from pure manpower perspective, that as well as to get feedback. As to the module which should have it first, I'm sure it wouldn't be a problem to either do one or another. The point is, the differences wouldn't be huge overall, but you would have a fresh thrill and uncertainty whenever you fly an airframe. It would also give a prospect of realism, and just how different one and the same airframe can feel. I recall a former SR-71 pilot mentioning that even among one of the most expensive airframes to take to the sky, there were differences. There were SR-71s that were easier to perform aerial tanking with (trim + throttle setup), and there were ones that you had the feeling of holding back all the time, as they wanted to constantly accelerate. There were more and less liked bort numbers. I have heard/read pilots mention this in many aircraft, chief amongst helicopters, where due to the delicacy of the controls, the differences are more noticeable. The reality is, that whilst you might have time behind the stick of an aircraft type, you are always going to treat the start with a bort as a new one, getting accustomed to how it feels. As mentioned, this goes for all machines made. That is a sensation, which I honestly believe should be in DCS.

Absolutely, hence why the option to toggle it on/off would fit well. In a sense, we cannot avoid the backlash from forums, as there are threads popping up every day, which are often repeating what was asked two or three months ago. If a general announcement would be made in a newsletter, and additionally a mention in the manual, then legally, ED would have done more than enough. We cannot avoid those who won't bother to search the forums, before posting themselves. This would actually go well along with the maintenance system. Not that we know much about it. The non-linear controls though, should be there irresponsive of freshness of a given aircraft, albeit with a additional "slack" adding over time (maintenance status). That would really enhance what we have today in terms of feedback, and actually represent reality very well! Neat stuff!

Good stuff!

I imagine, that if ED set a standard, then 3rd parties would follow in order not to pose as less capable. As to the modules themselves, well, one has to start somewhere. Overall, in DCS, the quality of the modules does seem to be pretty leveled out. That, taking into considerations time apart and technologies used when they were made. I don't really see anything more than issues/bugs, that might take some time fixing. That said, I'd still claim that members of the forum are often u realistic with regards to implementatio /fix times. Let's not forget how DCS has changed since MiG-21Bis got introduced. Before that, we had FC, Ka-50 and A10C, for years. There were also far less complaints about lack of content/updates. Ultimately, there are only a few select modules (MiG-21Bis, possibly other HB modules), which due to their far-reaching goals, had to find ways to achieve their objectives. That, in often a cluncky way, which then poses issues upon updating major parts of the module. That, however, does not seem to be the case with most modules in DCS, though. Consider BS3, Mi-8MTV2 co-op capability (this is pretty major of an update), SA-342 Gazelle, Mirage 2000C (major updates there over the years, both in terms of visuals, as well as objects and systems), etc... All these modules seem to accept updates, without having to rebuild it from scratch (MiG-21Bis is really an unfortunate example). If to make it simpler, include only the non-linear controls, and much is done already. The reason I'm mentioning a whole line-up of interesting features, is sinply the fact that to make the return on investment for ED/3rd parties better, it should be a component-based system which would allow to include other individual tweaks and functionality in an integrated framework. That way, there might still be differences between what each and every 3rd party includes (the differences haven't been any major so far) in their module, however the framwork/interface/layout is there. It's be a great step forward.

What Heatblur is making, is somewhat similar. My suggestion expands to non-linear controls, and more. This is a further step in the direction of realism. Some modules have singular aspects concerning this case, however a uniform implementation would be desirable. Realism all the way, but remember also that what I'm talking about, are systems working, albeit with a realistic touch of quirks and individual cases. One engine running hotter is good, however what you mention further, are reasons to abort flight/random system failiure. Indeed, radars would be a good step as well, although it can be as basic of an implementation as different illuminosities of the radar screen or such. The point is, I'm not asking ED to simulate dead pixels on MFDs (yet). Rather something that is much more common, primarily non-linear controls. This is normal for any aircraft, and even FBW doesn't alleviate the peculiarities fully (there will be better and worse actuators, e.g.). That's, what I'm mainly pushing this for, however ofher systems would be great to (precisely like Heatblur is doing, and that's a fantastic new direction to expand in).

I am not going to speculate on the work required. That is really for ED to decide. Ultimately though, I thought through it before, and I don't really see where there would be that much work. Realising that DCS is a ecosystem (especially modules with their system's integration), if you change one parameter, other, will often get affected. With that said; - For engine/oil/etc... temperatures, I imagine that the engine model could be tweaked for a delicate +-20 (approx.) degrees temperature range, without the need for too much else work. The difference in resulting engine power would vary as well, all according to ED's model. - Peculiarities regarding gauges, is really a matter of having them react slow/fast/oscilate. Granted, it has to be solved in a way resembling the quality of the systems themselves, thus, it might be more than just "change the number". - HUD/taxi-light/search-light/etc... - have a factor for brightness. Assign a random brightness value to the different layers. - Delay in component reaction-time, much like gauge - assign a slowdown/screen flicker/and more value. The big question is of course, whether ED would have to create completely new functions for these peculiarities, or whether it would demand the creating of new code-strings. Again, ultimately, ED would have to judge whether this is in the vicinity of doable or not. The end game though, would really be a new level of simulation bar none (not even professional ones, as far as I know). As to bug reporting, yes and no. If the function would be implemented by a toggleable function, than most people would know what they activate. On the other hand, I never underestimate sticky fingers and lack of reading capacity. Whilst we already do have a lot double, tripple and quadrupple questions being made on the same topics, the simple solution is - do comment to someone spending time flaming rather than studying manual. There would be some bug reports, no doubt, but I imagine that just as Heatblur's F-14 (mixed cosmetics of the cockpit), after the initial introduction, the community would adapt (those that wish to activate it at first). That's also precisely why I recommend to have it toggleable (individual module settings, not server). There will always be someone who doesn't like it. In this case, all needs are satisfied, and DCS really becomes unique in yet another aspect.

People tend to forget in their flawed comparisons with "games" out there, that DCS, while still being optimized and brought forth to modern standards, is far beyond in terms of sheer data being worked through. A map in DCS alone, is bigger, than a multitude of those games' copies. A module in DCS, can be more than 1/3rd the size of the other products' total install size. Then there is the part of actual simulation of avionics, systems, weapons and all other underlying components. If you do not understand the difference between a cockpit where gauges react to basic input alas speed/altitude (maybe a few other factors), vs. one where you have complete systems modelled (no magical input entered, instead, the whole chain of sensor - cable - computer - cable - component - cable - pilot interface), targeting devices and digital suites (MFDs which simulate software in software - basically more advanced than a complete product elsewhere), with much more, then you simply do not understand what you bought into. I won't even mention the fact, that DCS trashes flight models in basically any single one "simulator" out there. If not for DCS, I wouldn't even bother with having a high-performance computer, and I can guarantee you that you won't meet anyone more demanding than me. The comparisons drawn here, compare a military-grade (industrial) simulator adjusted for commercial market, to paper-plane sims. There is virtually no single comparison to be made, at any level. If you have a hard time grasping that, I invite to go into module-specific threads (for simplicity, WWII), and have talk there. You'll quickly find out what depth DCS goes into. Case in point; it is a very real problem of performance. The discussion becomes even more relevant, when VR is drawn into the picture. Whilst requesting new features is good, one ought also to understand that currently, we do not have hardware to run DCS maxed out in VR alone. When more powerfull hardware gets released, then it'll definitely be a valid point. Until then however, just toggling mirrors on/off currently, takes a severe FPS hit. I do not see how creating a more demanding system would be beneficial at the moment.

Hi, I'm wondering if it would be possible, to simulate (depending on aircraft) the sensation of individual controls sluggishness? In essence, it is a known fact, that with complex machines (often hand built), there are peculiarities in how each bort operates. Those can be differences in controls (uneven axis on collective/cyclic), where increments are not linear, one might shake more than another under given conditions, differences in neutral trim might occur, etc... This is an interesting spect, because pilots, often, have to get a feel for the aircraft that they are flying in the first stages of the flight (get accustomed to its peculiarities if you will). It gives a logical reason for wanting to do the required procedures associated with the airframe, and also shows, that the world isn't purely black/white. A pilot might have a better or worse airframe to his liking. This would really add another soul to DCS overall, where simply no other simulator models this. A possible way to do it, would be to have e.g. 20-50 different bort-layers, where each one would have their own peculiarities as mentioned above. A pilot, upon entering an airframe, would have a randomly selected layer (one of the reasons to have quite a few layers, is to avoid predictability/monotony), thus allowing for even a more immersive and realistic experience in aircraft simulation. The difference between the layers, could be not only in terms of controls' response and uniformity across their axis of movement, but also in the whole module: - Nominal engine temperatures (some running colder, some hotter - even individual differences between two engines on one aircraft) - Temperatures of oil/gearbox/etc... - Peculiarities regarding e.g. radar altimeters - HUD refreshrates and color/intensity (we all know they diminish/water down over time) - Taxi light intensity (search-light, or others) - Gauges reacting slower/faster to changes in parameters, including different imprecision-level in gauges - Delay/latency in component-reaction time (faster/slower ABRIS/MFCD, certain systems that might have a digital processor (and corresponding software) associated with them) - +++ Just as with any feature, I imagine there to be someone who dislikes it, thus having this as a selectable option (on/off), would likely make it just (at least in early implementation). Possibly, have it in the specific module settings, such that the feature can be tested before eventually wider implementation. I really hope that this gets looked at, as one of the reasons why simulators often feel isolated in nature, is that everything is ideal/perfect. We all know that IRL, this is not the case, whether it would be a car, ship, train or aircraft.

In Soviet/Russian tactics, the early systems had proprietary laser codes, as helicopter units (army) and planes (jets), never really communicated together. Having the same laser codes, would thus introduce the possibility of misguiding weaponry. Asking to add something that is not realistic, will not work. It seems like you should fly western aircraft, based on how you wish to use the systems.

A) This is not a whishlist thread. Use the appropriate forum. B) This has been discussed before, and the decision is decisive: C) The modules in DCS are most often specific bort/tranche representations, with few instances of a combination. As such, ED will never equip Ukrainian equipment on a helicopter which they specifically state is a Russian airframe representation. D) While an interesting concept, there is very little information on the topic, specifically with regards to effectiveness. All that's available, is qualitative data, and that is insufficient for modelling just about anything. There is a reason why IR jammers have been forgotten for nearly 2 decades, before their recent inception. Back in 80s, this technology, was simply immature. Beyond aesthetics, the system will do you most likely no noticeable difference. The more systems we have, the better. However, given the real world obstacles (manpower being among the main), there are other more pressing issues that the team needs to focus on. Additionally, the fact that the system got quickly dismounted after its initial introduction, just goes to show that it wasn't desired back then. That, works even more against us. This will not happen. As to the Ukrainian modification of the Mi-24s (mostly VP), they use this IR jammer: https://ru.m.wikipedia.org/wiki/АДРОС It was tested in 2004, and formally adopted in 2005.

I noticed brother, thank you for the update!

You didn't read closely what I wrote - Afghanistan, isn't designed by ED as a COIN environment, it is naturally a COIN environment, as there have never been any wars where Afghanistan figured as an opponent to a foreign attacked. There are actually many good missions, which have a randomness-factor associated with the mission build. That said, that factor is still designed by a mission creator. In other words, it is not a run-the-slot-machine-and-see-what-comes-out type of randomness (AI). Still, some well-designed mission do offer events occuring with a possibility tag attached to them. The problem is really that it requires knowledge of scripting, to perform. It is not a default tool in the mission editor, and that is a valid complaint. On the other side, who has ever worked with professional simulation, knows that scripting is the only way to go. That's just how it works. Regardless, if it was easier to build mission, based on observations from the mess consumers enacted in the "Afghanistan"-forums, I would not hold my breath for any more content or of higher quality. Until recently, one could have held their heads high up in this community, but with the recent chain of events (people proving they won't even read what's written), I see a different reality overall. Just a shame really. I digress; often, complaints orbit around ED not delivering content fast enough. Well, if Wags didn't have enough to do already (speculation), having to additionally go back to oral/visual content-making, indeed goes against what the community complains about all the time. To put it straight - because people are illiterate/not bothering to read, more manpower has to be diverted to making the product more "consumer"-proof. That, instead of allowing ED to divert all their capacity to relevant priorities. It is just a ridiculous turn of events, and all thanks to the grand wish of community. With regards to ground/sea/etc... operations, that had not been a priority, which is why it lags behind. If you'd ask customers about better AI vs. a new module, I imagine most would chose the second, purely based on instinct. ED has confirmed that it will be improved, but as everything, ot takes time. Arguing over something recognized, is pointless in itself. It will come. Patience, is key. In the mean time, I did list a couple of ways to mitigate thosr obstacles. The tasking in missions, is often limited to the designer's capacity and vision. Again, we already have tools to do many types of rather advanced scenarios, albeit not as easily available.

In light of the current Afghanistan announcement, the notion of currently only two coalitions, seems to be limited. In order to create ever more complex scenarios, an ability to have more than two coalitions would be great. Also, a basic menu (under coalition creation) to specify who, a given coalition, is friend/foe in relation to.

Afghanistan isn't intended to be COIN, it is COIN purely historically. There has never been a war in Afghanistan that was a country vs. country initative, in recorded history. This, due to the complexity of the region, chief amongst the complex socidemographic and geographic aspects. Resources is another important aspect which, to add to Wags interview, is also making the map relevant for Chinese (besides Russia and US). ^1 My point is, if to simulate historical incursions, the map is already there. Now, while simulating a proper scenario is a multi-aspect task (AI being component), there are already units which allow you e.g. visually create groups of insurgents (insurgent troops, insurgrnt vehicles, some badic buildings, albeit most not fitting this region, etc...). Most of it, will have to do with the creativity of mission designers. I will aldo point out that as per military/professional practices, missions typically only simulate that, one exact mission. It is rather modern in professional simulation to start creating complex mission scenarios which have manu components in one go. I mention this, because until multicore support, the amounts of units in a given mission, affected the performance severely. Now, however, I've tested a mission with more than 5000 units without any significant performance impact (highest difficulty AI). The only thing I noticed, was that the initial mission loading time was slightly longer. I will have to check this out more thoroughly, but it indicates that with time, we will be able to simulate individual battles with realistic force strengths across a map, which is seriously needed. I will add one thing here for ED, and that is the allowance of multiple factions in a mission, not only two. While we have few units to represent too many factions, such is the situation in real world as well (locals were often used to identify a friend or foe on the ground). The badic tools are there, it's really a matter of mission design. It pays to be clever. As an example, I'll add that some of the AI issues, can be alleviated with different AI difficulty. For example, if a given place has an enemy unit with APCs & tanks, and mission design doesn't predict any ground-battle, then you can lower the AI-level of those APCs and tanks in order to have them react slower and with less accuracy to air attacks. It's not perfect, but it works. Also, have a look at the attached maps, it just goes to show how interesting the terrain is. Based on that information alone, one can create interesting missions. ^1 https://www.voanews.com/amp/afghan-oil-production-jumps-with-49-million-chinese-investment-/7473728.html (There are unspecific reports of Chinese offical delegates visiting Afghanistan regularly. Time will show what that develops into. Natural resources is one point that makes the region attractive, strategic is another.) Map of ethnic groups anno 2005: https://www.loc.gov/today/placesinthenews/archive/2008arch/20080115_afghanistan.html

I am fairly sure that both terms get used inbetween, however the product PR's itself as "the most authentic and realistic military aviation simulation possible". I also happen to notice that simulators are increasingly being used as a substitute to actual flight hours (that is much of the agenda with F-35 and its elaborate simulator in order to alleviate evergrowing operational costs), and not only training. It is also my understanding, that many other professions use simulators to practice handcraft and especially procedures. I can speak on that, as a certified train engineer (driver) and instructor. We use simulators regularly, it is however, for annual competence checks. Trust me, there is VERY little "fun" in this environment. Most are stressed and worried when 3-5 pairs of eyes observe their performance. Don't get me wrong, if you wish to goof around, you can do so. It all depends on how you treat it. If you treat it seriously, you will get real value out of it. If you treat it like a toy, you can get entertainment in return. (Just because a plane can land/drive on water, doesn't make it a boat. Purpose defines function. We have a consumer version of a simulator used by militaries/professionals. Treat that as you wish.) I will also point to rules regarding constructive feedback, which the previous comment I refered to, was far from. Let's get back on track and not derail the thread. (I wonder if that girlfriend visited a UAV control station, she would think it's an amusement park? - Joysticks, keyboards and screens, game stuff, you know.)

It's a simulator. As a simulator, factuality is a major factor in determining its credibility as such. I don't see the point at all for such response to an otherwise good and justified question!

Absolutely, we are on point here, no doubt! If I was using TIR, then a tablet strapped to my leg with a downloaded clean maps (+ different layers and documents) would long ago have been working. The thing is, I am running with VR. That then, becomes inadequate. Even if the G2 (or ang VR with in-side-out tracking for that matter) would allow you to swap between program/camera-view with one button press, it wouldn't be good enough due to the resolution of the cameras. Ultimately, I see this request, as one that allow for expanded capability (make notes on a separate page, accept documents of different formats to be read by the kneeboard (e.g. pdf?), etc...) within DCS. Because of these instruments lacking in DCS, the whole aspect of planning/briefing/carrying out orders/debriefing gets "lost in translation". It forces one to do all this work outside of DCS and VR, and this is in particular true for VR-users. I know that ED have a plan here, no doubt. The thread is really to open the doors for whatever suggestions might come in, and generally help as much as we can with the ideas and user perception (especially us who have hardware not as widely distributed yet). Another big component of this system (specifically the modern/tablet one), will be the information flow and command structure, when the strategic component get implemented (resourcing, ground war, the whole shebang...). In the event of a modern scenario, you will want to have atleast a limited perception on what the situation is. This can be as basic as e.g. a pre-defined email/radio transmission/etc... being relayed to commander/relevant flights about the status of a defined region/airfield/structure. Whether it is captured, destroyed or so. I imagine that at some point, ED will want to implement a basic networking (military internet) capability. If this gets implemented at some point, then it would, no doubt, allow for sending emails and text messages between participants (in an orginized way). I am thinking very far forward, but that just signals the need to put in place a system that is future-proof in terms of modularity. The most pressing right now, is getting the basic map revised for a historical/current and current/modern aspect. All the fancy stuff can come down the line.

As a perfectionist, I have never been a fan of "mods" or user-created files. By all means, it´s nice that people do such things, but for me personally, I notice very quickly imperfections or bugs. Besides that, is also the fact that mods can quickly introduce other bugs, not present in DCS vanilla otherwise. That´s also why I push for a official request. WIth that said, thanks for the suggestion nevertheless!

I am not sure how air force tablets are utilized in the different air forces. It would definitely make sense to have such functions, provided real air force tablets have them. I imagine that there is a command-structure associated with each "user/pilot", where they register within a specified flight or so, but this is pure speculation.

It should definitely be split into two different views. One can retain the current AWACS (modern - simulating tablet), and one has to be a pure map with tools (historical/current - simulating only access to a basic map and tools for navigation). That much is clear. Anything else, would be a mix of functionality, and that doesn´t allow for too much realism. It is also clear, that while the modern map (tablet) can work very much like AWACS-view does currently (fine zoom, fine movement, etc...), the historical/current map, should only allow sector-type of navigating (view is changed by scrolling through sectors). The historical/current map should not allow for any zoom-level, other than pure view zooming. The big question here would be whether to extract maps in with different zoom-aspects, such that a user can selected through the F-10 menu (e.g.) which specific map he/she wants. If you expect to fly a short mission, you can chose a more detalied and zoomed-in map. If you intend to fly a longer distance, you chose a map with less detail, albeit with more conveniant coverage (allows to jump look around the map faster, than a zoomed-in one). In essence, this would require extracting 2-3 layers from the current AWACS-view at different zoom levels (again, think here of Mi-24´s doppler map - you chose one zoom level, and the you stay with it). The layout in-cockpit should be exactly that. One, being a tablet mounted to the leg of the pilot, where you can view any information otherwise kept in a kneeboard. The other, would be a simple kneeboard, mixed with a map that is layed on the legs of the pilot. In both cases, it has to work especially well with VR.

Yeah ok, an update will definitely go in pair with a visually new map Thanks!

Obviously, the label wasn't added before the thread started. Good, then case is closed.

@NineLine @BIGNEWY Will Afghanistan have climate-respective conditions? (Sand storms, etc...)

You did get an answer to that topic: While it's not an elaborate answer, it is answer enough. ED does not apparently want to go back and forth on pure opinion. With that said, don't worry, all is good. You got the answer, and now you know. While not all terrains will have all the features (Nevada is another example), that's just the reality of it all. At the end of the day, it is completely normal for Hornets, and anything carrier-related, to operate from airfields inland. More is better, but I imagine ED have their reasons (performance was mentioned as one). The nice thing with the current layout, is that we get whole of Afghanistan, a little Pakistan and even some India. The overall feeling of the map should be a harsh and dry climate, which really fits well with typical scenarios too. Don't worry, with time, extensions might come. You also got Syria and Persian Gulf, which permit navy in the region. We'll see what Iraq brings as well.