|
On September 11 2010 08:55 Pewt wrote:Show nested quote +On September 10 2010 11:41 Snowfield wrote:On September 08 2010 23:26 shawabawa wrote:On September 08 2010 22:53 rewsky wrote:On September 08 2010 22:28 Stromming wrote:On September 08 2010 22:03 Teejing wrote:
How can S2 create Hon, a game run on servers and 100% cheat/latency free while
You haven't heard of map hacks? Also, this will surely be fixed in a matter of days. You can't use maphacks in HoN because all of the data is server side. The server only sends what information is necessary to the client, thus preventing the hack in the first place. This isn't feasible for SC2 though. In HoN how many new units can enter the screen at once? like 5? What happens if you scan a 200/200 zerg army in SC2 with that system in place? Like 10 seconds of lag as all the data gets transferred. Even stuff like zergling run-by's would cause huge lag. lol, 200 units are barely some byte, you have no idea what you are talking about. Yes and no. If you are transferring the full information of units when they exit the fog (ie only storing the *existence* of units which the player can see) then you need to send a massive amount of information per unit and thus a large army would certainly lag it. If you are only transferring partial data (say, coordinates) you're right that it's relatively small (I'm guessing they use floats for position so say 8 bytes per unit, maybe 12 depending on how they handle height), but then you run into a number of problems: 1) You can still make a hack that is the equivalent of the "Units" tab, which is half the point of maphack anyways. Sure, you can't intercept their Mutalisks at every opportunity (or something similar), but you still are getting a massive amount of information about what they are doing. Even worse, this is much harder to notice in a replay, so you can think of the "better" but more obvious hacks as a means to catch cheaters, if you will. 2) This yields a lot of problems about how to calculate damage with splash. For example, let's say it's TvT and we have a setup that looks like this (m=marauder, |=cliff, v=viking, s=tank, -=ground): mm|--------vs The player with the tank and viking will see this: -m|--------vs Their tank shoots, and on their computer it damages one marauder (the other marauder's coordinates are unknown!) but on the other computer both marauders are damaged. As a result you basically have to run the entire game server-side (for this and similar issues), by which point you are once again transmitting massive amounts of data to handle large armies. There's probably more stuff that isn't coming to mind as well.
Do You know ANYTHING about game programming or programming in general, or networking for that matter? you just theorize with your imaginary numbers.
This makes you look both extremely ignorant, and just voids all your future arguments.
I'm not even going to try to explain how it really works because you wouldn't be able to comprehend it.
|
On September 12 2010 04:51 Snowfield wrote:Show nested quote +On September 11 2010 08:55 Pewt wrote:On September 10 2010 11:41 Snowfield wrote:On September 08 2010 23:26 shawabawa wrote:On September 08 2010 22:53 rewsky wrote:On September 08 2010 22:28 Stromming wrote:On September 08 2010 22:03 Teejing wrote:
How can S2 create Hon, a game run on servers and 100% cheat/latency free while
You haven't heard of map hacks? Also, this will surely be fixed in a matter of days. You can't use maphacks in HoN because all of the data is server side. The server only sends what information is necessary to the client, thus preventing the hack in the first place. This isn't feasible for SC2 though. In HoN how many new units can enter the screen at once? like 5? What happens if you scan a 200/200 zerg army in SC2 with that system in place? Like 10 seconds of lag as all the data gets transferred. Even stuff like zergling run-by's would cause huge lag. lol, 200 units are barely some byte, you have no idea what you are talking about. Yes and no. If you are transferring the full information of units when they exit the fog (ie only storing the *existence* of units which the player can see) then you need to send a massive amount of information per unit and thus a large army would certainly lag it. If you are only transferring partial data (say, coordinates) you're right that it's relatively small (I'm guessing they use floats for position so say 8 bytes per unit, maybe 12 depending on how they handle height), but then you run into a number of problems: 1) You can still make a hack that is the equivalent of the "Units" tab, which is half the point of maphack anyways. Sure, you can't intercept their Mutalisks at every opportunity (or something similar), but you still are getting a massive amount of information about what they are doing. Even worse, this is much harder to notice in a replay, so you can think of the "better" but more obvious hacks as a means to catch cheaters, if you will. 2) This yields a lot of problems about how to calculate damage with splash. For example, let's say it's TvT and we have a setup that looks like this (m=marauder, |=cliff, v=viking, s=tank, -=ground): mm|--------vs The player with the tank and viking will see this: -m|--------vs Their tank shoots, and on their computer it damages one marauder (the other marauder's coordinates are unknown!) but on the other computer both marauders are damaged. As a result you basically have to run the entire game server-side (for this and similar issues), by which point you are once again transmitting massive amounts of data to handle large armies. There's probably more stuff that isn't coming to mind as well. Do You know ANYTHING about game programming or programming in general, or networking for that matter? you just theorize with your imaginary numbers. This makes you look both extremely ignorant, and just voids all your future arguments. I'm not even going to try to explain how it really works because you wouldn't be able to comprehend it. Thanks for your constructive reply; you've certainly enlightened me on the flaws with my argument with your irrefutable logic.
|
|
|
Yes they do have their hardened shields.
|
|
|
On September 12 2010 06:33 Pewt wrote:Show nested quote +On September 12 2010 04:51 Snowfield wrote:On September 11 2010 08:55 Pewt wrote:On September 10 2010 11:41 Snowfield wrote:On September 08 2010 23:26 shawabawa wrote:On September 08 2010 22:53 rewsky wrote:On September 08 2010 22:28 Stromming wrote:On September 08 2010 22:03 Teejing wrote:
How can S2 create Hon, a game run on servers and 100% cheat/latency free while
You haven't heard of map hacks? Also, this will surely be fixed in a matter of days. You can't use maphacks in HoN because all of the data is server side. The server only sends what information is necessary to the client, thus preventing the hack in the first place. This isn't feasible for SC2 though. In HoN how many new units can enter the screen at once? like 5? What happens if you scan a 200/200 zerg army in SC2 with that system in place? Like 10 seconds of lag as all the data gets transferred. Even stuff like zergling run-by's would cause huge lag. lol, 200 units are barely some byte, you have no idea what you are talking about. Yes and no. If you are transferring the full information of units when they exit the fog (ie only storing the *existence* of units which the player can see) then you need to send a massive amount of information per unit and thus a large army would certainly lag it. If you are only transferring partial data (say, coordinates) you're right that it's relatively small (I'm guessing they use floats for position so say 8 bytes per unit, maybe 12 depending on how they handle height), but then you run into a number of problems: 1) You can still make a hack that is the equivalent of the "Units" tab, which is half the point of maphack anyways. Sure, you can't intercept their Mutalisks at every opportunity (or something similar), but you still are getting a massive amount of information about what they are doing. Even worse, this is much harder to notice in a replay, so you can think of the "better" but more obvious hacks as a means to catch cheaters, if you will. 2) This yields a lot of problems about how to calculate damage with splash. For example, let's say it's TvT and we have a setup that looks like this (m=marauder, |=cliff, v=viking, s=tank, -=ground): mm|--------vs The player with the tank and viking will see this: -m|--------vs Their tank shoots, and on their computer it damages one marauder (the other marauder's coordinates are unknown!) but on the other computer both marauders are damaged. As a result you basically have to run the entire game server-side (for this and similar issues), by which point you are once again transmitting massive amounts of data to handle large armies. There's probably more stuff that isn't coming to mind as well. Do You know ANYTHING about game programming or programming in general, or networking for that matter? you just theorize with your imaginary numbers. This makes you look both extremely ignorant, and just voids all your future arguments. I'm not even going to try to explain how it really works because you wouldn't be able to comprehend it. Thanks for your constructive reply; you've certainly enlightened me on the flaws with my argument with your irrefutable logic.
Np man, next time you want to spew out random information you made up, go to battle.net.
|
On September 12 2010 09:06 Snowfield wrote:Show nested quote +On September 12 2010 06:33 Pewt wrote:On September 12 2010 04:51 Snowfield wrote:On September 11 2010 08:55 Pewt wrote:On September 10 2010 11:41 Snowfield wrote:On September 08 2010 23:26 shawabawa wrote:On September 08 2010 22:53 rewsky wrote:On September 08 2010 22:28 Stromming wrote:On September 08 2010 22:03 Teejing wrote:
How can S2 create Hon, a game run on servers and 100% cheat/latency free while
You haven't heard of map hacks? Also, this will surely be fixed in a matter of days. You can't use maphacks in HoN because all of the data is server side. The server only sends what information is necessary to the client, thus preventing the hack in the first place. This isn't feasible for SC2 though. In HoN how many new units can enter the screen at once? like 5? What happens if you scan a 200/200 zerg army in SC2 with that system in place? Like 10 seconds of lag as all the data gets transferred. Even stuff like zergling run-by's would cause huge lag. lol, 200 units are barely some byte, you have no idea what you are talking about. Yes and no. If you are transferring the full information of units when they exit the fog (ie only storing the *existence* of units which the player can see) then you need to send a massive amount of information per unit and thus a large army would certainly lag it. If you are only transferring partial data (say, coordinates) you're right that it's relatively small (I'm guessing they use floats for position so say 8 bytes per unit, maybe 12 depending on how they handle height), but then you run into a number of problems: 1) You can still make a hack that is the equivalent of the "Units" tab, which is half the point of maphack anyways. Sure, you can't intercept their Mutalisks at every opportunity (or something similar), but you still are getting a massive amount of information about what they are doing. Even worse, this is much harder to notice in a replay, so you can think of the "better" but more obvious hacks as a means to catch cheaters, if you will. 2) This yields a lot of problems about how to calculate damage with splash. For example, let's say it's TvT and we have a setup that looks like this (m=marauder, |=cliff, v=viking, s=tank, -=ground): mm|--------vs The player with the tank and viking will see this: -m|--------vs Their tank shoots, and on their computer it damages one marauder (the other marauder's coordinates are unknown!) but on the other computer both marauders are damaged. As a result you basically have to run the entire game server-side (for this and similar issues), by which point you are once again transmitting massive amounts of data to handle large armies. There's probably more stuff that isn't coming to mind as well. Do You know ANYTHING about game programming or programming in general, or networking for that matter? you just theorize with your imaginary numbers. This makes you look both extremely ignorant, and just voids all your future arguments. I'm not even going to try to explain how it really works because you wouldn't be able to comprehend it. Thanks for your constructive reply; you've certainly enlightened me on the flaws with my argument with your irrefutable logic. Np man, next time you want to spew out random information you made up, go to battle.net.
I'm a programmer.
Pewt's second point is completely retarded.
I'm 99% sure that HoN and other server-sided RTS engines (uhm... if any?) is going to start sending out data about units once they are NEAR the end of fog of war, to try to limit the lag as much as possible.
Also the point is completely flawed because of the point of that if the units positions is stored.. .then the server logic would probably take handle of the units health too, even if you pointed out it wouldn't.
Hmm.. but to defend Pewt. Your (Snowfield) post is completely retarded too. The way HoN works is by dedicated servers. Battle.net does not really use that. And it would cost a ridiculous amount of money to support the 1000000 daily users on bnet servers.
|
On September 12 2010 09:35 cocosoft wrote:I'm 99% sure that HoN and other server-sided RTS engines (uhm... if any?) is going to start sending out data about units once they are NEAR the end of fog of war, to try to limit the lag as much as possible. You're absolutely right and I'm not sure why this didn't occur to me at the time; I guess I was taking the other poster's interpretations too literally. And yes, it would try to smooth out the lag, naturally, but that doesn't mean it wouldn't be transferring a ton of data in a relatively short time, and keeping any fog of war information stored keeps some sort of maphack available. I'm not saying that this lag would be the be-all and end-all of everything, but people with iffy connections can have issues even as it stands.
(You also have an issue with units like Sensor Towers, who would need special case coding (send that there is a unit there but not what it was) which might be inconvenient due to the editor's design specifically attempting to avoid special cases everywhere)
On September 12 2010 09:35 cocosoft wrote:Also the point is completely flawed because of the point of that if the units positions is stored.. .then the server logic would probably take handle of the units health too, even if you pointed out it wouldn't. I didn't say that it would be impossible to circumvent this problem; I specifically said that it would simply require more server involvement in running the game, and as a result require the game to transfer a lot more information than just unit positions when units came in/out of "existence" relative to a player.
|
Pewt, please stop pretending you understand the slightest thing about
a) How unit objects are stored in memory and transferred across the network
b) How this scales up with more units, more players, more games
Programmers are not stupid, a lot of work goes into optimising these things possibly using techniques like hashing, indexing, message compression, rollbacks, server / client side prediction, etc.
Blizzard is just too lazy because it is much easier to reuse the warcraft 3 code base.
|
On September 12 2010 11:08 juw wrote:
Pewt, please stop pretending you understand the slightest thing about
a) How unit objects are stored in memory and transferred across the network
b) How this scales up with more units, more players, more games
Programmers are not stupid, a lot of work goes into optimising these things possibly using techniques like hashing, indexing, message compression, rollbacks, server / client side prediction, etc.
Blizzard is just too lazy because it is much easier to reuse the warcraft 3 code base.
That's not being lazy. That's being efficient. If I had a large code base from an older game, I'd sure as hell reuse it in my new game. If they DIDN'T use it, they're wasting resources and delaying a game 12 years in the making.
|
Some one used this in a game I played recently. Is this bannable? What should I do if I encounter some one who uses this?
|
On September 14 2010 19:13 Alejandrisha wrote:
Some one used this in a game I played recently. Is this bannable? What should I do if I encounter some one who uses this?
Yes it's bannable. After the game click on their name and press "Report Player". If you're really concerned you can email hacks@blizzard.com
|
On September 14 2010 19:35 shawabawa wrote:Show nested quote +On September 14 2010 19:13 Alejandrisha wrote:
Some one used this in a game I played recently. Is this bannable? What should I do if I encounter some one who uses this? Yes it's bannable. After the game click on their name and press "Report Player". If you're really concerned you can email hacks@blizzard.com
Done. Thanks! xD
|
On September 12 2010 11:08 juw wrote:
Pewt, please stop pretending you understand the slightest thing about
a) How unit objects are stored in memory and transferred across the network
b) How this scales up with more units, more players, more games
Programmers are not stupid, a lot of work goes into optimising these things possibly using techniques like hashing, indexing, message compression, rollbacks, server / client side prediction, etc.
Blizzard is just too lazy because it is much easier to reuse the warcraft 3 code base.
Juw, please stop hammering some guy's technical theorycrafting based on nothing but "programmers are clever, Blizzard is lazy".
What he said pretty much holds together. If both players didn't have info on where all units are in advance, yes you'd need to pull their stats when you did a scan. Yes, that would be a pretty small amount of data, however you also want it in a very short time so relatively speaking it's quite big.
How would it scale with more units/players/games? Linearly. How else? Any cost you've got server-side for doing something for one game is going to cost roughly twice as much for two. In terms of simulation maybe you'd get some economies of scale if you ran all (X Process) for all objects all games simultaneously, but your networking stuff can't really benefit from that.
Data compression? Only goes so far. In the end you want to losslessly compress a pile of stuff in a format that will decompress fast (and probably only lose partial data if a packet goes missing).
Client-side prediction and rollbacks, client-side prediction? In an RTS? Really? Maybe I'm about to have a pile of examples dropped on my head of games that have used it beautifully, but what I'm picturing is fleets of units all suddenly snapping to some new course due to a rolled-back order, just after you dropped a storm.
But yeah, you're right, hashing and indexing everything will make everything work just swell.
|
That was so awsome .. Hopefully he doesnt end up warping in Motherships :D
|
Based on the way replays work (a replay is quite a small file, and to get to the end of it you have to play from the beginning, you are never allowed to fast forward past your "play" point) I'd guess that both replays and Battle.net work the same way: they are using the commands issued by the players and executing the rules of the game locally.
The game is a kind of simulation. It starts at a known point and uses known rules (no randomness) to figure out what happens next. The inputs to the simulation are the player actions -- move camera, select units, click here, build a unit, etc.
I expect Battle.net is transmitting these actions synchronously to all the players and spectators. Every local simulation of the game state is in lock-step with every other (maybe there's some lag resolution smarts, but if someone lags you have to wait for them to catch up before the server lets you continue).
In this way, every player's computer knows where everything is on the map at all times. Units emerging from a fog of war don't take extra network bandwidth -- all that was transmitted was the player's click to move them out of the fog. This is why the Warden needs to be present on player's machines -- all of the game data is in memory, so if you can hack it, you can see everything on the map.
Here's a replay of Morrow vs TLO in the Cologne IEM quarter finals. Top-tier players going at 200 APM, and it's a 13 minute game. The replay is only 76 KB. Let's assume replays are compressed at 4:1. That works out to 400 bytes per second for two players. In today's internet that's absolutely tiny bandwidth.
So my totally unsubstantiated theory is that the clients transmit their gamer's actions, all clients have a full picture of what's going on, and the hack here is that one of the clients decided it was okay to build Immortals from a warpgate. The other client didn't verify that this action was "in the rules" which is why its simulation (and everyone's replayed sim) includes the Immortals warping in.
Blizz doesn't run a full server-side simulation of the game, they verify all clients respect the rules with Warden. They might add stuff to clients to check some of these basic rules over time, so someone hacking causes an automatic detection, but they might also just stick with Warden to catch known hacks and player reporting to find hackers.
|
Try to open this with SC2gears and follow his actions to know how he could do it and post it plz. I'm at work ..
|
On September 10 2010 07:43 Malminos wrote:As an italian-american, i am very displeased with this "Wap gate" hack. Let's hope it gets fixed asap! 
On September 12 2010 08:52 ReighT wrote:I suppose as an asian american, I'm even more displeased with this hack? How does race play into this?  And do those immortals really act like them? Because as someone said earlier, their shields seemed to not have that hardened sheild ability to them.
<facepalm>
|
On September 14 2010 21:34 Msqrd wrote:
So my totally unsubstantiated theory is that the clients transmit their gamer's actions, all clients have a full picture of what's going on, and the hack here is that one of the clients decided it was okay to build Immortals from a warpgate. The other client didn't verify that this action was "in the rules" which is why its simulation (and everyone's replayed sim) includes the Immortals warping in.
Blizz doesn't run a full server-side simulation of the game, they verify all clients respect the rules with Warden. They might add stuff to clients to check some of these basic rules over time, so someone hacking causes an automatic detection, but they might also just stick with Warden to catch known hacks and player reporting to find hackers.
Is this normally how RTS games are designed? I only have experience coding and studying net code from other types of online games (mainly MMORPG) and letting the client verify these types of actions seems insane. However, I can imagine that it'd be impractical to verify everything because of the large amount of actions required in an RTS. If everything is verified locally, hackers must feel like they are in paradise.
|
This is quite interesting - I think it's disappointing that these hackers are out there. I'm very interested to see how he did it.
|
|
|
|
|
|
EPT
