|
While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to...
Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu.
As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness.
There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security.
|
On April 04 2010 09:36 Adeeler wrote:Show nested quote +While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security.
I hope you have some examples of your 'clever coding techniques' and 'infinitesimal loads' rather than just a very large amount of jargon and accusations...
Also, why has this thread gone so long without posting a single wireshark capture to back up these claims?
|
On March 25 2010 05:00 R1CH wrote:
since latency is generally worse over TCP especially with regard to lost packets.
Map Hacking
it should be possible for the server to eliminate map hacking by only sending unit data for what a player can currently see.
DONT WORRY ABOUT LATENCY
first sorry for my bad english let me add this:
there is no packetloss in TCP and its way more stable, if a packet isnt received it will be resent until it is received and then continue with the next one... :
Blizzard calculate the ping for both players and send delayed packet in a way that both player will almost see thing at the same time.
Even if before it was UDP, with the possibility of sending delayed packet depending on the players ping, Now the actions are going to happen more simultaneously for the players.
Instead of feeling like your computer is skipping some frames when someone is lagging, it will be much smoother.
For the maphacking issue, yea you're right sending data only if the player can see in that range.
but all the data are needed for the replays... you cannot send these data at the end of the game because you never know if a player will drop or something...
The only possible option i can see is that Blizzard would keep all the game data and send them at the end of the game if a player request the replay... but i dont know if blizzard server could handle this... would take a lot more memory and would cause a lot more traffic issue.
So personally i dont think Blizzard will do something for maphacking... game is already beta they cannot change the whole tcp architecture to only send whats in players sight + finding a solution to the replays issue that it would cause....
|
THANK YOU 
|
On April 06 2010 08:19 Tyraz wrote:Show nested quote +On April 04 2010 09:36 Adeeler wrote:While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security. I hope you have some examples of your 'clever coding techniques' and 'infinitesimal loads' rather than just a very large amount of jargon and accusations... Also, why has this thread gone so long without posting a single wireshark capture to back up these claims?
/agreed
There is no explanation as to what "clever coding" is and how it would necessarily guarantee the security of the game state if a client has all of the game data at any given time (ignoring minor discrepancies from lag).
|
On April 04 2010 09:36 Adeeler wrote:Show nested quote +While it is technically possible to reduce map hacking with some clever coding and possibly imperceptible latency compromises, this was not done. The technical requirements for such impose a great deal on the latency of the game, and for an RTS latency is extremely important. Which brings me on to... Yes and No to this paragraph. With todays CPU's the clever coding to reduce map-hackings feasibility wouldn't need to increase latency of the game in terms of the connection with the server only in terms of workload on either the players or servers cpu. As complex a game SC2 seems to be it isn't that complex that clever coding wouldn't reduce the amount of data to be sent to vastly smaller amounts then ppl think are being sent. The only times things could get dicey or pushed to the limit are with 200/200 armies and that is already allowed for with effective responsiveness. There are even ways of virtually eliminating any effective map-hacking with clever coding techniques with infinitesimal loads on even players 'old' cpu's. Why these things aren't done is somewhat a mystery but its quite common practice across the programming industry to code to spec rather then robustly to secure long term job security.
This is a lot of words which say nothing
|
On March 25 2010 15:14 Psyonic_Reaver wrote:
I'm on windows 7 64-bit and I see a DWORD (32-bit) and a QWORD (64-bit) R1CH says to use DWORD but I'm assuming he's on a 32 bit windows program. Should I use QWORD since I'm on a 64-bit?
Use 32-bit.
|
On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares?
This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player.
|
On April 09 2010 20:59 Paladia wrote:Show nested quote +On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player.
Reading comprehension isn't your strong suit. He first states how it is, then how it could be.
|
On April 09 2010 22:04 Hittegods wrote:Show nested quote +On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers?
|
On April 09 2010 23:23 Paladia wrote:Show nested quote +On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers?
You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares?
The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer?
|
On April 09 2010 23:32 Hittegods wrote:Show nested quote +On April 09 2010 23:23 Paladia wrote:On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers? Show nested quote +You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer? You didn't bold the part after. He claims that "this was done out of fairness". Obviously that does not apply to observers. Also, he says "Rather than allow the server to continue if one player is lagging", again, no mentioning of how it is for observers.
No where does he mention how it currently is for observers. I very much enjoy the irony of you attempting to point out flaws in others reading ability, however.
|
On April 09 2010 23:45 Paladia wrote:Show nested quote +On April 09 2010 23:32 Hittegods wrote:On April 09 2010 23:23 Paladia wrote:On April 09 2010 22:04 Hittegods wrote:On April 09 2010 20:59 Paladia wrote:On March 25 2010 05:00 R1CH wrote:
. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? This is definitely wrong. Currently if an observer lags everyone has to wait for him just as if he was a player. Reading comprehension isn't your strong suit. He first states how it is, then how it could be. Please inform me then, where does he state how it currently is for observers? You may notice there is still the "Waiting for players" screen. Rather than allow the server to continue if one player is lagging, it pauses the game for everyone. This was done out of fairness I imagine, since if someone is lagging it would not be fair for them to have to engage the other players army. Technically there is no reason why the game can't keep going similar to how HoN handles latency where only the player lagging experiences any lag. In theory this should allow a large number of spectators to be in a game without impacting the latency for the players - if a spectator lags, who cares? The bolded part is concerning how SC2 handles lag, the italic part is relating to how HoN does it, and how it could be. Are things getting clearer? You didn't bold the part after. He claims that " this was done out of fairness". Obviously that does not apply to observers. Also, he says " Rather than allow the server to continue if one player is lagging", again, no mentioning of how it is for observers. No where does he mention how it currently is for observers. I very much enjoy the irony of you attempting to point out flaws in others reading ability, however.
Right, which is why it's only in theory, not in practice ....
|
After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing  .
|
On April 27 2010 08:07 R1CH wrote:After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
lol. Somewhere in the southern parts of germany, Selector screams "FUCK YEAAAH!" T_T
|
United States12235 Posts
On April 27 2010 08:07 R1CH wrote:After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
I figured. They seemed to be pretty happy with that system in War3, and why reinvent the wheel? (That's rhetorical, obviously there are some significant benefits using a C/S system)
|
On April 27 2010 08:07 R1CH wrote:After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
How did you find out this? I tested it and only had 2 connections coming out, one to their logon server and one to their game server, which gets initiated once i join/create a game. No other connections were going out from the computer while playing.
|
On April 27 2010 08:07 R1CH wrote:After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
maybe because of beta?
war3 is client -> server, right?
why shouldn't sc2 be?
|
On April 27 2010 08:07 R1CH wrote:After some more research it appears SC2 is routed peer to peer rather than server based. Very disappointing .
Why is that? Isn't it better for lower potential latency to be p2p?
|
If it was true P2P like Brood War, that may be the case. But it's routed P2P, meaning all data travels through Blizzard's server first to overcome NAT and other issues. It's the same model used by War3.
|
|
|
|
|
|
EPT
