These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
Previous page123
 

Give us a "battle recorder"

First post
Author
Previous Topic Next Topic
Infinity Ziona
Sebiestor Tribe
Minmatar Republic
#41 - 2017-02-25 07:20:57 UTC  |  Edited by: Infinity Ziona
CCP Darwin wrote:
This topic comes up now and then. As it turns out, it's incredibly difficult to retrofit onto a system that was designed without such recording in mind.

Quote:
Wait, didn't they have something like this for an Alliance Tournament a few years back? I think it was 2013 or 2014, where you could see how the battle played out?

Yes, there was an experimental API for providing live access to what happened on-grid for each match in the AT. My understanding (which is somewhat shaky) is that it relied heavily on the tournament tools that we use internally for setting up and administering each match to generate and publish the data.

As has been pointed out here, such a system would have to record the game state server-side to be able to provide a complete picture of what was going on in a replay, and that would be a huge problem to solve.

I don't expect to see anything like that added to Eve, although I admit that being able to step through a replay of arbitrary in-game events would possibly be the coolest feature ever, if it were possible.

Edit: A feature like that would also raise all kinds of horrible game design problems related to leaking intel after an engagement. I'll leave that analysis to those who think deeply about such matters for a living. I do not.

This doesnt make a lot of sense to me. A lot of the data required for replay is already available. If I recorded data from a fight and then resent it from an emulated EvE server I should still be able to right click look at, zoom pan around ships etc surely?

Edit: nm you already answered the q

Edit: There is one way to do it, 3rd party util p2p that gathers participants individual data stored on their local machine. So you might have 1000 people in a battle the app collects their data and uses it to reconstruct the battle from that data.

In fact that might be a good way to distribute non-essential EvE data. Example: Server sends a person list of local members. Someone jumps into system, instead of server resending to everyone jumping in it sends a code to the first persons client to utilize p2p to send that data to the new person. You could theoretically distribute all non-dynamic server data once instead of repeatedly this way / could be encrypted as well.

CCP Fozzie “We can see how much money people are making in nullsec and it is, a gigantic amount, a shit-ton… in null sec anomalies. “*

Kaalrus pwned..... :)
Cade Windstalker
#42 - 2017-02-25 17:02:41 UTC
Infinity Ziona wrote:
Edit: There is one way to do it, 3rd party util p2p that gathers participants individual data stored on their local machine. So you might have 1000 people in a battle the app collects their data and uses it to reconstruct the battle from that data.

In fact that might be a good way to distribute non-essential EvE data. Example: Server sends a person list of local members. Someone jumps into system, instead of server resending to everyone jumping in it sends a code to the first persons client to utilize p2p to send that data to the new person. You could theoretically distribute all non-dynamic server data once instead of repeatedly this way / could be encrypted as well.


This is a terrible idea and would be *massively* insecure. Just for a start the information you would need the client to know for this to work would be a security leak. "Oh, looks like my client just sent data to 22 people but I only see 20 on grid... cloakies!"

Never mind the potential if you were to start actively fiddling with the data as it's transmitted. Hard to do? Sure. Impossible? Nope, and someone would do it sooner or later.

Lastly this doesn't even save you anything. If the server is sending out a packet that contains the same data the only thing it needs to do in order to get it to multiple clients is adjust its addressing, it doesn't actually need to send the same packet X times for X people.
Infinity Ziona
Sebiestor Tribe
Minmatar Republic
#43 - 2017-02-25 17:56:21 UTC
Cade Windstalker wrote:
Infinity Ziona wrote:
Edit: There is one way to do it, 3rd party util p2p that gathers participants individual data stored on their local machine. So you might have 1000 people in a battle the app collects their data and uses it to reconstruct the battle from that data.

In fact that might be a good way to distribute non-essential EvE data. Example: Server sends a person list of local members. Someone jumps into system, instead of server resending to everyone jumping in it sends a code to the first persons client to utilize p2p to send that data to the new person. You could theoretically distribute all non-dynamic server data once instead of repeatedly this way / could be encrypted as well.


This is a terrible idea and would be *massively* insecure. Just for a start the information you would need the client to know for this to work would be a security leak. "Oh, looks like my client just sent data to 22 people but I only see 20 on grid... cloakies!"

Never mind the potential if you were to start actively fiddling with the data as it's transmitted. Hard to do? Sure. Impossible? Nope, and someone would do it sooner or later.

Lastly this doesn't even save you anything. If the server is sending out a packet that contains the same data the only thing it needs to do in order to get it to multiple clients is adjust its addressing, it doesn't actually need to send the same packet X times for X people.

Its not a terrible idea you simply dont understand it. Granted I dont fully understand how the server handles data either.

From what I understand it does send data to each client individually, if a group of people are on grid and a proteus arrives on grid the server sends that event to each client that needs to know about it. If additional people arrive on grid the server sends those people information about the group and the proteus etc ad nuaseum.

What im suggesting is something like this:

There are 10 people on grid. Each of those 10 people have 100% of the data they need for the current 1 hertz tick. An additional person arrives on grid now the server needs to update the 10 clients with the arrivals info and provide the arrival with all the information.

Now with a irc style intermediary not only connecting each client to the server but each client to each other clients could share data making updating already known by clients faster than 1 hertz and less relient on the server.

Youre imagining Im saying it should be transparent to the user but Im not. In a multi-client system counting how many clients your client talks to is useless unless your client is the only client informing which is very unlikely.

CCP Fozzie “We can see how much money people are making in nullsec and it is, a gigantic amount, a shit-ton… in null sec anomalies. “*

Kaalrus pwned..... :)
Previous page123