Jump to content

Let's talk about RDMS


Oxyorum

Recommended Posts

I've been wanting to write down some ideas on RDMS for some time, but I've been too busy with other stuff.

So here goes, before I forget.

 

I am going to be using the same language as the original devblog on RDMS, so here are some terms you will see and what they mean in layman's terms:

 

Functions: roles (member, mod, admin)

Powers: permissions (opening a container, accessing a computer, etc.)

Tags: a grouping of permissions under a given name (ex: tag "containers" has "open" powers for all containers, so you can open all containers)

warranty: a tag that will expire after a stipulated amount of time, or after a certain amount of money is paid

 

Ok. So, I was about to make a thread about time-based roles for RDMS, but decided to search the forums and found the original devblog on the role management and duties system. There, I found the concept of warranties, which basically did exactly what I was going to propose in the original thread.

 

Then, I thought: "What if someone doesn't just want to have a tag expire off someone after a certain amount of time, but they want the tag itself to be deleted after the time has passed?"

I think it would be very helpful if there we're some sort of temporary tag, not temporary in the sense of the tag being removed from someone its assigned to after X amount of time, but deleted instead, such that all those that currently have the tag assigned would lose it. This functionality could be added to warranties, or be its own type of tag.

 

Such functionality would have several benefits:

  • Neatness: The less tags you need to accomplish the organizational structure you are looking for, the better. You don't want it to be 2022 and still have tags you made back in 2020 because you were too lazy to look or they got forgotten in the sea of tags you actually use, especially if those tags were only to be used for a one-time thing.
  • Convenience: This functionality would make it easy to create temporary tags for one-time situations. Just make the tag, give it the abilities you want the user to have and walk away, knowing that in X amount of time the tag will be gone and you won't have to do it manually.

 

Another thing I thought about was negation powers, specifically, special powers that can be assigned to a tag which, if assigned to a player, will negate previously assigned powers for as long as the tag is attached.  Ideally, there will be a separate power that has to be assigned to an individual so that they can add negation powers to tags they make, and another power for assigning tags with negation powers to people (and also what powers they can negate). Such powers should be given out wisely, to prevent abuse by bad actors within the organization.

 

This may look counter-intuitive. Why not just remove the powers from the tag? Flexibility. Let's say that your organization has a member function, which assigns some basic powers to the members of your organization (access to containers, certain ships and areas, etc). You find that a member took items from containers where you kept items intended for new members, and sold them in the market for some quick bucks. Assuming that a) he doesn't leave or b) you don't kick him for doing this, you can greatly restrict his access without affecting the other members of the organization. You can create a special tag, let's call it "thief", and assign negation powers to the tag for access to any containers or ships, or anything else that is common access. You can then personally assign him that tag and he will effectively be restricted from taking anything for as long as you want. You can even add a warranty where he can get the tag removed if he returns the amount of money the items he stole was worth! This is just an example, by the way. I would kick the crap out of that guy and then kick him from the org, and you would too. You might say: "this is stupid. just take member function from him and assign him a function that has the same restrictions, then delete it when you are done, or not." This is true. The point of adding the ability to negate powers in this way is primarily for variety. It's about having multiple ways to accomplish the same goal, that you can choose depending on your preference.

 

Yet another thing I thought about was the possibility for lua to be used to read tags and permissions from players. One of the things that the devblog talked about was how one way you could think about powers is written down as: "power/tree1/military". I found this interesting, because this format makes it easy to expose a player's tags through lua. A rough example of the way the information can be compiled is below:

 

{
	["org1"] = power1/tree1/military, power2/tree2/administration
	["org2"] = power/tree/logistics, power/tree3/spy
  	["orgName"] = power/tagTree/nameOfTagTree -- this is an example
	...
}

 

You can then add lua code that can query the game about the permissions in any way you like. The best use for something like this would be to create very specific access mechanism where just RDMS is not enough. Let's say that you have a storage area that is shared between multiple organizations. Each organization can access the storage area on certain days of the week. Let's call then org A, org B and org C. Let's say org A actually owns the building the storage area is in. Org A designs the storage area such that it can be accessed via a button press. Since they can only set permissions on the button for their own organization (or perhaps alliance) and orgs B and C are not directly allied with them, they set the button so that anyone can press the button. Once the button is pressed, code will run on a nearby programming board that will check the tags of the person that pressed the button. If he/she is from one of the organizations that is allowed to enter the storage area, and it is their turn to enter, then they will have access.

 

The last thing I thought about, which has been discussed in the forums previously, is invisible tags. The way I see it, invisible tags should not be more than a tag that cannot be seen by the person or people it is assigned to, used for internal purposes within an organization. That being said, I have no issue with them being added to the game.

 

Let me know what you guys think.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...