| Pages: 1 [2] :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 3 post(s) |
Cade Windstalker
854
   |
Posted - 2017.02.22 02:18:54 -
[31] - Quote
Thanks for dropping in CCP Darwin! Great to have some of my suspicions confirmed and my domain knowledge in this area verified :) |
Neuntausend
GoonWaffe
Goonswarm Federation
1585
|
Posted - 2017.02.22 02:32:28 -
[32] - Quote
CCP Darwin wrote:Neuntausend wrote:Oh bloody hell CCP Killjoy Darwin! Can you not once come here and say "Sure, I can do that!". That would be really nice.  I agree, it would be a lot more fun to talk about what we are doing. All in good time. :)
Alright, I will wait. But it'd better be something fun. If it's just the next jump fatigue, I will not strike out the nickname next time. 
PS. I am still mad because of the high res textures. So this is strike two. |
Alexander Bor
Polaris Global
5
|
Posted - 2017.02.22 02:59:41 -
[33] - Quote
There are more important things in EVE that should be done (changed/removed/added) so even such a tool is possible to be put in game (and I believe CCP are able to do it) it's not a time yet.
Anyway I don't see anything bad with summoning a camera man who do all necessary job with data fixation. |
Commander Spurty
1670
|
Posted - 2017.02.22 12:02:53 -
[34] - Quote
I'd just like a dscan.me killmail grabbed centered on the victims location.
If that's "too much effort" time for fresh faces at CCP.
Hint: should be super simple and no additional computation required
There are good ships,
And wood ships,
And ships that sail the sea
But the best ships are Spaceships
Built by CCP
|
Spurty
1670
|
Posted - 2017.02.22 12:02:53 -
[35] - Quote
I'd just like a dscan.me killmail grabbed centered on the victims location.
If that's "too much effort" time for fresh faces at CCP.
Hint: should be super simple and no additional computation required
There are good ships,
And wood ships,
And ships that sail the sea
But the best ships are Spaceships
Built by CCP
|
Nana Skalski
Taisaanat Kotei
28044
|
Posted - 2017.02.22 14:53:08 -
[36] - Quote
But all those moments are meant to be lost in time, like tears in rain. 
Every part of a game helps to tell a story =ƒôò
Where is Angry CONCORD guy when you need him
Osprey =ƒÜÇ
GëíGïüGëí GÖÑ
|
Nicen Jehr
Blue Republic
RvB - BLUE Republic
423
|
Posted - 2017.02.24 05:23:04 -
[37] - Quote
Instead, give us a way to snapshot the client's view of game state and load it in the client. You must have this capability for dev.
This way players can maintain opsec over who shares the snapshot.
A file would be fine, dragging links in the client would be better.
Killing the player session when you open a snapshot would be fine.
As a start, see if you can implement taking a snapshot and viewing it, without any loading capability, at server shutdown.
Many's the time I have turned on my client in the morning to see the shutdown message and no way to see the most recent state of chat windows.
Little Things to improve GëíGïüGëí-á| My Little Things posts
|
Garia666
CyberShield Inc
Triumvirate.
90
|
Posted - 2017.02.24 13:51:01 -
[38] - Quote
its spreadsheet online.. every action is a text based action.. it should be possible to make this.
It hasnt to be 100% accurate.. but mostly.. do something like UDP protocol traffic.. It only sends out and not recieve.
Give the client an option to record all actions vissible on his grid and record it to a file.
create player to play the recorded file and voila ;) . mabe a tool or two to adjust it slightly by the user.. that would have help allot.. |
Reiisha
1014
|
Posted - 2017.02.24 18:41:22 -
[39] - Quote
CCP Darwin wrote:Fek Mercer wrote:Thanks. What about the client only side of the discussion here? excuse any ignorance. Still very hard to implement, and would lack a lot of the information you'd like to see, even things you think you might expect but that aren't actually sent to your client during a fight. It wouldn't necessarily be much better than recording a video yourself.
Wouldn't it be a matter of tapping into the graphics output of the client rather than the gamestate?
All those bits need to be rendered somehow, so the information is getting to the client directly at *some* point. The GPU pretty much has all the information people are asking for, unless somehow some of the rendering is done server-side (which would be horribly inefficient and hilarious).
This also feeds into the UI rendering (for overview data etc to extrapolate information which may not be rendered directly, such as ship models at long ranges).
What about the in-house cinematic tool CCP uses? It can't have been developed in complete isolation of the client itself?
If even that is not directly possible, will it be done in the inevitable upcoming engine revamp? :)
If you do things right, people won't be sure you've done anything at all...
|
Veine Miromme
Center for Advanced Studies
Gallente Federation
59
|
Posted - 2017.02.24 22:10:01 -
[40] - Quote
+P > Accessories > Log and Messages >
multiplied by the number of players
= ¦¦.
Ship Type : Out of pod (for now)
|
|
|
Eli Stan
Center for Advanced Studies
Gallente Federation
658
|
Posted - 2017.02.25 05:45:33 -
[41] - Quote
CCP Darwin wrote:Fek Mercer wrote:Thanks. What about the client only side of the discussion here? excuse any ignorance. Still very hard to implement, and would lack a lot of the information you'd like to see, even things you think you might expect but that aren't actually sent to your client during a fight. It wouldn't necessarily be much better than recording a video yourself.
CCP Darwin, that actually sounds pretty good. Mostly because as opposed to a video recording, the camera drones can be manipulated, I assume, during the playback of such a battle recording, allowing for unique, multiple perspectives to be edited together. Another possibility is that the battle info can be recorded at minimal graphics settings for performance, then played back on a machine capable of rendering at max settings.
I also assume the data stream from the server to the client (plus any relevant input to the client from the player) is significantly less data than a 2560x1440@60fps stream, so that I would be able to record many hours of play without worrying about disk space...
(Obviously I have no idea just how much data is or is not sent to the client.  ) |
Infinity Ziona
Pandemic Horde Inc.
Pandemic Horde
2529
|
Posted - 2017.02.25 07:20:57 -
[42] - Quote
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 GǣWe can see how much money people are making in nullsec and it is, a gigantic amount, a shit-tonGǪ in null sec anomalies. Gǣ*
Kaalrus pwned..... :)
|
Cade Windstalker
913
|
Posted - 2017.02.25 17:02:41 -
[43] - Quote
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
Pandemic Horde Inc.
Pandemic Horde
2529
|
Posted - 2017.02.25 17:56:21 -
[44] - Quote
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 GǣWe can see how much money people are making in nullsec and it is, a gigantic amount, a shit-tonGǪ in null sec anomalies. Gǣ*
Kaalrus pwned..... :)
|
|
|
| |
|
| Pages: 1 [2] :: one page |
| First page | Previous page | Next page | Last page |