MON@H

Changed Status from Pending to Not a Bug

Why are your groups empty? Have you tried deleting them? If so, you can't use them in the "Limits Entities" lists because they don't exist (they weren't created by the plugin). Therefore, you can't use, for example, "TC"; you can only use Rust prefabs. LimitEntities.json

How exactly are you Using vanilla hammer or some custom plugin? In any case the plugin itself is not an issue. Try it on server without any other plugins and you'll see it's working just as expected. Most likely you have a custom plugin that preventing / avoiding to call OnEntityKill hook, which vanilla Rust does when destroying any entity and this plugin depends on it.

Changed Status from Pending to No Response

Attach your config. Have you tried to reload the plugin? Also you may want to set "Log Level (Debug, Info, Warning, Error, Off)": "Debug" then reload plugin and see more details in log file in /oxide/logs/LimitEntities

Changed Status from Pending to Not a Bug

There is an option in config to prevent that: "Prevent excessive merging of buildings": true What exactly do you mean by "bypass foundation limits entirely"?

Changed Status from Pending to Not a Bug

Make sure you have installed https://github.com/dassjosh/Rust.UIFramework/releases/latest

I'll add it into next version

Changed Status from Pending to Not a Bug

As I mentioned before, this plugin doesn't control the behavior of other plugins in any way. It works straightforwardly, preventing the creation of entitis above the limit. This plugin is using "CanBuild" hook and returns "false" to block entity creation. However, any plugin can create an entity while ignoring this hook. So, it's a matter of whether the developer wants to allow other plugins to prevent creation first. If so, they need to monitor this hook and not create entities if CanBuild returns false. If the developer doesn't want to monitor anything, they simply create the entity. We've already discussed this here right? Nothing has changed since then.

Changed Status from Work in Progress to Closed

Changed Status from Pending to Work in Progress Changed Fixed In to Next Version

https://youtu.be/6ai5UsQo8a4

I need a more recent error to look into it. That client version is too old and the method names have changed.

The “ReceiveFogOfWarImages / IndexOutOfRangeException” disconnect is not caused by Limit Entities. That stack trace is a client-side exception in BasePlayer.ReceiveFogOfWarImages (Hardcore fog-of-war RPC). Limit Entities does not touch fog-of-war, PlayerState.fogImages, map markers, or any RPC payloads. It only tracks/limits server-side entities (build/deploy) and may deny placement at build time. On the server, the fog-of-war RPC is sent using the saved PlayerState.fogImages list. If that list is corrupted (not exactly 16 entries), the client can throw IndexOutOfRange and disconnect when it processes ReceiveFogOfWarImages. So the likely root cause is a corrupted fogImages list in the player’s saved state, or another plugin modifying PlayerState/map/fog-of-war data. Limit Entities is not in that path. If you still think Limit Entities is involved, please provide a server-side stack trace pointing into LimitEntities.cs, or reproduce on a clean server with only Limit Entities and no other plugins.

Perhaps you want to start from here https://umod.org/documentation/plugins/permissions Then check this out as well

Changed Status from Pending to Not a Bug

Like I said, please read description page carefully

Use English, please. Also make sure you read description page carefully