ZEODE

Changed Status from Pending to Work in Progress

Hi, thanks for reporting this issue. You are not the only one to find this happening. I will be looking into this now and should release a fix later.

Changed Status from Pending to Work in Progress

Hi guys, sorry you are seeing this issue. I know the console spam is annoying but it shouldn’t change the plugin functionality. I have been out and just got back home so I will sit down and look at this shortly to address this issue.

Sure, I will work on adding it to the next update

Changed Status from Pending to Closed

You can add the command, but I would recommend adding the items to sell in shops instead of using the command. Use this to help you add the items to GUI Shop: https://codefling.com/plugins/bradley-drops?do=findComment&comment=27609

OK, I will do some testing with loot defender and that option later to see what I find. I use the plugins together without issue on our servers, but I don't use that option so I'll look into it.

Thank you, appreciate it

Hi, When I asked on the discussion page, you said setting maxlvl to 0 would disable that skill, but it's not. Am I missing something? On our servers we use a different plugin to handle all IOEntitiy power sources. Even with Electrician skill maxlvl set to 0 in config, the plugin is still affecting the IOEntities such as Batteries etc. We don't want this plugin to change any power source properties at all. It doesn't appear that there are any checks in Oxide hooks "OnInputUpdate", "OnOutputUpdate", "OnSolarPanelSunUpdate" and "OnEntitySpawned", or your methods "LoadElectricianEntities", "CheckElectricianEntities" to prevent IOEntities from being updated/changed, even if the Electrician skill maxlvl is set to 0. Having said that, it would be a lot of unnecessary calls to hooks we are not using for anything. Since it doesn't look like those hooks are being used for anything else other than the Electrician skill, it would be nice if the plugin unsubscribed from them on load if (config.electrician.maxlvl <= 0). In fact, any skill where maxlvl is set to 0 it would be great if there was a check or the hooks unsubscribed from if not being used for anything else. Is this something you will consider at all?

Thank you, all good.

0.2 is why its causing an issue with falling through the terrain. Set it to 0.5 and you will be good, 0.4 is also usually OK, but to be safe I recommend 0.5. Do you have any other plugins which control Bradley in anyway which might cause a conflict and make it not spawn?

Changed Status from Pending to Not a Bug

What are you setting for the parachute drag? If you set this too low, that is what can cause the falling through ground issue. As for the not falling from the plane issue, without more info to go on I can't really help you. I am not having anyone else report such a thing and all my testing on my test server is working fine. Maybe if you give me more info, such as any error messages in console? Is the plane actually being called in? Does a normal supply drop fall instead? Anything that might help. Also, players say a lot of things lol

it works fine, put 0.0 and it will spawn above the signal.

Changed Status from Pending to Not a Bug

I will see if there is anything else that can be done. I could easily add an option that would cause the tank to destroy any object that it collides with. This would solve this issue. I will try and add this to the next update. I am also working on improving the path finding and AI of the tank.

You can prevent people calling them near these objects by enabling the strict proximity check in the config: "Strict Proximity Check (Checks for objects close to signal, prevents APC landing on objects)": true, "Strict Proximity Check Radius": 25.0, This prevents players throwing the signal near objects within the radius you set, however, once the plane is called, players could still places these objects after to try and trap it. There is not a lot I can do about that, besides despawning the Bradley if it lands within these structures?

After looking into this more, I am noticing that the XPWeaponData.json file is being wiped on plugin load. I added simple debug code to the plugin: try { Puts($"DEBUG: Loading WeaponData..."); _weaponData = _WeaponData.ReadObject<WeaponData>(); _weaponCache = _weaponData.WeaponRecords; Puts($"DEBUG: Loading WeaponData Done!"); } catch { Puts($"DEBUG: Error, creating new WeaponData"); _weaponData = new WeaponData(); } The console output: XPerience was compiled successfully in 2570ms Unloaded plugin XPerience v1.7.4 by MACHIN3 [XPerience] DEBUG: Loading WeaponData... [XPerience] DEBUG: Error, creating new WeaponData [XPerience] Checking Config for invalid settings.. [XPerience] Config Check Complete For some reason the plugin is failing to load existing WeaponData, therefore it is catching the error and creating a new data. Then, when someone reloads their weapon with an already modified primaryMagazine.capacity, it saves this as the defaultammo amount in the data file, then each time calculates off this incorrect and increasing defaultammo value: if (!_weaponCache.ContainsKey(projectile.net.ID)) { int defaultammo = projectile.primaryMagazine.capacity; As we can see from your code, if the weapon is not in the WeaponData, then it adds it and initially uses the primaryMagazine.capacity as the defaultammo amount. This would be fine, but because the weapon is already modified, it creates this problem which is compounded each time the server restarts or plugin is reloaded. Do you have any ideas why the WeaponData is failing to load? Thanks.

Hi, the weaponry stat is currently bugged. It boosts mag size correctly the first time someone uses it. However, after each server restart or reload of plugin, the maxammo setting is multiplied again each time the plugin loads. I tried swapping the hook and it had the same result. Please see the video below: https://files.markiii-rust.co.uk/monthly/xp_maxammo_bug.mp4

Changed Status from Pending to Closed

Hey, thanks for the report! Whoops! I left it in there when I was testing some other stuff. It can be ignored and will be removed on the next update