Jump to content

Phoenix125

Pathfinder
  • Content Count

    121
  • Joined

  • Last visited

  • Days Won

    1

Phoenix125 last won the day on January 13

Phoenix125 had the most liked content!

Community Reputation

26 Excellent

About Phoenix125

  • Rank
    Scallywag
  • 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.1.3 (2020-02-23) Memory Leak Fix! Fixed params with spaces. Added Mod Update notes to announcements. - Fixed: Memory Leak! All output from RCON was not being properly dumped, therefore ASUU was buffering all RCON activity. (Thanks to @MeatShield for reporting and finding cause of memory leak). - Added: Mod update notes can now also be sent with Discord announcements. (Thanks to Doublee for requesting) - Fixed: Auto Update would restart the old version instead of the downloaded version. - Added: "Running" button to main window (in addition to the "All", "None", "Local", etc. (Thanks to @Neitfall for requesting) - Added: Grid Configurator: AddedEggHatchSpeedMultiplier, BabyMatureSpeedMultiplier values. (Thanks to @Norlinri for requesting) - Fixed: Grid Configurator: Several parameters were adding a space between param and =. ie. PlayerDefaultNoDiscoveriesMaxLevelUps =35. (Thanks to @MeatShield for reporting) NOTICE! Due to an error in v2.1.2, AFTER YOU COMPLETE THE AUTO UPDATE, ASUU will restart the old version. You will have to close ASUU and manually start the new AtlasServerUpdateUtility_v2.1.3.exe in the ASUU folder. Sorry. Then run "AtlasServerUpdateUtility_v2.1.3.exe" or the 64-bit version in the ASUU folder. v2.1.4 & v2.1.5 (2020-02-24) released.. Hotfixes.
  2. @Neitfall Good suggestion. I'll add an "On" or "Running" button. @ChupaA This issue was resolved on the Discord channel: It was due to having a space after the comma.
  3. @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!
  4. @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.
  5. @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.
  6. @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
  7. 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
  8. 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.
  9. 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!)
  10. @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.
  11. 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.
  12. 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!
  13. @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!
  14. @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.
×