Worrazen

Haha, unrelated but sort of interesting timing, Age of Empires II Definitive Edition seems to have something very similar to I've just suggested, Enhanced Logging Build. Noticed this today while reading October's changelog. https://www.ageofempires.com/news/aoeii-de-update-54480/

I'll try to reinterate what I hastly and unclearly wrote in an earlier post that I will avoid linking to now. I'll reiterate the elephant in the living room here I think, at least to me. It is apparent that things like SRS and other things that may or may not rely on it are infact just temporary community stop-gap measures to ease the wait until the actual feature officially supported and integrated with all the other subsystems across DCS. Absolutely good on all of you who supported and contributed to these great community projects, but, I would like to, in the spirit of realism that we're trying to simulate, offer a bit of a reality check. So why would the lack of API access prevent it's usage and uptake ... if DCS Voice, eventually will be able to do everything these community mods and utilities can do and more. There shouldn't be any need for these temporary utilities anymore, optimally. I hope people who are developing them are fully familiar with this most probable reality, that they are regularly re-evaluating how much effort spent into them is worth it depending on the hints and news of incoming mirror features DCS would officially support, and it would be quite rude for such community people to pony up some made up reasons to try to continue their pet projects, claiming some things to justify further relevance and it's development. It would be best to keep this finiteness in mind and to simply let it gracefully retire. I understand people can be emotionally attached to creations and legacy built around these community projects, but it would be most healthy for DCS, it's developer and the whole DCS community to not have things actually be in the way of DCS evolvement, sort of. This is why such community contributors should seek out and start new relevant supplemental projects earlier, so that they have somewhere to continue to put their energy any passion into much quicker, ahead of the retirement of the current stop-gap supplemental utility or mod, this should ease out and might even extinquish any bad feelings about the loss of relevancy of the current stop-gap. There is justified reluctancy from DCS developers to provide API access. Instead of spending time to evolve DCS, they would spend time developing a subset of the API available to the general public and maintaining it's functionality across updates; ... is that really the best use of their time, does that help DCS as a whole in the long-term. Furthermore, it may not just be simple access like a flip of a switch, even if it is, I think they would only unnecessairly encourage such temporary stop-gaps to continue dragging on, while the community as a whole would actually be lesser off in the long-run because of the side-effect of the stop-gap development efforts never moving onto other and newer supplemental DCS community projects, particularly in areas that are lacking and may not even be officially planned for the near or even long term. I think it would be a bad example of negotiation and unfair if someone takes this lack of API access here and argues that ED doesn't support modding in general. API access is something quite a bit more than just modding, modding it self isn't an established standard anyway, in regards to how much has to be moddable or how easy should it be. Yes the customers do have a voice and vote but it is still down to the specific game, product, platform, demographic, ecosystem, market, etc, and a more complicated relationship between the community and developers determines the right balance of modding access. The kind of API access you're asking here, modding level access, is the most open of them all, the DCS developer gets absolutely nothing too metered in exchange, benefit in new players (customers) attracted by the solutions using the capabilities of that access is only vaguely potential and hard to guarantee. Ultimately it's about simulation and the replication of systems and mehanics of the real world. The DCS developer has taken upon themselfs to simulate reality in such a wholesome way, then it's their job to worry about it. They or anyone could indeed decide to go for a modular and open-source approach, but it's a completely different model, mindset, philosophy and a lot of other things that would require either a whole market or a vision change for the company. Technically a modular approach would also change the way he end product would function and behave, you could say it for the better, but I think it's always a set of trade-offs. During my recent deep dives into Linux (3 distros on 3 PC at once :D) I've seen many cases where modularity isn't always the best approach, I can't remember the exact example right now, stuff like lack of updates to some dependency that provides a feature that should be considered core/basic, etc and the idea of "others will take care of that side of the system". Fracturing these systems into various random github scripts is just not really sounding like what DCS vision was, tho this paritcular API access might not necessairly become such a scenario ofcourse, I'm speaking in general as well. I am not on the side of one or the other, I chose to dwelve into why there wouldn't be access. If it works out for both sides and access is granted than that's totally fine. There can be no limit, a modder could use these same original arguments of "VoolKhan is an established community 3D-graphics engine, please open up the access so we can integrate into DCS" or whatever. Or the sound engine does not have API Access so we can't integrate our binaural-audio plugin, or something. If I'm technically wrong in any of this then I am absolutely open to correction. Disclaimer: Unfortunately trying to be the voice of reason a bit ahead of my self again. I never used SRS nor any of these mentioned community projects, ehm, yet. I am well into all things PC and tech in terms of HW and SW and I do a lot of work with PC, to the point that playing games is pretty low sometimes, so that's where I'm pulling the wisdom from for this post.

Though, I am a fan of having multiple variants from various points in time, it's a form of preservation of history, secondly the less advanced it is the more pilot skill is a factor, which means depth, and that means good product longevity (if not eternal in such cases) a good thing for DCS business which is required for them to bring us all the updates

I don't remember purposelly toggling labels in that P-47 mission right now, but maybe I did but forgot to mention it, or did it inadvertently and didn't realize it, that's all I have, sorry for not being more helpful.

I think there should be some kind of a tool and reporting mechanism that at any sight of replay and multiplayer issues, desyncs, weirdness, you could analyze the game state , on both ends in mp, and send detailed info to ED similarly like the crash reporter works, without the process or the game actually being a debug build and not revealing any internal confidential information, if possible. This would give more insight into all the mass cases of client-server networking issues and replays that reported by public beta testing. Closed testers may have some level of debug builds I think but there's probably only less than 100 of them, AFAIK? If this reporting system exists at all in any of the build then even closed beta testers aren't reporting all cases, maybe just some of them, I'm not exactly sure whether a report usually has any info attached to it or just a verbal report of "desync happened in that mission at this time when I was doing this", we could do better than this and for complicated client-server networking and mixing replay system with that we need to provide more, if possible, I'm not sure tho, perhaps full debug builds would be needed for what I'm proposing in that case it probably won't happen for public beta or even closed beta. I think it's not that easy and back in Starcraft 2 days it was mentioned by Blizzard that the dev team had to work hard to make the replay system as good as it was, apparently highly complicated area, but then they made it so you could rewind back while in the replay which to my knowledge was not possible in any other game at the time and is still a rare thing, correct me if I'm wrong, at that time they also made another dev post saying how it took some special programming magic of the deepest levels to create rewindable replays. So what you guys are asking, to make replays perfect, rewindable, is apparently a major undertaking, if that is applicable to DCS I'm not sure, I remember it vaguely that it works by CPU instructions or something, makes the replays very small in filesize, so when you go backward it kinda has to internally start from a checkpoint and seek to that point you're trying to continue because the CPU has to play the instructions to get to that state/time that you requested as the state isn't saved literally, that's very rought how I remember it, probably a lot more details to it, perhaps that's one of the versions and has since changed a bit.

Interesting, I should give it a try once I have time.

Sure, I believe it was open that a 3rd-party might do a transporter or wide-body aircraft, beyond that I don't know much more. I do not know who Anubis is either.

I don't think so but I wasn't following DCS deeply since summer, according to the translation it was a future plan of eventually something, nothing specific, so it's probably not anytime soon, unless it's a surprise or something, maybe that surprise that was being talked about was already announced or released, I'm not sure.

Radio-Mode or Comm Realism loses it's effect completely if it can be bypassed mid gameplay by anyone, this was infact a known thing all along, I've just didn't caught up about it until I read through all of the news and I suddenly wondered about it. I would have a similar response if DCS Voice wouldn't have supported Room Mode, with the difference that I would simply skip to discussing the outside-DCS ways of trying to come up with ways to respect Comm Realism in certain matches and servers. I happened to, perhaps unnecessairly, make a lenghtier take on it which would seem like a rant, but that's just how my thought process went in that heat of the moment. I was already knee deep in the huge discussion on Radio Mode in general and the future ideas of supporting Human-AI-Human Radio Mode relaying and forwarding capabilities (passive relay or how you wanna call it) along with an addition that actually does relate to this thread, it is infact part in that post that spawned this thread, the idea of simulating AI radio relay priorities which would be a component of the overall dynamic-campaign engine AI-structure and unit availability, so that you couldn't just get your relays unless you have valid reasons for, the other AI/Human units have to keep doing their tasks and shouldn't be able to just quit their stuff and provide endless radio relays, which a human player could exploit for chatting or providing key intel in almost real-time in a way that wouldn't be so realistic in RL. Your intel would go up the chain, you may not get a direct relay and would be forwarded and subject to delays and higher command processing, bits of info slightly lost during the way (that last part is way deep to expect anytime soon) I'm not talking about human sending actual voice to AI unit, just info that AI dynamic campaign engine uses for ordering other units around, which already would anyway, except without the radio comm and signal propagation particularities not being simulated, it's all-knowing all-seeing. So perhaps this thread was a bit rough, I was trying to point it out ASAP, even tho I later caught that it's probably figured out internally it just wasn't mentioned in the preview. I wasn't angry or anything like some are speculating. Either the server enforces it globally or it's left up for vote by the players before each match session, the restriction/enforcement would then remain locked for the duration of the match. Fortunately these fears are just for the worst case scenarios, the whole thing isn't that bleak, if it's a team of buddies that known each other well and play together they'll trust each other to respect Radio-Mode, even if DCS allows it or not, for the most part it would be fine in that regard. So perhaps the shocking counter argument is, respecting Radio-Mode by trust would have to address all ways of bypassing Radio-Mode, so if someone swears to respect Radio-Mode, they'll have to avoid any option to bypass it, whether or not DCS Voice provides it, so it wouldn't be necessary for DCS Voice to enforce anything, hmmm, I kinda didn't though of this before. Interesting. For general public MP servers, where random people join and leave, that trust thing wouldn't work as good. I'm not good with summarizations, I was able to make this one only after I went through all of the brainstorming earlier.

The discussion and argumentation around the eternal balancing act of what is proper simulation was the point, not the A-10C|| cockpit, obviously used as an example, so I'm not sure it bares much weight on the offtopic side in my mind, because first and foremost this thread is about entertaining the voice of realism and different approaches to that, stating what is the obvious position of reality or arguing and weighting if there's multiple competing variations that couldn't be immediately decided upon and need a broader group of professional input. Certainly the preference of the customers also has to be taken into account by the developer even tho the customer may be wrong with the philosopy and reality. Weighting which shortcuts and conveniences are fine, which are too far and affect the simulation accuracy too much, is a complicated effort, so if I knew the discussion would expand that much I would have mentioned this in the beginning. It's just that these deep philosophical discussions a realism-striving sim should have do not happen within the community often, so it's difficult to jump into it and wrap your head around it I would agree. I was always on the side to take the sim more seriously, and try to enjoy that kind of gameplay, there's enough of fun entertainment software out there, why can't some of them be more serious, with a community where we do ask and weight such bigger questions and give things a process of pros and cons rather than just copying from another product. A more correct and professional sim leads to more repectable product in the eyes of RL aviation commuinity, any kind of drama over ATC radio is frowned upon and there's quite a low tolerance bar. Professionalism even in a home entertainment product is a noble cause in the market full of non-serious software. At least that's my educated opinion. Secondly, yes you can all bastardise DCS right now by some 3rd-party utility, I know that, I said it in the beginning there's no control over external comms, but the bigger factor is that it's something that's outside DCS, it is immediately no longer DCS developer's responsibility, so you simply suppose to ignore it like it doesn't exist because it does not exist in the scope of DCS. Finishing the point, because the potential is there, yes the recent Fight of Honor commentaries mentioned how you can't use DCS to prepare for RL military career, DCS isn't good enough in RL pilot's mind to be a serious training software for flight school, you can go ahead and disagree with that, that's fine if they have that opinion now, but that doesn't mean the we step down and surrender, we would still want to continue the passion and vision and keep striving for realism accuracy. I would feel ashamed to spam the DCS developer to bring me some fast convenience features that spoil my subjective, or what's the word, sort of irresponsible enjyoment, while having little regard and consideration of whether that affects simulation realism and what other deeper consequences across the gameplay it could have, what habits could it promote in the users and all sort of things; the kind of dirty careless enjoyment, similarly to that kind of enjoyment that delinquent teenagers would get when hurting a cat or squirell, I'm not accusing anyone here, just saying what I'm looking out for, striving on my side to not fall into that position my self and talking about it to warn the community, the society can be dark and it is noble to defend DCS against these influences from other software products that are clearly invading into the sim community just as we expected. There is a lot of negativity associated with real-time voice communication in various entertainment software products, that ofcourse doesn't mean the technology it self is to blame, but it does by it's nature amplify the bad habits because knowing that your words are heard by the opposing team enhances the desire to use speech as a psychological way to demoralize and frighten them and to self-empower, it's all about that and is a biological life form trait that is present universally across the board. We could argue if that's what reality and nature designed us to have then it's okay to scream wildly over the microphone every 5 seconds just like you would in the jungle or outside during a physical fight with a wild animal. This can get deeper still but I wouldn't want to go that deep in this case right now. You even realize that Destiny 2, a PC shooter game (turned more to MMO) that I played for the past 2 years as an exception to my mostly serious hobbies, had no global chat feature during gameplay, you could not chat or send voice to anyone on the opposing team (didn't play for a year so I'm not sure if it's still true). So there you go, if anyone thinks I'm making this stuff up. The unrestrained and unharrasment is a big deal out there, enough that multi-million dollar companies have to debate around, research, and come up with a potential solutions. Subjectively (could argue) I find some aspects of these voice-enabled gaming scenes as unprofessional (and probably other terms but I wish to not randomly define something because I'm not too sure), if not it can simply be acoustically annoying, stress and health and conditions can have a great effect on the ear's tolerance to various frequencies. Research that if you don't believe me, similarly if you're in a dark room for 3 days and you didn't sleep well, you get out on the sun one day and your eyes get over-sensitive. There's other aspects that may be biasing me like I really don't like to wear headphones because it would make my ears sore, maybe I didn't try good enough headphones, but generally I was never a fan of headphones at all, and never felt the need to be a gorilla in a pack that wants all the attention in the world, sorry to say it like that, certainly that's my personal view which has nothing to do with the proffesional argument I'm using here, and I'm strictly not trying to use my subjective arguments to persuade anyone, as far as the realism discussion goes, even tho, as we know, just like in practice the DCS developer would have to take customer subjectivity into account, on your, or the popular end, but they would also take it into account on my end, even if that is less popular, and then decide whether it's practical for them to implement and whether it goes against realism rules, which are in it self undefined and that's why this discussion exists, to debate these things because there's no authority out there that defines what a simulator should respect and what shortcuts are fine, which things should be an option and which things should not be an optiona at all. This is precisely why I'm also struggling to write these posts because it's so complicated for me as well and I unfortunately don't have the time to devote only to DCS currently. I indeed shouldn't be writing these posts right now, in the year-end stretch. If the viewer of these posts is not in good mood, it will find it indeed very hard to read though, but in that case it's unfair to blame me. The topic it self is heavy and not something people who want to have fun would want their brains to deal with, I understand. ---------------------- ---------------------- There's yet another big fact, DCS Voice is a package of 2* different things, that happen to share a lot of the underlying technology, such that you treat it as one overall thing with different modes. I just realized the elephant in the living room I should have in the first post, because this is a common phenomena where the most obvious things can be hiding in the blind-spot. It is a massive difference in gameplay when switching between modes and it therefore it's safe to consider it a completely different thing in practice, and as expected some people will not like or take long to get used to comm realism, but it's no big deal, it's expected that it's a process that may take time, or never for some peopl. The unimpeded comms habit is very strong, and because no other unrelated entertainment software, that has heavy use of real-time voice communication, focuses on realism. Ofcourse that last argument wouldn't hold true for non-gamers who never played or used voice-chat in any game prior and would only start out with DCS while respecting comm realism, but that's a minority, so that's why most of the people need to check their subjective bias before debating the realism discussion, are you sure you're not biased by years of exposure to non-simulators and the unprofessional communities of various other entertainment software? Also this thread isn't something I jumped on today, I was the one talking about comms and in-game radio simulation prior to it's announcement, in the wishlist posts, and many other aspects of communications. And it was always about in-game radio simulation first and foremost, that's what advances the simulation, it was never about to have "Skype inside DCS" or something, there's nothing there really other than the user not having to click Skype.exe, what's the worthiness and return-on-investment of integrating voice comms without having the radio's work with it, if it wouldn't be much different from existing external voice comm solutions? Only the convenience factor remains, so that you don't have to launch a 3rd-party application. I think that if DCS Voice was hanging on that one reason it wouldn't have been developed under normal cirumstances, depending on how busy ED is, unless the communities spammed them about it without any regard to comm realism (I forgot that far back), which would be a good example of what I mentioned earlier, in practice due to artificial human limitations and requirements the DCS developer has to consider the customer's wishes even if the customer is incorrect or has poor reasons and weak arguments behind an opinion, if the opinion is popular enough, etc. while resisting this as much as possible. Game Balance was a perfect example a while back, some "professionals" thought that DCS has to balance RedFor and BlueFor, the CEO and Founder of ED had to come out and politely disagree and deny the request, that's how ridicolous that was. I really don't want to go down this route much right now, but I will what I've been thinking for a while, that it's sort of fishy how much drama in DCS was there in the months before and around the release of a major civilian flight sim from a major operating system software company, looking back, it felt like DCS might have been the victim of an immoral targeted social engineering campaign perpetrated by the unprofessional marketing agency of the competing product. Stuff like that wouldn't be anything new.

My thread here is about realism and simulation in DCS and DCS only. What kind of usage the majority of exising DCS players use DCS for and what kind of gameplay behavior they prefer on DCS MP servers is also of zero relevancy in this case. So I believe currently. There might be various relevancies for the development team in general, but I'm not the developer, secondly, I'm purposelly approaching this from an absolute reality point of view which has no financial, logistical, or any kind of common human limitations and has no obligation to adhere to any subjective opinion about eSports, other than the laws of physics and quantum physics. Any sim should support what is correct first, only then cater to various conveniences and shortcuts, some of which are already there fundamentally otherwise we would all a hard time simming at all, but we usually never point them out, it's obvious they're necessary, but they are still technically wrong. If you want to challenge my reasons and arguments around Comm Realism then you can do so. I''ve only mentioned what a potential solution could be for tournament organizers to control external chat usage, that's it about that here, it is a different topic altogether that I never intended to discuss any deeper here. It's silly really, why would you demand that I have to argue things in favor of your gameplay sytle which is "for fun" ... you can go play for fun and create your own arguments how that is suppose to be more realistic or otherwise if you want, others have their own and would hang out in their own subset of the community, there is no need for any clashing. That said, there is however the balancing act of what is the sim intended to simulate, the absolute reality with many possibilities allowed by laws of physics, or the reality of the users of these simulated machines who use it in a particular way due to many many factors which their validity is debatable, many of the reasons are subjective and have no techical underpinning, many of the reasons pertain to human social orders, human financial systems, and a ton of other influences that can't be listed. There is no standard to my knowledge as far as DCS developer goes, which one is defacto enforced, or preferred, it's not defined, not by any simming authority out there if there is one, and I think that's a good thing, this is a wildly complex and astronomical discusion, leave things open so developer has leeway to decide what makes more sense for individual subsystem, but they also have to take their human limitations and factors into account. For example I was the one who "campaigned" (made a few posts) how we shouldn't exclusively simulate the particular modifications and flavors of systems that one particular US military agency uses, and I admitted I might be biased because I'm not coming from RL aviation, I was on the side to have the new A-10C 2 Tank Killer come with the clean cockpit too, there were some rumors that only a worn cockpit flavor would be featured. I didn't made the argument because I'm not a RL pilot and never experienced a worn cockpit, I made the argument about what I just said, what kind of reality are we trying to simulate, and first and foremost, the aircraft that are being recreated digitally were created to such and such specifications by the original manufacturer, is it realistically correct to only simulate the user's version and not the manufacturer's version, these are the big reality questions a simulator should have to at least consider, but there's no need for anyone of us to come to some grand conclusion, both are valid because both did exist once in reality, A-10C did roll off with a clean cockpit once, right, most likely they didn't pre-worn it, but if they did, only then it would be a harder job at justifying of a clean cockpit in the digital version and if developers would be so strict and never provide it they would not be in the wrong of any realism rules, but if so many people demanded it because of the "manufacturer was wrong" ... in the end we can argue so many things to achieve what we like and have it be "correct with the universe" so this is not an easy road to go down, I have to be very careful to not try to let my subjectivity affect the argumentation and try to make a subjective preference seem like the correct reality thing. I'm completely open to disagreement, I have to be, because I am not a real pilot, far from anything aviation in RL, but I try to bring in objectivity so that things can be compared to it, I am still human and I can't be perfect in my attempt to emulate how the reality would see and argue these things. In the end it's the developer decision, they have all the power to disagree and I would not take it personal if they do, because I understand the situation fully. So if I didn't make it clear, I am not personally attached to some of the opinions I write, I simply play the reality character sometimes, if there's something subjective in that case then I probably made a mistake and I'm eager to be corrected. I have infact rewritten the OP completely after it was posted, to really make sure I don't go off course, this is the usual business with my threads, sometimes it takes a full day to realize what I written didn't make sense or was mistaken, had to cut some stuff out and change the intro because restricting Room Mode shouldn't be an afterthough as I initially written, because the whole purpose of Radio Mode is to be limited by Radio Mode, no? TLDR: The enforcement/exclusivity of Radio-Mode (+ Comm Realism) shouldn't be a question at all. According to reality it's enforcement is the whole purpose of it's existance. If it's not enforced, what's the point of it's existance. Infact the Radio Mode only restriction option might be a thing already internally, there might have been no foresight to mention it or whatever, no big deal at all, I am aware of that possibility as well when I write my thread, things I write could have been thrown around on meeting years ago, I write my threads from passion and personal brainstorming interest if time allows, so my effort won't go all for nothing in case they reply the next day to say that this is already taken care of.

I'm not a promoter of that idea, it's just the first obvious thing because physical LAN tournaments have multiple cameras around all contestants as well, so there's really no difference in that regard. A serious player would also have a dedicated sound-isolated PC room in their house, primairly because a flight setup takes more space than usual to begin with, so the background wouldn't be an issue, they wouldn't play in their bedroom. And I don't think it actually matters at all whether DCS is considered eSports or not, someone could wake up tomorrow and decide he'll play DCS for big bucks. There is no official standard in any country that defines what makes a game esports anyway to my knowledge.

For the tree damage model, it doesn't need to be that complex to cover branches, what it could do is have different penetration behavior based on munition flight parameters at impact and type of munition, perhaps it would penetrate through and explode on the other side if you set delay or it just would explode somewhere along the way of penetrating the tree hitbox, that's where the attenuation could come in, the more penetration into the tree hitbox the more damage it will cause on the other side, maybe just this is already costly on CPU, I don't know. But this would actually require weapon damage-dealing modelling too, in terms of shockwave and explosion radius, which should happen in DCS no matter what because it's a part of the overall ground unit damage modelling, we'll just have to have better hardware if necessary or have it optionally adjustable for lower end HW; ... while the tree just acts as simple attenuator in 3D space so it wouldn't need that much modelling on the tree side, muffling some of the energy in that direction and that's about it. So that if it exploded by tree contact, it'll still do some damage like it would in real-life if there's a unit nearby, even if on other side. Tho, some weapon are designed to only have maximum effect on direct hit and other's are designed to be quite resistant to splash damage so this needs some brainstorming, how the balance of simulation depth should be here. Thirdly if trees in real life can stop certain munitions or in certain circumstances from detonating altogether then yes that should be the case in DCS, but this surely does not happen all the time right, trees are hard enough to trigger explosion?

Yes, they can keep having that option. Grim Reapers do a lot of testing and I nor anyone definitely never intended to prevent them to disregard in-game physical limitations on comms, that would be severely detrimental in beta testing, and it has a huge effect on gameplay and the way videos are made. My thoughts are explained in depth in my own thread I made before realizing this one existed. If I may mention it:

Yep, that's one of my bad habits I can't shake off lately when I get enthusiastic I want to put it down on paper and can't easily stop. I'll fix it and I actually partially did here

The increased realism benefit of the Radio Mode and respecting in-game physical limitations on communications in general is actually only achieved if every other form of communication is disallowed completely. MP Server admins should have the ability to disable everything else that crosses these limitations as far as DCS is concerned, or the other way around, leaving the full realism mode as default unless disabled. Everything in this discussion is and can only be as far as DCS Voice is concerned, full-proof cheat protection isn't the expectation here and not DCS's responsibility. If someone really wanted to cheat they can do it in 1000 different ways externally, but that kind of enforcement is for the server admins and tournament organizers to find a way to enforce outside of DCS or and DCS component, and that's another topic too. If I may touch upon it, one of the solutions over the web would be to require a separate non-public video and audio feed of every player's PC setup and their body in view, basically a security cam, while dedicated security moderators would monitor every player at all times. Because most people play from home they would probably not be too eager to accept these requirements, but a well organized tournament could have legal-assurances and privacy safety nets on top of such feed being only streamed to the moderators and not the public, and the security cam footage deletion after the session is over. ---------------------------- Additional comments: DCS Voice's in-game radio simulation also encourages or even necessitates the use of dedicated in-game meeting places such as the virtual debriefing room currently in development for the Super-Carrier module, and other future in-game physical enclosures in general for use of communication between human players when radio and intercom is not available. If a pilot wasn't able to message over radio, radio relaying wasn't possible, you would have to wait to get into the virtual debriefing, planning or situation room to discuss in detail, there's actual time that passes for the human player and they would have to reference their memory when telling the story/intel just like in RL, then if someone is MIA/KIA in-game they won't be able to share anything in the virtual debriefing room or otherwise, that's a pretty big factor on gameplay. In future there's also the question if DCS would simulate IIA/WIA/SWA for delays in when you can get back into action to talk about the story or provide more intel. That's for another topic. Communities who would keep prefering unimpeded communication can obviously keep doing so and they would have no restrictions imposed on them by any of these ideas. These are all additions for other use cases currently unsupported. The Comm Realism might produce such videos and gameplay that unimpeded-comms fans might see as boring, so this is for the other people who do not care about the constant back-and-forth chatting and might want to prefer and recreate a more serious experience just like in real-life. Respecting in-game physical limitations on all communication would change many things in many different ways including the way youtube videos are recorded, but not necessairly. We should still be able record different types of videos (stream, or spectate) without having to turn off Comm Realism for the players in an active game session. First, there could be an additional mode for MP server admins to force spectators to sync both the visual and acoustics up, which results in F1 View + Comm Realism. And you could use this spectator mode to record the whole battle in if you so wish. Secondly a movie-type spectator mode that the MP server admins could select, where spectators are allowed to plug into almost any audio channel including have any kind of F view available, this would include a new GUI options where spectators could choose audio channels they get to hear on top of the screen they're watching. I think you currently can't do this in DCS unless there's scripting or some API interaction possible? You could record your youtube(or otherwise) videos using this spectator mode and produce videos where the viewer can have a full or edited overview of the events as they take place, without that having an effect on gameplay or any of the players when the session was active. After a session with Comm Realism completes, the players can as well have their external-post-session debriefing, immediately or later, and recording video of that for youtube could actually be entertaining or interesting as well, listening to the process of them figuring out the full story, producing more content for viewers. What Comm Realism "took away"* earlier now "gives it back"*. (in comparison to unimpeded comms, but it's not a valid comparison as far as reality goes, it's like this and nothing else) However, for realistic communication without radio or intercom, we couldn't just use the DCS Voice Radio Mode, would we? Perhaps we would need a new mode for actual local in-game mouth voices. Even though the Radio Mode would technically need to be an extension of the in-game real mouth voices, because when you speak in radio in RL you also use the mouth and you'd be heard locally as well. Simulation of 3D voice audio it may provide a realistic 3D audio experience for virtual debriefing rooms and offer ability for ejected pilots to scream through the forrest hoping they're heard by a passing allied vehicle or infantry on a nearby mountain road, if all else comms fails, or you have to keep radio silence. However it could be a bit overkill in enclosed spaces and serve no gameplay value (?), especially if it's a CPU resource cost. Either way a simpler implementation could be done and supported earlier if necessary. A Restricted Room Mode could be used instead, (or a better description/label), where each physical enclosure would have an associated pre-defined audio channel (room) that you can join only when your 3D person in-game is physically present within the boundries of the associated physical enclosure. You could also set to join these audio rooms automatically when walking between different in-game physical enclosures, if that's a supported feature. This would make the audio free from 3D effects and clearer, less noisy, but still simulate the physical limitations similarly to real-life. As a bonus, perhaps there could be some adjacent audio in the bordering physical enclosure, with lower volume, this trick can cheaply emulate the previous mode I talked about, to some degree. EDIT: Yes this can be moved to DCS Voice Wishlist, the new forum I didn't notice.

I've got mixed feelings about the modding arguments in this case. I'm not too sure how valid this case is. If I understand this subject correctly (i've been busy with non-DCS for a while so I'm not the best guy for this right now) Not allowing access might actually be a safety feature to protect simulation realism and prevent fragmentation in the community rather than shunning of modders. Way back when I was talking about this feature on wishlist, "DCS Voice Chat" was always going to be an in-game in-house official component in my mind, it's what the actual radio simulation needs, it just never existed before, infact it wouldn't even need to have such a specific name nor be regarded as a separate feature. It's just one of the components that should have always existed but in our simulation reality it takes time and resources to build it, it should operate wholesome with every unit in the game, not something extra. Remember all the discussions of what is "Core DCS thing", this is suppose to be one of them. I think some people are approaching radio communication from the wrong angle because of it's nature and similarity to computer internet chat, while this is many times necessary in practice for DCS users, particularly multiplayer, as we indeed do have some limitations (physical life, logistics, resources) that we cannot bypass when trying to experience the simulation, but that's not really a thing as far as simulation of the airplanes and it's radios is concerned, and extra features modding might do on top of to this system might go outside of the radio simulation and might over-convenience some aspects of chat and promote less realistic experience overall. The kind of applications that may be developed by the use of DCS Voice might be cool but if those tools are then used as a standard ... did someone weight if they might be unrealistic and giving an advantage over reality. I am however speaking generally here, I do not currently know nor I have spent speculating what would be the features and capabilities the modders would want to add on top of DCS Voice, so that's actually a good question for the OP here, what actually are you trying to do that you can't do without API access? The primary thing from the realism point of view is the simulation of the radios, not our computer internet chat, just like radars, it involves electro-magnetic radiaion that has a lot of depth to it, many factors affect the radio signal and this is reflected in the way we hear the audio signal, noise, volume, static, clicks, interference (environmental), jamming, knife-edge effect, antenna orientation, antenna radiation pattern, need to be simulated the same wholesome way as other components the focus was on all these years, it can't be just a bolt-on, because it's not about internet chat, that's just our convenience. To me, modding solutions to these well-known to-be-developer core components were always seen as temporary, stopgaps. The DCS Liberation mod is suppose to be the same thing. I hope it's just meant to be a fun project that while is not technically necessary, attracts the community, gives the upcoming DCS feature more interest and might even assist passively in the development because of the participant's exchange of thoughts and visions about the system, so it is healthy to have such projects, but not that these projects would then refuse to retire, but I do know how it's like to be emotionally attached to a creation, that's why it's important to realize sooner rather than later of the limited nature of such stopgap projects, so that it would be easier to digest the retirement later on. The effort done in the modding project and the results at retirement should be redirected to the main course and then those caretakers would be available to start another project in an area where a stopgap solution is lacking. Eventually, for a greater (*proper*) realistic "hardcore" dynamic-campaign experience, the DCS in-game communication simulation system should absolutely keep going pretty much everywhere for the duration of the battle session, even if the session is paused and resumed (not a thing, wishlist) or you come back to the session on a MP server later. Some aspects are debatable, but generally whatever state you are in, considering if is simulated, let's for example say that in case everything is, aircraft or not, every unit you're using, you shouldn't be able to switch to computer voice chat and talk with everyone unimpeded, using an unrealistic service to gain information and giving them information that would affect overall gameplay. Currently because a lot isn't yet simulated, you have no choice but to swtich to Room Mode as soon as you eject, though unless DCS would purposely prevent that even before CSAR and pilot radios are implemented? Probably not, still, everyone using a lot of traditional internet chat which I'm not sure but think is being used unimpeded (I'm sorry I actually don't do MP a lot, yet) should start thinking about these limitations and prepare for these proper limitations, because, not necessairly intentionally, but unintentionally gave away a lot of information that affected gameplay while bypassing realistic limits, similarly to how TGP displays we were experiencing all this time were reportedly way too good quality and we shouldn't have seen all the detail we did, some people may have harder time getting used to such a substantial change and it's good to start the psychological transition early, to assure the mind the change is proper and get rid of the old habit. Back to the eventual proper scenario, there should be a MP server admin setting to disable Room Mode, so after you eject, all you should be able to do is communicate via the radio you get from the ejection suit or seat, and/or hope that the emergency rescue radio beacon got activated and wait for CSAR. Whether direct or relay, respecting the physical limitations. Additionally, the good simulation of what a crashed pilot is usually suppose to do, like safe landing, finding a hiding spot, contacting and interacting with CSAR, survival on ground, recon of the area for extraction zones, should give focus on resourcefulness, so if you do get into a direct contact with your buddy, flying nearby, the sim forces you to talk only the most relevant stuff, in your opinion ofcourse. As a pilot on ground you are busy with other things, so DCS Voice and whenever CSAR comes and actual virtual debreifs at a base location in-game (only for in-session), it will reshape the way comms are done in DCS in many ways. Coincidentially for those FPS fans, this is where DCS would get pretty close to first-person shooter style gameplay, without taking infantry warfare into the equation, because it can be quite a part of the CSAR component. ---------- Not having Room Mode (or any other external unimpeded comms) should not mean you wouldn't be able to communicate with your buddies/allies without direct radio contact, DCS should eventually, as per the radio simulation across all units, support AI relaying functions. In this case I'm talking about an actual signal relay where each ends of the comm link can hear each other as if it were a directly comm link, if the radios in the relaying units have such a "repeater" function (tho I only know the old A-10C Radio has it, but if that has it, any AWACS surely has it too), it's the similar kind of function as your Wifi Repeater for your home internet (tho rather go Ethernet wired only, it's healthier and more reliable :p) Example1: Ejected Pilot(Human) -> closest CSAR unit (AI/Human) -> Squad Member in Aircraft (Human) Example2: Ejected Pilot(Human) -> CSAR Unit (AI/Human)-> ... -> AWACS or ATC (AI) -> Squad Member in Aircraft (Human) The other mode of relaying is just forwarding the kind of predefined radio commands and request we're already doing right now, it's just that you can't relay them AFAIK, this would be used when the target is an AI ... at least until DCS implements AI unit voice recognition which is a whole other discussion of feasibility and depth of recognition I won't go into right here. In this case These two modes are in on top of the standard dynamic AI-to-AI communication that the DCS dynamic-campagin engine AI system should use to manage all the units across the battlefield, issue orders, give headings, update locations, so you don't really have to, as an Ejected Pilot, contact any CSAR for help, the AI that saw you crashing, the locator beacong going off, the AI that can't get your reply and signal rom datalink would already contact the higher command and CSAR will beging searching for you and they'll talk and exchange info amonghs themselfs automatically. Just for full realism, this intra-AI communication should also use the same comm link and respect physical limitations as humans have to, not sure if this will be so when dynamic campaign launches initially, depends whether the big radio comm overhaul happens before or not. It gets hard when you try to have direct relay beween two humans but one of the AI's in the middle does not have that capability, this would require AI to analyze speech, again probably not happening anytime soon, or no? You'd just get reply back that direct relay isn't possible and should use the pre-defined message forwarding instead, the target unit wuld then hear audio of an AI tellhim Now I say pre-defined because I'm on the reserved side of what's possible, it might be possible to create a dynamic system where you could input different parameters not just the pre-defined options we have today, "Tell my target to go to heading: (insert or speak custom numbers )", perhaps a simple set of AI voice recognition could be implemented to recognize numbers. Additionally you could have the signal be affected by interference factors and have that voice recognition hear that. I'm not really sure of the feasibility of full blown voice recognition for AI aircraft. However, DCS eventually needs a system to prevent relaying absue particularly if Room Mode is disabled. Room Mode or not, in real life the military point of view "waste of resources" or "unnecessary" would be the valid reasons, because providing relays takes resources, attention, effort, unavailability to do other tasks, etc so it can affect gamplay a lot more than it seems. Relaying Priorities: This would be a system that many AI components would be aware of, the high-command AI engine (dynamic-campaign) and the units themselfs. The standard factors are ofcourse the individual unit's own availabilities. If the unit is in combat it probably won't be able to provide steady relay at all. If the unit is just cruising then it can easily provide relay and even change course to provide better relay for a longer period of time. As a player in a dynamic-campaign scenario you shouldn't be able to get relays as you please, the whole AI comm and relay system should use a priority system. The bigger (coalition) scale should be taken into account as well, to prevent relaying "abuse", because the Master AI, which would behave to how a real military would, won't just let you use up unit availability and resources for your potentially unnecessary, prolonged or completely off-topic relay links, even if the individual unit might be able to keep relay link ongoing, the Master AI might step in and determine that the relaying unit needs to do something else, giving it a different task elsewhere in the battlefiled where urgent support may be necessary. Naturally, if you're an ejected pilot, CSAR-related comms and relay requests would be high up on the priority list, treated with high or maximum priority, but there's a catch, only up to a point that is necessary for the situation. And this can get quite complicated, it would take some effort implement the priority system. Factors such as whether or not you are in the same squadron, reigment, wing, etc would matter, and affect the priority of your relay request. Location or zone that you're trying to contact should matter, is the target of your relay request even within the vicinity of your crash, is it even inside your mission zone, etc. An ejected pilot that should be thinking about CSAR-related duties should not easily get direct-relay with some random ally unit in a totally different location, outside of the ejected pilot's mission zone, performing a completely different task, that was totally unrelated. For that ejected pilot to know their location in the miitary structure, name, rank, ID numbers, it's highly likely it would be an attempt to chat with a off-militay buddy about off-topic things. Some familiarity of military operations that I have, I do not believe a real military would be eager to fly, spend fuel, open relay channel, if they were all hearing the relayed messages (I think they do?), to provide long-distance phone network for 2 to talk about the sunday's airshow or whatever which is not really necessary for the current situation, so DCS needs to do something to simulate this without spending a big deal on processing requirements. This is the scenario human players in DCS might try to poke into, when an ejected pilot would wait for CSAR and feel bored, would want to contact some other truck driver 400 kilometers away. While off-topic chat doesn't hurt (cheat) gameplay, it would still take resources away if the relaying units need to be in position and unavailable for some duties in order to provide the good relay signal, so this anti-abuse priority feature should be an integral part of the radio overhaul in DCS when support for full relaying comes to AIs. Ofcourse this is all from the DCS Voice point of view, we can't control whether those two use an external chat to communicate, this is for the torunament organizers to figure out a way to enforce and prevent potentially cheaty comms. For a low priority relay to work, all units which are relaying would need to be in state that allows them to even accept low priorities, cruising and not doing anytihng in particular, additionally, they would only provide that low priority relay It's not the player/source who sets the priority, might as well set it, but the relaying units would change it when forwarding it to the next relaying unit, or the Master AI should be able to override it. So you could for example select max priority: Ejected Pilot (P:10/10) -> CSAR-1 (P10:10) -> CSAR-2 (P10/10) -> AWACS-1 (P: 4/10) -> Airbase (P:2/10) -> AWACS-2 (P:2/10) -> Ground Command Post (P:2/10) -> FuelTruck-Driver-007 (Destination) The CSAR units will try to do everything in their power to do so ASAP, unless any other emergency factor prevents them to respond to priority 10 relay requests (max), such as being under fire or low-fuel. The reason why CSAR units in this case wouldn't downgrade the priority themselfs is because they (as also in real-life probably wouldn't) don't know where exactly your destination is, they might, but in this example they don't, unless they would ask the higher command to tell them, but I think this isn't usual military operation, I believe in real-life they would just let the higher-command deal with that themselfs, so they relay the same priority they got from source. The AWACS is the first that downgrades the priority in this example, because it knows or it figured out (attempt to contact, no reply timeout, a thing for DCS simulation depth in comm delays) that target unit is not in it's area of reach, then the Airbase gets the request with priority 4 and if it can it does handle it as a priority 4 request, again the factors if the AirBase is in a state that is able to process priority 4 requests (so not preoccupied with base defenses, airport activity, etc), but the AirBase, which has more info on units on the whole battlefiled (as a component of the master dynamic-campaign AI) sees that the target/destinatinon is even further out, requiring another AWACS relay, so it further downgrades the priority before sending it to the next relying unit. The second AWACS receives priority 2, not 4, AirBase downgraded it, so the second AWACS would respond only if it's available to respond to priority 2 requests, so that AWACS has to be relatively free of occupation, not refueling, certainly not under fire, probably circling without much other relaying radio traffic, the AWACS-2 might do it's own priority recalculation whether to downgrade or forward the request with priority as it is, same for the Ground Command Post, each unit would have it's own AI component recalculating whether to change the priority it sends to the next. Only after this journey would it be down to the FuelTruckDriver-007 to see if it can respond. That is, if real militaries would even allow for such a relays in the first place, direct ones, but then again we're at that question of whether we simulate full technical realism and allow all posibilities even if the military structures in real life have artifical limits in some ways. It might just involve 1 to 2 hops of direct relaying, then the higher command would take it and repeat it with their own mouths to the destination through more relays which would use their own mouth to repeat their relative source (not the original source audio), off-topic would most likely not have good chances of going through and would be denied in real-life, the source wouldn't even attempt it IMO, otherwise each stage would probably filter more out on their own, but we do not have the ability in DCS to have a super AI that scans all talk and thinks what's not necessary to spend relay resources on. But this is the kind of system I came up with right now to simulate the artificial relaying limitations a real military might have while keeping it technically possible. Alternatively if DCS ever supports human players in all* roles of the chain, which I already have thoughts written down on notes and probably spoke about it in wishlist threads, simulation of the command structure by AI in that case would already have to be a major part of dynamic-campaign, how diverse the AI structure is planned I do not know. Eventually it could be human controlled, having an advanced situational view, and that's why flyable wide-body jets aren't a joke, someone needs to fill AWACS/tanker/ground command and outposts too for this to function, higher commands, AWACS roles, and the whole thing with human players. Cases where the relaying units would upgrade your priority would be squad leaders trying to get direct contact to higher command, so the rank is also a factor, might get upgraded, or not downgraded as much. Priority may not need to be user selectable when making an inital request, because such a thing does not exist in real life is one reason, secondly if the units can't handle high priority they'll not be able to handle lower either and if the source does select a lower priority knowing it likely won't get a contact with higher priority through, their request would just be forward with the same priority they selected, without any difference in the end result versus if they selected a higher priority, because they would get automatically downgraded anyway. It might be simpler and well functional for the initial priority be an internal hardcoded one based on unit types and their tasks (and perhaps states) that would be predefined in and not adjustable by any player or AI in a session (unless modding), for example an ejected pilot contacting a CSAR unit or a unit in CSAR mode at the time of relay request, would have a priority of 10, automatically, without any pre-thinking by the receiving unit, the CSAR unit AI and the whole DCS AI's down the line would know the source is a pilot without it having been figured out by any of the AIs or the master AI or whatever. This is the first stage, the CSAR unit then sees priority 10 and starts behaving accordingly, and then comes the rest I talked about. That would look like: EjectedPilot1 request to EjectedPilot2 (different aircraft type, different mission zone, different rank, different task, different squadron, 800 km) == priority 1 -> CSAR-1 (P:1/10) -> CSAR-2 ...etc I felt enthusiastic today so I dug deep into this one, now I feel this could be way simpler, while still a similar safety net for simulating difficulty and necessity of long-distance relays. You can ofcourse hardcode the priority by source and destination, distances, check the lookup table and if it's too low get an instant denial for relay even without sending any request to any AI, and the AI's dealing back and forth.

They said nothing about cloud-services, but yes, I do want DCS to be fully featured offline product except ofcourse Multiplayer in the case of no connection (and except activation/licensing) If PC hardware's not good enough ... I doubt, but if the goals are high, then we just get better hardware then, I had a long time idea of a new professional PC platform that would be in between the PC high-enthusiast end and enterprise, workstation isn't really it and doesn't cut it. It would be for many things not just sims, but sims would be one of the things. Yes, optimistic

Hi Now it appears FM is indeed not finalized as F-16 is still in deep Early-Access, but I think occasional DCS players may not be fully aware or easily forget forget about it that things are WIP and they're playing varying degrees of E-A products in many cases. Now I'm not saying that Lemoine doesn't know about E-A, he only pointed out what seemed unrealistic, without mentioning E-A or anything else, so I may be speculating myself and I can't say one way or the other, but this is a good example to bring up an idea that I already had for some time, for other cases and future, as well as for other modules. The Idea: Perhaps E-A Modules could be identified as such across all of DCS, I would include "(EA)" suffix in the default name of the airplane in the Mission Editor including the labels (if enabled) in-game. "EA" does appear in the Main Menu bottom module reel already, but for F/A-18C (I do not have F-16C) it does not appear in the Missions,Campaigns, Training, Instant Action and Special Options pages on the left side, also a good place where it should. I would even go as far as to show by default an easily dismissable on-screen under-construction-sign style notification box on every mission start of a unit part of an Early Access module, containing a disclaimer Early Access state and unfinalized systems and flight model etc. Such a message could be completely disabled but it should take an explicit user action in the options screen to disable it, "Never show E-A warning at mission start", for example. But this in-game pre-flight warning sign should be made as unannoying as possible, it could be part of the usual welcome screen that is always there and everyone would just hit "FLY" button as we all have to do already, that might work even better, so the bottom portion would be extended and a YELLOW-BLACK construction-style warning box be added there, should be big-bold and colored enough to get immediate eye attention ! Thank you for consideration, I think there's been so much unnnecessary confusion and negative comments against ED just because people forget what they're experiencing is E-A and I think ED should be proactive against unfair criticism in other ways and this one of the ways and probably a lot more effective than defending on the forums, if people get that notification right there I think it eases the pressure because the boiler is quicker released of steam and not allowed to pile up, if people's steam keeps rising and finally goes enough for them to come to the forums to complain then that steam even if it's starts getting released by a good reassuring forum reply may still take some time to lower down because so much of it was built-up, if that works as an analogy https://www.bitchute.com/video/UOU75I4TIfRs/ https://www.bitchute.com/video/YaZOXSXWGoSs/ https://www.bitchute.com/video/DuCvh0A6mjIH/

Absolutely a must watch for all the non-techies trying to get onto Win11 so fast.

Great stuff an like that the documentation also gets the touch, but I wanted to comment a couple of weeks ago and I guess I forgot and I'm too late ... I was hoping the english manual would include english cockpit edition pictures and that the abbreviations and names in the english manual would be translated to english as well and referr to the english cockpit rather than the french. Perhaps that might require two different whole manuals in parallel, french and english one with their respective cockpit editions, not sure how this idea goes because might not be realistic if there's no official english airplane in existance but that's the most optimal idea. I found the mission tutorials keep referring to French abbreviations and modes for knobs that simply didn't exist for me using the english cockpit which kinda defeats it's purpose if I have to then use the French one. Ofcourse using the proper official language cockpit is what we should eventually strive for as users if we want to be all by the book and I certainly am not an advocate of too many conveniences, shortcuts and cheats. The english cockpit it self also has some things that aren't translated, I understand for things that have same letters in both languages, but for example the EFF button, if it means to delete/clear then shouldn't it be "CLR" or "DEL" ? EDIT: Oops I see I did infact talk about this on the previous Update Presentation thread and I did get a reply, sorry about that, and thanks for consideration! PS; for clarity, this thread could be named to include the date just like the previous one, ..13/11/2021..

Hi If you copy a group of trucks and refuelers, the parent units will lose their black radius indications, the new copies will not, and other unit groups will be unaffected. The black radiuses are restored once the copy-parent unit group is selected again. I was doing this in Mariana Islands terrain with Russian units.

Hi Seems like there's some inconsistency, I do not know much myself about how real airplanes deal with the numbers tho. Some liveries will let you have 3 numbers at the center, some only 2, some are placed offset different and the Ambulance livery is particularly bugged as it seems like it shows digits 2 and 3 so if you enter a single digit it won't work and will keep showing "00" If I enter "23" for Ka-50, "23" will be shown, but if I enter "23" for Mi9MTV2's Ambulance or RF Navy, it shows "02" So it appears some liveries don't show "00" or "000" by default if nothing is entered, they show nothing, some liveries have an invisible first digit, so if I enter "524" it'll show as "24" no matter what the first digit is. All of this appears to only happen for center fuselage indications, actual tail number indications (for liveries which have them) seem to be fine. Such as "RF-92023" where "RF-92" is static and "023" is the editable tail number, there the behavior works correctly, if 1 digit is entered it is automatically regarded with preceeding zeroes, so you don't have to enter "007" to get "007" shown, but just "7".

Hello It seems like loading cargo from ships does not work, various helicopters either crash themselfs attemption to land or they land through the ship as if it's not solid and try to land on sea-bed but they blow up and damage the ship. When using 100 meters approach they blow up themselfs in mid-air even before attempting to land. I used USA carriers, civilian bulkers and a frigate and put the cargo on the appropriate Helipad zones.

Most other numerical value boxes have a left-right button inside them in the left corner, but Time-Date boxes do not.