Jump to content

Oxyorum

Alpha Tester
  • Posts

    124
  • Joined

  • Last visited

Everything posted by Oxyorum

  1. You can just buy the pledge you want to upgrade to. You should be charged the difference between your current pledge and the one you are buying. This is assuming you bought your first pledge on the website and it wasnt a kickstarter pledge. I am not sure you can upgrade those. Contact support@novaquark.com to ask them if you can and how.
  2. In his defense, that's literally what the red "2" means. It means you have 2 unread messages.
  3. Welcome to Dual Universe! happy to have you with us
  4. For now, yes. You can be sure that test times will be much longer as we get closer to release, and eventually the servers will be up 24/7. If you pay the $120, you will have access starting with next week's test, which will last 48 hours. You can always check the test schedule at the server status page.
  5. No. You are good. You just need to contact support at Novaquark Support or send them an email at support@novaquark.com asking for access to the alpha section.
  6. Hello, MisterDoge. Welcome to Dual Universe.
  7. Welcome to Dual Universe! glad to have you with us
  8. Welcome to Dual Universe! glad to see we have some celebrities taking interest in the game
  9. Yeah, lets not make wild speculations about things that are not public knowledge. I am positive that we will have alpha 1 by the end of the month as stated by NQ and if there is any reason to change the schedule, we will know ahead of time. Another thing to mention is that Novaquark has not stipulated which founders will be let in at which time, something which they said would be stated before Alpha 1 was released.
  10. Welcome to Dual Universe! glad to have you on board
  11. Welcome to Dual Universe! glad you could join us, we are accepting of even the most virtual of beings
  12. Welcome to Dual Universe! glad to have you
  13. Its a permissions system to control who can interact with your things, not a shield. It can't stop someome from destroying your stuff - use a TCU or build in a safezone.
  14. 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.
  15. Welcome to Dual Universe, Kartam! glad you could join us
  16. I understand where you are coming from. I would not favor things that affect the social aspect of the game negatively. However, I don't believe that having RDMS in the game will decrease player interaction. It is necessary, especially when handling large organizations with hundreds of members (see the first page on the community portal) of which there could be a number of spies or other bad actors. Trust me, there will be plenty of player/org cooperation, with or without RDMS.
  17. Well, Novaquark is going to implement a way to handle stuff like this in a comprehensive way. So, why not use it? I mean, you could do it just by mutual trust and without using RDMS. However, this would probably only work with real life friends/family, in my opinion.
  18. Welcome to Dual Universe! good to have you with us
  19. This is an excellent idea. I would think, however, that if RDMS is going to be as extensive as we are being lead to believe, we could probably have the organization for the building, and have those who manage the building as the only actual members (all legates probably). Then, they can give roles to tenants and whoever else they want. This is all assuming that orgs can give temporary roles to people that are not members of the organization.
  20. A skeleton to attach cores is not very practical. In my opinion, its redundant because any one of those cores could manage the whole building most likely. Why not have one core for the entire building, along with the rooms made with voxels and RDMS control for each room? I don't think that cores will have a limit to the amount of voxels/elements attached to them.
  21. I agree with @ShioriStein. RDMS can be used to sort this out. You can assign special roles/rags for each residence, and only the tenant of said residence would be able to affect the residence itself. This way, you would only need one static core for the entire building while still providing access to the people who pay to live there (and JC already confirmed that there will be the ability to charge people monthly or weekly with RDMS).
  22. Core units already have standard sizes, as is shown by some of the earlier videos. There is no need to "standardize" them. As for standards in general, I am positive that there will be use of them when the game is released. Standardized landing dock sizes, standard road sizes and standard rules for flight in cities are some of the possibilities. Standards can be helpful for travel between cities/jurisdictions as well as trade between players. I do not believe that the game's architecture would allow for merging of constructs (grids) together in the way you are describing. I am pretty sure that we will be able to delegate work to other organizations, but not for modules. In practice, an organization will be able to use RDMS in order to allow other organizations to work on their buildings/ships, bringing their expertise and compensating them for their work.
×
×
  • Create New...