Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

Everything posted by Oxyorum

  1. Welcome to Dual Universe! good to have you with us
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. Just my two cents, In my opinion, for any standard, the key will be to define the standard in such a way that it can be implemented in any number of ways by organizations that choose to adopt it. That way, individual organizations or players are responsible to ensure that they are adopting the standard effectively and neither are constrained to a hard set of rules that they may not be comfortable following. It will be best to define things in terms of limits that NQ have placed on various things, which we will know by release. For example, let's say that someone wants to make a standard for communications while docking. Let's say that the organization wants everyone that wants to land to use a specific encryption solution that they have written. Who is going to land at their spaceport? No one, because who knows what type of weirdness might be in that code (tracking code, killswitches, etc), especially if it can access the internet. The better way would be to say "all pilots need to use X encryption algorithm". Let's use RSA for our purposes. All organizations that want to adopt the standard can either get an implementation from the internet that they trust, or write one. Then, when a player wants to land (assuming they can also encrypt using RSA - they are responsible for ensuring that they can), they can ask the spaceport for its public key and then, having received it, begin the docking process. This is just an example. Ultimately, it will be up to individual organizations to decide whether they want to follow any standard at all.
  7. Yeah, my bad. I ended up getting mixed up. Also thanks for finding the actual source for the probe stuff. If we are talking about FTL drives specifically: I agree. For FTL travel with drives, perhaps something like a beacon can be placed down in space. This beacon would allow a ship to lock on to it and then initiate FTL travel to that location. People have to physically travel to the beacon location in order to be able to travel to it at FTL speeds later. The data on the beacons can also be shared between players or at the organization level (think corp bookmarks from Eve Online), or even sold on the market. Who knows? I mean, it would be possible to use a probe like for stargates, perhaps as an upgrade to going to the location yourself and setting up the beacon from scratch. This would be useful if the location is say, weeks away by space ship or something like that. You'd send the probe, do a one-time FTL cruise to that location, then build the ftl beacon proper so you can continue to travel there in the future at FTL speeds. I agree, if we are talking about FTL drives, teleportation would be boring. Let it take some time to get from point A to point B. The only type of FTL travel that is like teleporting should be moving from one system to another via a stargate, since you'd imagine you'll be moving so fast it is akin to teleporting. It would be dope to have it so some materials just don't fare well at superluminal velocities. Players would need to employ things like shields around the ship to protect from the effects of FTL travel or enhanced materials that can take punishment at those speeds.
  8. I agree. As for how to set the start/end points, for going between systems, they've said that you will need to send out a probe that will eventually reach the destination (for going between systems). This same principle can be applied to in-system travel as well by just having people go to the end location they want and setting a probe there, linking it to the start location via a gate, probe or whatever else NQ decides. I do wonder though for travel between systems. I would imagine that we would have to build a stargate on both sides. I'm thinking that the probe can be traveled to via an actual stargate, but you may not end up exactly at the location of the probe and will have to travel to it. Once at the destination side with all your equipment you can then build the destination stargate and complete the connection. Note that this is all speculation until we get more info from NQ.
  9. Nothing like palace intrigue to spice up the gameplay. Seriously though, I am not sure if this will happen. There is no indication that those people will actually want to move over (barring Frogswarm and probably a few others). We will cross that bridge when we get there I guess.
  10. My understanding is that all of the kickstarter backer specific rewards (lifetime sub, etc.) will not be returning. The only packages that you can buy at this time are the supporter packages available on the website now. If you really want to support the game, you can buy all of the supporter packs instead of one. Hoping someone for Novaquark can give you a more official answer.
  11. Though I cannot speak in an official capacity for Novaquark, I suspect that we will have 24/7 testing by the time of Alpha 1.
  12. They aren't engines. They should not be used for take-off or landing, at least that's my understanding. From the dev-blog: They start working 1000m above the surface. I imagine that these are meant for very large structures that wont be doing a lot of moving and are too massive to use vertical boosters or other methods, such as logistics or support vessels, floating cities, and other sky-based structures.
  13. If you are really in a hurry, you can email support and ask nicely for them to give you access. I bought patron access today and I was able to get forum access an hour later.
  14. Agreed. I understand that NQ may not want to implement an API at this time because they are concerned it will lead to unfair advantages by some (i remember someone at NQ saying something like this - please correct me if I am wrong), I feel that an API for certain aspects of the game can be a valuable tool, especially for the larger organizations. For example, being able to read information on storage containers to keep inventory on resource amounts or receiving market data on a specific item from the day before (real-time market info gathering would not be good, not to mention that it can be a really fun job for someone to do). Refer to the CREST API from Eve Online, which does allow you to pull market data on a specific item, given certain arguments that you pass to it. The freshest information you can obtain is of the day before (as far as I am aware), which while valuable for seeing long-term trends, is not necessarily good for doing anything in the short term (in hours). This is my opinion of course. Those who are more experience with this kind of thing are free to correct me. Its just a matter of finding the right things to implement and what limits to impose on those aspects of the interface to give as much utility as possible.
  15. We will most likely be using a "sandboxed" Lua which has functions considered to be unsafe disabled and only affectsthe constructs in-game. If you want an example of what I mean, check out ComputerCraft for minecraft.
  • Create New...