Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Phoenix125 last won the day on January 13

Phoenix125 had the most liked content!

Community Reputation

25 Excellent

About Phoenix125

  • Rank
  • Birthday November 4

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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!)
  3. @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.
  4. 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.
  5. 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!
  6. @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!
  7. @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.
  8. 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)
  9. @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.
  10. @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!
  11. @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!
  12. 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/
  13. @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
  14. @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!