Why can't we have a hitscan point and fire based shooting system for CvC (and if we can't, why don't we have it already?)

[Shaman]

In many ways, a hitscan point and fire based shooting system is very similar to the way mining works at the current moment.

With mining:

The player shoots a raycast from the direction you are pointing, and removes voxels in the area around where the raycast hit.

With a hitscan point and fire weapon system this process is very similar:

The player shoots a raycast from the direction the gun is pointing, and removes voxels and damages elements in the area around where the raycast hit.

 

If these two processes are so similar, why do we have to stick with the boring EvE-style PvP mechanics we have now?

 

My two main theories are this:

1. it would be too hard to aim with such high ranges (nq should definitely reduce combat range + speed)
2. they haven't got round to doing it yet (most likely)

 

And I know this one is far off, but the same goes for AvA. why does ava have to be a locking based system as well?

[Atmosph3rik]

"Damage Pending"

[blundertwink]

50 minutes ago, Shaman said:

If these two processes are so similar, why do we have to stick with the boring EvE-style PvP mechanics we have now?

 

My two main theories are this:

1. it would be too hard to aim with such high ranges (nq should definitely reduce combat range + speed)
2. they haven't got round to doing it yet (most likely)

 

And I know this one is far off, but the same goes for AvA. why does ava have to be a locking based system as well?

 

The cost for terrain is much lower not just because it is closer but because it doesn't move due to player input. Even then, DU struggles to perform when there's a lot of people mining!

 

When you have to raycast against a dynamic object, slight lag / sync issues become vastly more important. My position as it exists on the server must be exact; a few hundred MS of lag isn't acceptable and will cause a lot of misses (or it will look like you dodged something that the server thinks should hit you). 

 

The other thing with terrain is that it is a very simple mesh -- depending on exactly how the collisions work in DU, raycasting against constructs could be extremely expensive because it has to know if your raycast might pass through some hole in the mesh geometry.

 

Since construct meshes are created from voxels, they might not be that well optimized...and larger/more complex meshes only increase that cost. It can become a performance nightmare really quickly. 

[joaocordeiro]

2 hours ago, Shaman said:

And I know this one is far off, but the same goes for AvA. why does ava have to be a locking based system as well?

 

The main problem is when a Chinese plays with a Brazilian its the latency grows above 500ms.

With this latency, there is no synchronization between the 2 clients. 

The Brazilian is seeing a speculation, generated by his game of where the Chinese was a second ago and probably will move to. 

 

This generates 2 problems. 

Any movement the target makes to counter the enemy, may be javing the exact opposite effect on the other side of the world. 

Like, instead of dodging near miss on the left engine by going right, he may be instead centering his ship with the fire. 

 

But, most important, this enables a basic type of cheat. One that does not require any outside programs and is already used in many games. 

Pull the network cable -> target stops for a fraction of a second -> shot everything you got -> plug the network cable again to transmit damage calculations. 

From the victim perspective, he is dodging fine, the enemy stops shooting for a sec, then he blows up. 

 

Regular servers prevent this by implementing a maximum latency, kicking anyone above 200ms.

So network unplug = kick. But DU is designed to support 1000ms latency, so they cant just kick ppl. 

 

[blundertwink]

1 hour ago, joaocordeiro said:

But, most important, this enables a basic type of cheat. One that does not require any outside programs and is already used in many games. 

Pull the network cable -> target stops for a fraction of a second -> shot everything you got -> plug the network cable again to transmit damage calculations. 

 

Yeah, if they are doing these raycasts in a very naive way that's possible -- but a robust online game doesn't just take the client's opinion that a hit happened and validates it server-side anyway.

 

Still, this goes to show how it isn't as simple as taking what works for mining and using it for combat...and why AVA will likely never be that good -- you need a really robust system built to handle FPS interactions with minimal latency and DU just doesn't have that. One of the many prices they paid for not rolling their own engine nor their own hardware, IMO. 

[joaocordeiro]

46 minutes ago, ShippyLongstalking said:

but a robust online game doesn't just take the client's opinion that a hit happened and validates it server-side anyway

But if the "client's opinion" is not taken into account, its still a lock and fire system but with an ui that tries to make you believe you have any input on it.

I would like it, since I hate the lock and fire thing to the core.

 

But I would imagine that every week we have a new YouTube video of some dude saying how NQ programmed a system to trick players into buying the game, and how he demanded the money back.

[blundertwink]

10 minutes ago, joaocordeiro said:

But if the "client's opinion" is not taken into account, its still a lock and fire system but with an ui that tries to make you believe you have any input on it.

I would like it, since I hate the lock and fire thing to the core.

 

What I mean is that the client's version of reality isn't what matters.

 

Naive games implement a "hit" by detecting if a raycast on my client machine hits an object. If it does, it sends that "hit" to the server, which accepts it as truth because it is the most simple implementation.

 

This "hit" isn't real, though -- because the model I hit might not actually be where my client thinks it is (due to a bad LERPing algorithm, lag, etc.).

 

This is why you can scam the system by artificially increasing lag or unplugging network temporarily --  because that stops syncing the enemy entity, making the model stop, making hitting it easy...and since the server "trusts" client raycasts without validation, it is a cheat. 

 

A robust online game doesn't work like that -- it doesn't take any client's raytrace "hit" as truth, it validates it against its own "truth".

 

Programming in multiplayer is like programming with multiple realities or dimensions -- entities live on every client that renders them and trusting any one client's version of events without server validation is always a problem. 

[joaocordeiro]

1 hour ago, ShippyLongstalking said:

A robust online game doesn't work like that -- it doesn't take any client's raytrace "hit" as truth, it validates it against its own "truth".

After i wrote the last comment i had realized that you were refering to that. 

 

But DU cannot support the calculation of that server sided truth. 

Constructs are dynamic, full if details, with dynamic armor zones and dynamic elements. 

This requires a full cpu + physics engine GPU to calculate. 

 

The server has no idea what voxels or elements or physics are. For the server its just data that has to be streamed to all clients in range. 

 

Clients do all the calculations. 

It is fairly impossible to delegate this task to servers with the current technology. 

 

With lock and fire mechamism, it is possible to set a snapshot of data for both clients to calculate damage and ask the server for a random generated value. Then both clients can calculate the damage in the same way and report possible cheats. 

 

But servers wont ever calculate physics...... 

 

At most, if NQ ever develops the, so called, headless clients, maybe the "server truth" could be calculated in a headless client instance, running independent from the servers, getting feed by the same data as the player clients. 

[blundertwink]

22 minutes ago, joaocordeiro said:

But servers wont ever calculate physics...... 

 

At most, if NQ ever develops the, so called, headless clients, maybe the "server truth" could be calculated in a headless client instance, running independent from the servers, getting feed by the same data as the player clients. 

 

Yeah, I agree that it isn't going to happen -- this is something they needed to build for from the start to really make work. Not easy, not cheap, not feasible. Even harder with them not having their own engine or hardware...and even harder since constructs don't have set geometry.

 

Competition shooters are built with this sort of thing in mind...it won't happen in DU. 

 

So...the longwinded answer to the OP is that it isn't going to happen because it isn't that simple.  

[GraXXoR]

...(and if we can't, why don't we have it already?)

 

erm. Say what now?