MON@H

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

Changed Status from Pending to Cant Reproduce

My answer remains the same: I can't reproduce the problem you described. I suspect you have another plugin causing it. Until you provide me with more detailed information so I can reproduce the issue, I can't help you. How can I "fix what isn't broken"?

Changed Status from Pending to Not a Bug

I can't (and shouldn't) control what entities other plugins are spawning. Limit Entities plugin is using hooks: CanBuild - to prevent player from placing an entity OnEntitySpawned / OnEntityKill - to track spawned/destroyed entities. Tracking entities relies on OwnerID, so if this field is unset (OwnerID == 0) when entity is spawned (entity.spawn()) it will be ignored. My guess is that's what happens now. If you want these entities to be tracked, ask author to set entity.OwnerID = player.userID before calling entity.spawn(). This will make them trackable by Limit Entities. However preventing players from spawning entities (to respect the limits) is a bit more complicated, the "easiest way" atm is to call LimitEntities.Call("CanBuild") or you may ask author to reach me if he need some specific api call, I can add it.

Call IsBasementEntity when each entity spawns, instead of changing the owner field after the entity spawns? - Optimization? Never heard of it. I mean, I can implement this check, it will only affect those who have this plugin installed, but I suggest going down the path I suggested.