twistking

Vielleicht war das einfach schon die Antwort, die ich gebraucht habe...

Maybe mod conflict or corrupted files. Delete all mods (if you have any) and run a repair/file verification.

Ich muss mal kurz Luft ablassen darüber, dass ED es nach Jahrzehnten immer noch nicht geschafft hat die Positionslampen der Flugzeuge korrekt darzustellen. Das ist so unheimlich frustrierend! Wie soll man denn mit nem Flugzeug ohne digitalen "Buddy Track" Schnickschnack einen Rejoin fliegen bei Nacht? Oder überhaupt nachts in Formation fliegen. Gibt es bei den ganz neuen Modulen (Mig 29, Chinook etc) irgendwelche Hinweise darauf, dass sich da was tut? Also dass z.B. die Distanz in der Lichter gerendert werden nicht mehr auf wenige hundert Meter begrenzt ist? Bei allen Modulen, die ich besitze, werden Lampen nach ein paar hundert Metern nicht mehr gerendert (zum Verzweifeln). Helligkeit stimmt auch nicht wirklich und bei einigen Modulen sind die Sprites sau hässlich und skalieren falsch...

The optimistic answer would be that radios are still WIP. The realistic answer would be that radios are still WIP but will be so for the coming years...

You can have spawning of units controlled by flags. So F10 would set some flags which would then be used to determine which units to spawn. Be aware that all the group activations should happen after the player set those flags, otherwise you would need to deactivate units, which is less straight forward i believe... I don't think there is a way to manipulate units skill setting with the ME tools though. *edit* Easiest way (but limited in many ways) would just be to spawn a limited set of groups for the "easy" experience and just "late activate" more groups for higher difficulty if flags are set appropriately. Would only need a few triggers.

I think it doesn't really matter. It's safe to say that currently every aircraft, be it a flyable module or AI is "broken" when it comes to the rendering of ext lights. I used to do bug reports for those issues, but they got ignored, so that's why it's a humble wishlist item now. I'm afraid that ED is silently aware that ext lights are broken since forever, but acknowledging that as bugs would put too much pressure on them to actually fix it?! It should not be rocket science to do it right, but would just need one orchestrated effort from the engineering and art departments. Every other game does this well and does it well since forever. It's negligence for the night environment and not an illusive art problem or a complex technical challenge. I sometimes hope that this is something that is on the back burner until vulcan get rolled out, but on the other hand it should not be complex enough for the vulcan switch to even affect it too much. It's a frustrating situation...

Thanks. I’ve been into "realistic" videogames for over 25 years, and I’ve thought about this dilemma a lot. I think it's just not worth trying to force "realism" into PvP. You can design systems that push players toward the dynamics we want, but they're always crude and end up feeling like crutches. Your idea with a single life mode will surely make players value their life more, but to me, that doesn't seem like an elegant or even practical solution. I'm not disillusioned though. I think each mode of play has its own strengths and weaknesses and embracing those leads to better results. My own frustration with the realism dilemma actually taught me to appreciate designs that lean into their format. I might scoff at "airquake" but I’ve also learned to enjoy Quake itself for what it is. I mean the actual arena shooter, not the DCS variant. For truly "realistic" experiences, I believe the real answer lies in cooperative play. And with advances in AI, I'm quite optimistic about the future of that mode.

I'm pretty sure that the Yak-40 and An-26 are the most used aircrafts in my missions not counting player/client controlled AC

Yes, technically you’re absolutely right. Coop is Multiplayer of course. Colloquially though, games with a focus on cooperative play are often explicitly referred to as Coop games. I think for some people PvP is considered the "default"; at least that's what comes to my mind first when I hear MP...

I think a lot of people really avoid the public servers. For me Coop is just a natural extension of singleplayer (everything is better with friends?). I don't even think of it as multiplayer per se. It's the default way of playing for a lot of games...

Maybe something to consider for an upcoming development report: From very early info about the DC (I think from Wags in a podcast, back when it was still in its early dev phase) it sounded like the DC and its logic would be a proprietary, monolithic system rather than a modular collection of parts. From more recent info though, it seems you’ve shifted toward a more modular approach. Improvements to logic and AI are being treated as core features, and the framework might even apply to user campaigns or missions of any size. Maybe I’m being optimistic, but I believe that’s the only really reasonable option. I’d appreciate if a future development report could clarify how the DC will play out in this regard.

Would not give me any feeling of accomplishment. To an organized group those random human opponents are less challenging and less realistic than the otherwise very challenged DCS AI.

So BATC claim that they developed their "small" LLM themselves. Meaning it could be extremely efficient. If you take an existing open-source / open-weight LLM on the other hand and just modify it with LoRA, you'll have some overhead, meaning your model might be bigger than what you actually need. This was probably the correct call for a product that is available right now, but i think for BATC the R&D required could have been a bigger economical factor than the running cost.

I would like to see the Venn diagram of people constantly wishing for and buying new aircraft modules vs the people who fly public PvP exclusively. Is it a perfect circle?

I think all major points have already been made, but there is another slightly more subtle argument, that i call the penny pusher problem: Public PvP in supposedly deep tactical games can feel like coin pushers: You can approach the game with skill and planning, but the tactical outcome is determined less by your individual input and more by the unpredictable cascade of random strangers piling in. Each round looks the same on the surface, yet wildly different results occur depending on who happens to show up and how they collide. Without roleplay, or at least shared intent, the illusion of a tactical layer collapses into arbitrary social randomness. Players might believe their actions are decisive, while in reality their agency is constantly undercut by uncontrollable and completely opaque variables. That kind of randomness can work in Quake, where chaos is the point and individual skill shines through nevertheless, but in a game that sells itself on tactical depth and interconnected systems it creates frustration imho, because what should feel like a battle of strategy ends up feeling like a chance based arcade machine. This randomness is arbitrary and opaque: It creates noise rather than depth. Therefore it should not be mistaken for the kind of randomness that fuels replayability in well designed dynamic scenarios (dynamic campaign?!) where variation emerges from clear rules and systemic design. In those scenarios, even losing can be satisfying, because players can see how their choices interacted with the rules. PS: I think the penny pusher problem captures the dilemma where public PvP inevitably drifts toward airquake, despite mechanics that on the surface aim to promote coordination and tactical play.

Oh, you were right. Interesting! It seems to be a new-ish addition and it's glorious. https://youtu.be/oV0oZvng3Pc?si=Krqa8SiYP1--eH4D The clearance guy in the tower also sounds a bit like @Wags. They have made their own small LLM, but they run it on their own server - not client-side, so there is no performance impact for players. You're right that this might not be commercially viable for DCS (i'm surprised it works for them to be honest), but ED could (and should) copy their approach. In a way it is very similar to my proposal, only that BATC have their own cloud-based model, while i propose an API hook at a similar position in the pipeline. In both cases the key is, that the LLM doesn't run the show by itself but is more "informational", while actual decisions are made on the scripted level. I hope ED watch the linked video and get inspirations from it. It's important to understand that such a lightweight LLM like BATC uses will soon run on every gaming PC and will do so with minimal latency - either on a few CPU cores or on a cheap, dedicated AI accelerator card. The complex part is not the LLM. The LLM is only an economical hurdle and won't be that forever.

BATC will probably not use an LLM, but simply sth. like STT->NLU->Clever Scripting->TTS This is also a very realistic expectation for DCS i think. It could have a small performance impact, but should not be noticeable on modern PCs. Arcade players could always ignore the ATC as they do now assumingly. Wags said that ED would be exploring the possibility of using TTS. Can't remember if he said anything about STT/NLU though... Of course it would also be possible to provide an API to have STT/NLU externally. Similar to what we have now with external STT software. An integrated system would simply be more convenient and robust. All the needed models are open-source and can be used commercially even. The only economical "road-block" - with current hardware - would be the LLM component. That is why i propose to have that as an optional thing via API hook. Early adopters could just use a cloud-based LLM if they want. Eventually every PC will be able to run those LLMs locally for free...

Does this mean that jamming is currently in testing on dev built? Why else would there be placeholder units in our built? Can you share something about planned scope of the feature? GPS Spoofing AND jamming? Radio comms jamming? Datalink jamming?

@SharpeXB@MAXsenna Fair enough. If ED released something like this tomorrow, most people simply wouldn’t have the hardware to run it locally anyway, and only a few would be willing to pay an AI company to make it work. In a few years, however, even mainstream PCs will be able to run a lightweight LLM alongside DCS without issue. The STT/TTS and NLU integration is something we’ll hopefully get with the improved ATC (and it would be a disappointment if not). If ED is reading this, I’d just want them to consider future-proofing it by designing the system to be modular enough for an API hook. Those optional LLMs could then be fully community-developed. ED would “only” need to provide a robust API, which - in the grand scheme - isn’t that much work actually. Assuming STT/TTS/NLU are all in place for the new ATC/AI communication: the API hook would sit in front of the TTS in the AI response pipeline. Instead of the TTS receiving input directly from the scripted system, the script-generated reply would go to the API together with auxiliary game-state data. The community-developed LLM would then generate a richer reply from those data points, which is finally sent back to the TTS. I would argue the difficult part is the STT/TTS/NLU and scripted logic, which ED is hopefully already working on. The API is comparatively easy. Tuning the LLM through LoRA to work with the provided data in an optimal way could then be a community effort.

That would be great: Silently communicating by wing wiggling alone is not very effective. And please add some animated pilot gestures for the pancake crowd as well...

Ok, i think that's a NLU model, which allows you to say stuff out of order with the system still understanding your intent from a limited set of possible commands. These are lightweight and would also be part of my proposal. I just did not mention them specifically to make the post easier to digest. The benefits of optionally integrating an LLM would be that the AI could actually react dynamically to situations in the sim. The API would not only pass along player communications (in text, after STT), but also selected sim parameters. For example, a flight instructor LLM could assist new players, while a RIO could comment on your flying skills or provide input on the tactical situation. The API could expose different sets of parameters depending on the role the LLM is meant to "play." A RIO would receive aircraft states and the tactical picture (within the realistic limits of what it could actually know). The model could also be trained on DCS manuals and NATOPS. I think the advantages are obvious, but i admit that currently it might push most computers too far. However, in just a few years the situation will be very different. There are already extremely lightweight LLMs that, if trained on the right data and fed with real-time game states, could easily take on the role of an instructor or a cocky RIO.

Interesting! I just watched a video about Beyond ATC, but it’s not entirely clear to me how they handle it technically. The underlying logic is probably still scripted. Placing an LLM between DCS logic and the text output could, however, add some useful functionality. Not strictly necessary for ATC, but for communicating with an AI backseater/RIO/Wizzo or C2/AWACS it could make a big difference. Yes, I’ve considered the economic hurdles, but please note: the STT/TTS components are open-source, proven, and reliable. ED would mainly need to build a robust scripted system that covers as many situations as possible. That’s busy work, but not rocket science. After that, they could develop a stable API that optionally connects to either a locally hosted or a cloud-based LLM. The LLM part would remain optional. Players or server owners could do one of the following: run a model themselves (a modern 16-core CPU with 64 GB RAM can already handle a very lightweight LLM alongside DCS) connect the API to a paid cloud-hosted service simply skip the LLM entirely and still enjoy high-quality, low-latency voice communications with AI in DCS through the scripted system

Amen! DCS needs consistency... and i'm not even a PvP guy.

It's a bit sad, that an aircraft that is known for having the most outrageously fabulous liveries comes with such a bland selection in DCS...

Hello, Since ED is currently prototyping new ATC and presumably other AI interactions, I hope I can provide some useful suggestions. I'm very critical of LLM "AI," but for video games - especially dynamic and immersive simulation environments like DCS - the technology is, in my opinion, extremely useful. To my surprise, the technology has now reached a point where it is also technically viable for a product like DCS, with very lightweight and fast models that can run locally on client machines, thereby solving a lot of economic obstacles. Also, most of these models are open source and relatively easy to implement. The cornerstone would be TTS/STT on the local machine, meaning speech generation and natural speech processing from the player (through a microphone). Models are now fast enough to run alongside DCS without significantly impacting performance. However, minimum system requirements would increase, as at least 2 CPU cores and a few GB of RAM would need to be dedicated to this task. This approach would not allow free-flowing conversations with the AI. The logic would still be scripted. A full LLM capable of handling open-ended conversation with the player would require a high-end workstation PC if run alongside DCS. However, models are becoming more efficient and average player PCs are becoming more powerful. ED should therefore anticipate the feasibility of locally running LLMs to further enhance the experience. In the meantime, ED could create an API for external LLMs to hook into their system, not to completely take over the logic but to augment the scripted logic with flair, personality and more dynamic conversations. Such an external LLM could be cloud-hosted (e.g., using the user's paid account with providers like OpenAI) or locally hosted, either on the player's machine or on a dedicated PC on the network. The proposed system would be fully multiplayer-compatible, since all communication with the AI is exchanged as text, while TTS and STT are handled locally on each client. If a larger LLM is desired for more free-flowing conversation, it could be run either on the server or in the cloud, with the server API managing the interaction between the game and the LLM. Thanks for reading. PS: One major advantage of this hybrid approach is that the LLM component could be easily maintained and expanded by the community. With a clean API separation, there would be no security risks for multiplayer or core gameplay, but plenty of room for creative extensions. For example, different LLM “personalities” could be developed - from a strict flight instructor helping beginners step by step, to a more casual RIO adding flavour and banter to the experience. Neither development nor maintenance of these LLMs would be on ED, as long as they provide a robust API for the external LLM to hook into.