Jump to content

Worrazen

Members
  • Posts

    1786
  • Joined

  • Last visited

Everything posted by Worrazen

  1. Yeah false alarm, I was opening it in LibreOffice Draw which took 1.8GB RAM, I think because it loads the whole PDF as an editable document and fully caches it into RAM, not just quick view. Opening in Okular or Foxit PDF Viewer on Windows takes less than 100MB.
  2. It does look like one yeah but, it open a page with a loading icon that spins forever and there's a small icon in right upper corner for download. It's Firefox for OpenSUSE (linux) Tumbleweed currently. ADD: Same thing happens on a much older Firefox on Windows 10
  3. Btw, perhaps replacing the PDF download with a direct file link, the preview link right now tries to open the PDF which at this huge size and complexity it'll probably never do in-browser, or it'll take a lot of RAM and lag a lot.
  4. Indeed, access to the airframe and/or cockpit would make it a lot more attractive because the 3D scanning can be imported into the 3D visual modelling software to speed up the process, taking less time and cost, and probably being more accurate than even what the blueprints would have explained.
  5. Yeah there is room for improvement in garbage collection, but it's general problem due to programming it self, C++ is such a programming language that requires manual garbage collection, it has to be programmed in, every bit of it. Don't worry about the "Standby Memory" or "RAM Cache", that's not the memory that will cause crashing, this is kept intentionally uncleaned by the OS or applications so that the next reads are faster. It get confusing if you try to dig deeper, it's a lot more complicated and the terminology doesn't mean what you'd first think it means, and it isn't consistent across the back-ends and GUI which adds to the confusion. If you fire up something else it'll drop unnecessary things automatically (it has some kind of an algortightm and rules which things to dump first, but I don't know how that is determined). If you get an actual crash you should report it, and record it or screenshot it, preferrably have multiple diagnostic utilities opened (process explorer, process hacker, task manager memory) while taking the screenshot when it crashed, and any error messages DCS might show. For DirectStorage, it's only for newer HW with updated Win10 and Win11, you don't need to turn it off, but you can't enabled it on games that don't support it, the developers have to patch games to add DirectStorage support. Either way DirectStorage won't work at full speed on Windows 10.
  6. https://www.khronos.org/events/vulkanised-webinar-february-2022
  7. When we say "The Vulkan API" we don't actually mean the raw API code alone, perhaps we're all not really using these terms correctly perhaps, but I think everyone out there uses the term API to refer to the whole pipeline with the drivers and all, so saying "Xyz API" does this and that, I'm talking about the whole environment, not just the raw API code. I guess perhaps the proper term would be to referr to it: "In a Vulkan API based environment" or "In a Vulkan API based application", but that's a mouthful. When you run a Vulkan based application, or in Vulkan mode, it won't use the same drivers as it does in DX11 or DX12. DX11 and OpenGL drivers where by because of the API it self, they have a completely different approach and require a lot more overhead from the start, and weren't designed for multi-threading the graphics backend (the graphics code that runs on the CPU). Vulkan's approach uses a "thin" driver that apparently does far less things under the hood and under the developer's radar, therefore also far more predictable and transparent in the stuff that it does, this is why it's harder to develop because many responsibilities shift to the application. https://www.intel.com/content/www/us/en/developer/videos/introduction-to-the-vulkan-graphics-api.html https://www.intel.com/content/www/us/en/developer/articles/training/api-without-secrets-introduction-to-vulkan-part-1.html One of the other things why legacy high-level APIdrivers are so bloated and require more CPU is because they run validation at all times for all end-users, with Vulkan API validation is optional. --------------------------------- As of right now, disclaimer I'm not a real Vulkan API or C++ programmer for that matter, I'm more of an analyst of the developer resource circles, going over the documentation and indeed spending hours reading it sometimes, various presentations, I spent many hours on reading up on Vulkan over the years. I don't completely agree with the earlier posts that the standard Vulkan API implementation out of the box does nothing without multi-threading. So CPU bound situations should definitely get some kind of a boost even if DCS wouldn't be getting the extensive multi-core enhancements across the board. The thin driver would immediately demand much less CPU resources by default, AFAIK. I can't find those slides right now but I distinctly remember that from the early presentations (That could have been Mantle API slides, but it should still apply to Vulkan). We would need a specific apple-to-apple comparison of an example Vulkan API implementation in single-threaded mode to a DX11 (ST) implmentation and compare just the driver overheads, which is what 3DMark "API Overhead" test might be all about. As far as games and sims go, who would bother going all the way to switch or add Vulkan API based rendering engine only to remain in single-threaded mode, so yeah, combining all of these things gets you some serious results in the end and it is very welcome that ED is taking a wholesome approach, multi-threading not only the graphics backend, but pretty much all the other major DCS components, and this is where a lot of the CPU improvements are. However as far as I know, again the cost of each draw-call is fundamentally much smaller with Vulkan API environment "it self", so hypothetically if you had all of this application multi-threading and kept "using" DX11 level of driver overhead and all of it's behaviors minus having that driver overhead stuck on one thread, maybe you could push much higher draw calls than standard DX11, but all of the CPU cores would get busier and thus less room to add other CPU work that the rest of the application could use. ----------------------------------- However, It remains to be seen to how much ED managed to split the various serial type of workloads, how much can be multi-threaded. I hope the AI logic calculations of each AI unit could have it's own thread or even threads, tho if they are expected to use very little CPU on their own for most of any kind of busy session, perhaps that wouldn't be necessary and a Unit Group could be it's own thread for example. That would get tricky when you have 100 units in one Unit Group tho, but I won't speculate on this right now, the approach could be totally different under the hood that takes care of my concerns here, dynamically spawning threads where needed, packing smaller jobs into threads, etc. Let's remember that many simulation type calculations cannot be parallelized, they will remain serial workloads even after all of the DCS multicore enhancements, a stream of calculations where the next one depends on the result of the previous one. Stuff like missile tracking, ballistic trajectory calculation and physics I think are serial and will remain serial workloads, but I suppose they don't all have to be on the same thread right, each weapon is independent and their tracking and physics simulation calculations could, but then there's the question of sync with the core engine for consistency and multi-player, so it's tricky how much of this can be independent. There surely would still need to be a kind of parent/main thread that connects all of this together otherwise you wouldn't have a working game, but it would have far less workload to do. I would appreciate if future reports would cover these questions as well. Would I be able to spawn 300x S-300 AA batteries and each unit would have it's own thread as per standard, then each missile launched would have it's own thread as well. Would that even matter in the end or would the engine always stall on something else first? But all of these small things could make a difference for really getting to be able to support those large dedicated server use cases, with a 128-core CPU and as much threading as possible maybe you could squeeze things out for a big mission, but then there are other things that are/would be parallelizable but may be too minor to make any difference in any kind of large scale mission, which would make that setup an overkill.
  8. Except Web is one hell of a platform to maintain, browsers keep changing things at a fast rate, generally Web and it's scripts are incredibly unreliable, depends on the skills and the environments, major sites may have no issues, simple sites either, but it's a very volatile environment. If it's all simple html then I guess it might work, but Mission Editor is going to go 3D, and that would mean trying to run DCS inside Browser, nah, possible, but it would be very impractical and inefficient for ED to deal with that on top of everything they have going on in terms of DCS codebase, legacy spaghetti code and stuff.
  9. I hope the modern displays/computer have an option for general font color, I still like green better over white for now.
  10. Appreciate the dirt airfields, that kind of auxiliary / emergency backup stuff is the stuff I like very much. Got a damaged A-10C, we probably won't make it back, but look there's that abandoned airfield there, might make a difference, if not rescuing the whole airplane anyway versus landing on pure raw dirt, it should increase chances of pilot survivability, more systems and cargo surviving, leftover fuel surviving, electronic cargo such as image or film perhaps etc. And to put these emergency gameplay use cases into actual use, the new DCS ground RTS systems part of the big so called Dynamic Campaign, has to support systems with such features in mind, so you could have several actions on the emergency landed aircraft in a dirt or otherwise runway, should be able to extract ammunition and use them elsewhere, extract fuel and use it elsewhere, extract undamaged cargo and finally even extract parts of the surviving aircraft fuselage or systems. You have a broken Jammer system on A-10C ... use the one from that stuck A-10C on that abandoned airfield, DCS Dynamic Campaign system AI commands an utility/repair truck to location (with escort) and you already have a logistics mission right there which can be a little side-story to the overall campaign, then get the spare Jammer and bring it back ... ofcourse you as a Pilot probably wouldn't participate in that if you're waiting for replacement, or maybe you as a player would be, so whether Dynamic Campaign will allow for swapping which pilots you control so you as a player could be at multiple roles in one session (Kinda like GTA5 character select, interesting?) Also DCS Multiplayer would have to extend support for game modes where fuel, ammo, spare parts are limited and ejections and pilot deaths and respawns cactually do count in the final score or some kind of a gameplay affecting factor. Partially it's already doable with scripts and warehouse rules AFAIK, perhaps not simple enoguh due to manual work by mission designer. Furthermore on the map and aircraft physics level, these abandoned airfields should be officially supported physically, not just esthetical graphics on the terrain. The terrain underneath and the tires contacting it should be supported so that appropriate terrain behavior would be observed. It's a bit hard to do it accurately for aircraft which were never meant to be used on offroad runways so real documentation of the performance is most likely not existent or rare. Aircraft not designed for offroad runways should at least be able to land in DCS and that would count toward the stuff I was mentioning. Perhaps only some of them being able to take off again if they're barebone and light enough. in a limited ammo type of scenario it would matter, or perhaps important intel or cargo onboard, and perhaps only take-off if they're empty. So the actual use of these things beyond esthetics, would give options for player comeback and open up strategies for a greater overall DCS experience. However depends how deep the Dynamic Campaign base-building RTS component is planned to go and whether ED needs documented cases in real-life to justify simulating these rare emergency uses, like salvaging engine parts, extracting fuel, which I think don't really have a problem with reality, it's something a military would do if presented with the challenge, but there hasn't been a large scale war in real-life of that kind where these cases would manifest and get documented. It would be a feeling of pity if DCS wouldn't be able to simulate these very probable possibilities just becuase they never happened to occur in real life military history. Might be somewhat more work tho, crash-model or damage-model would need more variations, but might not be that hard if you just hide the parts that get salvaged(extracted). Pretty animations would need more work tho, the military utility/repair vehicles with several engneers around the aircraft extracting the engine is very complicated animation if you want to do it in great detail, but for DCS, really don't need the esthetics, any simple approach should be fine at first. If lacking documentation I think a group of SMEs that specialize in mechanics, rescue, repair from general fields too as well as the military engineers, and the SMEs that were ex or even active mehanics that repair the very aircraft we're talking about, I think that's a topic they would love to brainstorm, they could advise ED on the feasibility and likelyhood of something working or not or how would it work, so that we can enjoy these things in DCS which do not happen often in real life.
  11. It's all about VRAM first and foremost, VRAM amounts are lagging behind due to the DRAM industry production bottlenecks, otherwise we'd already have 32GBs on these cards as per standard, and that would be enough to basically put one of the DCS maps fully into VRAM, but heavily depends on maps, with 32GB perhaps you could do that (I'm not on a system with DCS installed right now, so I can't have a quick check) RAM usage for gaming is in many cases as cache for VRAM data, graphics and texture data that the system needs in VRAM, but they either can't fit there, or aren't immediately necessary. So a high or low RAM usage isn't of a concern, there's no need to unnecessairly cache more unneeded graphics data into RAM, while VRAM is already being 100% utilized. The OP's GPU has 8GB VRAM and this isn't that much anymore, I have 8GB too and DCS's maps and everything would like to have much more if it could. Ofcourse VRAM alone doesn't mean that's the only blame for the OPs stuttering, we all know DCS is of a dire need to take advantage of modern software approaches in terms of multi-threading, resource management and graphics, which would enable a smoother experience even with not so optimal hardware resources. Most of the stuttering is actually more to do with CPU stuff than memory in my opinion. But yes, generally, we all know that software really should not stutter under a bit of resource constrain, if it's built to scale, if it has the ability to dynamically adjust it's output, but in a simulator you can't just not display an airplane or piece of land, it would look totally unrealistic, not to mention multiplayer unfairness if low-end users would see a less-detailed world and get some kind of an advantage, like seeing through forrest area or for, various environmental effects, etc. It might be interesting to see the comparison if for example you'd have game (DCS) debug and the OS too and disable RAM caching and just let the system deal with limited VRAM. However it be much worse on HDD and slow SSD storages than it would be today with fast NVMe SSDs, so either way it's not so bad like in the old days, but still ofcourse much less playable, any kind of stuttering can ruin the experience 10 fold. Either way RAM exchange has to happen on PCs because when you read new texture data from Storage, it has to go to RAM first, decompressed/converted by CPU before it can go to VRAM, but that's what DirectStorage is for, the data still has to go through RAM but the transport stack is apparently new and highly optimized for that VRAM upload to be much faster and the cost of GPU decompression is apparently much lesser as GPUs chrunch through that like nothing.
  12. Khronos Strengthens Vulkan Ecosystem with Release of Vulkan 1.3, Public Roadmap and Profiles https://www.khronos.org/news/press/vulkan-reduces-fragmentation-and-provides-roadmap-visibility-for-developers I wouldn't be upset if 1.3 is the new target for DCS and we suffer a delay for that Let it be a blast when it finally comes. Actually 1.3 is more about officialy confirming many of the existing optional extensions (features) as part of the core and required, so DCS could have already been using some of these extensions already. Dynamic rendering is highlighted, but how useful to DCS at this point it is, is out of my experience to speculate and guess. https://www.khronos.org/blog/streamlining-render-passes On the other hand, some of the extensions are mainly about making it easier for development, not necessairly improving performance or adding new features, but it would mean with less hassle a speedier development can mean we would get the final result faster. https://www.khronos.org/blog/vulkan-1.3-and-roadmap-2022 https://www.phoronix.com/scan.php?page=article&item=vulkan-13-2022&num=1
  13. Yes, youtube videos often seem to look better, tho I realized as well the creators probably enhcance things with Reshade which I think should be noted, but the video compression that youtube does also has it's side-effects that make it seem look better even tho it's technially not, they impose chroma-subsampling from 4:4:4 to 4:2:2 which loses color and pixels and should look worse than full RGB you get on the monitor. Other things the compression codec makes may indeed smoot things out in terms of aliasing so yeah, it's not 1:1 to what you see on the monitor.
  14. Yes, I made a new year (2022) commitment to not post any half-assed posts anymore and if it takes me a month to do a proper post then so be it.
  15. 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/
  16. 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.
  17. 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
  18. 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.
  19. 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.
  20. Interesting, I should give it a try once I have time.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...