Jump to content

RDMS Overhaul needed


Recommended Posts

I feel that the RDMS and Assets lists hark back to the first days where every player had a maximum of about 17 constructs and an org had a maximum of <300...

its far too clunky for dozen+ or hundred+ cores.


RDMS and Assets (Constructs and Territories) lists need to be leveraged here to maximise their benefits.




  • The RDMS policy rights are poorly documented with a single line of text for each. Much better documentation with examples is needed...
    • Game is still in alpha, but we need to start somewhere.




  • RDMS screen needs to have a clear list of all rights pertaining to the policy on a single, non-scrolling display and use CHECKBOXES to enable and disable the rights.
    • Remove the UNORDERED dropdown list of active policies and replace it with the single screen above.
    • When you check or uncheck a right, it changes colour to show that it is being altered and a simple press of OK or Cancel should determine application or not.
  • Management requires the ability to retrieve information rapidly and clearly
    • All lists need to be filterable by location, type, size etc. so we know how many and where they are.
    • Linking in the RDMS to the system map would be amazing, so we can see our assets on the map and drill down.
    • Allow assets




  • RDMS Needs to be include POLICY, ACTOR, ASSET, TAG,  where Asset means all constructs and territories.
    • Currently there is somehow NO ASSET TAB in the RDMS and we are still unable to assign or even view our constructs or territories tags from the RDMS manager.
    • NQ might want to allow the RDMS manager to list all the constructs and territories and assign the constructs to policies within the RDMS directly without having to visit the construct manually and add a tag to it.




  • Currently there are no Key Cards or Token access right now. 
    • There should be an asset class that when picked up or bought from a dispenser applies a tag to the holder
    • The token times out after a certain period or condition or can be cancelled by the RDMS owner.
    • Player retrieves or buys a token from a dispenser or receives one from an org member. The player then has the tag or tags applied to him for the duration of the token's existence.
      • Removes the need to manually add and remove players from the RDBMs to access assets temporarily.
      • This is perfect for guests, visitor days or test drives etc.




  • Leverage the DB. Everything is relationally linked, use those links to help the RDMS manager.
    • Currently, if you click on a policy, it shows what tags and actors apply.
    • Expand this:
      • View a list of all players that have rights in the RDMS.
      • Click on a player to see what Actors they belong to and what policies they are part of.
      • Click on an actor to see what policies they are part of.
      • Click on a tag to see what policies its used in and what assets its tied to
      • Click on an asset to see what tags are assigned and what policies its used in.
      • Click on an asset and reveal it in the map.




  • The RDMS has currently no way to deny or create exceptions. This means that additional policies are sometimes needed for subtle differences in access.
    • Add a tag to an element to REMOVE a particular right... for example #NoNoobs
    • We might want to temporarily deny certain rights in one policy without influencing a whole cluster of other policies or recreating groups from the ground up. Exceptions are essential here, like denying ALTs access to certain key assets.
    • This can also be useful in panic situation where a quick response is needed. Just deny first and work out the details later.
  • While constructs have the ability to remove inheritance from their parents, the RDMS does not have this. If you assign a right to a construct, everything ON THAT CONSTRUCT also inherits the right automatically.
    • Setting inheritance to only certain assets on a construct would be useful for example:
      • Public use extends only to furnature types but not combat types or containers.




  • Tags and to a lesser extent Actor groups have been shown to be more flexible but ultimately harder to manage and more importantly KEEP ORGANISED than simpler folder/directory structures.
    • Give players the ability to group constructs logically in folders and allow application of RDMS to folders and subfolders.
    • Give players the ability to group players logically in folders and allow application of RDMS to folders and subfolders.
    • The RDMS manager can then create folders such as public assets, high security, private etc.





  • This is linked to the above ACTORS section: There are only currently three org ranks formally defined. Superlegate, Legate and Member.
  • The Member part needs to be expanded to allow additional, org defined roles with more granularity than just MEMBER.
    • Rank policies assigned by rank.




  • There is currently no method to test any policies
  • RDMS cascading rights viewer is needed
    • Because cascading or inheriting rights from multiple policies is possible, we need to be able to select a construct or player from the RDMS list and view EXACTLY what rights are active or denied. Much like the CSS viewers on any modern browser that show all the applicable CSS attributes from all the cascading rules. Or the Windows active directory permissions viewer which shows actual and inherited rights.
  • Effect Viewer
    • If we change a policy, we need to see exactly what actors and assets will be influenced
    • If we can match a player or actor to an asset and see exactly that that actor/player can or cannot do, it would save a lot of heartache.
  • Construct overview
    • We need to be able to select a construct and see who has what rights and more importantly, VIEW ANY RDMS tags that have been applied to elements on that construct. It's all too easy to overlook a container hub with public rights or a dispenser that is only available to legates.
  • Element rights viewer
    • At a construct level, we need to be able to right click any element and view EXACTLY what rights pertain to that element including inherited rights from the parent construct.




  • RDMS needs to include asset visibility right to allow non legates to view constructs on their maps.




Why is this important? 

Link to comment
Share on other sites

As an professional software developer I am used to dealing with complex data structures and dev software.

But whenever I try to use the RDMS in DU, I am never quite sure if it is doing what I think (hope) it is should be doing.

Link to comment
Share on other sites

@CptLoRes  I’m in the same boat. I was an active directory and Open LDAP administrator back in the day and before that taught RDBMS theory and data integrity courses at a university. 
I was thrilled when the RDMS was released but very disappointed by the clunky interface and the complete lack of interrogation tools. 
And also by the COMPLETE LACK of an asset tab leaving us unable to dynamically assign tags or confirm assets’ RDMS status  

heck we can’t even test our own builds while “pretending” to be just an org member, from another org or even be a member of the public without org standing.


without testing tools the RDMS is just another MP15 waiting to happen. 


I will say though that the philosophy behind it appears thorough and sound, it’s the implementation that is in need of some C&A. 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now

  • Create New...