Leaderboard

https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.18.12899/ DCS Core Fixed: CTD when landing on a carrier with no radio communication. Scripting API. dostring_in default behaviour has been returned to the state before last patch, after initial feedback and issues with single player campaigns. We are evaluating feedback for future change. DCS: F-16C Viper by Eaglе Dynamics Fixed: F16C Crash F16C.dll. DCS: AH-64D by Eagle Dynamics Fixed: Crash when using George CPG.

Wenn ich nichts übersehe, haben wir hier im deutschen Teil des Forums noch keinen Thread für allgemein wissenswerte Schnipsel, die nicht direkt mit DCS oder Luftfahrt zu tun haben, dabei zu interessant sind, um gänzlich unerwähnt zu bleiben, aber nicht interessant genug für einen eigenen Thread. Zum Auftakt gibt es die Empfehlung, die Nvidia-Treiber zu aktualisieren. https://www.heise.de/news/Sicherheitsupdates-Schadcode-Luecken-in-GPU-Treibern-von-Nvidia-geschlossen-10501190.html Nvidia hat in den neuesten Treibern teils kritische Sicherheitslücken geschlossen. Falls ihr eure Treiber von Hand aktualisiert, wäre jetzt ein guter Zeitpunkt für ein Update.

Thank you to everyone who gave constructive feedback. After initial feedback made it clear we need to rethink our approach we will with todays hot fix patch temporarily revert net.allow_dostring_in changes. We are considering a GUI toggle option for a future update.

Vietnam War Vessels 2.0.0 This release is a major update of the Vietnam War Vessels mod. With VWV 2.0.0 comes a new directory structure, where all assets have a [VWV] prefix in the folder name. This makes it necessary that you first uninstall the old Vietnam War Vessels 1.x.y completely. We welcome the USS Enterprise, CVAN-65, in its 1966 configuration, to the fleet. The first nuclear driven carrier has been derived from the modern USS Enterprise, and takes a place of its own now. The complete launch and parking system has been overhauled, leading to a hopefully more immersive experience. The second new addition to the mod is the A-37 Dragonfly. This iconic aircraft of the Vietnam War is now available for AI use within the virtual DCS sky. Please take a look at the Known Limitations below! Updates, Ships Knox class - FF icons are used instead of DD BB-62 New Jersey - CC map icon in use, better helicopter landing on the deck, new custom shell for main armament CVA Essex and Bon Homme Richard - model improvements, nick name as short display name for Bonnie Dick Many ships - sound updates to gun fire Updates, Planes A-1 Skyraider - split into A-1H (with bridle cat support) and AD-4 (without), add Napalm bombs from A-4E-C mod, add toilet bombs to all pylons, rework flight model to take off from Essex ‘44 with 70% loadout H-2 Seasprite - use of a new model, split into SH-2F, UH-2A, UH-2B, UH-2C classes MiG-21MF overhauled nose gear, support for RATO take-offs O-1 Bird Dog, add engine nozzle definition, Flight Model change for more realistic take-off RA-5C Vigilante - Flight Mode change, more lift at low speed Known Limitations CVA-31 Bon Homme Richard - Player controlled helicopters slightly move forward on the flight deck F-8 Crusader - Aircraft is intended as static and for limited AI operations - Player control is experimental at best, but largely untested and unsupported - Carrier launch and landing operations are not supported for player aircraft, only AI - Unknown how to drop bombs as player aircraft - Variable incidence wing is not enabled - Collision shell not reliable under player control - Nose wheel rotation disabled MiG-17F "Fresco-C" - Player control is almost untested and unsupported - Collision shell not reliable under player control - Damage susceptible when placed as static H-2 Seasprite - Wheels don't touch the ship deck - Landing gear is deployed multiple kilometers away from landing spot Fletcher Class Destroyers with FRAM II upgrade - Bridge and mast are WWII style RA-5C Vigilante - The plane is too large for regular parking spots, best to use as single plane on the runway MiG-21MF "Fishbed-C" - Textures are work in progress - Gear up location is pretty bad A-1 Skyraider - The new bridle disappears during launch - The precision of dropping Napalm is abysmal - Takes off like a spaceship from land - Tiny Tim rockets seem never to be launched A-37 Dragonfly - Flight model is raw and has not been tested much - Only one pilot ejects, ejection somewhat broken O-1 Bird Dog - The propeller blur is static CVAN-65 Enterprise - Catapult hookup spotty, sometimes planes start to drift - Parking spotty, some planes start to drift - Probable inability to sync INS when taking off cold - RA-5C and F-14 Tomcat slightly too large for safe aircraft operations when taxiing - The shoot power of the catapults seems insufficient at times - No support for night operations, e.g. no lights Download (Github): https://github.com/tspindler-cms/tetet-vwv/releases Alternative download (Google Drive): https://drive.google.com/drive/folders/16pUuupD08L36KnD6vDel5VRlmwwftX5o?usp=drive_link Enjoy, The Vietnam War Vessels team

hi guys , With the precious help of HAGEN and holydays starting , the pit is on good tracks ! here are some pics !

With Great Contribution of @flanker78. good advance on W IP ASM, big work Comrade ...

I've given it a go in IL2. Apart from the auto IPD being a bit sketchy (I intend to set it manually next go, not sure how that's done yet though) it's quite impressive. Flawless performance at native res and 90fps (5090 and 9800X3D). The higher rez over the OG is noticeable and the colours are betterer. The sun though, jeezuz!

That's the bottom line. A few people forget there is a lot of players that don't touch on PvP where crafted missions, dynamic campaigns, mission generators and co-op vs AI far exceeds enjoyment on hoping onto a server that once again is at noon, few clouds and is constantly unbalanced by player numbers let alone machinery specs. Kudos to ED to make an F-35 if it is their wish to do so. Many will flock towards it in many scenarios solo and with their friends in co-op.

Hotfix https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.18.12899/ DCS Core Fixed: CTD when landing on a carrier with no radio communication. Scripting API. dostring_in default behaviour has been returned to the state before last patch, after initial feedback and issues with single player campaigns. We are evaluating feedback for future change. DCS: F-16C Viper by Eaglе Dynamics Fixed: F16C Crash F16C.dll. DCS: AH-64D by Eagle Dynamics Fixed: Crash when using George CPG.

Well said! I absolutely agree. I know the intention of the original comment was to point out, it is a bit of advanced scripting, but the attitude of "if you don't have at least A certificate and 3 years experience in any major script language and already know lua, you won't understand" doesn't cut it. Every(!) DCS creator started learning the DCS scripting environment by reading the documentation, researching hoggit, looking at other scripts AND mostly, kindly asking this awesome community for help! And help was given, not snide comments. To make use of the new scripting features it is necessary to understand what they do, how they do it, and especially with the security implications, in a way that people don't fall back to the usual "just give every permission and it works". I've seen so many YouTube videos, posts and comments in scripts, that tell people to "just comment out the following lines" to de-sanitize the DCS lua environment and the script works fine... Some at least point out, that this means you should review ANY script in every Miz file and make sure it doesn't contain malicious actions on the io or lfs environments... but, like cfrag pointed out, my guess is the majority does not understand the implications and just did it, to "make it work".

I think I never mentioned blame here and I feel many believe my comments were anti F-35. It's not the hate, its more of an a critique on how the ED's DCS ecosystem is built. To understand this better lets consider how the MP servers work. To play this in MP with reasonable level of authenticity, you need both sides if the server/mission intends to have healthy population. In PvE this does not have worry about this. You can happily have 60 F-35 racing each other to kill more Mig-21s and other lower aircraft, as long as you spawn enough of opponents to keep them happy. There is certainly a customer base exactly for this kind of level of commitment. In case of PvP this assumes that both sides have equal chances of winning the game. F-35 will not have the counterpart which means that the server will have unhealthy and unbalanced population, unless server owners bring F-35 on both sides. Historically even the most famous servers did struggle with maintaining the healthy populations. After a while one side would simply stop playing, and almost always the server owners go for introduction of PvE elements. At the end these servers stay with low count of players only to deplete completely when a new server with healthier and larger population arrives. This is how practically most of famous servers died over the years. Now some may mention the skilled players may try their luck with low tier aircraft. In the wast majority of cases they will not do this, keep in mind that they are actually the smartest players around.

Should be soon.

The important thing to emphasize in regards to the AN/ALR-56M in DCS is that it is not really an issue of evidence or documentation, but of interpretation. As I mentioned, the DCS F-16C manual was correct in the way it described the functionality of the AN/ALR-56M, but the way it was implemented in-game was based on an incorrect interpretation of that information. I'll look into writing a bug report on it when time allows.

Any changes performed to the damage model are global, including previous missions or campaigns, unless you modified data in files or added scripts. this issue is now fixed. thank you for confirming

Mine's just been delivered. The address on the label is correct and Yamato hadn't already tried to deliver it, so fk knows what Pimax was talking about. Probably sitting there giggling, getting me at it. So, cleared customs on the 12th, I finally get it sixteen days later. I haven't opened the box yet, I've run out of energy.

The blame on this lies on the server/mission creator, not ED.

Off course PvP to be any fun requires balance, but simulation doesn't, it only requires to be as realistic as it can be. Cause simmers wanted realism, and that doesn't include balance

They are quite easy to understand and you have described it fully. …which is still more than it should be and which creates insecurities that didn't exist and shouldn't exist. It's that simple. This is a bad solution, implemented hastily with no warning and seemingly no testing of value. The number of things it breaks for no gain is ridiculous. The workarounds create bigger problems than what initially existed and does the exact opposite of what was intended with this whole idea. Hell, even the OP gives a big red warning sign. The reason I say that you didn't do any testing is because you've managed to break SLmod for a number of people — probably other common and crucial mods that are used all over the place. This should have been an immediate discovery and show-stopper. I would suggest a two-step process: Hotfix-patch rollback. Do any of the things cfrag has suggested. Or see two posts above. This may seem drastic and contrary to how ED does anything, but trust me, the alterative is much much worse. That alternative would require them to, first thing tomorrow morning… At the top of the forums, the DCS website, the launcher, in the game main menu, and on every reddit, discord, and My Little Pony Online chatroom where they have any kind of social media presence, put out a warning sign in huge blinking letters that they have changed the security model in such a way that users may now be tricked into allowing remote code execution. In a very public post — not hidden away in this obscure “mission editor” corner of a forum that not many visit to begin with — document, in full, what the function does, how the different scopes work and what they affect, and under what circumstances each scope might allow for ACE. List and publicly endorse the minimalist exception rules for the 12 most common scenarios where you might want to allow dostring_in to work, from an end user perspective (eg if you want to use some of the products ED sells, or use userfiles of some kind), from a server perspective (how do you still allow common server mods to function, what are the caveats, how does it minimalisticly mesh with eg. shared moderation roles), from a coder perspective (what are the most common uses, what do these require in terms of exceptions, what are other more secure ways of doing the same thing). 36 cases in total, full documentation, full transparency of where, when, and how code (and in particular remote code) can be executed. Determine and clearly communicate which scopes and combinations should pretty much never be used because of what they open up. And in doing so, maybe just not allow that to begin with. Again, anything that creeps towards “remote…” should probably be stomped hard. Implement some kind of code signing so the end user can differentiate between trusted developers and random junk they find on the intenet. Congratulations, you are now Microsoft. Oh, it's just text files and there is no way to sign those…? You don't say… It's almost as if it has caused new problems. Implement a security tab in the game settings where this and related settings are made. Too many things are affected by this to just leave it as an obscure text file code injection — that just leaves option the ability to trick people into putting harmful code in there. If kept, the model need to be extended to not just be “these scopes are allowed use; these scopes are allowed access” but rather make it a proper model where you can decide, scope by scope, what is allowed. A full set of access control lists — congratulations, you're Microsoft again. This, once more, requires something a lot more complex than can be safely relegated to code in a cfg file. Rather, in the Security tab, these options can be explained to the user and particularly bad combinations can trigger warnings our outright blocks (here, at this level, is where it might be appropriate to allow overrides via cfg file edits). All that to make sure we don't get a slew of malicious code out there, combined with malicious suggestions for “solutions” that leave the client wide open. Again, the problem here, as others have mentioned, is that users will just be faced with an error box and go search for the first available solution. This will not be your clean three-line autoexec addition, but rather something far more malicious. ED's official answer and suggestion needs to be the first hit on every search engine, and anything that deviates from that should come with a huge warning that the player will notice. The information campaign needed to combat malicious use of this new security hole is immense. Let's just be kind and say that huge information campaigns are… not ED's forte.

No discussion here. DCS needs good, scalable and easy to maintain security. In the past, I have recommended a couple of approaches in these forums how, for example, DCS could easily sandbox (better: sidestep) the lfs 'sanitize' issue by allowing a controlled, sandboxed 'writeString()' method that saves a string to a mission without having to 'de-sanitize' DCS (and compromise security). It was never followed up on. Pity. Instead we got the 'save mission' system that simply doesn't work, solves no problem at all, lfs still needs to be de-sanitized using a really, really bad 'unlock this for everyone' approach, just like this approach for dostring_in(). And to truly underscore how bad things are, the two approaches to resolving related issues (security) aren't harmonized. To me this is indicative of deeper troubling issues at ED than merely a bad IT security design team. The problem is that this new 'enhanced security' is, as implemented now, utter garbage; an inept, heavy-handed approach that will lead to LESS security. Why? Because soon (if they haven't already) videos and article will appear that tell you how to 'fix DCS' when all these "attempt to call field dostring_in" errors pop up in-mission. Invariably they will tell you to 'simply place this autoexec.cfg here, and you are done'. Because of the hare-brained one-size-fits-all approach, now the entirety of DCS is open, for every mission (not to mention providing a new attack vector through a malicious autoexec.cfg that is provided by the attacker in the video). Anyone with merely passing working experience in security can tell you: this approach is bad, much worse than not doing anything. So my opinion: this 'security' design is utterly inept, and it results in REDUCING security because everyone will bypass this 'security' for their comfort. Its like putting a fantastically complicated lock on your front door. Because it inconveniences everyone, they just keep it unlocked, opening the door for anyone. Is that improved security? A better design would allow per-mission sandboxing. There a billions of possible approaches: put the mission in a folder /insecure, and if it is in there, use the settings screen in DCS to regulate what is allowed (and yeah, lfs and io should be in there too). Better yet: have a GUI for that allows players to drag missions/directories into. Any mission in there is allowed risky stuff (configured by the GUI). Simple, and it does not take a lot of talent to implement. I'm not saying that above is good security design. Far from it. I'm merely saying that it's better by orders of magnitude than the current, inept design. What deeply troubles me is the fact that something this badly designed has made it past the design stage. What angers me is that it made made it into production. ED - you have a serious quality issue. Cheap, badly thought out code like this should never make it to the customer. This is really, really bad, ED. Please fix it. And please, if you don't have the talent, I'm sure there is ample talent in the community to help you out. Just ask.

DML has completely gone South, and today I do not feel charitable. Any mission using a recent version of DML, Olympus, SSB, or slotblock (i.e. anything Foothold or similar) will no longer work without you changing your DCS install. Expansion, most of the missions I released to UserFiles in the last year, and many interesting missions created by others in the last 24 months are affected. They continue to run, but you must install that godawful "autexec.cfg" <shudder> in the correct location(s). And yeah, that includes your servers. Good luck figuring out which context name corresponds to "scripting" - you may have to rewrite your server scripts. If you can. Fun. If this continues, I foresee that - out of simplicity/convenience - 90% of all DCS installs are set to execute insecure code, completely ruining security - the exact opposite of what the kind people at ED set out to do. Maybe they should have asked someone...

This is atrocious -- I am severely disappointed and aghast. I feel that you (ED and their community managers) could have announced this change more than 24 hours in advance (6 months would have been a better time frame), and perhaps solicited feedback from the community -- because the way that you (ED) chose to implement this sandbox protection scheme is a 1980's design. "autexec.cfg" - are you frigging kidding me? Doesn't anyone at ED understand modern UX and or UI design? Why use such an obsolete and user hostile one-size-fits-all scheme when it would be so much better to build a "sandbox on/off" switch into DCS proper, and then add a simple UI that allow users to add folders to an 'allow unsafe' box that automatically allows unsafe invocations for any mission inside? Users could drag folders/directories and/or missions into the box and - boom! - they allow unsafe invocations. Designing this is (or should be to your talent) near-trivial (I did interface stuff like that in 2 hours -- 2002, on a Mac in XCode!), and a so much better approach for users who grew up with a Mouse. I feel that this new 'design' of yours is unworthy of you, and it feels like such a blatant slap into all of your content creators' face that I am deeply saddened to see how you simply (and callously) implement a far-reaching change like this without ever feeling the need to consult your community and contributors. Are we that worthless to you? That new 'feature' of yours kills any mission that uses net.dostringIn(). You do realise that mission scripters resort to doscript_in because DCS's mission scripting environment requires this to circumvent a bad flaw in MSE's design, do you? This means that any mission today that is sufficiently advanced will stop to work and require that unsafe patch, which will probably result in most DCS installs being unsafe. The exact opposite of security - likely a complete failure of what you set out to do. Why, why, why did you not try to sound out this change with those who spent lots of time creating missions for your product? I would have expected more from you, ED. For the record, can I request that you. or someone from ED, elaborate if you agree that this is merely a coarse stop-gap and that you do have a real, user-accessible and well thought-out future version waiting in the wings? Because this? This is bad design. Will we get a real 'sandbox' security interface for DCS? I don's feel like updating the 50 (?) missions I put on Userfiles, so maybe they run, maybe not. 9 out of the last 10 missions I published there no longer work and now require unsafe invocations. So be it. I cannot be bothered to care if you, dear ED, can't be bothered to engage with your community either. What a mess. I hope that you will fix it soon. Will you, ED?

Guys, I just tested the Sniper TGP and I have to say that you did a wonderful job with the video filtering. The digital zoom feels like a digital zoom, the video processing of the XR feature is top notch. You really feel like you are using a real TGP with flir instead of a reskin of the F2 camera on the MFD. Now my question is, are you planning in updating all the older TGP, mainly all the different litening implementations on ED modules as well? Or will the litening remain as a superior pod just because you have unrealistic focused and sharp digital zoom and sniper will be just for SIM hardcores and campaign developers? Because as it is now, the Sniper is inferior to the litening (and don't start me with the litening v4 of the razbam harrier) because on those the "digital zoom" is sharp and the flir cam is just a reskin of the TV cam, all sharp with no halo or smudges. The lantirn is ok in both implementations (tomcat and eagle) I'd say the FC4 images can stay because that's legacy code and should be a nightmare.

As I've mentioned earlier MP servers don't exist in a vaccum and there is a lot of pressure from online community towards mission designers and admins. I don't like it, but it is a fact of life. People want to be aces and shoot lasers, so that they can land on home plate for tea and medals. If the sim offered F-35 along with Su-57 (not that it's possible), this would make more sense. No one's gonna fly a target drone for shooting practise.

I'm glad it finally worked out. As one of the lucky ones who has been able to test the Super for a few weeks now, I can only say that it was worth the wait. Have fun unpacking and enjoy!

Hi, we are aware and have fixed it on our side already. It should be in the next update in August

I have benefited greatly from your training missions on various aircraft, so it makes me VERY happy to have been able to give back to you!!

Fixed. It will be available in a forthcoming update.

Could it be a potential side effect of the new "sanitization" of the dostring command? Did you try putting in the autoexec.cfg in this thread?

Indeed, and the Mini Updates thread hasn’t gotten an Update in almost 3 years…

First thing I’d do, the moment a “forum assistant” is introduced, is figuring out how to turn it off

Scared of what? Because of a name? The map has not been pulled from the store. That means it was not in Razbam's power to do so, and should tell you everything. Cheers! Sent from my SM-A536B using Tapatalk

Hello Folks, there we go to the beloved Su-35S Flanker-E/M. Still WIP for current time, no release date planned yet, we keep working and upgrading models, External and Internal 3D, EFM and ASM. Internal with full clickable cockpit. keep tuned ...

Hi all, I was just wondering if you are planning to get AI working cooperatively. I mean today when I see for example two fighters AI (reds) commiting to a couple of aircrafts (humans or humans and AI), what I see is the red engaging without any conscience of the other red wingman on the sorting and maneouver. Even not also being aware on the allied SAM that can support them on the engaging. It would be great if the AI AA is able to work cooperatively, for example doing drag, delousse, etc, or dragging to a red SAM the blues or to anothe AI aircraft, perform grinders, etc. @BIGNEWY, @NineLine Is that kind of things in the road map?, how far are we today to that picture? Thanks in advance.

I just finished this campaign, and if you're open to it, here's some constructive feedback (forgive me if I come across as blunt but I prefer clear communication): Pro: Cons: Overall: A little story from my experience: Closing thought: clearly a lot of effort went into making this campaign, so I thank you for that and wouldn't mind seeing more in the future IF they are a bit more VR-friendly

KC-135 Tanker Improved PDL Lights

LOL. As long as it is not same solution as in Il2 where the whole cockpit moves when you hit the limits. Personally I learn the limits of head movement available so I don’t end up with my head outside of the cockpit. Takes a while but even this bull headed type learns!

Yes hotfix planned for today

Looks like it's not decided yet:

Calm down, son. Catch a deep breath rather than going full reheat against someone who started with "Apologies". Also, it is a legit question since this has been done for what, 17 years? You know, copy coordinates either directly from the game or to a piece of paper, plan before the mission itself on the F10 map, Google Maps, CFlite, and make your own spreadsheet. But you want something in-game, right? Is the ruler not enough? Drag a line and call it day. Why does that not work? You can also write the results on the canopy itself, instead of using openkneeboard. Actually, I will record a brief video to show you how you can open a map, drag a line, write two numbers. Already in-game, already in VR, takes a minute. This would be so much more coherent with your statement. Ad verbatim: > It would be most beneficial for just about every single phantom player that really wants to play with the module in the spirit of true gen 3 aviation. But I doubt you want that. In fact: > This is about getting basic information calculations into the kneeboard from the off, which is easy for a PC to do if you have known GPS positions. Having the bearing and distance to the next waypoint as part of the kneeboard would be invaluable. These are not really basic, but OK. If I understand correctly (my English is not great - "from the off"? Off mission, off track, off what?), you want something that knows your position as well. I thought we wanted a "true gen 3 aviation" experience here. Anyhow, since you want a GPS, the NS430 works perfectly (it also lets you cheat when updating the INS Fix, but don't tell any real pilot, they get mad because they never thought about it /s ). I have an F-4E/G EWO/WSO and a F-4F pilot who mentions that they used actual GPS in the Phantom in their career. If you want no GPS, then the solution is simple: INS, pilotage and DR. But I see it's not over: > It was then a logical progression to have a speed table to calculate times on the fly in a vertical column, or even two columns would make sense. Ok, now you want multiple speeds. So, to recap the necessary parameters to do what you want, we need: TAS for each turn/leg; Course for each turn/leg; AoB/G for each turn/leg; Altitude for each turn/leg; MagVar for each turn/leg; Wind direction/speed for each turn/leg. I can think of more parameters, but this should give a general idea. The first 4, besides the course, require manual input. Wind is interesting because it is a big factor that should be accounted for IRL. But wind changes. So, do you want it fetched in real time in DCS? What happens when the dynamic weather arrives? Anyway, the input part is getting crowded already. But then you want fuel as well. OK, easy to do. Should DI and weight be calculated in real time and fetched in DCS? Or at the beginning of the mission? Or at the first WP? Is the first IP the ingress/reference or just a turn? What if there is an AAR scheduled before or after? What if you are delayed? How do you plan for a dogleg/trombone fuel-wise? All these variables should be specified somewhere. This kneeboard is getting a tad tiny for the purpose. However, up to here, it's all easy. But then the problems start: DCS players. Imagine you build your mission and flight plan from the mission editor and share it. Altitude is 10,000ft, speed 360, 2000 ft 420 kts at the ingress, 540 kts at IP and delivery. Player A flies instead at 6,000 ft the whole mission and at 450 kts. The plan says he can make it fuel-wise, but he uses reheat for too long at departure, or perhaps loads a couple bombs more, and he runs out of fuel. The next thing he does is go and complain because the kneeboard doesn't work. I know because, throughout the years, I answered so many complaining about the AIM-54's crappy performance, when the fault was all theirs. The alternative would be to recalculate everything in real time: positions, timing, fuel, speeds, DI, wind, magvar, et cetera. Feasible for sure, but then you are asking for functions present in the modern Hornet and a GPS. Not really "gen 3 aviation" vibes here. Why not use the NS430 at this point? It is actually realistic past a certain time frame. The point I'm trying to make is quite simple: either devs make something very basic, like course and distance from the specified points and leave out player-influenced parameters, or you make a thorough tool. The former can be done already with no additional tools, both in VR and pancake, and takes a minute. Seriously, I'll put a video together when I have time. The latter requires more work, but this must not be on HB's shoulders. It should be a concerted effort driven by ED. There should be a proper planning tool before pressing "Fly", opening a mission editor-like page, where all the parameters can be set. A nice, full-screen tool, with all the appropriate parameters, where the members of the package can be specified and the plan shared (not only across groups, as on casual servers, this does not work), and so on. Something that works across modules, with the option of having Jester ready to input coordinates right after startup, and creates a series of reference kneeboard pages. Ideally, something that spits out something like this: https://flyandwire.com/wp-content/uploads/2025/04/low-level-planning-tool-launch-example-map.jpeg It is quite simple to do, in my opinion (but of course, I don't know what's under the DCS hood, so it may be very complicated instead). It's all a matter of resources, priorities, and time. ED already has a lot to do in this regard. Nevertheless, a planning tool, a TacView and LotATC equivalents should be part of DCS already. The in-game VoIP is a good first step, but it'd be great to see more basic functionalities "returning to DCS". Again, this is not a 3rd party's job to do, no matter how cool and sexy they are So, if you want something like that, I'm all aboard for it, just tell me where to sign. A kneeboard page instead is good to present an output, but there are too many parameters to be considered if you want to do a thorough job, and, imo, it is not worth the dev's time. What do you think?

Threads merged, this is still on our list to do but there are higher priorities ahead thank you

Ordered 12 Feb, email advising of shipping estimated in May, followed by another email a week later estimating shipping in late June or early July. Email received on 14 July stating headset ready for shipment which would be advised in 7-14 days. Email sent from me requesting shipping update received a response this morning that shipping may happen in 2-3 weeks. If it was ready for shipping 2 weeks ago why will it take a further 5 weeks from then to ship . if I am lucky it might ship in late August so I guess I am looking at September for receipt as the earliest! Not happy - Sorry Pimax you are falling waaaay short on meeting customer expectations.

If you don't have one, you can just create it. Preferably, use a proper editor like Notepad++ rather than regular notepad. If your %USERPROFILE%\Saved Games\DCS\Config, directory (or equivalent working directory you select via the command line) create a new file called autoexec.cfg. Make sure it is actually named that and that Windows or your editor isn't hiding the true extension (hence why regular notepad is not a good option — it loves to make it .txt no matter how much you protest). From my testing so far, the file Special K offers in this post is sufficient and can even be pared down further. Basically, if you have no other settings and it's newly created, it should contain if not net then net = {} end net.allow_unsafe_api = { "userhooks" } net.allow_dostring_in = { "server" } This has worked for my setup and use case, but we don't use the full set of slmod functions — it's entirely possible that some other functionality is lost with just this. Similarly, you might be using other server mods that require other context to be allowed, but you're going to have to ask around to figure out which ones are needed for which mods.

You also need to consider pilot skill. Just because you can fly it doesn't mean you can do it well or even know and can manage all the systems on board. I get shot down in the F-16 ALL the time, by cold war era jets no less.

Did you ask George to turn on the systems ?

without using any other third party app or having to insert files into a saved games folder, please explain how waypoints set either in the mission editor or mission planner tool would then give leg distance, bearing of each waypoint and this be loaded into the kneeboard prior to takeoff, and easily available during play? If you read my post, you will note time and also VR considerations. Note personally i use open kneeboard and also have a drawing pad/stylus that can write into that directly - however most players will not. This is not about what i want, but what is better for the module and players in general with simple improvements. This is about getting basic information calculations into the kneeboard from the off, which is easy for a PC to do if you have known GPS positions. Having the bearing, and distance to the next waypoint as part of the kneeboard would be invaluable. It was then a logical progression to have a speed table to calculate times on the fly in a vertical column, or even two columns would make sense. Again i do that myself and have experience, but this is about making it more realistic and helpful to the majority. It wouldnt be too much of a push to have a base fuel calculation either for each waypoint.

You mean pay twice? Did customers cause all those troubles?

Visible wingtip vortices are a function of the humidity level in the air. I don't know for a fact, but I doubt that DCS factors in humidity in causing wingtip vortices to be visible (don't think humidity level is an option in the Mission Editor). As a default, I suspect DCS just programs visible vortices to appear anytime that you put a G-load (greater than 1) on the plane. Not at my computer right now to check, but it seems (based on memory) like visible wingtip vortices may decrease with altitude in DCS. I'll check that later to verify. However, I was doing some AAR yesterday with an F-16 behind a KC-135 and there were visible vortices coming off the tanker wingtips at 28,000-ft MSL, but none off the F-16. I flew my F-100 from Vietnam back to the States in late September 1970. Here is a picture of my flight refueling behind an KC-135 at around 30,000-ft MSL over the Pacific. No visible wingtip vortices on any of the planes. Update: Just cranked up DCS with the F-16 AAR at 28,000-ft MSL. The KC-135 was generating visible wingtip vortices at 280 KIAS, level flight. The wingtip vortices on the F-16 would become visible at about 1.4G at the same altitude and airspeed. However, if I load missiles on the wingtips, I could not get it to generate any visible wingtip vortices, even down at sea level. So, DCS must be modeling the impact of missiles on the formation/visibility of the vortices.

Since this basically means it’s very likely the RAZBAM modules will have serious issues (or cease to work altogether) in 3.0, let’s hope an agreement can be reached and implemented rather soon…