Jump to content

Phoenix125

Pathfinder
 View Profile  See their activity

  • Content Count

    144

  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Phoenix125

  1. Phoenix125
    @Blackavar Sorry. I do not know why it's doing that, and I'll try to reproduce your issue to fix it, but in the meantime, here's how you can "fix" it: ASUU stores the current ModIDs in a temp file. It scans the ServerGrid.json every 10 seconds and compares that with the stored ModIDs. If it detects a change, it reboots. (People requested this feature). For some reason, it doesn't seem to be updating the temp file for ya, so you can do it manually (while ASUU is shut down): Open \[ASUU]\AtlasUtilFiles\AtlasServerUpdateUtility_cfg.ini Put your ModIDs here: aServerModList=xxx Another way is to put your ModIDs in using ASUU's Grid Configurator (if you can keep ASUU from rebooting too quick): @MeatShield Thanks for the suggestion, but ProcessWaitClose() had an unacceptable delay.. that's why I ran the While... End loop in the old code. And now, after your discovery, it would cause the same memory leak issue. It appears that I have to perform the StdoutRead before the CMD window closes in order to clear the buffer... no idea why, but that's what my testing showed. Good thinking, though. I certainly am open to other ideas as your discover them. Thanks!
  2. Phoenix125
    @Neitfall Thanks for the log file. I'll take a look, although @MeatShield may have found the cause.. a memory leak. @MeatShield You found the memory leak! THANKS MUCH! After a couple hours of testing using: ... the "fix" wasn't the StdioClose() nor the $STDERR_CHILD, but rather the way I was getting the StdoutRead. The $STDERR_CHILD made no difference in memory. (I was surprised). Executing StdioClose() too early caused AutoIT to freeze. The "standard" way would of getting Stdout would cause ASUU to get stuck in a loop occasionally. So I tried a diff method in ASUU previously... Unfortunately, that way caused the memory leak because it never wiped the StdoutRead from memory. So now I have a hybrid that has been working great so far in testing: Old: Local $mOut = Run($aMCRCONcmd, @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD) If $mWaitms > 0 Then Local $tTimer1 = TimerInit() Local $tExit = False While ProcessExists($mOut) And $tExit = False Sleep(50) If TimerDiff($tTimer1) > $mWaitms Then $tExit = True WEnd ProcessClose($mOut) Local $tcrcatch = StdoutRead($mOut) New: Local $mOut = Run($aMCRCONcmd, @ScriptDir, @SW_HIDE, $STDOUT_CHILD) Local $tTimer1 = TimerInit() While 1 $tcrcatch &= StdoutRead($mOut) If @error Then ExitLoop If TimerDiff($tTimer1) > $mWaitms Then $tcrcatch = "ERROR! " & $tcrcatch StdioClose($mOut) Sleep(250) ProcessClose($mOut) ExitLoop EndIf WEnd Return $tcrcatch Thanks again! Unfortunately, a work project took my free time this weekend, so I prob won't get the fix out for a couple more days. (I'm a hospital nurse. We're upgrading our main software (Cerner) next weekend. I had to develop a program to create an offline dump of all Order Sets used by our physicians during the downtime. http://www.phoenix125.com/downtime.html ) Thanks for understanding.
  3. Phoenix125
    @MeatShield Thank you for the valuable information! I will release an update by end of Sunday.
  4. Phoenix125
    @Neitfall This is the most helpful log for me: @MeatShield Thank you! I'll certainly give that a try! That code was so old I had forgotten about it. As for your grids that are "turned off"... ASUU shouldn't be trying to poll them if you have them off... therefore I'm assuming they're being run on a separate PC? If so, you could set them to Remote and disable "poll remote": It would stop polling on the running remote grids, too, but it would decrease the log spam and some time. Maybe someday I'll add a selection for which remote grids to monitor.
  5. Phoenix125
    @Neitfall re; memory leak: The following is from my 5x5 on my Dual Xeon E5 2680 v2 after running for several days. You definitely have, what appears to be, a memory leak. Someone else reported something similar a couple months ago, so I double checked all the document opening-and-closing routines in the code.. I found two that were opening, but not closing, documents and were therefore potentially sucking up RAM. He hasn't reported any issues since. I'll take another look for similar things. The log I want is the most recent Detailed/Full log when the system crashed. It will let me know what ASUU was doing last. One other person sent me his logs and it was inconsistent, but maybe after a few more logs, I may be able to narrow it down. I worked hard on that KeepAlive prog. Make sure you're running it, but assuming you are, I'm disappointed that it didn't work for ya. @MeatShield re; memory leak: Same info as Neitfall above: Could you send me your most recent detailed/full log also? It may help me narrow down what process is causing the lockups. I thought about "clumping" together RCON message delivery, but they generally send real fast. I can send a message to my 25 grids in about 2-3 seconds.. and that's while waiting for a response. If no response needed, such as sending "DoExit", it takes about 0.5 seconds. If I grouped the messages into a single text file, then sent that using one instance of mcrcon.exe, it might shave .2 seconds. Generally, the "slowness" is due to using old method of Discord messages. Try changing the config to :Use Fast Method to send Discord messages? (if problems, disable)(yes/no) ###=yes' I improved the delivery process in v2.09 I think.. it sends MUCH faster and more reliably now. Atlas has an issue with reporting active players: When a player travels from one grid to another, he/she often shows up on both grids. Therefore it is difficult to monitor true patient counts and locations. Therefore I am working to integrate with the redis server to improve accuracy. I had it working for me, but it didn't work for most, so I needed to gather more redis.db files to see where the differences lie. I hope to have this done within a month or so. Once I have accurate (or lat least MORE accurate) player reporting, then I'll consider adjusting affinity to surrounding grids. I realize I could do it now, but I feel it will be more useful after I get the redis integration completed. Just trying to prioritize my efforts a little. Great suggestion... thanks! -Phoenix125
  6. Phoenix125
    Thanks for reporting. I reworked the KeepAlive in the latest version (v2.1.2). The KeepAlive NOW should automatically detect ASUU lockups then task kill the froze instance and start another. I also worked on ASUU's detection process (to detect if it's already running), but I did that a few versions ago. FYI: If you have "Allow multiple instances of AtlasServerUpdateUtility? (yes/no) ###=yes" (YES), then ASUU doesn't look for existing ASUU instances. As for it freezing.. I do not know why it's doing that. If you send me your log when it happens, I can try to figure out what it was doing when it froze. kim@kim125.com Have you had issues since upgrading to v2.1.2? Thanks again, Phoenix125
  7. Phoenix125
    New Update! v.2.0.8 (2020-01-26) New! CPU Affinity! Bug Fixes. - Added: CPU/Process Affinity added to Grid Configurator. Affinity can be changed without restarting servers. (Thanks to Infiniti for requesting) (Affinity only works on systems with 64 or fewer logical processors. If >64, it can only assign first half. (ie, if you have 80 processors, it can only assign first 40). I am working on an update.) - Fixed: Line 43225 Error. (Thanks to JW2020) for reporting. - Fixed: Line 49621 Error. (Thanks to msmcpeake for reporting) - Fixed: ASUU was not unassigning PIDs during some shutdowns. This should prevent misidentifying existing servers. (Thanks to @Yet for reporting) Tip: Move the CPU Calculator next to the Grid Configurator window to quickly go from one grid to the next.
  8. Phoenix125
    Sorry about that and thanks for reporting! I have it fixed and will release the fix tomorrow. (I'm in the middle of adding CPU affinity and it's hard to release a fix while unfinished code exists.. sorry again!)
  9. Phoenix125
    @Yet Thanks for showing the screenshots. I now understand what happened. I've only had it happen once before, although it was NotePad, not an Atlas server, that was "Duplicated": I had forgot about it. The explanation can be confusing, but here goes: - When ASUU starts Atlas grids, it saves the PIDs to a file. - When ASUU starts, it reads the PIDs from that file and compares those PIDs with programs already running. - During a scheduled restart, all grids shut down. Server C2 was PID 6292. Currently ASUU does not delete the PID from the file, therefore even though C2 is no longer running, the PID file still has C2 assigned with PID 6292. - So, what happened was one instance of ASUU started the grids.. and coincidentally, Windows assigned a new Atlas server (A5) with PID 6292. - When the other instance of ASUU started, it read that PID file and compared all the old PIDs (from the file) with current running processes. - It detected a running process with PID 6292 (grid A5), and since PID 6292 was previously assigned to grid C2, it went ahead and assigned it to C2. Therefore, in reality, there is no C2 server, even though ASUU says there is. In the explanation above, I do not know if C2 or A5 was originally assigned PID 6292, so I could have the order reversed, but now I understand what the issue is. - This only occurs when multiple ASUU instances are allowed. When only one instance is allowed, ASUU uses a different Atlas server detection process. - I need to have ASUU unassign PIDs when it shuts down grids! THANK YOU FOR REPORTING WITH DETAILS! I will fix it in next week's update. To fix for now: (either C2 or A5 is not running, but to resync ASUU, you'll need to ensure both are shut down). 1. Close one instance of ASUU. 2. Shut down the PID 6292 grid (using the running ASUU). 3. Start the other instance of ASUU.. It should detect the one grid not running and restart it. 4. Start the grid again on the "running" ASUU. That should get everything back into sync.
  10. Phoenix125
    Update! v.2.0.7 Bug Fixes. Improved ASUU "already running" duplicate detection. Added a total of 140 ini parameters to Grid Configurator. - Added: grid configurator now has all known (and some untested) parameters from https://docs.google.com/spreadsheets/d/1X4nY0xMzsr65ud5ugvhdF2ZItDXcacbEBxxudfxseyM/edit#gid=607610888 (Inspired by DFS) - Fixed: Line 43163 Variable Used Without Being Declared Error. (Thanks to msmcpeak for reporting) - Fixed: MUCH NEEDED! Added a third (and more reliable) ASUU Duplicate Instance check routine to help prevent unintentional multiple instances of ASUU. - Changed: Removed Underscore _ from filenames in main ASUU folder, except the _Start.bat file. (Thanks to Linebeck for requesting) - Changed: ServerSummary creation only gets logged in the Detailed log now to prevent it from being broadcast to Discord. (Thanks to Linebeck for requesting) - Fixed: When closing the Grid Configurator or any of the Wizards, all fields are now saved by using a new close button. (Thanks to msmcpeak for reporting and helping diagnose issue) - Added: Web Links to NAT Loopback Help, Redis Desktop Manager, and Fix "Starting" Grid Status notice.
  11. Phoenix125
    PIDs are assigned by Windows when any process is started. There can never be duplicate PIDs running on the same PC. Therefore, I do not know what the issue is.. I was certain it would be the RCON ports. Do you mind PM or email me the detailed (Full) logs from your two systems for the same day (but not today.. a full 24h would give the best info)? This will help me significantly. kim@kim125.com Thanks!
  12. Phoenix125
    @Yet Thanks for the report. I assume you set ASUU to run multiple instances in the config? ASUU shuts down servers by RCON first then PID, as you suspected. Check to make sure that RCON ports are not duplicated in both instances. This is the likely reason: by default, ASUU assigns the same ports via the wizard. If server A1 is assigned port 25710 on both instances, it would then end up shutting both down. Try changing the RCON port assignment. Once done, the servers will have to be restarted. If that's no the issue, check to see if ASUU failed to properly detect/assign running grids by comparing a few PIDs from one instance to the other. This shouldn't happen as long as you have the "Allow multiple instances of AtlasServerUpdateUtility? (yes/no) set to no, but it's the only other thing I can think of. Let me know how it goes... I'm working on an update right now. Thanks!
  13. Phoenix125
    @Bovin Did you figure out your issues? Sorry it took so long for my reply. I occasionally forget to check this forum. Most activity is on my Discord, but I'll try to remember to check here regularly.
  14. Phoenix125
    Update! v.2.0.6 Fixed Discord Fast Method, added ModIDs & Online Player List to Configurator, Discord "Ready" status announce delay, & more. - Added: Option to check for mod updates but not install them until "Update Mods" button pressed. Helps prevent mod update from crashing your server without you knowing. (Thanks to @Neitfall for requesting) - Added: Added an "Enabled" check box in the ALL GRIDS section to help prevent executing commands on all grids when intending to do select grids only. (Thanks to @Neitfall for requesting) - Added: ModIDs field to Grid Configurator. Hover mouse over text to see current mod list with names. - Added: Discord announcement delay after grid reaches Ready status. (Thanks to Nyt & Infiniti for requesting) - Added: If more than one RCON port entry is in a GUS.ini file, ASUU warns the user and uses the first entry. - Added: Execute external script before BACK UP feature added. (Thanks to Infiniti fro requesting) - Added: ModIDs and Names List added to ServerSummary.txt file at end of file. (Thanks to Anorak1313, AceMan, & Infiniti for inspiring) - Added: Discord: If error 429 (Too many requests), ASUU skips retries.- Added: Online Players list when you hover over grid name/number in Grid Configurator. - Fixed: Backup: Added DefaultGUS, DefaultEngine, etc to backups. (Thanks to @Neitfall for reporting) - Fixed: Discord Fast Method: The code was improved. It should work on more systems. (Thanks to AceMan, Linebeck, and others for reporting) - Fixed: "Error allocating memory" error. I fixed three known causes of this error; Most likely cause was a large log file. (Thanks to AceMan for reporting) - Changed: Number of Online Player RCON retry attempts (0-3) ###= increased max number to 9 (Thanks to Nyt for requesting) - Changed: Log: Added more entries/details for server restarts, more details in Discord Fast Method log entries. - Changed: Batch File folder no longer deletes the entire folder, but batch files still get overwritten every time ASUU is started. (Thanks to @BentoFox for requesting)
  15. Phoenix125
    @NeitfallThanks for the report. You are the third person to report it. It might be related to ASUU opening a file, reading it, and not closing it... but I have not found out for sure. I'm investigating. Since it has never happened to me, it's hard to pinpoint. If you find something odd in the logs, let me know, but I'm guessing the logs will look normal. Thanks.
  16. Phoenix125
    @NeitfallVERY good idea.. I, too, have fallen victim of clicking the wrong box!
  17. Phoenix125
    @kasyhn The only time AtlasServerUpdateUtility (ASUU) makes any DIRECT changes to the GUS, Game, Engine, SG.json files is if you use the "Grid Configurator" or the Setup Wizards. BUT! Any changes made that can affect the command line used to start the Atlas Servers, such as password, IP, Ports, etc. will be added to the GUS, Engine. etc by Atlas itself. Try making your GameUserSettings.ini, Game.ini, Engine.ini files and the ServerGrid.json file READ ONLY to help prevent unwanted changes being made. Then, if you want to purposely make changes via the Grid Configurator, ASUU will ask if you want to make changes to a read-only file. Hope that helps!
  18. Phoenix125
    @Yet I may have an idea what is causing your memory leak thanks to AceMan reporting a "Error allocating memory" error... first time it's ever happened. It's possible that the util is not closing a file properly after reading it.. therefore every time it reads it, it keeps adding it to the buffer. It's the first thing I'll work on for the next release! Thanks!
  19. Phoenix125
    Thanks for posting. I have a whole Discord thread devoted to this subject. Here's a recent post I posted here: Here's a summary of my Discord discussion: I've had people tell me that Windows Defender reported my util to have viruses. So I ran AtlasServerUpdateUtility_v1.7.2.exe through www.virustotal.com. - The results were exactly the same as when I sent my tiny screen capture program, so the issue must be with AutoIT. (I've read everywhere that progs written in AutoIT cause false flags). - Nonetheless, I ran a couple virus scans on my AutoIT installation.. to be safe! It came back clean. Below are the www.virustotal.com results of AtlasServerUpdateUtility_v1.7.2.exe 10 / 70 reported it as suspicious... So 60 / 70 said it was safe. Rest assured.. I did NOT put anything malicious in there. I've put way too much time and pride into this thing to ruin it by adding garbage. - As I've always said, people can look at the source and compile it themselves if they wish to be extra safe...I'd understand! Source code on GitHub: https://github.com/phoenix125/AtlasServerUpdateUtility AutoIT DL: www.autoitscript.com/site/autoit/downloads/
  20. Phoenix125
    @Yet Atlas Dedicated Servers have a built-in mod updater. Atlas itself is causing the "SteamCMD automatically checking for updated mods". To keep Atlas itself from updating mods, you need to add "-manualmangedmods" to command line. I guess I should've told ya last time Sorry about that! In summary: In order to completely manage the mods yourself, two changes are required: 1. In ASUU, change the following in the config to disable ASUU's mod updater: Use this util to install mods and check for mod updates (as listed in ServerGrid.json)? (yes/no) ###=no 2. In ASUU, add -manualmangedmods to the command line in the config to disable Atlas' mod updater: Atlas extra commandline parameters (ex.?serverpve-pve -NoCrashDialog) ###= -log -server -servergamelog -NoBattlEye -nocrashdialog - manualmanagedmods
  21. Phoenix125
    @Yet The option exists to manually manage mods (or let Atlas manage them) in the AtlasServerUpdateUtility.ini file (or simply click the "CONFIG" button): [ --------------- GAME SERVER CONFIGURATION --------------- ] Use this util to install mods and check for mod updates (as listed in ServerGrid.json)? (yes/no) ###=no It's down about 25-20 lines in the first section. Thanks!
  22. Phoenix125
    @Neitfall Great idea! I'll add it to my list. @Joew Alabel The util pulls the latest mod version number from the following website: http://steamcommunity.com/sharedfiles/filedetails/changelog/[ModID] Sometimes the mod developer does not update their mods properly or it's also possible that your gaming PC is not updating the mod properly. No one else has reported issues with the mod updater, but if your problem continues, let me know. Post the ModIDs and I can test here. @ReilanT I completely understand your concern! Almost any software written in AutoIT (the programming language ASUU is written in) gets flagged as a virus by Windows Defender... even my 2 line mouse move prog gets flagged. - I submitted an exception to Microsoft and they added that version of ASUU to their SAFE list, but it only applied to that version and it would only take affect when people do their monthly virus definition update. Since I release updates far more often than monthly, it's essentially pointless for me to keep submitting to Microsoft. - In my Discord server, I have a channel dedicated to this subject: I have screen shots showing that the util is found safe by 60/70 virus scanners. - For those that are very skeptical, I post my source code to GitHub. Anyone can review the code and compile it for themselves https://github.com/phoenix125/AtlasServerUpdateUtility Thanks!
  23. Phoenix125
    Update! v.2.0.4 Bug Fixes and a couple new things. NOTICE! The Redis Integration for Online Players is temporarily disabled until I get it working for people other than me - Added: Optionally disable Grid Memory and CPU reporting. - Added: Disable grid process crash detection (for using util with ChromeSDK's Atlas Server Controller). (Thanks to @Neitfall for requesting) *WARNING! **Disabling crash watchdog is Extreme BETA!** For now, it will NOT RESTART grids after ANY shutdown, including daily restarts, mod/server updates, etc.* *In future release, I will have it detect running grids and restart those during daily restarts, mod/server updates, and skip polling online players for "crashed" grids.* - Fixed: Line 39838 Error. - Fixed: Line 39857 Error. - Fixed: Send Msg to ALL GRIDS was not working. - Fixed: Grid Configurator: AltSaveDIR was only accepting numbers. - Fixed: 64-bit version batch file wasn't updating properly. (Thanks to @Visual for reporting)
  24. Phoenix125
    When changing files, such as ServerGrid.json or GameUserSettings.ini, ASUU creates and saves backups in the same folder as the file being backup'd. For the Backup feature (backup save and other Atlas folders), it saves them in /[utilfolder]/Backups folder. It creates a new file for each backup. You can set how many backups to keep.
  25. Phoenix125
    Sorry for delayed response. I am not sure why it is not working for you. I will do further testing. You can look at the util's log file and see if the mods / password are causing errors, although not likely. ASUU gets the modIDs and assigns the password in the GameUserSettings.ini. You can look there for errors. Easiest way to get to the GUS.ini is using ASUU's Grid Configurator.
×
×
  • Create New...