Maverick87Shaka

I don't want going Off Topic, but I definitely agree with this, multiplayer is a crucial part for overall experience of the simulator. You can put as much effort as you can trying to recreate detailed systems and simulation, but if it's crash on multiplayer it's not really going to care so much for final users. I was also little bit confused since not so much times ago ED announce a new wave of closed beta tester to help to figure out more problem before delivery even the Open Beta build. So far it looks that most of the server admins that normally are trying to report bug, are still "outside" this closed test, and they have to post here on forum every time for some blocking issue after OpenBeta release. BTW, it's another topic so I really don't want to start this discussion here, but ED please note that it's should be considered a really blocking issue, we're here to help to identify the problem. Regards.

I can confirm, the problem is still there with the latest build 2.5.6.57530. Here the last part of my log before crash ( some data obfuscated for privacy ): 2020-11-11 20:56:58.624 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:00.583 WARNING LOG: 1 duplicate message(s) skipped. 2020-11-11 20:57:00.583 INFO DCS: wcTanker::onEvent:1 2020-11-11 20:57:00.584 INFO EDCORE: (wcTanker::Channel)enterToState_:2 2020-11-11 20:57:00.620 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:00.679 DEBUG Scripting: make: country: 2 2020-11-11 20:57:00.679 DEBUG Scripting: Phrases make : key = 4371 2020-11-11 20:57:01.622 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:10.962 WARNING LOG: 9 duplicate message(s) skipped. 2020-11-11 20:57:10.962 INFO SCRIPTING: *** Qeshm counter Attack Scheduler is alive: Nov 11, 2020, 21:57:11 *** 2020-11-11 20:57:11.622 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:12.895 WARNING LOG: 1 duplicate message(s) skipped. 2020-11-11 20:57:12.895 INFO SCRIPTING: *** AirToAirMenuScheduler / Air To Air is alive: Nov 11, 2020, 21:57:13 *** 2020-11-11 20:57:13.623 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:37.661 WARNING LOG: 24 duplicate message(s) skipped. 2020-11-11 20:57:37.661 INFO DCS: wcTanker::onEvent:6 2020-11-11 20:57:37.661 INFO EDCORE: (wcTanker::Channel)enterToState_:4 2020-11-11 20:57:37.756 DEBUG Scripting: make: country: 2 2020-11-11 20:57:37.756 DEBUG Scripting: Phrases make : key = 4372 2020-11-11 20:57:38.634 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:40.692 WARNING LOG: 2 duplicate message(s) skipped. 2020-11-11 20:57:40.692 INFO DCS: wcTanker::onEvent:9 2020-11-11 20:57:40.692 INFO EDCORE: (wcTanker::Channel)enterToState_:5 2020-11-11 20:57:40.787 DEBUG Scripting: make: country: 2 2020-11-11 20:57:40.787 DEBUG Scripting: Phrases make : key = 4375 2020-11-11 20:57:41.636 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:41.880 INFO DCS: wcTanker::onEvent:6 2020-11-11 20:57:41.880 INFO EDCORE: (wcTanker::Channel)enterToState_:4 2020-11-11 20:57:42.634 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:43.975 WARNING LOG: 1 duplicate message(s) skipped. 2020-11-11 20:57:43.975 INFO SCRIPTING: *** Qeshm counter Attack Scheduler is alive: Nov 11, 2020, 21:57:44 *** 2020-11-11 20:57:44.412 DEBUG Scripting: make: country: 2 2020-11-11 20:57:44.412 DEBUG Scripting: Phrases make : key = 4372 2020-11-11 20:57:44.633 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:45.036 INFO DCS: wcTanker::onEvent:9 2020-11-11 20:57:45.036 INFO EDCORE: (wcTanker::Channel)enterToState_:5 2020-11-11 20:57:45.635 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:46.068 DEBUG Scripting: make: country: 2 2020-11-11 20:57:46.068 DEBUG Scripting: Phrases make : key = 4375 2020-11-11 20:57:46.636 INFO SCRIPTING: checkHoverStatus 2020-11-11 20:57:47.917 WARNING LOG: 1 duplicate message(s) skipped. 2020-11-11 20:57:47.917 INFO SCRIPTING: *** AirToAirMenuScheduler / Air To Air is alive: Nov 11, 2020, 21:57:48 *** 2020-11-11 20:57:48.136 INFO NET: accepting connection from 7*.**.***.**6:53955 2020-11-11 20:57:48.161 INFO NET: adding client[2] 2020-11-11 20:57:48.318 INFO NET: added client[2] name=Tyros53 addr=7*.**.***.***:53955 2020-11-11 20:57:48.319 DEBUG NET: ServerInfo json size is: raw = 3662, gzip = 1342. 2 chunks. 2020-11-11 20:57:48.322 INFO EDCORE: try to write dump information 2020-11-11 20:57:48.324 INFO EDCORE: # -------------- 20201111-205748 -------------- 2020-11-11 20:57:48.325 INFO EDCORE: DCS/2.5.6.57530 (x86_64; Windows NT 10.0.14393) 2020-11-11 20:57:48.325 INFO EDCORE: C:\Eagle Dynamics\DCS World OpenBeta\bin\lua.dll 2020-11-11 20:57:48.326 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 3EE53E00 00:00000000

Hi, Multiplayer server crash almost 99% of te time, so just need to ask if you need some dcs.log, it will really easy :D At this link you have some of the most recent files, for two different server: https://drive.google.com/drive/folders/1pruID30Bk1xBpIoUvlKenqo9f7sfAqDV?usp=sharing ( i can't upload since log ar bigger then 500kb that is the limit of this forum ) I've also enabled the full debug, even if the DCS.log looks the same to me. Servers crashing randomly on client connection. Not the same client every time, never seen crash on first client connection, some times produce log error in DCS.log, some times crash without dumping to log ( in debug mode :D ) Let me know if you need some more test. Regards, Shaka

Uhm, I'll try to add this also to my server, but we are experiencing several crash even in a single raw. As mentioned previous build was able to run for all 6 hours of my scheduled reboot really smooth. With the latest OB build server crash even just after 5 mins if decide to. It's a complete nightmare! I really hope that ED is planning for an hotfix and not trying to go for one month like this, it will force everyone to rollback ( like some squadron already did ) Cheers, I let you know with new full debug mode what i can see.

Hi, I can confirm the last OB UPDATE 2.5.6.57264 is really bad in terms of stability. Server that was usual to run smooth for 6 hours ( scheduled restart every 6 hours for me ) on previous build are now keeping crashing, sometime suddenly in less then one hour after start. It looks like it happens on client join, it's not always the same client that create a crash in the server, the same client maybe in the next restart can stay connected without any problem. Here last part of my log as well:

Credo stesse cominciando a funzionare, quindi hanno sentito l'esigenza di fare un update :D

.....non che prima fosse il massimo in termini di grafica, ma almeno aveva un senso e si riusciva a usare. Si sono proprio dovuti impegnare per riuscire a fare di peggio.

I can confirm, it's happening every time on CVN-75, works well on other carrier and supercarrier. So looks like a problem only of the new carrier :thumbup: Since the code is working for other, I hope it will be fixed soon, but I suspect something on ED side should be also required. :music_whistling: BTW, here attached really simple mission to test it, problem occurs also if you start mission in single player! Regards. test_align_F14.miz

It will be nice see more decent assets populate our DCS World, actually we've really limited AI aircraft and most of them has a really outdated 3D models! I'll definitely love see more assets, and if 3rd party can helps it will be super, but honestly from my personal point of view, if third party is committed to create realistic modules, maintain the whole assets updated and aligned with the 2020 computer graphics should be something that ED should take care of! BTW ( OT ).....I'm very pleased to see that finally the 339 will be an official module! :thumbup:

The file itself must be named as .cfg, so autoexec.cfg is the file. The syntaxto be used if you want create a "complex" logic inside that it's LUA script. :thumbup: But i didn't recommend to create some articulated code here, rather then i'll suggest to create batch script as suggested by Devrim and maybe use windows task scheduler to keep everything clean automatically ;)

DESYNC is coming back! it's simply something that is never been fixed, just mitigated somehow, so it's not strange see this come back over and over again, I'm not surprised but yes I'm really bored about this, especially because I pay 800€ each year for an high end tier bare metal server that can run other gameserver with thousands of player without loosing a tick, and here on DCS is not capable to take 4 clients synced together. BTW for us the worst desync is happening with weapons, only the client that release GBU12 or maverick can see the Bombs/missiles flight to the target, all other connected clients see the bombs hit ground elsewhere, and then see the explosion of vehicle for "nothing"! Embarrassing!

Welcome End of 2020! Maybe 2021 will be the year to get this feature on DCS? :music_whistling:

MP sync :megalol: Really? At least it's not a DCS UH-1H unique bug. We can expect an improvement also for the overall MP Sync?

Dear all, I'm trying to design a new 24/7 mission that will include a lot of Helicopters operation since this map its amazing to flying at low altitude. I found a really nice spot with an helipad in Netafim Military Base, unfortunately land on that helipad doesn't trigger any Land Event, so it's almost unusable. Here attached you have a really simple mission with an UH-1H on Ground Hot, after 5 seconds a script start to monitor your helicopter, you can land everywhere also on the ground and a text message appear to notify that you've landed. If you try to land on Helipad in Netafim Base, you'll see that no message will be displayed since no event is generated. Thanks a lot for this great map! Please Fix this error and keep improve this great map! ( it's look like a simple ground/level collision point or something like this ) LandingDetection.miz

+1 After almost three year there is no build in function for ground or ships units. It will be a nice addition to ME

Hi Ciribob and all, there is a way to add a prefix on spawned unit from crates? All troops has the "dropped" prefix, so it's really easy to count all of them and use it with Moose or other framework, but I have trouble when I want to look at the units that comes out from the crate, for example all JTAC or TOW. Actual name after spawn is: M1045 HMMWV TOW #3, i would like to add a prefix and have it like: CTLD M1045 HMMWV TOW #3 and so on

It looks that this CPU features the Intel® SSE4.2, so even on the worst scenario that ED going to make this a requirements again, this specs should be fine to run a DCS Server. Don't expect to be able to host large scale mission with large number of players on it, but for "normal" use like co-op squadron missions and so on should be enough.

OMG, I can't believe what my eyes are seeing! After more than one year, finally I can appreciate runway lights in multiplayer If anyone is wondering if it's come with the latest OB update, OFC the answer is NO! Is not the DCS Update that solve this problem, but just the new Syria map that has runway lights always on, that IMHO if the ED are not able to fix the base engine code to make it working according ATC or/AND Daytime, it's the only solution available to get back lights work on this simulator. So, now that we've seen that is possible to have lights in multiplayer, the real question is: when you're going to upgrade all other maps to make the lights works? Thanks

OFC users has final choice, but I think a kind of "mod&skin" download prompt when you try to join a server could be nice addition to DCS :thumbup:

The main problem of this device is the base clock, that is really too low to handle 20 player server. It's rated for only 1.6Ghz of base clock, and even if can boost up to 4.2ghz, it's better to check how long and how much load can handle without start thermal throttleilng back to base clock. Also it's not a "cheep" solution intel NUC, so far, you can assembly an ITX solution that can overcome NUC performance and cheeper. :thumbup:

While I'm totally agree to "loose" old CPU support if its can bring benefits to the game, I'm not sure reliant to SSE or any other tech that can be potentially unavailable on virtualized technology is a good move, at least for server side application. Any other game server can run on really small ( even linux ) VPS with great performance, while on DCS we're forced to have powerful dedicated machine. Coding the server engine on SSE or any other instruction set means make some step back.

Of course it can not be a solution....... That means that basically it was useless, at least for server side, so didn't get why should have to force it as "requirement". we spent years ask for a dedicated server to have this? not thanks! By the way, going in depth with the problem, it was not really a missing feature on XEON CPU, but it was something more related to "security" of virtualized environment. I was finally able to run ( even with old build ) the DCS on our VM infrastructure enabling flag.

After last update OB 2.5.6.49718 is required to have SSE4.1 hardware support even with --server --no-render So basically 70% of CPU available to rent in datacenter are NOT able to run DCS server. :thumbup: Thanks!

Actually there is no settings that you can change to force specific flag, it's based on GEO-IP localization only, i hope they'll give to server admin the option to override it. :music_whistling:

As you can see, also parking light are now chained to in game time and they are working on both client and server........but not the runway lights. IMHO best option is to use the same behavior of all other lights for the runway. :thumbup: A good result with not much effort since the code is already there ;)