Ripper

The server overhead for a 1000 player battle would be ENORMOUS, if the servers had to perform hit detection for every shot. They've already made the decision to go a different direction. So unfortunately, while your idea is great, I don't see it happening.

This is MY vision of what sensors should look like. Low Gain Omni Sensor: High Gain Omni Sensor: Low Gain Directional Sensor: High Gain Directional Sensor: BEAM Sensor: ANYTHING detected within the AREA of the sensor, is reported back to the DPU.

Comparing DU's Kickstarter to Inovae Battlescape http://www.kicktraq.com/projects/309114309/infinity-battlescape/#chart-daily http://www.kicktraq.com/projects/1949863330/dual-universe-civilization-building-sci-fi-mmorpg/#chart-daily Battlescape had to average $10,700/day in pledges to inch over the finish line. DU will need to average 15,200 euros per day to make it to the finish line. Let's hope JC can keep Dual Universe in the spotlight. (and do your part. Post to your favorite game forums.)

This has been on the Dual Universe Wiki for over a month! http://dualuniverse.gamepedia.com/Dev_Blogs

I agree with NQ on Stargates. 1. The vastness of empty space necessitates them. Travel at the speed of light is difficult, some would say impossible. Travel at 70,000+ times the speed of light to get interstellar travel to be within months of real time is only plausible within a game. 2. Travel AT the speed of light takes 11 REAL hours to get from one side of Pluto's orbit to the other. Nyzaltar has already indicated that you will be able to travel at "multiples of the speed of light" with a FTL drive. (just not multiples in the range of 70,000) This will allow you to visit anywhere within the solar system. 3. Look at No Man's Sky. There's nothing to do. It's almost impossible to find other players. Stargates are also a way for NQ to manage player density. This will provide greater gameplay depth. 4. I don't think most players even comprehend the SCALE of a single Solar System. A single solar system should have plenty of "content" to keep the average player busy. Ultimately its a great tool to manage player density.

I think you're confusing atmospheric ballistics with space ballistics. Why does an unstable round fly off course? Because air resistance knocks it off course. Once an item in a vacuum is placed in motion, it will continue on its vector until acted upon by another force. It doesn't matter whether spin has been placed upon that object, or not.

This is a standard FPS issue. Rubber-banding is caused, because of latency. Your client attempts to predict where everyone is by utilizing the packets it receives to predict the location and vector of the players. When a LOT of packets are dropped, this "prediction" is prone to error, and when new packets are received, positioning is updated. That's where the rubber-banding comes in. What NQ is suggesting is this. Send the most packets for people who are close to you, with fewer packets being sent the farther you get away. You're most likely going to interact with players that are near you. Rubber-banding would occur with people far away, but here's the kicker.... Due to the focal length of long distance targets, the rubber-banding would be less noticible for ships that are far away. Imagine someone standing next to you and warping 20 feet away. Now envision them 200 yards away, and warping 20 feet. When they're close by, it would dramatically effect your aim. But at 200 yards, it's a minor adjustment.

What's to keep me from surrounding all of my critical elements with "hardened elements"? It may look like a house, but it flies like a tie fighter

I like the idea. From my understanding, we're limited to 25cm (10 inch) voxels. This limitation would make some of our creations massive. It would be VERY interesting to have a skill tree that would allow smaller builds. The higher your skill, the smaller the component. This could open up some interesting scenarios.

Short duration auto targeting (tab targeting) performed by fixed weapons would give the illusion of FPS/Sim combat

Hi Nyzaltar, What will we be able to target in ship-to-ship combat? Voxels? Core Modules? Mesh Elements? I understand that voxels are most likely a 'No'. If its a core module, how do you determine the hit points of a Deathstar vs a fighter? If its mesh elements, will we be able to cycle through the traget's components, and disable specific ones? How will damage be applied to voxels and mesh elements?

Targeting Mesh Elements would be interesting.

They look the same. Firing arc / targeting cone. This post is about how to IMPLEMENT the solution. Instead of "tab targeting" where the player designates the enemy with a mouse or keystroke, my post is about an AUTOMATIC targeting of whats directly in front of the weapon.

"Tab targeting" or "target/damage" model of combat has been confirmed by JC Baillie in this interview. (between 6:00 and 7:30) https://www.youtube.com/watch?v=m1WMwIDWFKI I'd like to point out the following observation to the devs, and get their feedback. The above method of combat is perfectly fine for larger ships with turrets, but isn't viable as fighter combat. Players will want to have fixed weapons, and dogfight other players. How can this be achieved with the "target/damage" model? I've previously, suggested an invisible target lock on the players hud, which acts like a short term missile lock. It essentially only allows the weapons to fire when the target is directly in front of the player. However, I've discovered a couple of possible ways to exploit this. My new suggestion for the DEVS: Targeting Cones for Weapons. It doesn't matter whether the weapon is fixed or a turret. The weapon should have a sensor that "Targets" the enemy ship at the center of the cone. It would perform a short term "Target" (milliseconds to seconds), that would allow damage to be applied. How does this effect combat? Turrets won't be able to fire through the players ship. All weapons are limited to their cones of fire. Fixed weapons could be mounted forward or broadside. They would only hit targets that are in their field of fire. The above solutions provides for simulated FPS/SIM combat, without having the overhead of hitscanning on the server side. This would need to be done on the "mesh element", so it needs to be coded by the devs.

It's been FOR E VER since I've putzd around with Eve. Can someone provide a basic description of the mechanics?

I don't believe "Tab Targetting" has been confirmed

Agreed, It would be cool to have a "Construct Meshification Process", where players can submit working constructs to be "meshified" and incorporated into the game.

It all boils down to mesh iterms. If the mesh elements can be assembled like voxel elements but on a much smaller scale than 25cm voxels, then modular weapon types, for even personal weapons can be created. AND I would encourage NQ to investigate the possibility. Combining mesh elements larger than 25cm shouldn't be an issue, and we just have to see what NQ provides us with.

You said it yourself "targeting cone". If the devs have developed a solution which limits a turret to a cone of fire (direction of fire), then they already have a solution for fixed weapons.

I'm interested in the following: Key presses Mouse X/Y coordinates Mouse Buttons Multiple analog variables from -1 to 1 that can be mapped from joystick, VR headsets, gamepads, or any other device. Other device buttons And a virtual joystick solution for those that want to use one. Then let me set them up how I'd like.

Also, For this to have a chance of succeeding, fixed weapons should be much lighter, and use less energy than a turret. Otherwise, there's no benefit to running a ship with fixed weapons. There would need to be a benefit to running fixed, if everyone else is running turrets, but I'm sure the devs will balance this.

I'm really looking forward to the coding side of things. So, weapons.. Components... We'll see if I can be successful in churning out things. However, I'd like to see the Devs look into the RITL. I think it should be hard coded to the cockpit mesh. If that doesn't happen, I'll look into it.

LOL Pittouniata == Chris Roberts

UPDATE: This is a suggestion for the devs to implement on single seat cockpits, and allow fixed weapons. Otherwise, nobody will want to fly fixed, if its scripted by the players, because they would be at a disadvantage to players with turrets. ALSO, it MUST be done by the devs at the "mesh element" level, due to the way damage is applied (in a traget/dmg MMO model). A simple scripted lock solution will allow fixed weapons to fire in any direction, and is open to exploit. One possible solution is to have the RITL performed by the fixed weapon "mesh element". This will allow users to build their own turrets, or other exotic weapon systems. Bear in mind that combat has NOT been implemented yet. So things can drastically change. Nothing's set in stone. I haven't seen a confirmation on this, but there are rumors that combat will be based around "tabbed targeting". From my understanding, this is like most MMOs, where the player "targets" the MOB, and then attacks it. To be honest, targeting is just fine for capital ships with turrets, but what about those fighters? Most players are going to want a sim/fps experience. They're going to want those fixed weapons. INTRODUCTING THE RIPPER INVISIBLE TARGET LOCK In your standard MMO, target locking, can be performed by selecting a MOB with your mouse, or tabbing to the next closet MOB. The RITL is essentially another method to target a MOB. The "Ripper Invisible Target Lock" method, is a short duration missile style lock that implements tab targeting. Coupled with a small radius from the reticle to lock on. This forces a player to line up the shot. They have to have their target in their cross hairs. In the background, the RITL selects the target for one to two seconds (balanced for gameplay), and the player fires the weapon. As long as the ship remains in the cross hairs, the target remains locked, but if the target out maneuvers the pilot, the target lock is lost. There's no need for the target lock to be visible for the player. Its specifically there as a mechanic, to provide the illusion of SIM/FPS combat.

Combat isn't implemented at this time, so there's plenty of time to discuss how combat will take place. Regarding "Tab targeting" with small fighters. I'm sure we all want to experience the excitement of dog fighting with fixed weapons. Using the "tab targeting" model, I've already suggested the "Ripper Invisible Target Lock" method, which is essentially a short duration missile style lock that implements tab targeting. Coupled with a small radius from the reticle to lock on. This will provide the illusion of fighter/FPS combat without having to implement that style of game play. Heck, I'm wondering if the R.I.T.L is something I can script, if the devs don't come up with a solution. It would be NICE if some of those mesh weapons weren't mounted to a turret.