dFxPhoeniX

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

For Economics, use its deposit command instead of giveto. Example: "Rewards": { "@": [ "deposit {playerid} 25" ] }, "Reward Descriptions": { "@": "25 $" } giveto is for inventory items, not Economics currency

Changed Status from Pending to Closed Changed Fixed In to 3.2.9

Changed Status from Pending to Closed Changed Fixed In to 3.2.9

Changed Status from Work in Progress to Not a Bug

Thanks for the update This is not an Easy Vote Extended bug. Reward entries are executed as server commands exactly as they are configured in the plugin config. So if giveto is no longer a valid command on your server and inventory.giveto is required instead, the reward command needs to be updated in your configuration. For example: inventory.giveto {playerid} stones 10000 The voting and reward system itself is still working correctly - the issue was only the configured server command. I’ll update the example/default reward command in the documentation/config to use 'inventory.giveto' to avoid confusion in the future.

Changed Fixed In from Next Version to 3.2.9

Changed Status from Work in Progress to Not a Bug

The 'Server Vote Custom link' option is used to replace the individual vote links shown by /vote with one custom URL for that server. The value on the left must match the server key used under `Server Voting IDs and Keys`. For example: "Server Voting IDs and Keys": { "ServerName1": { "Rust-Servers.net": "ID:KEY", "Rustservers.gg": "ID:KEY", "BestServers.com": "ID:KEY" } }, "Server Vote Custom link": { "ServerName1": "https://alliant.gg/vote" } In this example, ServerName1 is the server key, so the same key must also be used under Server Vote Custom link. If you renamed ServerName1 to something else, for example: "Server Voting IDs and Keys": { "Alliant Games Rust Resurgence": { "Rust-Servers.net": "ID:KEY", "Rustservers.gg": "ID:KEY" } } then the custom link must use the same name: "Server Vote Custom link": { "Alliant Games Rust Resurgence": "https://alliant.gg/vote" } Also, please check the documentation before opening a support request, as the configuration structure and custom voting setup are already explained there. The 'Adding a Custom Voting Site' section explains a different feature: adding a completely new vote tracker/provider. For a custom tracker, it must first be added under 'Voting Sites API Information', for example: "MyVoteTracker.com": { "API Claim Reward (GET URL)": "https://example.com/api/claim?key={0}&player={1}&server={2}", "API Vote status (GET URL)": "https://example.com/api/status?key={0}&player={1}&server={2}", "Vote link (URL)": "https://example.com/server/{0}", "Site Uses Username Instead of Player Steam ID?": "false" } Then the same tracker name must also be added under the desired server: "ServerName1": { "MyVoteTracker.com": "SERVER_ID:API_KEY" } So these are two separate things: - Server Vote Custom link = replaces the links displayed by '/vote' with one custom URL. - Adding a Custom Voting Site = adds a new vote provider/API to the plugin. If your custom link key already matches the server key and it still does not display, send the relevant parts of your config with the API keys removed, together with your plugin version, and I can check it

Changed Status from Pending to Closed Changed Fixed In to 1.2.19

Changed Status from Pending to Closed Changed Fixed In to 1.2.19