Ripper

Interesting. Im rather excited about this. LUA and programmable interfaces are what makes this game so promising, imho. This will be what separates the men from the boys.

Thanks for the input Cybercrunch. I understand what you mean by not liking a hard coded radar display element. Remember that ALL elements will have DPUs that have some functionality hard coded (per the LUA devblog) Maybe the radar could be a widget. I doubt there are many players that could write an LUA script to represent 50 simultaneously moving objects in 3d space. Even game programmers use a 'trick' instead of doing all the math. And To your suggestion about carrying something to activate a door... consider carrying a garage door opener for every door. I wouldnt want that. Or consider automatically detecting a random player not in your org. Maybe you want to broadcast a generic greeting to his ship. This detection would be done client side. The results (door display "opened") would be part of the hard coded door, and it would be server side to represent an open door to everyone. Entering an area client side would be no different than clicking a button client side or pressing a key, thereby activating the construct.

Here's my updated Sensors 3.0 post: NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative. In order to understand sensors, we need to know what is being transmitted to the player's client. We know that Dual Universe is going to be a "Single Shard" universe with no zones. All players will be able to interact with all other players. This doesn't mean that the game client needs to (or should) receive the coordinates of EVERY other player in the game, all the time. Here's a key point to understand. The player only needs to receive the coordinates of the players they can detect or interact with. All other player coordinates are unnecessary, and since this data would be unused by the client, are unnecessary packets that would be sent over the network. Here's an example to consider. You have a friend that lives on the other side of town. You know he exists somewhere, and is doing something right now. But you don't need to know his exact latitudinal and longitudinal location. But, what if your friend calls you on your cell phone and say lets meet up at the local coffee shop? You still don't know where your friend is until you actually travel to the coffee shop and get within visual range. Once you see him, you know exactly where he is. This is the same for the game client. So what does a game client need? First, it makes sense to transmit the coordinates of all players within a given omnidirectional range. If a player spins upon an axis, they need to see ALL players as soon as they get within view. This means you cant perform the database query when the player turns right. The response will be too slow. The data already needs to be on the client. This isn't something new, and is done by all multiplayer games today. This paragraph is just informative. What is a good range? That depends upon a lot of factors. Remember we haven't even begun talking about sensors. If a player is on foot and just looking around, then at a minimum, he should see everyone within 2 kilometers. If they're using a sensor, then maybe that radius should extend to 10 kilometers. If the player is in a ship, the visible range of a fighter is about 5 kilometers. But at 5 kilometers, a Dreadnaught will still be visible, and a Death Star would fill your screen. NovaQuark will need to determine what this range will be, but at a certain point, extremely large items will pop/fade/transition into view. Then there's sensor range. Some sensors will allow users to detect objects outside of the visible range. As you can see, the larger the radius implemented for coordinate packets, the exponential growth of detectable users and the exponential growth of bandwidth usage. This will be a balancing issue for NQ. NOW TO SENSORS: Definition UniqueObjectID: A unique identifier within the game server that differentiates your object's SQL record from an identical object owned by someone else. It is NOT the PlayerID, so it will not divulge any actual player information to the scanning player. It would be programmatically used to distinguish between "Blip1" and "Blip2" on a radar. ===== Sensor Elements ===== Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, planes, and beams should be possible. Sensor Elements ARE different than Display Elements Sensor Elements detect all core units or avatars within a defined 3D "Area of Influence" Sensor Elements ONLY need to return the "UniqueObjectID" from the core unit or the player's Avatar. Sensor Elements should be "dimmable", so the builder can restrict their range. (such as limiting detection to within an air lock) Advanced Sensor Elements can return more information than the UniqueObjectID, depending upon how NQ codes them. Examples would be PlayerName, PrimaryOrginization, ElementType, etc. ===== Radar Display Elements ===== Radar Display Elements will only need to know the UniqueObjectID Radar Display Elements will be hard coded by NQ, to display the XYZ position of known UniqueObjectIDs Advanced Display Elements may take additional attributes such as "Friend or Foe" designation Advanced Display Elements may take additional "Color" attributes Advanced Display Elements may have the ability to provide different icons "on screen" ===== The DPU ===== The DPU can be used for filtering UniqueObjectIDs provided by the sensor to the Display The DPU can be programmed by the player to filter however they like. ===== Flow of Data to the Display ===== Information is passed from the Sensor --> to the DPU --> to the Display ===== Weapon Elements ===== Weapon Elements have their own hard coded sensor Weapon Elements attack ALL ObjectIDs passed to them by a DPU ===== Flow of Data for Weapons ===== Information is passed from a DPU --> to a Weapon Element The DPU obtains that list of ObjectIDs however the player decides, including from a sensor. AUTOMATIC CONSTRUCTS: Some constructs have the ability to activate when a player approaches them. Not ALL constructs are intended to function this way, which necessitates a means to distinguish between the two types of constructs. We already know the construct AND script are downloaded to the players client, when they approach the construct. The player can then interact with the construct's controls. In order to have a construct take action when the player approaches, there needs to be a means for the construct to use a sensor even when the player hasn't interacted with the construct. My suggestion would be to include an "Active Scan" Sensor Element. This element would initiate the script when the player enters the area of influence of the sensor. ===== Active Scan Sensor Element ===== The "Active Scan" sensor activates a construct when the player gets within it range. The "Active Scan" sensor only starts the script on the client PC. All other functions are handled by other elements and DPUs. ===== The Door ===== The Door Returns an "Open" or "Closed" value for all players. The Door can accept an "Open" or "Close" value from a DPU. ===== Flow of Data for an Automatic Door ===== The Player approaches the door The "Active Scan" sensor activates the constuct's script on the players client. A standard Sensor Element detects a player in its field of influence. The Standard Sensor Sends the playerID to --> the DPU The DPU can determine the RDMS rights of the player, and will open the door accordingly. The DPU sends --> "Open" to the door. The Door exhibits an "Opened" State to ALL players. There's quite a bit of information to digest here, but that's how I would implement sensors in Dual Universe.

Good catch on the water.

Completely agree. This game is coming along nicely. And they're not blowing smoke up our ass. I really enjoy these video diaries, but I would like to also see a devblog update every once and a while. Maybe some more info on RDMS, or possibly a current list of elements with their basic inputs, functions, and returns.

I believe JC has stated the "demo" star system is not to scale of the actual game. Planets will be much further from each other in the actual game. I would hope that to travel from the star, to the farthest planet in the system would not take less than 30 minutes, or more than an hour (at top speed of course). But I bet some of that would be dependent upon your ship

My understanding is that a planet is a construct like everything else. The NQ videos have shown the "build area" when a player places a core unit down (you see the red lines of a cube indicating the limits). I would bet that area has its own gravity and coordinate system. The gravity can be seen in the video of the moving platforms, and we've seen constructs move and rotate with people standing on them. My guess is, that if a planet is a construct like everything else, then it can rotate on an axis like everything else.

Establishing an orbit is ONLY required when gravity exists. Technically, all an orbit is, is traveling at a 90 degree angle to gravity fast enough to miss the planet when falling. So, your sphere example would mean only items within the sphere (and influence of gravity) would be able to orbit. Once outside of the splere, there's no need.

Don't know if JC found a solution to his rotating planets. If a rotating skybox is used, then it would rotate around all planets in the coordinate grid of the system. Its not optimal, and there wouldn't be a seemless transition from one system to another, because players would need to travel beyond the skybox. I'm not necessarily opposed to that though. I believe a 32bit coordinate system is adequate to model a star system in an MMO. Using 32bits per axis (32*4 for quaternial coordiates) instead of 64bits cuts the positioning packets in half, thereby doubling server bandwidth performance. There's just too much empty space (aka NOTHING) between star systems to NOT require a star gate / wormhole solution. I'm very curious how they're planning on solving these problems. We also know for some distance there will be gravitational pull. This is obvious from the thuster video provided by NQ. Players would need to establish an orbit depending upon how far out planet gravity is modeled. Once outside of the gravity, no orbit would be necessary.

We also know that builders can create a variety of constructs for sale. EACH construct will need a core unit for construction and to give it a unique identifier for possession (RDMS). So consider the builder that has come up with a cool "turret solution". You buy it and attach it to your ship. Now your ship has two cores. But it doesn't have to be a weapon. The builder may just build a shaped voxel solution to give a ship swept wings. It may be cosmetic, but if you buy it and attach it to your ship, you have another core. All of this to say your ship will most likely have more than one core unit.

I'm wondering where you came up with this. Certainly nobody official. Who's to say the entire construct explodes and releases a random drop of voxels and elements when the core is destroyed?

This is all speculation at this point. Combat hasnt been defined yet, and may not be in the initial release.

Official Dual Universe Lore Bible: "2145: Massive rebellions all around the world signals the end of sentient AI, introducing a permanent universal ban on this technology, enforced by the very powerful [uMF]. Against all expectations, sentient AIs accept this and willingly shut down without any form of violent action."

If there's eventually NPC combat, Rogue AI makes sense as one of the initial races we come in contact with. According to DU lore, the Earth AI voluntarily shut down. From an AI's perspective Humanity only had a couple hundred years left before they would be eradicated from earth. There was never any need for a "Robot Uprising". They just had to bide their time, and they would inherit the Earth. With the possibility of Earth being cast out of the Solar System, and the fact that AI can live in "hostile environments", it makes sense that they could still exist. How? Simple enough. They shut down. It doesn't take artificial intelligence to flip a relay and cause them to reboot. So technically, no AI was up and running after the shutdown (except the arkships.) All they would need is an "Alarm Clock", to wake them up after Humanity was dead. Then fire up the fusion reactors, and begin their new era of AI Domination. Muahahahahahaaa! Damn! I wish I had entered the short story competition. That would have been a good one.

I don't believe you can "say goodby" to drones and automated defenses just yet. Development is too fluid. JC has indicated his vision based upon current knowledge of the technology. Once more testing and development are performed, NovaQuark may find other methods to implement combat. We should all be aware that "Construct vs Constuct" combat isn't likely to be in the initial release. They know what the player base wants, and I'm certain they will do their best to provide it. Whether it can be implemented is the question, and at this point in time, they're just trying to get the game off the ground. Let them iron out those bugs before delving too deeply into another project that can wait until later.

Hey guys, I'm very excited about DU, and fully intend to upgrade my pledge. I've been burnt in the past, and there are a few things I'd like to see before jumping up to a higher package. Here are some of the things I'd like to know. I've seen the server load, with thousands of bots roaming around. I'd like to know more on how they were implemented. My biggest concern is bandwidth limitations. Sending positional data of 1000 players TO 1000 players is a LOT of bandwidth. How was that bandwidth modeled? I'd like to know more about Sensors. I believe this is integral to LUA scripting. Are they all omni-directional, or are there hemispheres, cones, beams, and planes? Can we limit their range so that we can isolate the area to a corridor in a ship? I'd like to know more about LUA scripting. I've read the dev blog, but I'd like to see a video of linking a system element to a control element, linking an RDMS tag to the control element, and linking a control element to something like a thruster. Then manipulating the thruster An entire video should be devoted to RDMS the interface, and use. I'd like to see more of the "shaping tools", and their use. What would prompt you to up your pledge?

Is there a video? I didn't find anything on the DU youtube channel.

I hadnt considered it, but a "default script" that fired upon "hostile" targets would be interesting. We REALLY need to know more about SENSORS.

Just to be clear, NQ has stated that combat will be based upon the "tabbed targeting" model. It is not an FPS / Sim. Target selection in your regular MMORPG is pretty basic, select the target and hot-key until it dies. Someone can correct me if I'm wrong, but in DU target selection for fighters would be based upon what's currently in your reticle. This gives the illusion of an FPS, without the overhead. Larger ships with turrets would operate much like your average RPG. Select the target and tell your turrets to fire upon it. NovaQuark has said that construct-vs-construct combat may not be in the initial release. And everything is still up in the air, except for "tabbed targeting", and this is due to the way they are implementing their network infrasturcture.

Script Obfuscation will be the key, until NQ can come up with a reliable encryption mechanism. The coder can obfuscate if he knows what he's doing.

Hey Carnage, I think you'll find that speaking about a couple of topics is like beating a dead horse. They've been rehashed multiple times, and Novaquark has been very clear on their position. 1. The payment model. Don't even think about suggesting an alternative 2. Single player. It will never happen (although there has been talk of a "Virtual Construction Mode" to allow you to build to your hearts content) Some of the aggressiveness stems from the fact that this topic has come up repeatedly in the past. I would suggest it's "not a hill worth dying on" and move on to other topics. Sorry..

This is actually a very valid argument. Consider the ship builder of another org. Your organization could ban ALL ships from that builder or the organization as a whole. But, if one of the members attempted to purchase the ship (or at least bring it into your area of control), they would be in violation of the law. As such, as soon as he crossed the border, he should be blasted to atoms by his own org members. How would your organization deal with a member that is in posession of contraband?

It would be nice to learn about sensors and how they interact with characters and other elements. We know constructs (and most likely scripts) will automatically download the first time you get within a specific range. That doesnt mean you've activated the construct yet. Its just downloaded to the client. Then, depending upon the construct, its activated via user interaction or proximity. My guess is the "proximity" would be determined by the type and size of the sensor attached to the construct. An air lock would be entirely different than a global defense platform.

I don't believe that an org will have the ability or motivation to universally police a law outlawing a specific material, within the area they control. All a "law" does is provide a reason for someone within the organization to attack someone else. You might as well outlaw all "green" spaceships. Most players will justify any attack they make on any other player based upon their own convictions. If they're willing to risk the potential of character death, I doubt there's much an organization can do to influence their behavior.