Jump to content

Search the Community

Showing results for tags 'rdms'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Starting Zone (EN)
    • Rules & Announcements
    • General Discussions
    • Off Topic Discussions
  • Starting Zone (DE)
    • Regeln und Ankündigungen
    • Novark's Registratur
    • Allgemeine Diskussionen
  • Starting Zone (FR)
    • Règles et Annonces
    • Registres du Novark
    • Discussions générales
  • Beta Discussion
    • Beta Updates & Announcements
    • Idea Box
    • Public Test Server Feedback
    • DevBlog Feedback
    • The Gameplay Mechanics Assembly
    • Streamer's Corner
    • The Builder's Corner
    • Innovation Station
  • Organizations
    • Org Updates & Announcements
    • Novark's Registry
  • Fan Art, Fan-Fic & Roleplay
    • Novark Agora
    • Novark Story Time
    • Novark Art Gallery

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL










Found 12 results

  1. 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!
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. (Posted Friday 31th of March 2017 on the DevBlog) Hi everyone! Today we are going to talk about the organizations in a more detailed way! As usual, keep in mind this is how the organizations are planned to be implemented for the official release of Dual Universe, not for the Alpha. As it is still work in progress, some mechanics might change based on community feedback and/or for technical reasons. For the Alpha (currently planned for September), we will most likely have a basic version similar to what we currently have on the Community Portal*. Veteran MMORPG players will undoubtedly be familiar with the basic concepts of guilds and clans from other games so some of this information might feel like a review to you. However, we wanted to give a complete overview of Organizations so that even players new to Massively Multiplayer games would understand what Organizations are, the benefits of joining one, and why you might choose to create one. If you have friends who like building games but haven’t ventured into MMORPGs yet, then they might be interested in this Blog post. (*we are talking here of the current version on the Community Portal + an update scheduled to add a Super-Legate rank and many changes for Members and Legates rights) What exactly is an Organization in Dual Universe? It’s a Moral Entity able to: - accumulate “Quanta” (the in-game currency) - own Assets (Items and Constructs) - gather Player Characters under the same flag for a common goal. - create a hierarchy, with ranks and roles for all Player Characters gathered in it. - be a member of another Organization, just like a Player Character. What are the purpose and benefits of an Organization? - It enables players to accomplish greater goals than what a player could do alone: The ability to pool resources and in-game currency will help a lot. - It consolidates the continuity of a long-term project: Players can enter and leave an organization without heavily impacting long-term projects supported by the group. - It gives a political dimension to the game: Rights & Duties can be transferred from one Player to another, and Powers are decided by the Legates through a vote (if the Organization is a democratic one). - It legitimizes conflicts between several group of Players: This will enable members of different Organizations to fight between themselves and kill each other, without being the target of reprisal mechanics (like bounty hunting) if a war has been declared between the said Organizations. RDMS (Rights & Duties Management System) in an Organization: - Different actions can be done on each Asset: each possible action is defined as a Power. - Access to a Power on an Asset is given by a Tag. - Each Power has a list of Tags associated to it. - Each Player Character has a “wallet” of Tags. Here is a quick example illustrating the system: Here we have an Asset having 3 Powers: Use, Sell and Edit. The Organization is composed of 3 Player Characters: Alice, Bob and Warren. In this situation: - Only Bob can edit the Asset. - Only Warren can sell the Asset. - All three can use the Asset: 1) Alice can use the Asset through the Tag “alice” 2) Bob can use the Asset through the Tag “bob” and “squad1” 3) Warren can use the Asset through the Tag “squad2” But that’s not all: you will be able to create more complex administration rights by creating a hierarchy between Tags! Let’s say “stock_management” is the parent Tag of “ammo_management” and “raw_materials_management”. If a player has the Tag “stock_management” in his wallet of Tags, he will be able to use or manage any of the Organization’s Assets having the Tag “ammo_management” or “raw_materials_management” depending on which powers are associated with those tags. The Rights and Duties Management System is also used to create the Functions. A Function will contain various Tags defining an assignment. Let’s say that Warren gets the Function “President” in the Organization “MyOrg”. Now his Tag Wallet in “MyOrg” looks like as follow: As the President, Warren will have the ability to declare war to another Organization. A Treasurer will manage the Organization bank account , a Gunman will be able to use some (or even all) weapons and military Elements to defend the Organization, etc. Of course, we will provide standard, ready-to-use Functions such as President, Treasurer, Miner, Industrialist, Gunman, and Military Officer to save time and allow players to quickly get their Organization operational. Acting in your name or in the name of an Organization: A Player Character can be a member of several Organizations. Therefore knowing whether they are acting on their own behalf or on behalf of an Organization (and which one) is very important. We call “Role” the state where a Player Character represents an Organisation (or just himself). By default, a Player Character has at least the Role where he can represent himself. Under each role, the Player Character has a Tag Wallet. When a Player Character is accepted into an Organization, the Player Character automatically gets an additional Role where he can represent the Organization. While under the Role representing the Organization, all the actions can affect the Organization. For example: - Receive Quanta on behalf of the Organization: Quanta are transferred to the Organization - Craft an Element: the Element is owned by the Organization (not the Player) as a result. - Harvesting resources: The resources are owned by the Organization (not the Player) as a result. Example: After declaring a war that displeased most of the members in “MyOrg” (which has a democratic system), Warren has been demoted from his function of President and kicked out (Warren, what have you done? You should have consulted your guildmates before doing that!). He has now joined a new organization, “Corpo1”, as a miner and has just discovered he can act in the name of “Corpo1” or act just for himself. In the windows where he could choose his active Role for the time being, it will look a bit like this: However, keep in mind this is a simplified view of the Tags: as it will probably become quite common to have the same name for a Tag in different Organizations, the Tags will be “scoped” to avoid conflicts. Let’s say Warren is accepted again in “MyOrg” and gets the Tag “miner”, just like in “Corpo1”. To avoid conflicts, the Tags will be scoped as follow: Political Action (Vote) in an Organization: Only Legates will be able to vote. Votes could be used for administrative decisions like: - Accepting a new Member in the Organization - Excluding a Member from the Organization. - Giving a Function to a Member - Changing of the Vote rules Of course, the list of administrative decisions above is far from exhaustive. A Legate can also give his/her ability to vote to a representative (another Legate) Above, the Organization “MyOrg” has 5 Legates: Kim, Bob, Alice, John, Steve. John and Steve give their right to vote to Alice. Alice now counts as 3 votes. However, she will be absent for the next vote so she delegates her right to vote to Kim. Bob also gives his right to vote to Kim as he trusts her completely. In the end Kim will have all the votes so she will be able to make important decisions for the Organization without involving the other Legates. Big responsibility for Kim! We hope this has given you a better grasp of how an Organization will work in Dual Universe. Not all related game mechanics have been explained as it’s still currently in development, so there will be probably a second part later. As always we can’t wait to read your feedback of what we’ve discussed so far! The Novaquark team
  12. 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?
  • Create New...