Aces High Bulletin Board
Help and Support Forums => Aces High Bug Reports => Topic started by: MachFly on September 10, 2011, 03:45:28 AM
-
Shot a K4 with a 50cal about a foot or two behind the pilot, the bullet flew perpendicular to the length of the fuselage and the pilot still got wounded.
http://www.mediafire.com/?dylcixj1qr48yav (http://www.mediafire.com/?dylcixj1qr48yav)
-
Lag. If there's a bug fix to come of this... shooting someone's wing with a large caliber gun almost always takes off the opposite wing, not the one that got hit.
-
Lag. If there's a bug fix to come of this... shooting someone's wing with a large caliber gun almost always takes off the opposite wing, not the one that got hit.
lag has no effect if neither party is moving.
-
lag has no effect if neither party is moving.
I've seen non moving tanks lag before...
-
I've seen non moving tanks lag before...
How can you lag if your not moving?
-
How can you lag if your not moving?
like lag on runway when your freinds plane start majicly floating in the air and back to the ground again lag
-
like lag on runway when your freinds plane start majicly floating in the air and back to the ground again lag
I have seen that too but that must be a bug...
for example...
Player A is at location <50, 75, 100>
Player B is at location <50, 50, 100>
if player A is 200ms behind player B due to network latency and both players have a velocity of 0, then 200 ms later they will both still be at their initial locations.
Lag occures if say player B is moving at 10 units per 100ms on the z axis. Then the location of player B to player A will lag by 200ms, so..
From Player A's perspective
| time 0 | <50,50,100> |
| time 100 | <50,50,100> |
| time 200 | <50,50,110> |
| time 300 | <50,50,120> |
From player B's perspective
| time 0 | <50,50,100> |
| time 100 | <50,50,110> |
| time 200 | <50,50,120> |
| time 300 | <50,50,130> |
I do not understand how if neither player is moving lag can affect either's position.
-
^ Agreed
-
I think what happened was bunnies FE detected a pilot hit even though machfly's FE showed it hitting lower. So once bunnies FE detected the PW it sent it back to the server which then displayed red goo for machfly to see.
-
How can you lag if your not moving?
Think of the planes that float slowly skyward when a mass of players is sitting on the runways and waiting together. Those floaters are lagging to some degree.
-
Think of the planes that float slowly skyward when a mass of players is sitting on the runways and waiting together. Those floaters are lagging to some degree.
They float when someone makes small movements, in this case neither one of us was moving.
-
In rough laymans terms, lets think of a single object in the game under a player's control.
What the server is receiving from an "uninhibited" high-speed connection: forward forward forward left left right up down left right right forward
What the server is sending to you over an uninhibited high-speed connection: forward forward forward left left right up down left right right forward
Same commands, but lets add some inhibiting (missed/dropped info due to malfunctioning equipment or a limited connection = lag).
What the server is receiving from a "laggy" connection: forward forward ____ ____ left right up down ____ right right forward
I believe, but can be wrong or behind the times on the way its being done in AH atm, but it has been known that in this game (and many other online "shooting" games) the server "smooths" out the flight of those on limited connection by essentially predicting/guessing the pieces of data that get inhibited from those slower connection for those of us with higher connection. So!... same commands still, but now we got some server guessing going on for the blanks so that their flying appears smooth and seemless to the rest of us (and not jerky/laggy every single time a bit of data gets lost, which is also beneficial because this data packet loss can occur for high-speed users too, so overall it "smooths" out the game):
What the server is sending to you over an uninhibited high-speed connection: forward forward forward forward left right up down down right right forward.
This is also why planes float off the ground and skyward for players on laggy connections while sitting on the runway next to those of us whos connection to the server are strong and solid. The server is predicting that the plane was moving in that direction and at that rate. Then when some data gets sent from that laggy player the server goes "oh, wait, no he's back over here" so skip/jump/lag-jerks back onto the runway where he's supposed to be.
As for registering bullet hits from you upon other players, that's all done on your machines end, with the hits being then reported to the server and then to the opponent's computer, which then on their end decides that the 5-cannon rounds you scored on the wing ripped the wing off, and then sends those damage results (the wing torn off) through the server and back to your machine, which then rips the wing off of your opponents plane on your end (thus the delay in shooting an opponents wing and it (or any other damaged part) flying off).
This is all mostly speculation from observation and is subject to whatever HTC confirms or denies as they see fit.
So, to answer your question, they don't have to be moving at all, they just need their connection to skip/lag a bit and the server then reacts by plugging in its own "predicted" bits where the blanks are.
-
In rough laymans terms, lets think of a single object in the game under a player's control.
What the server is receiving from an "uninhibited" high-speed connection: forward forward forward left left right up down left right right forward
What the server is sending to you over an uninhibited high-speed connection: forward forward forward left left right up down left right right forward
Same commands, but lets add some inhibiting (missed/dropped info due to malfunctioning equipment or a limited connection = lag).
What the server is receiving from a "laggy" connection: forward forward ____ ____ left right up down ____ right right forward
I believe, but can be wrong or behind the times on the way its being done in AH atm, but it has been known that in this game (and many other online "shooting" games) the server "smooths" out the flight of those on limited connection by essentially predicting/guessing the pieces of data that get inhibited from those slower connection for those of us with higher connection. So!... same commands still, but now we got some server guessing going on for the blanks so that their flying appears smooth and seemless to the rest of us (and not jerky/laggy every single time a bit of data gets lost, which is also beneficial because this data packet loss can occur for high-speed users too, so overall it "smooths" out the game):
What the server is sending to you over an uninhibited high-speed connection: forward forward forward forward left right up down down right right forward.
This is also why planes float off the ground and skyward for players on laggy connections while sitting on the runway next to those of us whos connection to the server are strong and solid. The server is predicting that the plane was moving in that direction and at that rate. Then when some data gets sent from that laggy player the server goes "oh, wait, no he's back over here" so skip/jump/lag-jerks back onto the runway where he's supposed to be.
As for registering bullet hits from you upon other players, that's all done on your machines end, with the hits being then reported to the server and then to the opponent's computer, which then on their end decides that the 5-cannon rounds you scored on the wing ripped the wing off, and then sends those damage results (the wing torn off) through the server and back to your machine, which then rips the wing off of your opponents plane on your end (thus the delay in shooting an opponents wing and it (or any other damaged part) flying off).
This is all mostly speculation from observation and is subject to whatever HTC confirms or denies as they see fit.
So, to answer your question, they don't have to be moving at all, they just need their connection to skip/lag a bit and the server then reacts by plugging in its own "predicted" bits where the blanks are.
Simple way to test that theory, is there a way to force AH to use a TCP connection? TCP protocol will resend packets if the packet fails to deliver, as such, no packets should be lost and and no smoothing should come into effect.
-
How is this a bug? Did HTC post somewhere that only direct hits on the pilot cause a pilot wound? :devil
-
Simple way to test that theory, is there a way to force AH to use a TCP connection? TCP protocol will resend packets if the packet fails to deliver, as such, no packets should be lost and and no smoothing should come into effect.
Except not, as the smoothing is programmed directly into the engine to attempt to smooth time between packets. The game tries to predict your current vector all the time, meaning the only way to get an exact representation is to use a zero-latency connection...of which only one "official" one exists in HTC's debugging consoles.
-
Except not, as the smoothing is programmed directly into the engine to attempt to smooth time between packets. The game tries to predict your current vector all the time, meaning the only way to get an exact representation is to use a zero-latency connection...of which only one "official" one exists in HTC's debugging consoles.
One would hope that the smoothing code is smart enough to recognize that if neither party is moving, then there is no smoothing necessary.
-
One would hope that the smoothing code is smart enough to recognize that if neither party is moving, then there is no smoothing necessary.
It is, if both parties are on solid broadband connections and updating the server constantly with updates that their planes are absolutley not moving.
Thing is, the nature of this game is that things move... and they move very fast and quickly. Given that, it is also smart to have the smoothing code constantly running in the background. As I said, as much as it's obvious that this is to assist with slow connection users (IE: 56K), it is probabley less obvious that this is also an assist for those of us on stronger connections, as we may not be loosing 10-20% of our data over the connection, but we're still loosing 1-0.1% (so for that 1-second hickup in your connection during a 5-minute long dogfight, your opponent didn't see your plane skip 50-feet).
Overall, it is a fundamental and critical component of the game and it's competitive online playability. To think it is unecessary otherwise is simpley a lacking in understanding the reality of the internet, or a belief that all ISPs are in it for 100% service continuity and quality to their customers above profits - it simpley isn't true.
-
It is, if both parties are on solid broadband connections and updating the server constantly with updates that their planes are absolutley not moving.
Thing is, the nature of this game is that things move... and they move very fast and quickly. Given that, it is also smart to have the smoothing code constantly running in the background. As I said, as much as it's obvious that this is to assist with slow connection users (IE: 56K), it is probabley less obvious that this is also an assist for those of us on stronger connections, as we may not be loosing 10-20% of our data over the connection, but we're still loosing 1-0.1% (so for that 1-second hickup in your connection during a 5-minute long dogfight, your opponent didn't see your plane skip 50-feet).
Overall, it is a fundamental and critical component of the game and it's competitive online playability. To think it is unecessary otherwise is simpley a lacking in understanding the reality of the internet, or a belief that all ISPs are in it for 100% service continuity and quality to their customers above profits - it simpley isn't true.
In the case of the bug filed, neither party was moving. Furthermore it was made sure that neither party was moving for the purpose of reporting it and neither party had been moving for some time (several min) so unless the server didn't update for several min (which is unlikely), the above comment is not applicable.