HunterZ
-
Posts
358 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by HunterZ
-
@fullwipedcan you test this?
-
Make sure you're stopping your server by typing `quit` into the console and not by hitting Ctrl+C or closing the terminal window.
-
This shows only a few NREs: Vehicle Deployed Locks: Update to 1.14.1 to fix this Building Sites: Report this to the developer in a support ticket: 11:46 [Error] Exception while calling NextTick callback (NullReferenceException: Object reference not set to an instance of an object.) at Oxide.Plugins.BuildingSites+BuildingSite.GetSiteByBuildingPrivilege (BuildingPrivlidge buildingPrivileged) [0x00058] in <bfd8f968920d4b4a8735db057ad76f3a>:0 at Oxide.Plugins.BuildingSites+<>c__DisplayClass15_0.<OnEntitySpawned>b__0 () [0x0000f] in <bfd8f968920d4b4a8735db057ad76f3a>:0 at Oxide.Core.OxideMod.OnFrame (System.Single delta) [0x00051] in <15f61ddda771464d8246ebdce8ff4811>:0
-
Players don't see logs...what is the in-game symptom that they're seeing that is making them furious?
-
Not seeing this in my logs. I'll take a look but it's unfortunately going to be difficult because unlike Carbon, Oxide doesn't output line numbers to help narrow things down.
-
Some of the challenges off the top of my head: Players shooting/hitting a base to check if it's protected could inadvertently trigger an extended cooldown. Possible mitigation: Not sure, as this is extremely subjective...maybe only allow damage-based protection delay to take effect based on certain types of attack, a certain amount of damage, building block breakage, etc.... Whatever it is would need to be intuitive for players. Raiders could delay offline protection perpetually by hitting the base a it with a spear, potentially giving them hours to farm and cook boom Possible mitigation: Same as above...and/or only refresh the damage-based protection delay while the base is online, effectively allowing for a longer but still limited delay once the base goes offline.
-
I'll leave this open, but probably won't implement it...there are just way too many corner cases that would prevent it from being able to work well, and I'd end up with a ton of support requests due to confusion.
-
Changed Status from Not a Bug to Pending
-
It was reported to me that Offline Raid Protection's permissions do not show up under Permissions Manager. I found that this is true when ORP is run under Carbon, where it runs as a Carbon plugin instead of as an Oxide one. This code tweak in GetPlugs() appears to get it working: foreach (var entry in plugins.GetAll().Where(x => !x.IsCorePlugin).Select(x => x.ToString().Replace("Oxide.Plugins.", "").Replace("Carbon.Plugins.", "")))
-
Changed Status from Pending to Not a Bug
-
The Permissions Manager issue is due to the fact that ORP runs as a Carbon plugin under Carbon. Permissions Manager apparently does not currently recognize Carbon plugins. I'll report this to the Permissions Manager developer. In the meantime I suggest using Carbon permissions management facilities - it provides its own GUI via Carbon Panel.
-
This is what the "Cooldown in minutes" config option does. It's probably not very descriptively named, but it is described in the documentation. Thanks I'll try to take a look. I'm pretty sure it shows up in Carbon panel's permission UI, and it also shows up in Carbon web panel's permissions UI.
-
I would recommend not giving regular users permission to check protection status. Instead, enable sound and/or popup notifications and have players hit/shoot a base to check. This is how I do it on my server. -
I think it was maybe working for a bit, but then broke again. Unloading UpdateChecker, removing ForeverRipe from UpdateChecker.json, then loading UpdateChecker back up got it working again somehow. -
Error while compiling OfflineRaidProtection: A constant value is expected
HunterZ replied to oldmenrust's Support Report in Support
Changed Status from Pending to Not a Bug -
I'm having the same problem with Forever Ripe from game4freak. Relevant config section: { "Name": "ForeverRipe", "Author": "VisEntities", "Plugin version": "1.2.1", "Link to plugin": "https://game4freak.io/plugins/forever-ripe.46", "Marketplace": "Game4Freak", "Ignore": false },
-
Full Rust CUI anchor + offset values are provided for each individual state. To make UI scaling stay relative to vanilla GUI elements, you'll want to: Keep min and max anchor the same Set anchors to 0, 0.5, or 1.0 to anchor to screen center, a side middle, or a corner ("0.5 0" default anchors to bottom middle) Use various min and max offset values to control both offset from the anchor and size -
This is a vanilla "grief protection" feature: When a TC is destroyed, it will move up to 24 hours worth of upkeep to what I call a "shadow TC" to give players a chance to reclaim their base.
-
Actually this is a nothingburger - I just reloaded the plugin at a bad time.
-
Apps like RustPlusDesk seem to still detect when and where CargoShip and Building Blocked volumes spawn, even when they aren't getting map marker data.
-
This doesn't have a config file, you have to edit values in the code to turn features on and off.
-
One ProtoBuf.AppMarkerType value is missing: TravellingVendor
-
It looks like maybe this only blocks chat from the game to the Rust+ client - would it be possible to block things going the other way? Maybe it doesn't matter so much if map markers are disabled though, since it seems that the recent bot phenomenon mostly depends on those? Edit: Seems to be the other way around, which is fine. -
Version 1.0.2
77 downloads
What: On each composter update, this plugin composts a total number of individual items roughly equivalent to what players can achieve in vanilla Rust via stack splitting, but without regard for how non-fertilizer items are arranged in the composter. Why: As of time of this writing, vanilla composting logic composts exactly 1 item from each stack in a composter, which forces players to split stacks in order to maximize efficiency. This is annoying, and also non-intuitive due to being inconsistent with the behavior of all other item-transforming deployables at this point. How: This plugin replaces the vanilla composter update logic with the following process: Calculates a "work capacity" (maximum number of individual items to compost) based on the number of composter slots that contain non-fertilizer item stacks, plus the number of empty slots Loops repeatedly over the composter inventory, composting 1 item from each non-fertilizer item stack until either the work capacity is exhausted, or nothing is left to compostFree
