Ripper

Liquids wont be modeled in the initial release. Transfers of cargo will most likely be performed via a standard trading window.

Outlawing a product in your territory wont create a black market and increase its price. All the org is acomplishing is depriving itself from salestax. I'll just buy it somewhere else at a cheaper price. Why buy at an inflated price when I can purchase the same product cheaper in the neighboring territory?

What org in their right mind would outlaw the possession of specific items. Therefore no contraband. What kind of laws are you going to pass to force specific player behaviour. All your doing is coming up with an excuse to blow the other player away. Just do it and steal their cargo. Stop being a pussy by justifying the act.

Running a gauntlet of pirates and pk'ers isnt the same thing as smuggling.

You're describing a P2P gankfest. Thats not smuggling

Without laws enforced by AI, there won't be any smuggling. You cant prohibit a player from purchasing or owning a specific item. VERY few players in an org will want to spend their time patroling some border as customs enforcement

There will be a single "shard", which all people will be playing on. I agree with Twerk, the back end will be cloud based, with multiple sets of "resources". That could include physical servers, but none of that will be visible from the end users perspective. The end user will expereince a single environment where every player can interact with every other player.

Hey Twerk, I'm excited about UI customization, and it certainly makes sense to have something as easy as HTML5 for custominzation. Can you direct me to where you obtained this information?

It's certainly not going to be in the game at the beginning. One issue is the size of the voxel. At 25cm (10in.), that single voxel is much bigger than a pistol. At the moment, all constuction is via Voxels. However, I could see a high enough level of a builder that could imbue a voxel with a specific abililty, or multiple abilities. This would certainly allow the creator to manufacture ship weapons. But I doubt the animations will exist for carrying a voxel like a pistol, rifle, or swinging one like a sword. I'm betting it will be a LONG time, if we see anything like player built weapons.

Twerk's Back! I missed you

To be honest, I don't see the need for FTL sensors, or creating the lore behind them. In my opinion, all combat should take place in sub-light speeds. You shouldn't be aware of inbound attackers until they drop out of FTL.

An Alcubierre drive will create a gravitational wake that could be detected.

Correct! W is the quaternion variable for the rotational position of a ship. X,Y,Z only indicate where you are in space. Not the direction you're facing.

I've been thinking about the HUGE issue of sending everyone coordinates of every player within the game. The server guy has a lot on his plate. Assuming NQ uses int64_t variables for w,x,y,z coordinates, you're looking at 32 bytes per player. A 508 byte packet will only support 15 players. That means 66 packets would need to be sent in order to update the positions of 1000 players. The latest FPS games on the market transmit at about 60 packets per second. So you're looking at 1 update every second, for those 1000 players. JC has indicated that closer players would be updated more frequently than those farther away. This will most certainly help with this issue. The player will most likely interact with other players that are close to them. So the "One packet per second" above, isn't true. Players that are closer to you will update multiple times a second, while those farther out, may update once every 2 to 3 seconds. However, In addition to what we know from JC, I'm wondering if we can improve performance for combat between players. My suggestion would to include a "flag" in the server side database, for "hostile players". If one player has fired upon another player withing the last few seconds, the positioning packets should be given a higher priority (placed first in the queue). This will allow for players IN COMBAT to have a more fluid experience. Example: Three players are in close proximity. Everything being equal all packets should be sent to all three players, at approximately the same rate. The overall player density of the sector, doesn't matter in this example, because they are so close together. They're getting the highest rate of updates. Player 1 & 2 are in an organization. Player 3 is in a competing org. Player 1 & 2 don't really care if their updated position is off by a little, because they're friends. They're not going to be shooting at each other. But if Player 1 attacks Player 3, both player 1 & 3 would want the most positional fidelity. These updates should be given priority over all other positioning packets. They should be sent first (in addition to critical packets such as damage to each others' ships). So initially, due to the overall player density, all three players were getting positioning updates 20 times a second. This would be the normal rate in an FPS. Player 1 fires on Player 3. The server flags both players as "High Priority", and place their coordinates in the hight priority queue. The server transmits each players location with every packet. Players in combat would update 60 times a second, while Player 2 (not in combat) would still be updated 20 times a second. The high priority coordinates are just those between players in combat. They wouldn't receive the coordinates of evey player that was currently in a fight. Just the player who they were attacking, or who was attacking them. THIS ALSO WORKS FOR SNIPING!!! The identical scenario above, but ranges are considered "Long". This means instead of receiving packets 20 times a second, all three players would receive the update once every TWO seconds. Player 1 fires on player 3. Players are marked hostile to each other by the server. Player 1 and player 3 positions are updated at 60 times a second, for the next few minutes, or until someone dies. Player 2 still receives updates at once every two seconds, because all three players are still at "Long" range.

Where did this idea of baking a mesh come from? My understanding is that ships are a combination of voxels and mesh elements.

Something to keep in mind is packet updates of long range targets. Depending upon the network algorithym and number of players in a sector, those updates could be a few seconds old. What you see on your display may no longer be there. They could have "warped" someplace else, and you wouldn't know that until the next packet update for that specific Ship ID.

Sensors are such a generic term. I'm sure to begin with, sensors will be used to detect an avatar and perform something like opening a door. In their most basic sense, they detect either an avatar or a core unit, and emit a response that can be used by a DPU. More than likely, they will detect these things in a given geometric volume of space. As a builder/programmer, I would like to have the ability to adjust the size and shape of that geometric volume. An example would be something like a wireless access point. I can adjust its power to regulate its range, and I can purchase different antennas to adjust the shape. Anything from omnidirectional, to hemisphere, to cone, to a beam (for some sort of tripwire). Once the above is programmed, then we can focus on the "space warfare" stuff. Optical, IR, ES, and Radar could be variables that could be added to the basic sensor.

Now hacking the core of a captured ship is something else. You WOULD retain the original construct.

The Devs have commented on this. There is the distinct possibility that if you blow the core, the entire construct will blow and drop random voxels and elements as salvage

I'm thinking some type of FTL missile/torpedo to pull a ship out of FTL. Attaching an FTL drive to a warhead seems plausible.

Oh I agree. We will need to travel +1000 the speed of light to get to another system. And several orders of magnitude to get from one point in a solar system, to another in a timely manner.

I just used 0.9c as the example. Any velocity could be used. Since I believe all combat should be sub-FTL with the exception of FTL torpedoes, I used that speed. Lasers and projectiles are sub-FTL. Relativistic velocities only add to the complexity of the math, and don't change the point I was trying to make.

Diffusion has nothing to do with the inaccuracy of lasers at long range. A light-second is roughly 186,000 miles. That's not a large distance in terms of bodies within a solar system. In fact, it's 226,000 miles from the earth to the moon. Then consider ACTIVE sensors. The light or radio waves have to travel FROM your ship... reflect off the target... and return to your ship. This type of sensor has less of an effective range due to the additional travel time. (Approx 93,000 miles) Then consider the speed of the laser. That's ANOTHER second to the target. I'm keeping the distance at a light-second to keep the math simple. Feel free to use whatever fraction of that you'd like. Now consider that ship that just came out of FTL. It's currently running at .9c Using optical sensors (passive but more accurate) you detect the ship and fire on that position. That's one second for the sensor and one second for the laser to return to the target. You just missed the target by 335,000 miles, because the target has been moving for 2 seconds. 558,000 miles if you were using an active sensor. But you say "The ship computer can compute the trajectory" That's true. IF the target was a meteor. But another ship making even a MINOR random course adjustment would be impossible for the ship computer to make an accurate prediction. Your shot would still be off by miles. But you say "That's at 186,000 miles. We won't be engaging ships at that distance" Just take the above example and change the distances by a fraction. Then recompute the time it takes to travel those distances. How close do you have to be to be accurate within 100 meters? (The length of a ship)

You're projecting too much