Player Features and Ideas Discussion

Actually I do. I have a degree in electronics engineering, to be specific.

The damage amounts would take up no more overhead than an instant message, and many game systems already have cross platform communications. The drone behavior can be reduced to heading towards, or simply orbiting, targets they are engaging.

What you have, to the server, amounts to:
(Substituting english for shorthand variables here)
(DRONE PLAYER ID) does X damage to (EVE SHIP ID)
The pilot did a fantastic barrel roll, and a strafing run, hitting the destroyer with his EM rounds.
The DUST side, receiving the resists from the EVE side, can even take over handling drone damage amounts in these cases, reducing server load in exchange for communication.
or
(DRONE PLAYER ID) goes to range X with (EVE SHIP ID)
The DUST pilot is ordered to change attack to a Scimitar cruiser, so he punches his MWD and races into battle, guns locking on...
The EVE side would just see the drone changing to a new target, and trying to orbit that instead. No change from current behavior, and the algorithm handling drone behavior is unloaded from the server while the DUST side provides the info.

oh snap

It's not the connection speed that's the issue, it's how the server processes control input.

While a keyboard only needs to process data if a key is actively being pressed, a joystick has to continually monitor the X-Y position of its control column and communicate with the server to stay synchronized with what you see on-screen.

What this means is that each time the joystick's control column is moved, it has to send a new signal to the server with updated X-Y data. By that time, the joystick has likely been moved again, requiring another signal to the server when it (the server) hasn't yet responded to the first set of X-Y data.

As a result, your ship will behave erratically, becaause the joystick will get one response from the server on one tick, and then a second response with the updated control data on the next tick. On a single-player desktop, that's no problem (because there's only one signal and the CPU is more than equipped to deal with it), but there's only so much the server can do with thirty to sixty thousand continally-updating control signals in play.

It's not the server-side load that's the problem, is what I'm saying -- it's how the individual commands are dealt with on a technological level. As I understand it, the EvE server updates the client's data at a set interval, and a joystick transmits its X-Y data too often to match that interval properly.

Basically, a joystick presents a constant flow of data, but the server is programmed to store the data and only send an update once per 'tick'.

Of course, I may be way off-base -- I'm not a programmer. after all :)

That is the key. We are not using EVE ships here, so the actual EVE servers don't need to be involved beyond a minimal role. We are using the drones, for two reasons.
1. They are small enough to actually dogfight, (even frigates are too big to be agile on this level).
2. The EVE servers have them AI preset to such a simple level, that passing over detail controls to another server can be nearly invisible. EVE players need never see the fancy flying and tactics done by the drones, they can see the regular orbits with damage exchanges as usual.

The DUST servers, by isolating themselves for the planetary battles already, are placed in a very good position to handle this aspect as well.

The EVE server is simply updated on Drone focus, (which ship it is targeting, and therefore orbiting), and damage done by drone. It responds with damage done to drone by the ships.

To the EVE player, the drones are still orbiting the target as usual, and the player controlling the drone is a nearly invisible detail.

What might become interesting, is if opposing drones cross engage, allowing the DUST servers to handle the dogfight, whether the enemy drone is an AI standard, or another player.