dFxPhoeniX

Thanks for the logs. They show problems with the player entity before the SimpleStatus errors. The October 23 disconnect also has a different stack trace, involving BasePlayer and Client.Update. This suggests the SimpleStatus exception may be a consequence of the incident rather than its cause I ve prepared a fix for the destroyed-component issue in SimpleStatus 1.3.6, which I haven t uploaded yet. It addresses the SimpleStatus exception, but I can’t confirm that it will also resolve the disconnect or missing inventory AdvancedStatus is also throwing exceptions, so those are worth reporting to its developer. Once I publish 1.3.6, please test it and let me know whether the problem persists. Thanks for helping track this down

Thanks for the full stack trace. This one does point to an actual issue in SimpleStatus The error occurs in the AdvancedStatus tracking path when SetStatus reaches a StatusBehaviour that Unity has already destroyed, most likely during a player lifecycle transition such as death, disconnect, despawn, or another rapid state change. SimpleStatus then calls IsInvoking on that invalid behaviour, which causes the ArgumentNullException: Value cannot be null. Parameter name: self exception I’ll fix this in SimpleStatus 1.3.6 However, I can’t yet confirm that this exception itself is what disconnects the player, kills them, or causes the body to disappear. Normally, this error should only interrupt the SetStatus call. It may instead be a secondary error triggered by the same event that is affecting the player If possible, please send the console lines immediately before the disconnect, including the disconnect reason and any other exceptions. That will help determine whether SimpleStatus is only producing this error during the incident or is actually involved in the disconnect/death problem In any case, the SimpleStatus exception shown in this stack trace is valid and will be fixed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Fixed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Fixed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Fixed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Closed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Fixed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Closed

<b>Changed</b> Status <b>from</b> Pending <b>to</b> Can't Reproduce

I checked it and the plugin itself looks fine. The problem is with the image path. This link: https://rebel25.com/server/Skills.png does not actually open an image. It opens your website, so Rust cannot load it as an icon. Also make sure the local folder is exactly: oxide/data/Buttons/images/Skills.png with a capital B in Buttons. On Linux, Buttons and buttons are not the same folder. So try this: 1. Put Skills.png in oxide/data/Buttons/images/ 2. Use "Skills.png" in the local image field 3. Leave the image URL empty for testRelod 4. Reload the Buttons plugin If it still doesn't work after that, send me the exact file path from the server and any console message you get when reloading the plugin.

This means that custom vitals has been loaded From this perspective, you should see much better performance than with the legacy GUI

Changed Status from Pending to Can't Reproduce

If PurgeFX is a paid plugin, then honestly this should be handled by its developer. I’ve already tested the SimpleStatus side extensively and the issue does not reproduce there I’m not going to purchase paid plugins just to debug or potentially fix someone else’s compatibility issue. I’ve tried to help as much as I reasonably can from my side, but without the PurgeFX source or proper logs, the next step is with the PurgeFX developer If the PurgeFX developer is no longer providing support, then unfortunately there isn’t much more I can do without access to the plugin code or useful debug information showing exactly what PurgeFX does when the purge ends

If you want, you can add me on Discord and send me the plugin that’s causing the issue. I can check the SimpleStatus integration directly and see whether something changed there Based on the tests I’ve done, I’m fairly confident the problem is coming from that plugin rather than SimpleStatus itself. I’m not sure what changed in the compatibility if you say it used to work before, but having the actual plugin would make it much easier to confirm exactly where the status is being left behind or restored incorrectl

That’s useful to know. Even if you didn’t change anything manually, it could still be a timing/state issue that only shows up when the purge ends while the player is offline. From the video, the important part is that the status is being restored after you reconnect even though the purge has already ended. I tested that exact SimpleStatus scenario separately: the purge-style status is active, the player disconnects, the event ends while the player is offline, the external plugin clears the status with SetStatus(s 0), and after reconnecting the status does not come back. I also tested this with the Legacy CUI fallback active and across plugin reloads. So this still points more toward PurgeFX not clearing the saved SimpleStatus status for an offline player when the purge ends, or restoring/reapplying it from its own state when the player reconnects. Since the UI is destroyed when the player disconnects, the bar you see after reconnecting is not simply an old UI element left on screen, the status is being restored from stored state. If it happens again, please check the console around the exact moment the purge ends. That would help confirm whether PurgeFX is actually sending the status removal while you’re offline

Yes, I have UseCustomVitals set to true. However, for this particular PurgeFX status it should not make much difference, because PurgeFX is using assets/icons/warning.png. SimpleStatus detects that the asset icon is not supported by Custom Vitals and automatically switches the affected player to the Legacy CUI fallback. All the tests I mentioned were actually done with UseCustomVitals = true and with that Legacy fallback active I also tested almost the exact scenario you described: the purge status was active, I disconnected, the purge ended while I was offline, the external plugin called SetStatus(.s 0) while I was offline, and when I reconnected the status was gone. I also tested it across SimpleStatus and external-plugin reloads So changing UseCustomVitals to false may change the renderer being used, but I don't think it is the root cause here If it happens again, could you check the console (if the purge plugin have logs) around the exact time the purge ends? The most useful thing would be to know whether PurgeFX is actually clearing the SimpleStatus status when the purge ends while the player is offline. SimpleStatus handles that case correctly when it receives the removal call

I tested this pretty extensively on the latest SimpleStatus build and I haven’t been able to reproduce the stuck purge status. The console message you posted is expected and is only informing you that PurgeFX is using a Rust asset icon, so SimpleStatus falls back to Legacy CUI for that status. It is not an error. I tested: adding/removing the purge status while online removing it while the player is offline timed status expiry while offline reconnecting after the status expired reloading SimpleStatus during the purge reloading the plugin controlling the purge during the purge restoring the status after reload and then clearing it while the player was offline In all of those cases the status was removed correctly and did not reappear after reconnecting. At this point I can’t reproduce an issue in SimpleStatus itself, so this may be related to how PurgeFX is restoring or clearing its purge state in your specific case. The problem probably is not SimpleStatus itself, and may be related to how PurgeFX is restoring or clearing its purge state in your specific case. Can you tell me exactly what happened before the status got stuck? For example, whether the server restarted, PurgeFX/SimpleStatus was reloaded, the purge ended automatically or by command, and which versions of PurgeFX and SimpleStatus you are using. If you have any console logs from around the time the purge ended, send those too

Also, did you see some messages in console like "Status 'xxx' from plugin 'SomePlugin' requires the Legacy CUI integration because it uses a progress bar..."?

Thanks, that pretty much confirms what I suspected You re on 1.3.1, using Oxide, without AdvancedStatus, and the startup log shows that CustomVitals was unavailable and SimpleStatus fell back to Legacy CUI I just uploaded version 1.3.2. It fixes a startup timing bug where SimpleStatus could initialize before the Facepunch server state was fully ready, causing CustomVitals to be marked unavailable until the plugin was manually reloaded Please update to 1.3.2 and do a full server restart, not just a plugin reload. After startup, you should see a message saying that the CustomVitals backend is available through the SimpleStatus internal wrapper If it starts correctly on CustomVitals, the whole rendering path should be considerably lighter, since it won't need the same frequent CUI layout checks and redraw work I m also going to go through the Legacy CUI path myself and see if there's an actual performance issue there that needs fixing, because I don't want to just assume the fallback is behaving optimally Based on your logs and the before/after reload graphs, I think the performance issue is very likely tied to the Legacy CUI path rather than CustomVitals itself If the CPU usage still starts climbing again on 1.3.2 while CustomVitals is confirmed active, send me a new graph and the SimpleStatus startup messages and I'll keep tracing it

Hey, thanks for the report and the graphs. The increase in the 1-second average is worth investigating. Could you confirm your exact SimpleStatus version, whether you’re using Oxide or Carbon, and whether AdvancedStatus is installed? Please also send your Permission Status config and any SimpleStatus backend/fallback messages from the console Roughly how many players were online before and after the increase around 00:30? Also, after reloading SimpleStatus, does the 1 second average drop as well, or only the cumulative total? I’ve identified some potentially unnecessary work in SimpleStatus’s update paths, but I need those details to narrow down what’s happening on your server

Changed Status from Pending to Fixed Changed Fixed In to 3.2.9

Changed Status from Pending to Fixed Changed Fixed In to 3.2.9

Changed Status from Pending to Closed Changed Fixed In to 3.2.9

Changed Status from Pending to Fixed Changed Fixed In to 3.2.9

Changed Status from Pending to Not a Bug Changed Fixed In to 3.2.9