robgraham

The issue with the S3 is that the baskets normals are inverted meaning it screws up with light sources hitting it.. reported it ages ago still hasn't been fixed.

Chiz, it should be able to still track the radar simply by locking onto the U rather then the S/etc during the handoff phase of the missile programming. The HARMS meant to be able to track what the RWS can detect

Thanks for the update n roadmap goals Kate. Hopefully the second half of the year goes better then the first for hitting milestones, also hopefully as part of this we do see some of the incorrect 'assumptions' fixed? Eg flare load outs, limits on the ale-47 being useable only with master arm on, even though check lists for said unit warn to have it in stby during landings too prevent flare or chaff drop by accident (master arm is already off / inhibited with gear down ) On the datacard/muni/mission planner does this mean we will have an extended wait for long periods again? Ecause currently most of the 3rd parties have given us some form of mission planning and art loading through .lua or txt file in save games andmarker points in map. The current have to edit the mission method, doesn't work for multiplayer full stop and is really a core feature that needs some priority given it's as you said something that impacts more. Then just the hornet and really is a quality of life upgrade that has been promised for over a year now in some form. In the intrum is there ANY chance we can have the settings in ALE_47.lua for thecmds program able to be user editable in savegames so it doesn't Break IC but ppl can program temporary cmds programs?currently ppl are editing it in the dcs/mods/f-18_lot20/cockpit/systems/ etc folder but that breaks ic as mentioned.

Honestly I think it's something to do with the in game Quad Plain used for the LSO overlay.. if you stop and try and replicate this which is VERY replicatable it's at the same angles each time and is caused because your 'clipping' through an object plain with one eye but not the other, giving you a massive shadow because as far as it's aware with that eye it doesn't need to render anything further across at the moment as it's being Culled, due to you being right on the edge of the geometry. It's either that or a rogue shadow map plane.

Honestly I'm with the crowd saying let it be done and people adjust for it.. it's painful yes but on the other hand Eagle Dynamics has always said that VPS and heck even windows server that the majority of us even on dedicated server boxes use is not supported. We need the newer instruction sets if DCS is to move forwards and the reason it was 'removed' as a requirement wasn't due to VPS etc but because the older FX series AMD processors literally don't support it and AMD didn't start supporting 4.1 & 4.2 until like 2016/17 or some time around there, despite both instruction sets being given the stamp. For server operators though yeah it's a pain, but eventually it's gonna happen you can't expect any company not to leverage CPU instructions that have been STANDARDIZED now for over 10 years. (Part of the blow back AMD got for the FX series not having them). It means that yeah a lot of the 'cheap' VPS options and even some of the cheap AMD based dedicated server options might run into issues.. Though most data centres are running on chipsets that support SSE on dedicated hardware now. It's kinda like the 1.5.x - 2.5 'issue' were the hardware requirements changed.. It's gonna happen, it's not a case of if, but when and all we can do is roll with it and move our kit.

You wanted a log Newy, here you go.. this one doesn't spawn ground units after the start the only thing that respawns are Air units for CAP etc. 13 hours into the mission (that we'd hope could run for long periods due to reduction in coding etc etc ) we started to see this 2020-05-31 01:37:53.230 WARNING LOG: 23 duplicate message(s) skipped. 2020-05-31 01:37:53.230 WARNING EDOBJECTS: RegMapStorage has no more IDs 2020-05-31 01:37:53.230 ERROR EDOBJECTS: Failed assert `false` at Projects\edObjects\Source\Registry\RegMapStorage.cpp:42 2020-05-31 01:37:53.289 WARNING EDOBJECTS: RegMapStorage has no more IDs every second just spamming the logs and a FPS decrease to go along with it, why is there a limit like this in this day and age and if it's 4000 like people are claiming does that include Ordiance spawns? Because if it does then that numbers massively low for what people do these days.. and if the SC etc is spawning and despawning stuff, I've attached the log. you'll see it start at the time stamp given above. Mission is attached, should run even with sanitised files etc as no server side loading etc etc etc taking place on this one. dcs.rar Persia_Aflamev0_65.miz

and great example at the time of posting here.. latest Open Beta on our main server this feed is from the server.. What should be happening? All those units currently out having a swim for no reason should be driving to Sochi-Adler.. but they aren't instead they decided to go.. who knows were, at speeds they would never be able to go on water.. so now shilka's are speed boats and the like ..

So with the latest patch units might not be rubberbanding around anymore, but ground units are anything but 'working' when moving on multiplayer even on rather simple missions. (Were the attached track file is from). What is happening: - Ground units either A. Refuse to move along their paths. B. Move but not co-ordinated. C. Move but some units decide they just want to wander off in random directions. E. Some move and some dont. etc. What should be happening: Ground units should be moving along their pathing, coordinated etc, remaining together, doing as they have been told, across all clients and servers When did this start: It's been happening in some way or another for a long time, but seemed to have 'settled' a little in the last patch there was minor rubberbanding still happening at times, but units where pathing correctly and 'generally' trying to stay together and move, with the Latest open beta build however you can and often do suddenly find half a Ground Group was gone off on it's own, decided that it wants to swim etc. Level of issue: Game Breaking. Some might disagree with that statement, but DCS is meant to be a combat simulator,a big chunk of that Combat involves Ground units MOVING following orders even in multiplayer, it involves more then 1 or 2 of said units doing so especially when looking at Armour advances etc. Multiplayer has a severe issue with this, and while ED has acknowledged the issue and made progress this latest open beta build has really.. messed things up again and makes me wonder if testing of moving ground units etc on multiplayer servers with more then 1 or 2 units etc is actually taking place?. I get the fact that 90% of servers get 'around' this by simply... Not having ground units move, but honestly that should not be the solution, because that's not what the games meant to be about, just like the normal excuse of 'Well you have too many units/too complex' isn't exactly a valid excuse either, this mission doesn't even have really 2 tank companies worth of ground units told to move.. let alone if you wanted to simulate infantry moving out in the open etc.. It's.. frustrating. Newy asked for a track files showing it, I can't give a track file from our 'main' server as every time I do I get told 'the track file doens't play correctly due to scripting' I did however get some example of it on our Practice server with ground units not remaining cohesive, etc so I have attached it and the screen shots I sent Bewy on discord showing how bad this is at the moment. The dropbox for the track (it's to large to attach) https://www.dropbox.com/s/aw4990sh6uv09zt/practice-scnstennis-20200523-102134.trk?dl=0 The other thing is this isn't just a 'Client' issue looking at direct server telemetry for this stuff you get the exact same issues/unit movements, with the units being out where they shouldn't. scattering etc.. If it was 'Desync' I'd expect it to be on clients only. I can give video etc showing how bad it is on our main server if needed as well. -

Are you flying the pattern and giving the calls etc properly else it tends to not work.. the ones I've noticed you have to do/order if your case 1 case2/3 are different you have to do your established etc etc.. 1. Inbound. 2. See you at 10 (some times.. ) 3. Kiss Off. (Case 1) 4. Ball.

yeah user error i'm a twit who forgot the steps.. i need to fly the cat more again lol. Thanks Sandman.

So just did a check incase this was just a Multiplayer issue and no it's not, non MP and same issue, load in a carrier slot and get an instant CADC failure.

With the latest open Beta no matter if I or a number of mates start on the new Super Carrier or the Stennis we are getting instant CADC failures with no ability to repair/fix. If we start on the Ground at an Air field no CADC error. Have tried C&D, and Parking Hot. Log doesn't show anything that i can see either. But with the CADC fail, means that Wing Sweep Auto fails to work.

Does the same with Helicopters, worse it doesn't proximity fuse half the time like it should when the Heat source aspect suddenly changes further then the missile can turn to intercept so proximity kills fail.

I posted on reddit to nick my actual main thought, but hoenstly the items on the ORIGINAL pre-order sales page need to be completed for it to be termed 'Out of Early Access' .. you guys might have changed it's page (and the vipers etc) to no longer have those lists but we brought it with said list. To move the 'goal posts' after the point of sale is just wrong on soo many levels. As I said in the response to Nick, I get it.. some of those features need core DCS World update to be finished, in that case say as much and explain it properly or don't remove it out of EA until those items are done. But moving the 'goal posts' just plain wrong :(

Newy, Ok, here's the Server mission and a client track with OUT scripting and I can cause it to happen with a Combined Arms command. The steps to Reproduce the 'lock up' 1. Run the SERVER in DEDICATED, No Render server mode on the mission. 2. Log in to the Server from client, select the Game Master Slot. 3. Tell the 2 red Armies near Sochi Russian Army and Russian Army 2 on the Roads to Route to Gudauta. 4. Watch it start to route then suddenly loose desync as the server bogs down and goes Non-Responsive to windows and remains in said state for over 5 minutes. What I believe is happening based on running it locally and watching what happens as well. The Routing issues that seem to have start since this patch mean that Once those two units are told to route the server's becoming bogged down on the path finding, while it might 'eventually' get out of the state if given long enough it's enough to basically ruin multiplayer for any one. This only started with the latest Open Beta.. Red Iberia 2-2-17a_NoCV_noscripting-20200418-052937.trk Red Iberia 2-2-17a_NoCV_noscripting.miz

Our Red Iberia multiplayer mission has literally become unusable as of the open beta release today, despite it working fine prior to patching. The events of what are happening. 1. Server starts perfectly fine. 2. Mission runs through it's start up with out any issues. 3. Ground units get told by script to route. 4. DCS World goes into a non responsive state slowly updating logs. 5. DCS stays in this state for over 374 seconds and our automated kill process happens. Watching the log files at the same time as this is happening it happens immediately after the ground units are given the script commands to route. I believe others have said it seems to be related to the CA routing which given that was 'adjusted' this patch might make sense. Log files pointless beyond showing that the server is 'slowly' running in the back ground even in ti's non responsive state. Steps to reproduce i'm hypothisising here as I can't make the mission to test given my local machine is still patching. 1. create ground units. 2. script call telling the ground unit to move to another position. 3. watch the game grind to a halt. -Rob.

1. Honestly email Atl and tell them what you need, they generally really really good, the issues going to be that you want public/private/public which is not the easiest to do as you already know you have to basically be able to either have 2 seperate Repo's or one with distinct seperate areas .. which technically might be possible but not easily, plus Alt charges based on user group etc... I think its been a little bit which makes things more headachy.. other then that would be to script in a 'copy' button into both sides that stores the db uid and copies the pertaent information over each time. 2. There getting better yes but case in point update before last missed a lot of scripting engine fixes and changes, it wasn't until last patch those notes got on and they were a direct copy and paste of what i'd said to Nine was missed.. 3. Ah.. I have been submitting logs, not only for myself but at least 4 others Kate along with automated reporting every time a crash happens now for 2-3 months. I can list the threads were I've done the reports myself but I can also list the threads were others have reported the exact same crash but just mine for 2.5.6 on this one issue.. - First time when it looked like it was just the hornet causing the issue but as the thread points out it wasn't.. https://forums.eagle.ru/showthread.php?t=265362 - after getting frustrated 2 weeks ago when it ruined an entire night for our group.. again https://forums.eagle.ru/showthread.php?t=268593 that doens't include the reporting of the sync issues etc etc So I've done what you asked, we have reported multiple rigs, sent reports every time a crash happens by the automated reporter etc.. These need to be acknowledged as happening in patch notes and if cause isn't known admit it but at least acknowledge that it exists and is known.. i mean over 1/2 of the crash reports in the crash area atm are the same exact crash as I said if you review the log files.. they all look something like this 2020-04-13 09:36:23.543 WARNING EFFECTS2: BowwaveEmitter: unknown parameter 2020-04-13 09:36:23.783 WARNING LOG: 1 duplicate message(s) skipped. 2020-04-13 09:36:30.786 INFO EDCORE: try to write dump information 2020-04-13 09:36:30.786 INFO EDCORE: # -------------- 20200413-093630 -------------- 2020-04-13 09:36:30.787 INFO EDCORE: DCS/2.5.6.45915 (x86_64; Windows NT 10.0.18363) 2020-04-13 09:36:30.788 INFO EDCORE: 2020-04-13 09:36:30.789 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 1D564518 00:00000000 2020-04-13 09:36:30.792 INFO EDCORE: SymInit: Symbol-SearchPath: '.;J:\Eagle Dynamics\DCS World;J:\Eagle Dynamics\DCS World\bin;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'robert' 2020-04-13 09:36:30.793 INFO EDCORE: OS-Version: 10.0.18363 () 0x300-0x1 2020-04-13 09:36:31.371 INFO EDCORE: 0x000001F6C3C698D8 ((module-name not available)): (function-name not available) + 0x0 2020-04-13 09:36:31.373 INFO EDCORE: 0x0000000000106857 (Visualizer): RenderParserImpl::DrawTransparentAll + 0x87 2020-04-13 09:36:31.374 INFO EDCORE: 0x00000000001066E4 (Visualizer): RenderParserImpl::DrawTransparent + 0x34 2020-04-13 09:36:31.374 INFO EDCORE: 0x000000000010B369 (Visualizer): RenderParserImpl::isEmpty + 0x3CA9 2020-04-13 09:36:31.374 INFO EDCORE: 0x0000000000037945 (GraphicsCore): enlight::Water::renderRefraction + 0x6E5 2020-04-13 09:36:31.374 INFO EDCORE: 0x0000000000037A46 (GraphicsCore): enlight::WaterWrapper::renderRefraction + 0x56 2020-04-13 09:36:31.374 INFO EDCORE: 0x0000000000140836 (Visualizer): smSceneManager::CreateSceneManager + 0x6E46 2020-04-13 09:36:31.374 INFO EDCORE: 0x00000000006DBCC7 (DCS): woLA::loadNewInputLayout + 0x303BC7 2020-04-13 09:36:31.375 INFO EDCORE: 0x00000000006ECEC3 (DCS): dDispatcher::InitDatabase + 0xDFF3 2020-04-13 09:36:31.375 INFO EDCORE: 0x00000000006C3364 (DCS): woLA::loadNewInputLayout + 0x2EB264 2020-04-13 09:36:31.375 INFO EDCORE: 0x00000000006C3729 (DCS): woLA::loadNewInputLayout + 0x2EB629 2020-04-13 09:36:31.375 INFO EDCORE: 0x0000000001696BD3 (DCS): AmdPowerXpressRequestHighPerformance + 0xB19BCF 2020-04-13 09:36:31.375 INFO EDCORE: 0x00000000008A01FE (DCS): uiAsyncNet::onGameStop + 0x67CCE 2020-04-13 09:36:31.375 INFO EDCORE: 0x0000000000017BD4 (KERNEL32): BaseThreadInitThunk + 0x14 2020-04-13 09:36:31.375 INFO EDCORE: 0x000000000006CED1 (ntdll): RtlUserThreadStart + 0x21 2020-04-13 09:36:31.791 INFO EDCORE: Minidump created. I'll let you know if it's still there after the patch today but yeah that bugs been there now since 2.5.6 first dropped and kills the game for VR users especially but even non vr users are getting it.

Extra one to add to this @BigNewy we have one person whom had the crash with out being in VR and yet the metrics look almost the exact same. file is attached. I'm just collating from my guys now.. know there is a patch coming tomorrow. dcs.log-20200415-135631.zip

Hey kate, posted most my comments over on reddit because yeah but to summerize, thanks for actually keeping your word on the roadmaps and the like, really think you could have communicated before release day, but also understand easter.. Big one though still is what is going on with bug tracking and patch notes? Because currently that part still doesn't appear to be improving, patch notes are still missing vital information, they still don't list known ongoing issues etc which is frustrating as is having to ask Newy etc each week and being told 'wait and see'. Case in point the crash happening with 2.5.6 and VR users, it's been reported now for 3 months since 2.5.6 dropped to open beta, it's a game stopper for a lot of VR users and appears to be an issue with your changes to 2.5.6's transparency and translucency implicit renderer based on the logs and the data they are throwing out as that is the top of every one of the memory dump items other then the last log item saying 'bow wave' but we have not seen it acknowledged as an 'ongoing' issue each patch, instead we have to ask if it's been fixed, get told 'dont think so if it wasn't in the patch notes, but give it a try and let me know if it is fixed'.. We should be able to look at the patch notes each time and see a list of known ongoing bugs not have to guess :( I know it's not easy things have to be translated etc but the bug tracking and the like was the other big 'gripe' beyond communication/roadmaps etc over the last 6 months and it would be nice to see that new 'better' tracking you mentioned finally implimented with JIRA ;) Other then that again thanks for listening, thanks for keeping your word about trying to be more open, wish you'd gotten it out before today but yeah. To all the ED staff, keep yourselves safe in these times and hope you had a good easter.

So even with that file renamed to .bak so it doesn't load in.. still get 2020-04-13 08:24:55.095 DEBUG Scripting: Phrases make : key = 4267 2020-04-13 08:24:55.130 WARNING EFFECTS2: BowwaveEmitter: unknown parameter 2020-04-13 08:25:00.801 DEBUG Scripting: make: country: 2 2020-04-13 08:25:00.801 DEBUG Scripting: ATCToLeaderHandler : make, coalition = 2 2020-04-13 08:25:00.801 DEBUG Scripting: Phrases make : key = 4267 2020-04-13 08:25:01.740 WARNING EFFECTS2: BowwaveEmitter: unknown parameter 2020-04-13 08:25:04.841 WARNING LOG: 1 duplicate message(s) skipped. 2020-04-13 08:25:04.841 DEBUG Scripting: make: country: 0 2020-04-13 08:25:04.841 DEBUG Scripting: Phrases make : key = 4250 2020-04-13 08:25:06.597 DEBUG LuaGUI: --- onChatMessage--- SierraMikeBravo connected to server nil 2020-04-13 08:25:06.625 DEBUG Scripting: make: country: 2 2020-04-13 08:25:06.625 DEBUG Scripting: ATCToLeaderHandler : make, coalition = 2 2020-04-13 08:25:06.625 DEBUG Scripting: Phrases make : key = 4267 2020-04-13 08:25:07.645 DEBUG LuaGUI: --activeGroupId, activeRoomId--- 0 0 1 2020-04-13 08:25:11.470 WARNING LOG: 1 duplicate message(s) skipped. 2020-04-13 08:25:11.470 INFO EDCORE: try to write dump information 2020-04-13 08:25:11.471 INFO EDCORE: # -------------- 20200413-082512 -------------- 2020-04-13 08:25:11.472 INFO EDCORE: DCS/2.5.6.45915 (x86_64; Windows NT 10.0.18363) 2020-04-13 08:25:11.472 INFO EDCORE: J:\Eagle Dynamics\DCS World\bin\Effects.dll 2020-04-13 08:25:11.473 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 207F9D3F 00:00000000 2020-04-13 08:25:11.477 INFO EDCORE: SymInit: Symbol-SearchPath: '.;J:\Eagle Dynamics\DCS World;J:\Eagle Dynamics\DCS World\bin;C:\WINDOWS;C:\WINDOWS\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'robert' 2020-04-13 08:25:11.477 INFO EDCORE: OS-Version: 10.0.18363 () 0x300-0x1 2020-04-13 08:25:12.677 INFO EDCORE: 0x0000000000049D3F (Effects): Effects::GraphicEffect_Impl::undock + 0x166EF 2020-04-13 08:25:12.678 INFO EDCORE: 0x0000000000106857 (Visualizer): RenderParserImpl::DrawTransparentAll + 0x87 2020-04-13 08:25:12.679 INFO EDCORE: 0x00000000001066E4 (Visualizer): RenderParserImpl::DrawTransparent + 0x34 2020-04-13 08:25:12.679 INFO EDCORE: 0x000000000010B369 (Visualizer): RenderParserImpl::isEmpty + 0x3CA9 2020-04-13 08:25:12.679 INFO EDCORE: 0x0000000000037945 (GraphicsCore): enlight::Water::renderRefraction + 0x6E5 2020-04-13 08:25:12.679 INFO EDCORE: 0x0000000000037A46 (GraphicsCore): enlight::WaterWrapper::renderRefraction + 0x56 2020-04-13 08:25:12.679 INFO EDCORE: 0x0000000000140836 (Visualizer): smSceneManager::CreateSceneManager + 0x6E46 2020-04-13 08:25:12.679 INFO EDCORE: 0x00000000006DBCC7 (DCS): woLA::loadNewInputLayout + 0x303BC7 2020-04-13 08:25:12.679 INFO EDCORE: 0x00000000006ECEC3 (DCS): dDispatcher::InitDatabase + 0xDFF3 2020-04-13 08:25:12.679 INFO EDCORE: 0x00000000006C3364 (DCS): woLA::loadNewInputLayout + 0x2EB264 2020-04-13 08:25:12.679 INFO EDCORE: 0x00000000006C3729 (DCS): woLA::loadNewInputLayout + 0x2EB629 2020-04-13 08:25:12.679 INFO EDCORE: 0x0000000001696BD3 (DCS): AmdPowerXpressRequestHighPerformance + 0xB19BCF 2020-04-13 08:25:12.680 INFO EDCORE: 0x00000000008A01FE (DCS): uiAsyncNet::onGameStop + 0x67CCE 2020-04-13 08:25:12.680 INFO EDCORE: 0x0000000000017BD4 (KERNEL32): BaseThreadInitThunk + 0x14 2020-04-13 08:25:12.680 INFO EDCORE: 0x000000000006CED1 (ntdll): RtlUserThreadStart + 0x21

one of my guys tried it and reported an hour with out any issues, I'm gonna give it a shot next day or so. See how it goes, it might not even be the whole file looking at the lua but possibly just one of the items in there.. I'd almost point at { Type = "vehicleBow", SubEmittersOffsets = { {0.0, -1.0, 0.8}, {0.0, -1.0, -0.8}, {0.0, -1.0, 0.0}, {0.0, -1.0, 0.4}, {0.0, -1.0, -0.4} }, Texture = "foam2.png", TextureFoam = "foam_03.dds", ParticlesLimit = 150, ScaleBase = 0.35, ScaleMax = 0.5, OpacityBase = 1.0, BaseColor = {1, 1, 1}, SpawnSystem = { RepeatSpawning = true }, Speed = { {0, 0.1}, {50, 7.0}, }, LifeTime = { {0, 0.0}, {20, 1.7}, {50, 2.0}, } } given it's the only one with transperancy apparently and it's a render crash in transperancy that seems to be the actual cause. Course would be nice if Eagle Dynamics could confirm if they have found the cause and FIXED it or not for next patch as well.. But if we can work around it it's a start right?

Yeah we've still got a little but moment the CV group was removed we saw a massive increase both in terms of performance and in the Rubber Banding Newy.. Sorry it's taken so long, things have been a little .. busy here.

Yeah I'll remove the carriers and put the server back up and let you know what gets reported to me, even though Carrier ops are a chunk of our mission server

So we tried to run a mission tonight we had 12 people on about 2/3rds of our users were in VR, and every one of us in VR had the dreaded Bow-wave crash that has now been plaguing the game since 2.5.6 dropped. Every one of us has good rigs, ranging from 2070's - 2080ti's and RX5700xt's etc with 16-32+ gig of ram etc. Some times the game will run for hours with out any issues, other times you will get the crash the moment you select a slot. Something that was done with 2.5.6's renderer is at fault the memory space in the logs looks exactly the same each and every time. What is interesting however is that it seems to be tied to something very very specific though we can not actually work out what the trigger is (unit/static or what) as we have a practice mission that runs 100% fine for every one in VR for well hours. The other note is that all of these machines can run DCS with out any other issues. I've included a copy of a mission that has the issue happen eventually and a copy of a mission that doesn't. Along with all the logs from the users from TGW whom were around whom could send me them after (most had left to sleep out of frustration from this crash) What we do know is there is no commonality beyond 'all using vr' we have people crashing on a mix of systems and a mix of headsets from the Rift S - the Reverb. This is killing the game for our group. Thanks Rob One drive Link of logs etc from tonight: https://1drv.ms/u/s!AowS0PfqL_UIp2QaF-Q_BYDlrRs5?e=XSy3IV Prac2 - can be run for hours with out any issues. Red Dawn e4 has crashes happen. - Including logs from 3 separate machines 1 of which has debug logs in. - server log including debug log as well incase it helps at all in trouble shooting.

So since the last open beta, the TGW servers and I'm going to guess others by the other thread here has been experiencing massive amounts of Desync between Clients and the server. Bignewy asked that I post the server specs etc here so I am, along with the last set of logs though right now this sets not going to show much as it's from well off peak times. But I'll point out that we are seeing this not only on our main mission which has been running with out issues on the previous builds no desync nothing for months now but also on small missions with little to no scripting and it is happening across many different clients and providers. When this happens if you have the new information displayed you can see that it's not due to either high Ping Rates or Packet Error to the Client as the RTT which again i'm going to presume is Return Trip Time can be sub 50ms and the packet loss can be sub 0.09% all of which should mean that the link between client and server is rock steady. The server is also running fine with out any issues when these are happening. This is happening I'll point out on a server that is more than capable of running the 2 server instances we have running an I7 7700k with 32GB Ram DCS on a SSD, sitting on gigabit fibre at the OVH datacenter in Sydney, with a 250mb/s upload pipe and a 1gb down pipe, and can have this happen with as little as 1 or 2 people on the server, a server again at times we've had 32 people on with out issues and this exact same mission etc running fine, traceroutes from clients to the server at time of desync's show exactly what DCS shows same RTT in ping and 0% packet loss. I've included the log as you asked newy but as shown in the thread here: https://forums.eagle.ru/showthread.php?t=267030 we aren't the only ones having these issues, 2.5.5.X was rock solid no issues, 2.5.6 first release was fine except for crashes caused by the transport.dll's etc, the last patch before this one had some ground unit desync start to happen and this patch just has things going insane. DCS is running in dedicated server mode. Yes we have Tacview running, Yes we have SLMOD running and yes we have lotatc running, but again we've always had these running and while I'd kill them until DCS offers Admin tools SLMOD is required and lotatc was working fine this time last week on the server and the server was running fine this time last week as well. Server CPU utilisation even on our main server is at the highest 15-20% for each DCS instance and the main server has only ever reached 6gb of active ram useage, network utilization has NEVER been saturated and monitoring the Network while desync happens the send rate is no where near being hammered with it occurring at times with a out send of as low as 1.5mb/s. we have a planned mission tonight that were hoping to run so i'll also try and get the log from that as well and have it running in full debug mode but this is the main server log but again while this mission is 'complex' we have had the desync occur on missions that have the minimum amount of scripting in them. Its getting really frustrating and has a lot of our users wondering if the Supercarrier is even going to be usable when it drops because of the increasing amount of desync and other issues rather then improvements. tgwmainserver.rar