ZEODE

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

Changed Status from Pending to Closed Changed Fixed In to 1.0.31

Hi, thanks for the report. Can you let me know when and how often this is happening please? Do you know which items you are trying to stack when you get this error?

Changed Status from Pending to Closed Changed Fixed In to 1.0.23

Changed Status from Pending to Closed

Ooops, ty

Ваша конфигурация выглядит хорошо, нужные вам настройки установлены правилЬно. Кажется, у вас естЬ еще один плагин, который управляет разблокировкой ящиков для других игроков? "Lock looting crates to owner": true, "Unlock looting crates to others after time in seconds (0 = Never)": 0, Это хорошо, так что должен бытЬ другой плагин, разблокирующий ящики.

Привет, если игрок не атакует вертолет в течение определенного времени или слишком долго прячется от вертолета, он отключится по умолчанию в Rust. Существуют и другие параметры конфигурации, которые также могут повлиятЬ на это, пожалуйста, опубликуйте свой файл конфигурации, чтобы я мог вам помочЬ.

Changed Status from Pending to Closed

Did you find anything? Are you still having this isue?

Locked crates is doable yeah, nobody else has asked for them and I haven't even thought about adding them either, but I think that would make a good addition. I will add that to the next update. Supply Signal Alerts is a very old plugin, but very simple so not much can go wrong with it in the 5 years since it was updated. I wrote this plugin to be compatible with Inbound, which a lot of people use. But if you want to carry on using SS Alerts, you could just open SupplySignalAlerts.cs in an editor and change this: if (!(entity is SupplySignal)) to: if (!(entity is SupplySignal) || entity.skinID != 0) That should make it only announce for normal Supply Signals.

Changed Status from Pending to Not a Bug