This would be fantastic. I love that idea.
I've read that "named permission" would be pretty memory demanding. I'm not sure that permission that simply restricts use to the owner, his faction, his allies, or opens to all would be as demanding as named permissions though. Part of why this approach seems feasible. The station issue had occurred to me as well. My thinking is that station build permission would override the module since the editor could delete it. Otherwise it opens the way to troll station owners with blocks stuck on their base by someone who had been kicked. Basically if you own a station you should be the only one editing it anyway or you expose your whole faction to risk already. And if a faction can't trust their leader, then that's something no module can solve. But permission mods can at least solve major problems for public factions and less frequent "ship borrowing" and storage theft problems in private factions.
This is kind of what my OP said, except I think mixing it into the faction permissions is the wrong way to go. Just make the current "Faction Permission Module" into a generic Permissions Module that lets you either Private, Faction, Allies or Public whatever you stick it to. This way it solves issues for factions AND is usable by individual players not in factions.
(Note: If you're not familiar with database design then the following 3-5 paragraphs are going to sound like gibberish. If you have questions regarding how relational databases work direct them to Google, or go read a book on Microsoft Access or something.)
I really don't see how individual permissions is that demanding. The players are identified by a specific id, and are marked as members of a faction (including factionless players since they are considered part of the "null" faction), which is a one-to-many relationship - in other words, you have your "faction" tale with faction ID's as your primary key, and your "player" table which has player ID's as a primary key, and a parameter that uses an ID from the "faction" table to associate the player with their chosen faction (including a "null" ID for factionless players).
So in other words, when a player tries to screw with a block on a factioned structure, the server makes a query to its internal database to find the faction ID of the player. This involves querying two tables: "player" and "faction". It then takes that result and checks it via boolean operator (X == Y), and if the check returns false it doesn't let the player do what they are trying to do.
On the other hand, if you were to have individual blocks that store the id of an individual player, then the server would only need to query the "player" table; in other words, that is one entire database table less to query a player's individual ID as opposed to querying their faction's ID. So with this assumed scenario in mind, how the hell does individual permission blocks use more resources than existing faction blocks? It makes no sense to me.
That aside, individual permissions is a thing that needs to happen. We can use the existing hiearchy of faction module and permission module, with faction modules affecting the base permission level for the entire structure, and permission modules overriding those but only for the blocks they are connected to. All we would need to do is set the individual permission system to work the same as the faction permission system; when you first set a faction module down it is blank, you have to activate it and hit "Enter Faction Signature" to make it work. What it is doing is most likely storing your faction's ID in that block's "memory", so that it can run the faction check query when someone tries to use stuff. Individual permission blocks would work EXACTLY the same, only storing your player id instead. Think of it as like a fancy high-tech apartment complex or something where they use fingerprint scanners instead of traditional locks. You have to initialize the system by scanning your print; once you do it's tied to something that is uniquely identifiable to you. This would be useful for having personal facilities e.g. maybe a room with a few storage chests, a small factory system and of course your own parking spot in the hangar bay. The only thing I can forsee causing performance issues is that individual blocks would be used more often than faction blocks; but like I said, only one DB table to query instead of two, it really shouldn't be that noticeable of an effect.
Quoting myself from
a different thread:
I also think you should have an option for making the permission block generate a logic signal if the rank requirement isn't met.
For what it's worth, binding a block (like a shop) to one player requires substantially more information than checkboxes. Shops can afford that because they have full inventories which use up tons of memory anyway. Also, what happens if I have high enough permissions to get in a build block and destroy your permission block?
One solution is reserving some segment of faction ids for stuff owned personally by a player, independently of faction alignment; allowing you to create stations and ships that you personally own (and not your faction). In addition to the "Enter faction signature" option on faction blocks, you would also have "Enter personal signature" or something to that effect, which binds the grid to you and you only instead of your faction.
So yeah, basically this.
Also, Monchoman45 your idea of having a "pay to access" permission setting is, if you'll forgive my NSFBBC language, bloody brilliant. It opens up a whole new sector of the economy, namely services. We can have stations that are literally road-side motels/service stations, where you can pay to have a parking spot and a room with basic factory access for a few hours, and also possibly a shipyard and/or repair service.
