PondLife

Noodle, any chance you can attach your updated scripts, I've been looking for something like this for a while.

That would be great, I'm having the same problem, re-spawning often occurs on top off or very nearby destroyed units.

this is a good link: http://www.overclockersclub.com/guides/overclock_intel_4770k_guide/ Haswells can run hot so be careful to stress test the overclock using "afterburner" or similar and ensure the tmp doesn't go over around 85c at 100% CPU usage. It took me around 6 hours to come to a "reasonable understanding" with my i5 4670K and I managed to get 4.8 Ghz stable reasonably easily. It's not that hard if you concentrate on core and voltage as Erforce suggests. Basic: CPU core voltage to 1.2 Clock multiplier to 42 reboot, check Ghz speed stability and core tmp using cpu stress tool increase voltage in small amounts, then clock multiplier, reboot....check stability etc etc. When you get to a point where the system crashes, roll back the changes to the last stable values and use them.

I'd suggest the following, not necessarily in order: 1. Start flying online 2. Learn more abouts TADS, net setting, display settings (EXP1 and 2 etc) 3. Practise different ways of receiving and marking targets (TAD data, EGI direct markpoint entry, HUD markpoint creation, TGP markpoint creation etc) 4. Practise sending targets to other flight members (TAD data, message, SPI) 5. Practise and learn how to change DSMS weapons release options (particularly laser codes for GBU's and HOF for cluster bombs) 6. Learn how to setup and release ordinance fast, so its second nature, particularly useful is multiple MAV release on the same pass and ccip consent to release modes for dumb bombs. I found the best way to learn all this stuff is to figure out the need for it by joining an online squad, members are usually more than willing to carry out coaching sessions and the important stuff is self evident.

Accumulators usually only store enough pressure to work the brakes for a short time. On some aircraft there is an EHP or electro hydronic pump (not an A10) otherwise there's usually a manual way of pumping up the accumilatir for breaks on towing and for hydraulically operated canopies.

The only reason you'll get AutoHotkey starting multiple instances is if: 1. You haven't entered the coordinates correctly in the autohotkey script and its not actually starting DCS properly 2. The sleep times in the autohotkey script need tweaking 3. The window size and coordinates change every time on DCS startup for some reason The logging will only tel you if DCS is not running and what the DTS of this is. I could add logging to every action of the autohotkey script but that would increase the over head. There maybe a problem with headless servers.... (there probably is)I haven't tested on one and we don't have one. My suggestion would be: 1. Just run the autohotkey script to see if it start dcs properly 2. If it doesn't you'll could try redoing the coordinates for the mouse clicks 3. If that doesn't work then I suspect it's because the server is headless The only option you then have is to have a client running all the time with an open window. Thats not optimal obviously....

A few tweaks Added logging, added hotkey kill to stop script, added comments to vb script and hotkey script. Please don't try this if you're not reasonable capable of understanding what the files actually do..... You'll also need to add a log location for the log file and tell the vb script where it is. YOU MUST CHANGE THE HOTKEY SCRIPT MOUSE COORDINATES to match your environment! DCS_Servermon_2.zip

No problem, I'll update the zip attachment with the new stuff.

See the main thread, http://forums.eagle.ru/showthread.php?t=114361 The script is now working perfectly on our remotely hosted S77th server. Please hit the server so I can watch it crash and re-start ;)

I haven't tested this on server 2012 or windows 8. To debug it you could do something like this: it does the same but for notepad.exe. If this works the VB script is fine. Also just to add, the script is now working perfectly on the S77th server and re-starts DCS after about 3 minutes on crash. '**************************************** '* Application Restart Script * '* based on http://www.intelliadmin.com * '* amended by s77th yeti for DCS * '* AutoHotkey is also needed in order * '* to re-start the dcs server * '**************************************** set Service = GetObject ("winmgmts:") set Shell = WScript.CreateObject("WScript.Shell") '**************************************** '* Set variables * '**************************************** 'Name of the DCS exe we want to watch sEXEName = "notepad.exe" 'Path of the folder the AutoHotkey script is in (Don't forget the trailing \) sHotKeyPath = "%windir%\system32\" 'Hot key script name sHotKeyScript = "notepad.exe" 'polling interval for the monitor in milliseconds (10000 is 10 seconds) sScriptInterval = "10000" '**************************************** '* NO NEED TO EDIT BELOW THIS LINE * '**************************************** 'Loop until the system is shutdown or user logs out while true bRunning = false 'Look for our application. Set the flag bRunning = true 'If we see that it is running for each Process in Service.InstancesOf ("Win32_Process") if Process.Name = sEXEName then bRunning=true End If next 'Is our app running? if (not bRunning) then 'No it is not, launch it WScript.Echo "notepad is not running, do you want to launch it?" Shell.Run Chr(34) & sHotKeyPath & sHotKeyScript & Chr(34) end if WScript.Sleep (sScriptInterval) wend

So I've just implemented this on the S77th server and it appears to be working fine. We had a few people join the server and everything was OK. The only thing I can think is it may be is that that AutoHotkey app had multiple instances running because someone shut down the server and didn't kill the scripts using the bat file. Just to be sure everything stops when you run the stop bat I've edited it slightly: taskkill -T -F /IM wscript.exe taskkill -T -F /IM AutoHotkey.exe

Firstly, I'm glad to see ED are paying attention and are working on the instability issues. I also don't doubt the dedication of the ED testers. Any application will have bugs and DCS is no exception, the problem here I believe is the general bad quality and stability of this last release, having looked at the debug logs on the client and some servers, I find it hard to believe any kind of thorough "white box" testing was done on this release. Regardless of whether this release was a "beta" or not, it was still shipped to customers, that makes it a release which should have been fully regression tested. Beta testing is only intended to capture edge case scenarios encountered by some customers, it is not intended to uncover basic instability issues which have the potential to drive customers away permanently, that wouldn't make any business sense would it??? I'm usually on the receiving end of these kinds of complaints, and believe me I do know something about software QA. ED please fix this quickly but do a thorough test before you release the patch. And next time perhaps do a more thorough regression test.

Same uh1 dll error I'm having exactly the same error: Ticket raised with ED From XXXXXXXX at 21.09.2013 12:51:55 XXXX_Report.wer (26.03 Kb) [ download ] This is happening almost every day at some point in multiplayer missions. Note it's not the actual server crash, its the local running app. 1. I'm flying the DCS A10C at the time, not the UH1 2. this has only happened since the 1.2.6 update 3. I haven't actually flown the UH1 since the update I've attached the full crash log, issue appears to be related to: Sig[3].Value=uh1_protect.dll Interestingly, The crash hasn't happened since I've flown the Huey for the first time after the patch, this leads me to believe there is some issue under the following circumstances: 1. You update to 1.2.6 2. You have all modules installed 3. You only actually run 1 module (in my case A10C) After actually running the Huey module (flying it) I haven't had the error. so maybe related to a DRM check on first running the huey which obviously doesn't activate if you haven't run it yet and causes the "uh1_protect.dll" runtime error.

Correct and no it will not work if there is no window view on the server. I was not aware you could fully start the DCS server (and load missions) in no gui mode....

I'm not quite sure what you're saying here... are you trying to run the Hotkey script on your local machine and interact via a VNC viewer window? this is never going to work. You need to run everything on the server and re do the hotkey script for your environment on the server. It should really matter if its a window as a long as the reference window size is the same on start up, which it will be if you leave it alone. I'll install the scripts on our remote server which we manage with radmin and try and prove the concept.

You could do that but it would have a high overhead and would slow the script down. The vbs script catches the fact DCS is not running, if it is running the hotkey script does not run, if DCS is not running it runs the hotkey script which bounces the server. Note that the DCS "zombie process only hangs around for a few seconds before it dies and the bounce of the server occurs. The amount of time the dcs process hangs around after a crash dump is set in: (I think) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting] "ServiceTimeout"=dword:0000ea60

addendum OOps, forgot some stuff.... In order for the script to work, you need to ensure a few things: 1. Ensure The DCS network config file has "pause_on_load = false" set. The file can usually be found here: C:\Users\YOUR USER NAME\Saved Games\DCS\Config 2. In order to handle/bypass the crash dialogue box which appears after a DCS server crash, you need to set a couple of registry keys. IMPORTANT - this will effect all application crashes you have on your server, instead of a dialogue box saying "bla bla stopped working" close the application or get a solution online" (or words to that effect) the application will crash straight to a dump file without any prompting. The DCS process will then hang around for about 6 seconds before closing. I STRONGLY recommend you backup your registry before making any changes. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting] "ForceQueue"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent] "DefaultConsent"=dword:00000001 DCS_Servermon.zip

I've re-posted this in here, server admin more applicable. The linked thread describes a method to automatically monitor and fully re-start servers after crashes. http://forums.eagle.ru/showthread.php?t=114361 It's clunky but it works......

So re-starting the dcs server after a crash is currently a manual process due to the cmd line limitations of DCS. I've come up with a solution using a VB script to monitor DCS and a "AutoHotkey" script to re-start it. Example files attached to the post Demo Vid: You'll need to download and install AutoHotkey from http://www.autohotkey.com/ I've tested this on windows 7 pro 64 bit Basically the VB script monitors for the DCS process and starts the autohotkey script if DCS is not running. The VB scripts then loops at a pre-defined interval to monitor the server. Autohotkey is a UI test tool which can enter mouse clicks etc to test an application. It can also obviously be configured to start DCS and select and load missions using the DCS GUI. YOU WILL need to create a new hotkey script to match the GUI properties of your DCS window but this is fairly straightforward. The VB script: '**************************************** '* Application Restart Script * '* based on http://www.intelliadmin.com * '* amended by s77th yeti for DCS * '* AutoHotkey is also needed in order * '* to re-start the dcs server * '**************************************** set Service = GetObject ("winmgmts:") set Shell = WScript.CreateObject("WScript.Shell") '**************************************** '* Set variables * '**************************************** 'Name of the DCS exe we want to watch sEXEName = "DCS.exe" 'Path of the folder the AutoHotkey script is in (Don't forget the trailing \) sHotKeyPath = "C:\utils\bin\" 'Hot key script name sHotKeyScript = "DCS_mon.ahk" 'polling interval for the monitor in milliseconds (10000 is 10 seconds) sScriptInterval = "10000" '**************************************** '* NO NEED TO EDIT BELOW THIS LINE * '**************************************** 'Loop until the system is shutdown or user logs out while true bRunning = false 'Look for our application. Set the flag bRunning = true 'If we see that it is running for each Process in Service.InstancesOf ("Win32_Process") if Process.Name = sEXEName then bRunning=true End If next 'Is our app running? if (not bRunning) then 'No it is not, launch it Shell.Run Chr(34) & sHotKeyPath & sHotKeyScript & Chr(34) end if WScript.Sleep (sScriptInterval) wend The autohotkey script: #NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases. ; #Warn ; Enable warnings to assist with detecting common errors. SendMode Input ; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory. Run "C:\Program Files\Eagle Dynamics\DCS World\bin\DCS.exe" --net-mode gui sleep 20000 send {Enter} Sleep, 10000 click, 654, 1020 left Sleep, 10000 click, 1348, 449 left Sleep, 10000 click, 1415, 1019 left Exit

Noted, and I agree it's virtually impossible to replicate all hardware and software configurations for developers, however this doesn't appear to be related to a specific edge case of software or hardware incompatibility as it occurs on multiple configurations with a large number of online servers and clients. Anyway, I'm glad to hear ED is tacking it seriously and looking into it.

Isn't this something ED should be doing? crash logs on the servers (almost all of which are having similar problems since 1.2.6) and generic runtime errors on the clients are not really pointing to one specific cause, this problem really needs to be de-bugged properly by ED development and QA. Agreed that accurate information when reporting issues is essential but given the amount of customer feedback, I think ED should be proactive in trying to reproduce the issues and fix them.

:) so I just raised a ticket and it was resolved within the hour! great support. Created: 17.09.2013 09:53:47 by Modified: 17.09.2013 10:58:58 by Closed: 17.09.2013 10:58:58 Category: Shop Subject: Cannot process payment in e shop

Sounds like a plan, but using simple comms, nothing seems to happen when I contact CAS or SEAD flights, no further options...

I think so, but every time I select on the "other" comms link and the the SEAD flight, nothing appears to happen.

Thanks, that thread is useful.