Ripper

I would expect cameras to be part of the sensor unit group. As for displays, I wonder if that could be implemented in the contol units group. The control units are supposedly completely customizable

I've decided to just update the WIKI with the correct information.

Dont you HATE games like Battlefield 4 where there's NO visual indicator for missile lock. Please keep this in mind devs

And THERE'S the beginning of fascism.

As long as it doesnt turn into a Star Wars Galaxies "Jedi Knight thing". It took FOR E VER to figure out how to become a Jedi

what about moving a player made stargate? :evil grin:

Can I shove that asteroid at your planet?

And although it may be planned, I'm betting its made of a lot of sub-assemblies

Hey guys, Has anyone heard anything about piracy, smuggling, and bounty hunting? I haven't seen anything yet. This may be a good topic for a future dev blog.

Every time I hit a website with sound, I cringe. I just dont like it, and dont believe its professional.

I have to say... "NQ has their ducks in a row..." Everything Ive seen from them is very detailed and logical. It definitely boosts my confidence in the project. I'm really excited to see what they can pull off.

Im perfectly fine with you bringing a sword to a gun fight

There has to be some level of granularity thats the cut off. You wouldnt want to mix your own gunpowder. I think this conversation is a bit premature. We havent seen them yet. Im sure theres plenty of parts to make stuff out of.

So instead of a "size 1 laser cannon", maybe a scalable laser emitter? The same would apply for gravity, propulsion, sensors, etc?

Realistic distances in a solar system would require a FTL drive. Realistic distances between star systems would necessitate jump drives or star gates. Its not a question of either/or. Its both.

Im not a big fan of background music on by default. If a prospective player visits the site from their work computer it could cause problems. Definitely not the first experience NQ wants to give to someone.

Here's my wishlist: Generic Dashboard Controls for PDU Generic Display Unit for PDU Shield Generator Reactor Sensor Arrays Radiator Fuel Tanks FTL Drives

Hey Everyone, Here's a list of Premade Game Elements that can be used to build with. Tell me what you'd like to see and I'll add it to the list. Then I'll update the list with confirmation from Novaquark. Core Unit - CONFIRMED - Nyzaltar Cockpits (Single Seat) - CONFIRMED - Nyzaltar Engines - CONFIRMED - Nyzaltar Boosters - CONFIRMED - Nyzaltar Dashboard Control Unit (multiplayer ship) - CONFIRMED - Nyzaltar "Propulsors" (Same as Boosters?) - CONFIRMED - Nyzaltar Distributed Processing Unit (Scripting) CONFIRMED - Nyzaltar Mechanical Joints Generic Dashboard Controls for PDU Generic Display Unit for PDU Shield Generator Reactor Sensor Arrays Radiator Fuel Tanks FTL Drives Rotators Pistons Wheels Tethers Struts (Like metal pole, think Kerbal Struts) Detach points, so you can make a satellite on the planet surface, fly it into space and detach it from your main vessel to orbit the planet. A Button

Here's the deal, Client to Client isn't necessary. All of this can be ran through the server at the cost of increased overhead. There's always a tradeoff for security, and it's NEVER 100%. And there are always server side hacks. If the alternative is a generic "RPG target", you're not going to get the granularity of FPS hit detection.

Sadly, I'm not familiar enough with voxels or how NQ plans on displaying their coordinates to answer this question. I would personally isolate all "hits" to a single voxel. Even missile hits. The clients would extrapolate the damage from there.

The Answer to hit type is the contents of the "locked status" packet. The client would have a "Locked Table" array to account for multiple attackers targeting the player. When attacker 1 "locks" The server verifies the lock, and transmits the attackers weapons loadout and playerID to the defender. The server also updates the damage table to make sure it hasn't been modified. Hit detection is performed client side, and the attacker sends "Attacker1, Hit Player 2, voxel location, weapon 1" The client looks up weapon 1 in the lock table, sees that its a "Size1 Laser" and cross references its damage from the damage table. Both of which have been provided by the server in the past few seconds. UPDATE - The "Damage" table can be merged into the "Locked Table" with weapon loadout & damage.

Well, What needs to be verified. Did the player actually hit the target? What did he hit the targe with? Where did he hit the target? How much damage did he do? Answer: He had to be "locked on" or the target had to be selected via "RPG Targeting" - Server Verified Hit type ... (server supplied - see below) The location can be determined client side and trasmitted to the other client. A regularly updated damage table(once per second? balanced for load), that's queried by the damaged player. - Server Supplied Let's consider how we prevent the attacker from changing that "Size 1 laser" to a "Size 5 laser". I seriously doubt a hacker is going to be able to specify a certain voxel to hit. So, hit location shouldn't be an issue.

Thanks, WHY does "RPG Targeting" exist? Its sole purpose is anti-cheat. I have to be in range, and hopefully facing my target to do damage to it. This prevents a malicious user from dropping a fireball on me from the other side of the game map. Once targeted, the player can click to their hearts content to apply damage, and the server sends "pre-defined" damage packets to Player 2, based upon the type of damage inflicted. Hit detection on the average FPS is verified server side, and can be extremely complex which creates a load on the server. If the detection and location of damage were client side, those packets could be sent from client to client. The only other consideration is magnitude of damage. There would need to be a way to indicate that the standard "Size 1 laser shot" does 20 points of damage, and an anti-cheat mechanism that would prevent player1 from modifying that value. Maybe. The clients only transmit hit type and location. Then the damaged client would request the amount of damage from the server. In fact, the client would only need to request the "damage table" every so often. That way it would reference the table instead of making a query every single hit. This would prohibit the player from modifying the damage table, because it would be regularly overwritten.

A post on a previous thread got me to thinking. This makes a lot of sense from the single shard approach. Hit detection becomes MUCH more difficult when the server has to account for rubberbanding. Of course there are those of us that would like to be able to hit specific parts of a ship to disable it. The player base is going to WANT "FPS Hit Detection" instead of "RPG Targeting". Here's a thought: Consider the missile "lock on" reticle. Your ship usually has to face the target and have it close the the cross hairs in order for your missiles to lock on. Now imagine an invisible "lock on" reticle (because the player doesn't need to see it). This reticle is strictly an anticheat mechanism. This reticle is much more difficult to achieve, and the lock doesn't last very long. The game client transmits a "locked on to player 2" packet to the server, which is verified. This is essentially an "RPG Target". Instead of clicking on a MOB the client selects it for me. Then when Player1 shoots at Player2, the damage all hit detection is done client side. If they're "locked on", the damage is applied to Player2. (much like my lightningbolt hitting a MOB) And consider this... The server only has to transmit "locked status". All damage could be transmitted between clients (with the occasional additional anti-cheat mechanisms in place). This would reduce network infrastructure load. EDIT - See Post 5 & 7 for clarification What do you think?

Here are the Dev Blogs of interest Building with Voxels https://board.dualthegame.com/index.php?/topic/378-devblog-builder-gameplay-voxel-tools-elements/ Tools: https://board.dualthegame.com/index.php?/topic/14-voxel-tools-pre-alpha-game-design/ Rights Management: https://board.dualthegame.com/index.php?/topic/272-devblog-rights-duty-management-system-rdms/ Economy: https://devblog.dualthegame.com/2014/12/04/from-barter-to-market-economy/ My understanding is you buy the construct. Unless the builder actually offers the blueprint for sale. Of course, there's nothing stopping the player from reverse engineering the construct.