Something I think would be a very useful addition to an admin's arsenal is to add optional mass and entity count restrictions to /sector_chmod commands such as +noenter and +noexit. Being able to restrict mass in specific systems and sectors would allow among other things settings only favoring small craft over capital ships for example. The establishment of non titan areas in the systems around spawn or in areas where large and numerous objects would not be appropriate also comes to mind.
This is something that could be a huge game-changer for servers as now they would be able to more effectively and specifically direct player activity in a way that is like terrain. Players could adapt to these geographic pockets by using smaller craft for example.
Ok, here's a good example. Lets say I want my spawn station and the system around it to be mass and entity limited so only ships and stations built there or entering can be 4k in mass and no more than 16 entities. I type in /system_chmod (system coordinates) +noBuildOver 4k. 16entities I then put in /sytem_chmod 0 0 0 +noEnterOver 4k.
In short:
Add a /system_chmod command with the same current functionality as /sector_chmod
Give additional function to /sector_chmod, /system_chmod commands allowing restriction by mass and entity count
add new specific conditions such as +noenter and +noexit with an under/over mass and entity count component ie. +noenterover (ship mass). An important additiona to this would be a +nobuildover component which would prevent ships and stations from being built over restrictions within the exclusion zone.
I like this! There could be a lot of uses for server admins to use this new functionality.
However, I would recommend creating new chmod values for each type of restriction, to avoid any sort of confusion.
Examples:
/sector_chmod 2 2 2 + noentermass 5000
/sector_chmod 2 2 2 - noentermass
/sector_chmod 2 2 2 + noexitmass 10000
/sector_chmod 2 2 2 - noexitmass
/sector_chmod 2 2 2 + noenterentitiespership 16
/sector_chmod 2 2 2 - noenterentitiespership
/sector_chmod 2 2 2 + noexitentitiespership 32
/sector_chmod 2 2 2 - noexitentitiespership
Separating out the values allows for easy changing of the values because it removes ambiguity. For example, let's say it was implemented as additional layers of "noenter". Then a person might type "/sector_chmod 2 2 2 + noenter mass=5000 entities=16". This is all well and good, but what if they then type "/sector_chmod 2 2 2 - noenter"? Is this supposed to remove any mass and entity restrictions or just the catch-all "noenter" value, leaving the mass and entity count restrictions alone? This also complicates the error messaging if a player enters the wrong amount of arguments, or uses invalid arguments. The error messaging would have to determine all possible scenarios and then have a cohesive error message returned. Keeping it simple would allow for more easily understood error messages.
I definitely like the /system_chmod addition! Right now it is incredibly wonky trying to set up large custom areas with /sector_chmod. Literally hundreds of sectors have to be set to +noenter and +noexit surrounding a system in order to prevent people from jumping out (or jumping in). Additionally, the higher the jump distance on a server, the bigger this box needs to be. This makes it virtually impossible for servers with higher jump distances (like 80). How can they have things like an event sector where players battle it out, but are trapped inside of that one system? Or what if they want a special system next to spawn just for new players that has custom settings and pirate spawning? Even for servers that have lower jump distances, such as the default of 8, having 8 layers of sectors surrounding a system set to +noenter and +noexit creates a really awkward overlap that will effectively make all surrounding sectors (26 of them) mostly-useless and confusing for players to navigate around. Half those systems will have to be blocked off from players, making them useless.
But in addition to these new features, the dev's also need to fix fleets and how fleets navigate through sectors with no-enter and no-exit. Right now fleets can easily go through any area that is set to no-enter or no-exit when the sector unloads. And even when the sector is loaded, they push through the barriers. Now, make it so the fleets do not attempt to leave a no-exit sector should be relatively easy. Also make it so they do not attempt to try to move TO a sector (or system) with no-enter set should also be relatively simple. But what if a fleet is told to move from a valid sector to another valid sector, but there is a noenter or noexit sector or system in their path? This would require the StarMade server to calculate the trajectory of the fleet and then check all sectors and systems in that path, then if detected, it would need to figure out a custom path OR cancel the order and inform the player that the path is blocked. Informing the player that the path is blocked, however, is problematic because players cannot see which systems are set to no-enter or no-exit (and perhaps they should not be able to see this either). I think the ideal situation here is to have it so fleets automatically move around the system or sector, but also informs the player that the flight path was blocked and maneuvers around the area had to be done. Another complication that would need to be handled is if a fleet is already moving, and an admin then blocks the path. The fleets would need to recalculate their trajectory for every sector change, because if they are suddenly blocked, then they would need to recalculate or simply stop moving. For example, if they enter a sector or system that has no-exit. Sure they can move into the area, but since they cannot move out, then they need to stop moving and provide feedback to the player. Some people might think I am going a bit overboard here with this, but really I'm not. This functionality should have been implemented when fleets were released, because noenter and noexit chmod values existed prior to fleets and there needs to be support between the two.
