hid333

I just created a new one and checked it. The icon source made no difference; the name wasn't reflected in either case. However, when I changed the parent item to "rhib" and checked, the item name became "rhib." It appears that the display name has not been reflected. Can you think of any possible cause?

It would be great to have a command that allows unlocking achievements for a specific player, to handle cases where an obtained item fails to register for some reason. Since the record data is stored in a data file, it cannot be modified directly, so a command-based solution would be very helpful. Example: A command to set the status for "player1" to "AK Rifle obtained" (unlocking the achievement) within the Collection "T3 WEAPON" category.

Items created using scrap as a base sometimes retain "Scrap" as their display name. I created several similar items: Items where the icon source was set via URL correctly adopted the specified name; However, items created by modifying the skin ID remained named "Scrap," even though I had changed the display name. I verified this by creating the items using the "Create x1" function within this plugin.

Notifications sent using Notify appear in red and display the default title "Error," so I would like to use the blue notification style instead. Is it possible to change this in the settings? "Work with Notify?": true,

This issue resembles a problem I encountered previously with Gun Game or Arena modes: the moment I join, I fall through the floor instead of remaining in the lobby. If the game starts in this state, I get stuck in a loop of repeatedly dying and respawning, causing the screen to flicker (an endless cycle of death → respawn → death). Please look into this. I tried resetting the center coordinates, but that did not resolve the issue.

oxide

This issue is affecting everyone—including players who have been logged in since the official wipe for this season—and the behavior appears identical to what occurred during the wipe itself. I didn't observe it personally, but it is possible this didn't happen in the previous version. While multiple official updates have already been applied this season, I have only verified the situation following today's update. Of course, the server has not been wiped, so players' bases and items remain intact.

After a Rust server update, the "NEW PLAYER JOINED" message is sometimes triggered again. This occurs even for players who were already connected prior to the update. Please ensure that this message is displayed only at the appropriate time for a wipe—such as when the map changes—rather than immediately following an update.

Please add the fridge-related items to the plugin's target list. This includes DLC items as well. fridge mini fridge gamesroom.minifridge electric.wallcabinet These are the ones. Adding them to "Allow Prefabs" in the config had no effect. There was no change even when I tried entering the specific prefab name: "assets/prefabs/deployable/fridge/fridge.deployed.prefab"

Recently—especially in ocean areas—multiple dynamic monuments have been spawning in close proximity, allowing a single player to monopolize them. I would like a feature that allows setting a minimum distance between dynamic monuments. Additionally, I would like them to be prevented from spawning when a tugboat or player boat is nearby. They sometimes spawn in the exact same location; since players tend to leave tugboats parked for immediate reuse, dynamic monuments can end up spawning right next to them (as shown in the photo). I currently have the setting below configured to 100, but I believe it would be beneficial to also have configurable settings for the minimum distance from dynamic monuments and from player boats. Please consider this request. "Minimum distance from a TC at which a monument can spawn (0 – do not use this parameter)": 100.0,

It appears that one of the "Blue Card" rooms in the "Oil Depot" does not open even when the button switch inside is pressed. Please check this.

Please, I beg of you...

I investigated the Waystones performance issue more closely. The repeated OnEntityTakeDamage took average ~1.1s warning appears to be misleading. The actual repeatable slow operation is WaystoneConsoleCommand, which consistently takes around 1.1–1.2 seconds when the issue occurs. This seems strongly related to the teleport process rather than the damage hook itself. The current teleport flow appears to perform several expensive operations in the same command execution: destination validation, teleporting, trigger/network group updates, clearing the entity queue, and finally forcing a complete player snapshot. On my server, which has around 50 players and more than 115k server entities, forcing a complete network resync on every teleport may be especially expensive. Could you please consider optimizing the teleport flow? Possible improvements would be: Avoid forcing a complete snapshot on every teleport unless it is actually necessary. Use the minimum network updates required for a normal teleport. Avoid clearing/rebuilding the player's entity queue unnecessarily. Cache validated teleport positions more aggressively instead of repeating multiple physics/entity checks. Add internal timing measurements for each teleport stage to identify exactly which operation causes the ~1.1s delay. Reduce unnecessary globally networked decorative Waystone entities/lights where possible. The goal would be to avoid doing all expensive teleport/network synchronization work synchronously inside a single UI command. The OnEntityTakeDamage average warnings are probably a side effect of the accumulated Waystones execution time rather than the actual source of the delay. I’ll leave the implementation approach to you, but I believe optimizing the teleport/network synchronization path could significantly reduce these server-wide micro-freezes.

I created a test version that takes this behavior into account. With that version, RustEdit damage triggers work correctly while the normal SimplePVE protection remains active, so it seems possible to support these environmental triggers without losing the existing PvE functionality. If possible, I would greatly appreciate it if you could consider implementing similar support officially. If supporting the damage triggers directly would be difficult, another possible solution would be to expand the current zone exclusion functionality. At the moment, when an existing ZoneManager zone is added to: "Exclude Zone IDs From Rules" PvP damage and some related rules are correctly bypassed inside that zone, but SimplePVE is not completely disabled there. In other words, the behavior inside an excluded zone is still different from completely unloading SimplePVE. For example, when SimplePVE is fully unloaded, RustEdit damage triggers such as Damage Trigger High work normally and players receive the expected environmental damage. However, adding the same area to "Exclude Zone IDs From Rules" does not currently reproduce that behavior. If direct support for RustEdit damage triggers is difficult, I would appreciate it if excluded zones could instead become a true full bypass of SimplePVE. Ideally, inside an excluded zone: SimplePVE would not modify or block any damage RustEdit damage triggers would work normally Radiation and other environmental effects would work normally PvP damage would behave normally All other SimplePVE protections and restrictions would also be disabled In short, I would like an excluded zone to behave as closely as possible to an area where SimplePVE is completely unloaded, rather than only bypassing certain PvP-related rules. I would greatly appreciate it if you could consider either approach.

I would like to report an issue regarding SimplePVE and RustEdit damage/radiation trigger prefabs. On some custom maps, map creators use damage areas, hazardous floors, lava, and similar environmental hazards. Many of these are created using the standard damage trigger prefabs documented on the Facepunch Wiki. For example: Damage Triggers https://wiki.facepunch.com/rust/Volume_Prefabs#damagetriggers Damage Trigger Low Damage Trigger Mid Damage Trigger High Damage Trigger Death Radiation Spheres https://wiki.facepunch.com/rust/Volume_Prefabs#radiationspheres Radiation Low Radiation Med Radiation High These prefabs can also be found in the RustEdit prefab list. The problem is that when SimplePVE is enabled, some of these environmental damage triggers are also blocked by the PVE damage protection. Because of this, custom maps that intentionally use hazardous areas do not behave as expected. For example, a floor or lava area configured with Damage Trigger High may cause no damage at all while SimplePVE is active. Radiation triggers can also be affected depending on how the damage is processed. Would it be possible to officially support these RustEdit environmental triggers? A possible approach would be to detect damage originating from the standard RustEdit/world TriggerHurt / TriggerHurtEx damage volumes, or from prefabs under the standard hurt-trigger prefab path, and allow that environmental damage before applying the normal PVE damage-blocking logic. It would be important that this exception applies only to world/environmental damage, so normal player-vs-player, trap, NPC, turret, and vehicle damage would still continue through the existing SimplePVE rules. In short: Allow standard RustEdit Damage Trigger Low / Mid / High / Death damage Allow normal Radiation Low / Med / High behavior Keep existing SimplePVE PvP protection unchanged Treat these as environmental/world damage rather than PvP damage Some custom maps rely heavily on these standard Facepunch/RustEdit trigger prefabs, so official support would be very helpful. Thank you for your work on SimplePVE and for considering this request.

Yes, I have inquired about this previously, but just to be certain, I have submitted a fresh inquiry this time as well.

I would like to report an issue that occurs when a monument is located near coordinates 0,0,0. In RUST, the coordinates 0,0,0 appear to have a special meaning. Based on the behavior I have observed, it seems that various entities or objects may temporarily be created or initialized around 0,0,0 internally by the game. Because of this, problems can occur on custom maps where a monument—for example, an Airfield—is located at or very close to 0,0,0. For example, when attempting to apply a monument lock to the Cargo Ship, the monument located near 0,0,0 may also be incorrectly detected and locked. In this example, the Airfield may become locked as well. This can result in situations where players are unable to attack the NPCs on the Cargo Ship, which may eventually cause the players to be killed by those NPCs without being able to fight back. I would greatly appreciate it if you could consider implementing a way to avoid this behavior. Whenever I use a custom map, I make it a point to check the area around 0,0,0 first. However, depending on the map design, it is not always possible to move or modify the monument. I understand that the monument lock detection threshold can be adjusted quite precisely using the Monument Finder commands. However, if a monument is located directly above or extremely close to 0,0,0, it can be practically impossible to avoid this issue through threshold adjustments alone. In such cases, my only workaround is to exclude that specific monument from the monument lock system entirely. If possible, I would appreciate it if the plugin could include some kind of special handling for entities detected at or near 0,0,0, so that monuments located there are not incorrectly associated with entities such as the Cargo Ship. Thank you very much for considering this issue.

When Vanish is turned ON or OFF, certain states or effects may sometimes persist. For example, if Vanish is enabled while inside a Safe Zone, the Safe Zone state may remain even after leaving the area. It seems that the issue preventing access may be caused by a similar behavior. Since this only affects administrators and does not impact regular players, I will simply make sure to be careful about this in the future. Regarding the Airfield, it can still be affected even if the prefabs themselves are not placed at coordinates 0, 0, 0. This is not an issue with this plugin itself. It is related to how monument-locking plugins define monument boundaries. The monument area is generated as a spherical region large enough to cover the prefabs associated with the monument. Because of this, the same issue occurs with both the free Monument Lock plugin: https://codefling.com/plugins/monument-lock and the paid Monument Owner plugin: https://codefling.com/plugins/monument-owner For smaller monuments, I would normally just move them slightly to resolve the issue. However, since this involves the Airfield, relocating the entire monument would be quite difficult. In this case, the only practical solution was to disable monument locking for the Airfield. If you create maps in the future, I would greatly appreciate it if you could avoid placing monuments around coordinates 0, 0, 0 whenever possible. Doing so would prevent this issue from occurring. Of course, I understand that this does not affect everyone, so this is only a request if it is reasonably possible within your map design. If you happen to have some flexibility when placing monuments, I would appreciate it if you could keep this in mind.

Failed to call hook 'CanRecycle' on plugin 'OwnCasinoPremium v1.7.6' (NullReferenceException: Object reference not set to an instance of an object) at Oxide.Plugins.OwnCasinoPremium.CanRecycle (Recycler recycler, Item item) [0x00000] in <2bbedefd5da74791ad7d6bd5b235d143>:0 at Oxide.Plugins.OwnCasinoPremium.DirectCallHook (System.String name, System.Object& ret, System.Object[] args) [0x003fe] in <2bbedefd5da74791ad7d6bd5b235d143>:0 at Oxide.Plugins.CSharpPlugin.InvokeMethod (Oxide.Core.Plugins.HookMethod method, System.Object[] args) [0x00079] in <42f9bedc659b4f4786eb778d3cd58968>:0 at Oxide.Core.Plugins.CSPlugin.OnCallHook (System.String name, System.Object[] args) [0x000de] in <15f61ddda771464d8246ebdce8ff4811>:0 at Oxide.Core.Plugins.Plugin.CallHook (System.String hook, System.Object[] args) [0x00060] in <15f61ddda771464d8246ebdce8ff4811>:0

For players who do not wish to participate, the "Join" button remains visible for a long time and is a nuisance. Could you please either hide the "Join" button (making participation possible only via a command) or add a "Do Not Join" button (such as an "X" button)?

There is an invisible wall at the underground entrance of the MOTEL, preventing entry. Also, for your reference: There is an Airfield located at coordinates (0,0,0). It appears that (0,0,0) holds special significance in RUST, as all NPCs and items seem to spawn there initially. Consequently, if you lock the Airfield—for instance, using a "Monument Lock" plugin—it can affect the entities spawning there. This can lead to issues, such as the Cargo Ship getting locked along with the Airfield, so I would appreciate it if you could offset the location if possible.

Apologies for the delayed response regarding this matter. The issue has been completely resolved thanks to the information you provided. Thank you very much.

I would like to report a possible issue with **AdvanceVehicle v1.6.1**. My server occasionally produces a very large number of: Main thread stalling: Write queue at capacity, waiting for write thread... When checking the logs, these stalls very frequently occur immediately after this AdvanceVehicle exception: InvalidCastException: Specified cast is not valid. at Oxide.Plugins.AdvanceVehicle+VehicleUI.Awake() at Oxide.Plugins.AdvanceVehicle.AddComponent(BaseEntity) at Oxide.Plugins.AdvanceVehicle.SetupVehicles(BaseMountable, BasePlayer) at Oxide.Plugins.AdvanceVehicle.OnEntityMounted(BaseMountable, BasePlayer) ... at RustHelicopterController.AttemptMount(...) at VehicleMount.AttemptMount(...) In the latest log, most Write Queue bursts were associated with this same exception. After checking the source, this line in `VehicleUI.Awake()` looks particularly suspicious: fuelsys = (EntityFuelSystem)_vehicle.GetFuelSystem(); This is a direct cast. If `GetFuelSystem()` returns a different fuel-system type, it would produce exactly this `InvalidCastException`. The same direct cast also exists in: getfuelcolor() VehicleUI.UpdateUI() Since AdvanceVehicle supports many vehicle types, including helicopters, boats, submarines, cars, snowmobiles, bikes, trains, etc., could you please check whether every supported vehicle is guaranteed to return an `EntityFuelSystem`? It may be safer to use type checking such as: var fuelSystem = _vehicle.GetFuelSystem(); var entityFuelSystem = fuelSystem as EntityFuelSystem; if (entityFuelSystem == null) return; There is also another small issue in `VehicleUI.Awake()`: if (_vehicle == null) { ... DoDestroy(); } There is no `return` after `DoDestroy()`, so execution may continue while `_vehicle` is null. I cannot confirm that AdvanceVehicle is responsible for every Write Queue stall, but the correlation between `VehicleUI.Awake()` exceptions and the large stall bursts is very consistent. Could you please investigate the `EntityFuelSystem` casts and vehicle compatibility, especially when used together with `VehicleMount` / `RustHelicopterController`? I can provide the full server logs if needed. Thank you.