Search the Community
Showing results for tags 'rdms'.
-
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. DOCUMENTATION 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. UI 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 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. TOKENIZED TAGGING 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. DATABASE RELATIONSHIPS 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. DENIAL / EXCEPTION / INHERITANCE 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. FOLDERS, TAGS and ACTORS 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. https://asistdl.onlinelibrary.wiley.com/doi/pdf/10.1002/meet.2008.1450450214#:~:text=Tagging permits a many-to,accessed again later by either. here is an (oldish) research paper discussing the relative merits of folders and tags and came to the conclusion that having both is better than either since we all work and think differently. ORG RANKS 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. TESTING 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. ADDITIONAL RDMS needs to include asset visibility right to allow non legates to view constructs on their maps. Why is this important? NEVER FORGET MARKETPLACE 15!
-
I did not see a way to post into upvote and did not see this feature suggestion there or here. It would be nice in the RDMS to be able to target Org Legates vs Org as a whole. Currently you have to manage rights by creating an actor that contains multiple members and adding/removing people from that. If you could target Org Legates in addition to the org that would keep Org leadership from having to create somewhat convoluted RDMS rules. Bonus points if we could have multiple levels in the org beyond just "member", "legate", and "super legate". And be able to target those from the RDMS. That way as people progress in an org you would have the ability to grant access based on the level of progress somewhat automatically.
-
I added this to the Upvote site, but I will also post it here for discussion: Players logging off on other people's constructs is a problem, for numerous reasons. Players that log off on someone else's construct should be "kicked off" the construct. When a character logs out of the game on a construct that they do not have permissions for (defined either by a construct-wide RDMS right similar to Board Construct, or by applying Use rights on a "Security System" element), their character should be moved outside the build area of the construct and their physics should be de-parented. There should be a way for the player to know their right status on a construct before logging off to avoid confusion. When not in the safe zone, the security system could become lethal instead.
-
Idea: Add 20 more rights to RDMS system for each build mode tool and it's negation (the alt key). Perhaps add an expanding menu to keep rights UI simpler. Why: A good sandbox game is one where cooperation and organization among players is rewarded. With respect to industrial complexes, the game is already struggling with making teamwork necessary, let alone encouraging it. Current RDMS system is one reason why teamwork is discouraged. Mega factories take a lot of time to build, and build right to delegate building. The build right is too powerful right now. Someone can scoop your entire factory and go with it. We'd want new recruits to work on the large factory projects. But trusting one of your legates let alone a new recruit with your 150+ hours building the thing is impossible. Now, if we could limit some rights while handing out some, that would solve at least the discouragement. Perhaps we want people to be able to add machines and links, but not remove them. Perhaps we want them to add and remove machines, but keep cosmetic the voxel-work intact. Perhaps we want them to just link everything we put down. The new granular system would allow us to at least trust more people with mega factories. This would make teamwork on factories at least possible, then NQ can focus on making it rewarding as well.
-
Basically I can't find the option in the RDMS that I can use to prevent members from unclaiming items. It seems like every org member can unclaim items.. How do I prevent that? Can I create a sub-org that I claim the items for? And then how do I allow industry to work with these claimed items? (I know about the difference between unclaiming and stealing.. Stealing would atleast result in a notification) Thanks in advance.
-
Hi all, I had a quick look and didn't see a post for this so apologies if there is already. Played a little last night and found that adding every single right to a policy is time consuming. Can we get an 'Add all' button? Additionally, is it possible to create sub headings? For example, rights that are to do with territories would have the Territory sub heading, or things to do with machines, vehicles or other objects might have something else like Vehicles or Objects. Then each of these sub headings can be bulk added to a policy as well? Just an idea? Would love to hear other people's opinions. Thanks, HG Dan
-
It would be useful if construct owners could permit specific players to build only in specified zones of a construct via RDMS. This would be especially useful in, say, an apartment complex, where you could allow a resident to edit and furnish their apartment and not any other part of the complex. Construct owners wouldn't have to find workarounds like splitting it up with multiple core units, for example.
-
what I'm talking about here is essentially being able to trade permissions for specific parts of a construct in exchange for money or whatever. these permissions would have a time limit on them, and (crucially) the person who owned the construct would NOT be able to modify those permissions until the time limit expired. one example of this would be a parking lot/hangar bay in a city. if I wanted to park my ship inside a hangar bay I would purchase the permissions to open and close the main doors, toggle lights, open some storage inside the bay, etc. if I just wanted to stay there for the night then I would only buy 24hrs worth of those permissions. during this period the owner of the building that has the hangar bay would not be able to open the door or toggle the lights or open the storage etc, and would not be able to modify the permissions or delete the construct/elements until the 24 hour period expired. perhaps to enable this some option would have to be enabled in the RDMS settings, as to prevent new players from accidentally selling their homes to random players for 999,999,999 hours for 1 quanta.
-
Hi everyone. Until now, we couldn’t manually manage (remove/promote) Legates in an organization easily on the administration side. Since Yesterday, we are able to use a feature simplifying considerably the process. As we already mentioned many times in the past, we (Novaquark) don’t want to involve ourselves in the management of organizations created by players. However, we are also aware that the current (and temporary) state of the management system contains obvious flaws. You know it. We know it. As this is still “work in progress”, we hoped that organizations creators will be reasonable enough to avoid abusing the well-known flaws of the system and would wait that all the rules are implemented before trying to sabotage other organizations. So we are going to state the obvious here: It’s ok to “play a bad guy” and use dirty tricks once all the rules are implemented. However, it’s absolutely not ok to start exploiting the flaws of a work in progress system: this is not “playing a bad guy”, this is just toxic behavior and trying to gain an advantage while not playing by the rules. That’s why - despite our will of non-involvement - we will make exceptions until the full implementation of the RDMS (Rights & Duties Management System) for the Organizations. Why did we decide to intervene? Two reasons: 1) In the current state, a Legate has much more power than in the final system, due to the minimalistic mechanisms temporarily in place. If in the current system, any Legate has the right to promote a member to Legate status by himself alone, in the final system the default rights will be completely different: promoting a legate will be done only with a vote by majority rule, or the right to promote someone will be given to specific persons and not every Legate. 2) In the current state, a Legate cannot be demoted by any mean (even by the creator of an organization). In the final system, default configurations will allow to demote a Legate with a vote by majority rule. A Legate could also be demoted by specific persons who have been given the right (most probably by the Organization founder) to do so. How is this going to work? Each organization is going to have one "wild card": if there is a problem with the Legates in an Organization, you can contact the support team at support@novaquark. However, keep in mind we (Novaquark) reserve the right to intervene (or not) on a case by case basis. Example of a case where we will intervene: Some Legate using the flaw of the current temporary system to vandalize (or generate troubles in) an organization. Example of a case where we won’t intervene: Two organizations have merged in one, and now both creators of previous organizations want to mutually exclude each other from the organization. In this kind of case, we won’t remove anyone. We won’t favorize one creator above another. However, we will do our best to help finding a satisfying solution for both parties. As a global reminder: If someone finds a loophole in the rules in place (that may happen), and this loophole is used to generate trouble and spread a toxic behavior, we won’t stay idle watching the situation deteriorating. Best Regards, Nyzaltar.
-
- rules
- organization
-
(and 2 more)
Tagged with:
-
I would like to know if RDMS will allow us the concept of Holding Organisations and Subsidiary Organisations. Case 1: When a single person owns both the holding organisation and subsidiary organisation. Case 2: When the owner of both the holding organisation and subsidiary organisation are different.
- 4 replies
-
- RDMS
- Organisations
- (and 4 more)
-
Rights and Duties Management System (RDMS) will be one of the very powerful customization systems in DU. Read the DevBlog here if you have not already. Effectively tags can be used to give access to assets etc etc. I assume that in the current RDMS system, a player will know what tags he/she has. Effectively these are like keys to a spaceship or passcard for a door. The suggestion of this topic is that a tag can be placed on a person without their knowledge. These invisible tags would not be able have duties connected to them because this could lead to a player losing money without knowing about it. The uses for this are also quite broad. For example: it could be used to not only tag intruders but to keep track of the intruder long after they have left. This has an additional effect that invaders would need a hacker to look at their hidden tags and clean out any unwanted ones. What would you use invisible tags for?