Jump to content

RDMS Question


Musclethorpe

Recommended Posts

The hierarchy is actually rather logical but at the same time it is explained very badly because a dev, who would understand the mechanic, designed the UI. Generally in such a case, the dev would take knowledge for granted and/or believe that all this detail is needed. And while it makes perfect sense to him/her, they fail to realize it may not be so obvious to "your average user"

 

Right now, the element you are looking at would have rights applied to it which are set on an element (or the construct itself) it a child of and the hierarchy you see shows you how these rights work their way down to the element you look at. You can choose to remove this element from that dependency so it no longer has the (parent's) rights applied to it by using "uncheck all".

 

What makes this bad UI/UX design is that there is too much information there which is really not relevant to the player. A single checkbox "Exclude this element from applied parent's rights" would do the exact same thing as the entire section, be all the information the player needs, take up way less space and be much more obvious in it's function.

Link to comment
Share on other sites

44 minutes ago, blazemonger said:

The hierarchy is actually rather logical but at the same time it is explained very badly because a dev, who would understand the mechanic, designed the UI. Generally in such a case, the dev would take knowledge for granted and/or believe that all this detail is needed. And while it makes perfect sense to him/her, they fail to realize it may not be so obvious to "your average user"

 

Right now, the element you are looking at would have rights applied to it which are set on an element (or the construct itself) it a child of and the hierarchy you see shows you how these rights work their way down to the element you look at. You can choose to remove this element from that dependency so it no longer has the (parent's) rights applied to it by using "uncheck all".

 

What makes this bad UI/UX design is that there is too much information there which is really not relevant to the player. A single checkbox "Exclude this element from applied parent's rights" would do the exact same thing as the entire section, be all the information the player needs, take up way less space and be much more obvious in it's function.

I believe I understand your explanation. By the sound of it, if I want Random-Person to be able to use this screen by simply assigning them as an actor in my "Passenger Policy" I should "Uncheck All" and uncheck "Use Construct Rights", as by default those are set only to me. Am I picking up what you are laying down?

Link to comment
Share on other sites

You can also set up tags to apply to screen only.

Create a Simple tag, say "Passenger Access"

Create a Composite tag, select the "Passenger Access" as main tag

Type "screens" as Precision Tag

 

You will now have a "screens@passenger access" tag

 

You can now set up the policy for this precision tag and apply the main tag "Passenger Access" to the construct. It will now allow passengers to access any screen in any area they have access to without you needing to add this tag to all screens separately. Passengers  will not have access to anything else in this case, just the screen on the construct they can get to. You would use the "doors" precision tag to set which doors they can use and "chairs" to allow them to sit down in chairs but not control seats.

 

So you add only the main "Passenger Access" to the construct and that will apply all precision tags you set up "under" it which would allow you to make changes without needing to go through all elements separately and set new tags.

 

 

Another example is that on an org base you can use this to allow org members to use all industry elements but not access containers unless you set specific rights to the ones they should ba able to access.

 

To go back to your screens for a moment.. What the "items hierarchy" shows is what a tag would affect, In case of "Screens", their parent is "Displays" which would also be where "Signs" are under.. so a "screens@access" tag would only apply screens, but a "displays@access" tags would apply to both screens and signs.. 

 


I hope that still makes sense ;)

 

 

Link to comment
Share on other sites

21 minutes ago, blazemonger said:

To go back to your screens for a moment.. What the "items hierarchy" shows is what a tag would affect, In case of "Screens", their parent is "Displays" which would also be where "Signs" are under.. so a "screens@access" tag would only apply screens, but a "displays@access" tags would apply to both screens and signs.. 

 


I hope that still makes sense ;)

 

 

Hmm, sorta. Trying to keep things simple, and my ship isn't very big, so I don't mind doing this on an element by element basis. For this case specifically should I, or should I not, uncheck either or both of those options if I want my passengers to have access to that screen specifically?

 

Thanks for all the help by the way.

Link to comment
Share on other sites

8 minutes ago, blazemonger said:

If it's a small construct, just do not set permissions on the construct at all and add tags to the elements individually.

 

In general yes, if you uncheck, any permissions set on a "higher level" will be ignored for that element

Yeah, I wish that "Use Construct Rights" button wasn't defaulted on. I have made no alterations to the construct rights in any form. Thanks again!

 

Edit: By the way, does anyone know if I allow a person access to use a Detection Zone, will that allow them to trigger it, which then opens a door they normally could not directly?

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...