Dangerzone

Is your problem with MT and ST, or just Multi-Threading? If multi-threading, the solution will be to switch back to ST and wait - as it appears a number of us are seeing issues with MT - and MT is still just a 'Preview' release at the moment (we're all Beta testing it). If your problem is with ST as well, I'm not really sure what to say then except to try as I mentioned previously dialing down some settings because from my perspective abandoning DCS before trying to dial down a few settings when you have options seems a little heavy approached. No - I agree you shouldn't have to do this - but in the same place - ED are currently working on performance optimizations - something we've been waiting on for years, and it's now here - in BETA testing, so it would be a shame to abandon DCS right at the edge of where their may be improvements if there are settings that you could dial down a little as a workaround for now. However in saying that - that is my perspective - I also understand if DCS is becoming more of a frustration than it is enjoyment then it might be worth putting it down for a while until things are sorted out, but I personally hope you try dialing down the settings if ST is causing you issues for the time being.

A thought for consideration is to have a new tripwire function added to the AWACS function. The idea would be to have under the Tripwire "Cancel" to cancel previous tripwire requests and 10, 25, 50, 50 & 80 mile options. (5 choices with user able to set them in the Special tab would be better). This comes from having the tripwire (or "Set Threat x") option available in Overlordbot for the past few years. For anyone who has used Overlordbot - It's in credibly handy - gives the immersion that the AWAC's isn't just a response to a menu call bot - but is actively having your back while you play. And given very sadly that OverlordBot looks to be heading south - having this option natively in DCS would be a helpful feature.

Not sure if you're aware, but there is a dark-mode option availble on the site. Right down the bottom of the page under the social media icons is Language - Theme - Privacy Policy - Contact us. Click on theme, and you can choose Darkmode. Note: The darkmode option of this side does have some bugs, but it may give you what you want without having to use extensions or otherwise.

Can you please provide Track files so we can see what you're doing and what your SHOW settings are configured to? By default I don't believe that Targets/Threats are boxed, so you need to turn these on in order for both your target points to be shown as well as other threats.

There's a reason it takes hours of training... with a real life instructor, just to learn the basics of hovering and taxiing with helicopters that are more friendly than the AH64. A track file allows people to see exactly what is happening. What your conditions are (wind, direction your facing into wind, your power levels, your inputs, etc) and to in some ways do what a RL instructor would do - observe and give feedback. Without it - it's like a real life instructor trying to instruct over text messages - very handicapped. As I understand it - flying the Apache is no simple task. I think when we have access to it as a 'game' we think - "Oh - it's a game - it should be easy to get into and fly - I want to go shoot something", and when it's difficult and we experience dynamic rollover, or settling with power, or VRS, or mast bumping, etc we think "It must be a bug - it's not flying right". However since we're talking about a simulator and not just a game (like WT) - the emphasis is on being realistic, not being simple - and it's going to be a challenge. A better quality stick may help - but it's not going to correct bad habits, and could actually be more damaging. (Cover up bad habits). My suggestion is to take up the offer for people to help you with what you have first with track files of what you're doing. Then, with a bit of training - if you are able to master it with those controls (some people are doing it with much less like a Logitech 3D pro), and once you have good habits - if you still want to upgrade to a new stick - you'll get the most benefit of the new stick instead of it just being a bandaid for potentially doing it wrong.

Please correct me if I'm wrong - but according to your log it seems you're running a NVIDIA GeForce GTX 1050 Ti with 16GB RAM, and have a number of graphic hungry options set. (MSAA, Raindrops, Lenseffects, max terrain textures, etc)? If so - I think you might be asking a bit much from your GPU. I'd suggest trying DCS with all settings on LOW or OFF where possible (and all sliders down to 0 except the preload radius). Then see if this makes any difference. If that works - then maybe look at increasing some graphic settings one by one until you start seeing issues, and back off a couple of steps and see how you go with that. If I'm reading the log file wrong - can you post a screenshot of your graphic settings in DCS, plus your actual machine specs?

Just wondering if there is currently a known issue / outstanding issue with AH-64 and repairs - in particular with the APU? I came across an issue after a repair in MP where I couldn't get the APU to start up again after the repair. (Tried repairing multiple times). It was about 3hrs in on a multi-player server, so I don't think there's any point providing a track file, however if there is not a known issue - I can see what I can try and do about replicating it again in SP with a small track but thought I'd ask first before spending time trying to replicate the same scenario.

How do the "Import F10" commands work on MP with different aircraft or spawns. I've noticed for instance with CTLD - to pick up a create some spawns have it as F10-F4-F7-F1 and others may have it as F10-F4-F8-F1. Does VA know which aircraft is which and what to use - or will this cause conflicts?

'return precontact' has been clinically shown to cause wing damage on air force tankers. True that - when I was first learning - repeated calls of 'return precontact' did end up with the tanker being damaged just after my master arm was turned on!

Only ED can answer this topic. I would hope however that if this ever did unfortunately ever occur, that ED would release some sort of last build or similar that turned off the licensing check to just allow people to install and play bypassing the registration checks, but that’s hope, no guarantee. The simple fact is, when you buy licensed software that requires activation, you never truly owned the software or have rights to it. There is always a risk, whether Adobe Photoshop or now even Microsoft Windows considering calls home periodicly to check whether or not you’re operating system should still be activated all these have the potential to disappear on us. Or even be “turned off “if they deem the region, we living or our conduct is no longer within their terms and conditions.

I'm fairly sure the server can be setup to provide only these dot labels. (Configured at a server level), so the server will allow the client to either have no labels - or if labels are selected by the client - they'll get this 'dot label only' showing up - but only at the distances and color, etc specified. It's the only option I'm aware of at the moment to bring VR distance vis in par with 2D.

I'm assuming you're talking about VR? If so - have you tried going full screen (as opposed to windowed)? I only have a problem with my cursor going out of game if a window/dialog pop's up in front of DCS myself, or if I'm on the extreme edge of the screen - so I've muscle trained myself that whenever I take the cursor over, to go past what I want and bring it back slightly to ensure I'm 'in the window', but failing that - full screen might help maybe?

I would have suggested first not reviving a 3 year old thread that has to do with a different version of DCS. If you mean spotting as in being able to identify units further out - there are certain scripts that can be implemented for labels that will have a single pixel populate at a certain distance, and then fade that out as the unit gets closer where you can then actually see it in VR. Something similar to:

Hey Pnguin9999, So glad to hear that it solved the issue for you! I understand the MP side of things. I've been fortunate enough to find servers that suite my needs in Stable Release. Don't be afraid by the number of servers out there, there are some gems in both parties - but I do understand the flexibility that is oging along with the masses. I had to laugh too - just after replying to you the first time I find that Stable has been updated so we're both on the same version atm now. Enjoy your weekend!

Glad to hear of your success. I've been finding the opposite. If I run MT - I seem to be getting stutters - whereas on single thread the experience seems to be much smoother. (I am using OpenXR motion reprojection). Thankfully ST is still available to use while they iron out these issues with MT.

Can I suggest that you try renaming your DCS folder in your saved games directory to something like DCS.OLD and then re-launch DCS. You'll get a new config setup but if that works for you - you will be able to narrow down the location of where the potential issue lies. If it doesn't work for you still, you can delete the new one, rename the dcs.old one back to dcs, etc. If on the other hand renaming this works for you, you can then copy the config/input directory from your dcs.old over to the new one so you don't have to reset up all your bindings, etc. And respectfully - (and I completely get the frustration of having to diagnose problems with a game/simulator when you go to do updates ) you have chosen to be an Open Beta user, so you have opted to be part of the testing team also. I think your expectations are a little unrealistic of ED. If you're looking for a more stable solution (not perfect, but less hassles) - have you considered switching to the Stable Release instead - that might be more suitable? There's fewer releases, and the ones that are released have been more tested (by much more of the public), so hopefully you run into less issues, and if you do - someone else has already probably come across it, and you may be able to find a quick answer. It's what I run on primarily and I enjoy just being able to 'play DCS'. (I use open Beta for testing my missions / scripts / etc) I get it and fully understand if you want to stay on Open Beta to have the latest stuff as quick as possible - it seems that's what the majority of the DCS community prefer, but if so - you have opted in to be part of the public testing team by choosing the BETA version - so as my wife has said before to her friends "The secret to my happy marriage is I needed to lower expectations", (poor reflection on me maybe ) - the secret to a happy DCS experience on Open Beta may also be to lower your expectations as to what experience you are going to get to fall in-line with what a BETA tester would expect. Please let me know if renaming the saved games DCS folder works for you.

I can see these being used in some cinematic video's, maybe part of the next airshow video's, etc, not to mention those that just want them for greater immersion. Nice work. Thanks!

I suggest if you want to report this as a bug - best to provide a track file that replicates.

I've previously suggested a different approach to force trim in DCS that I think would work with all airframes which is a soft trim option. I think that approach would also help with the AH64 as well in this instance. The idea is for a "SOFT Trim". When the trim button is pressed, the existing trim variables start to work towards the new trim that has been set at a rate specified by the user. (By default for instance the user could have 2.5 seconds as their default). When the user sets a new trim - there is no sudden movements that need to take place, nor do they ever loses momentary control of the helicopter. (At present, unless someone has FFB, we either have the helicopter suddenly change it's input as the new trim is applied and 'lurch' in the direction the trim was made as we have to quickly reset our peripherals back to the center, or otherwise we either lose control (input) between from when we set the trim until we get all our controls back in the center and DCS re-engages our input). So with the soft trim approach, once it is set - the aircraft doesn't move suddenly, nor lock out controls as it does at the moment- but as the trim is slowly being relocated from the current offset to the new trim offset the pilot naturally will be moving their controls back to center to offset the movement. This would be a natural feeling, and means that the whole process is fully controlled. No sudden trim movements, and no loss of input. If this was implemented, then with the Apache, it could simply be combined with the existing SAS/Att hold, etc. So effectively the user would depress the trim button which would disengage SAS but leave the existing trim exactly where it was (as it currently happens). They then move their controls to the new position and when satisfied with the position they release the trim button. At this point SAS is re-engaged but unlike the 'return to center lockout' or 'immediate application' the trim offset behind the scenes starts to slowly move towards the new offset meaning that the pilot can slowly move their controls back to the center for the new trim setup. Additionally - at any time while the new trim is being returned to the center - if the pilot needed urgent input - they just apply it - and it's available as nothing is disabled. I got this idea from the VKB Modern Gunfighter. There was an option to set trim on it, with the option for a soft reset. When I tried it, I couldn't believe how natural it felt - and how well I could still control. I just thought to myself - imagine doing this in the reverse direction and having it as a native option in DCS. Twould be trim heaven. The problem being - in real life there is no 'center' of the stick. What happens is if you push the trim - the 'force setting' is released and you can easilly move the cyclic to the new position. When you release the force trim button - the stick doesn't move anywhere - just that force pressure is applied so that location is the 'new center'. We can't have this with conventional joysticks. We need to return to the center (unless we're fortunate enough to have force feedback), so yes - IRL it's simpler because there's no trim and return to center - it's just apply force trim. The problem we face with DCS is we're trying to merge real life application with gaming peripherals that operate differently. I came up with a potential solution I've been dreaming about for a couple of years (per above post) that I've been trying to find a way to do outside of DCS for a while.

I have a couple of options that may be potentially useful to you for a workaround at the moment: One option is to have each side place their units in a separate mission. Then I believe that you can import templates from other missions over the top - so you could have one person as the administrator tasked with the job of importing both to the final mission at the very end before setting up the game. Everyone else wouldn't then see the different sides. Or - going one step further - I have been playing around with scripting that will automatically load other units from other mission files into the running mission as it plays out. This second option is probably more suitable for people who are happy with scripting in running missions, but it does allow scenario's to be brought in on the fly that anyone can previously design with just the mission editor: I know neither option is what you've asked for - but if you need a solution now - these are 2 possibilities.

Thanks for the counter view gentlemen. I don't know if my thought process is right, but what I seemed to notice with DCS (with my 10700) - is that 100mhz seemed to make the difference at one stage between stutters and no stutters to me. My guess (and I admit it's a complete guess) is that with the settings or server scripting / number of units / etc on the MP map is that once DCS hits a limit - it doesn't gracefully degrade gradually - it degrades in steps. The problem I had is I haven't been able to push that 100mhz and keep it stable. I was going to give up on VR, but then OpenXR came out, works smoother with less frames and saved my bacon seemingly solving the issue. So when I looked at these 2 options, and saw 400mhz difference after my experience - it's always been in the back of my head that with DCS - it's not necessarily a down hill run, but a cliff that you can meet between acceptable and non-acceptable, and I've been paranoid ever since - so 400mhz difference to me got my attention. My question now is - cost side, is there any benefit not going for the 13900K? Will the additional e-cores create more problems, or can they just easilly be completely disabled/turned off leaving just the extra 400mhz available as elbow room if someone has money to burn, or are there other negative aspects in going with the 13900K besides finance?

My thought is to go with the i13900K. The reason - it may not give an advantage now and the 13700K is probably enough for now... but I'd go for futureproofing. DCS has been (and continues to be) very heavy in the CPU department. I know that multithreading is being worked on, but I take the approach that I don't believe anything will work until it's actually been released - and is working. Even then, we don't know just how much of it will be effective. As such, that extra headroom the 13900K may give in additional mhz may come in handy down the track. Mind you - I've been CPU bound in many occasions so I'm probably BIAS, but I'd hate for a 4090 to be restricted due to being CPU bound - it's a small extra cost to ensure that you get the most potential you can out of the GPU. Very interested to know what more knowledgeable people think and whether they differ in logic.

Thanks CFRAG for picking up on that problem. Sorry for misleading you @timothyboss, there's a lot more traps for me to learn about with lua it would seem. Thank goodness for the wealth of info shared in these forums. Would it be possible to set a lastran_x stamp instead. Then when starting a script you check to see if the 'other' script has been ran within the last 5 seconds and if it has you skip that instance and wait again. This way it may not end in a deadlock but rather uses timestamps so if something does go amiss - it would reset itself?

OK - I'm not sure what's going on there. I could have sworn that players weren't kicked out of their aircraft when slots were changed, but maybe I've gotten that wrong. Just very quickly without testing - do you have the line ssb.kickPlayers = true -- Change to false if you want to disable to kick players. set to true or false? I'm not convinced this is the culprit, but I'm not in a position to test your mission at the moment, and don't know what you have configured on the server side scripting anyway. Try changing it to false and see what happens if you have it set to true.

It depends on how you code it. But you only have to do it for the client aircraft. My suggestion is instead of coding each aircraft individually - have a standard prefix to start with that allows you to quickly find or get a group/filter of the clients. Then iterate through that group to set the flag. That way, instead of having to do it for every single client, you're only specifying it for each individual airfield. It's a bit more depth in coding - but less code in the end than manually having lines for 600 separate client aircraft/slots, and makes it much easier to add new clients when you need without having to change more code again. (Just add using the existing prefixes to add more aircraft).