.50 cal ammo

[earl1937]

Earl,

This may sound strange but, have you updated any drivers on your PC around the time your rubber bullets started? Have you installed any new programs? Did your antivirus program receive an update to it's engine along with the latest definitions? Have you allowed Windows Update to install hotfixes?

Sometime Windows Update turns things on that you have disabled as part of finishing the update's install.

Do you run a batch file or application befor starting the game to reduce your running services down to about 32-33? This is where Windows Update screws you sometimes because you don't count services after updates thinking MS wouldnt dare do that.
--------------------------------------------------------------------------

Have you turned your router or broadband modem off and let it sit for 10 minutes recently? Sometimes with ATT I have to do that when I get rubber bullets in AH. When I start it back up I also get a new IP address and a temporary halt to automated scans of my ATT IP address by IP addresses registered to hotels in mainland china.

Something to ponder, how old is your router or your cable\dsl modem? A few years back my first ATT DSL modem was getting old and I had a long streatch of rubber bullets. I replaced it and started hitting things again. I've had the same thing happen with routers going bad. Another thing to ponder is if you login to your broadband provider with PPPoE, is your router MTU and network card MTU both set to 1492?

You can download SG TCP Optimiser from here to test your MTU window size for packet fragmentation on the way to the game server. Packet fragmentation can cause rubber bullets.

http://www.speedguide.net/downloads.php/
--------------------------------------------------------------------------

I recently caused my own rubber bullets by installing the latest and greatest ATI drivers for my video card. I had to roll back 3 versions and my .50cals started sawing wings off again. If Hitech was going to change gunnery it would happen during a patch release as a global effect to every player. If your rubber bullets are not happening right after installing the new patch. The source of the problem is anywhere from your PC to the internet path to the game server.
--------------------------------------------------------------------------

Have you run PingPlotter to 206.16.60.38 to see whats happening in your internet path to the game server?

Have you performed normal house keeping of your harddrive like a comprehensive defrag along with a boot time defrag?

Have you checked to see if something is phoning home from your PC that shouldn't be on your PC?
--------------------------------------------------------------------------

Whenever I get rubber bullets and it's not immediately after a game update. I run through this kind of laundry list of steps and it usualy comes down to one of them. More often it's just a bad night, or even a week on the internet between me and Texas.

Understood everthing you wrote in your suggestion to the comma after my name!!!! After that, I am a complete computer dummmmmbie!!! Thanks for your suggestions though!!

[LilMak]

Damage model favors cannons. Damage seems to be cumulative. (So many hits to one spot you lose a peice) A single 20mm hit does all sorts of damage to one spot where as 5 or 6 hits from 50s does less damage because it's spread out. AH doesn't account for radios, gauges, wires, cables, turbos, propellers, controls and all the other little things that could reduce a planes ability to fight yet not render the plane incapable of flight. If .50s in game were as effective as the navy says they were (3 to 1 vs hispanos) jug would have the same snaphot ability as a spit16. It's not even close. This is painfully obvious when gunning down ack.

A .50 bullet will penetrate 1/2 inch of armor @ about 500 yards. I'd like 3 rounds @ HT's car with a Browning from 400 out. (don't even need API) If he can drive it more than two blocks when it's over, I'll accept the in game .50 as accurate. Until then, I'll just deal with the .50s we have.

[Pand]

I'm confused why video settings would cause hits not to register? 

Trying to walk through the process logically:

The round is fired, the computer registers it as a hit, displays the sprite on the video, and sends notification to the server. 

Regardless of what happens visually, I don't understand why it would prevent the notification being sent to the server?

Not claiming to know how it works, just curious as to how the process works.

[bustr]

Earl,

Your loss of "go boom" shooting 50cal in game may be due to a change in the internet between you and Texas.

Or your device that connects to the wall to give you internet access could be old and having problems.

Or your PC may just need normal maintenace like defragging your hard drive and doing something to reduce the number of running services before starting the game.

You got any freinds who work on their own PC's like some of us change our oil and spark plugs? If you do, have one of them read what I wrote then look at your PC. I'll bet it's something simple.
---------------------------------------------------------------------------------

Pand,

I've been a corporate server support engineer for 12 years. The drivers cause more to happen in the background than just displaying the screen. Drivers require CPU and GPU time and can delay the output of internal process data to other processes and functions. Whats happening in the background to CPU cycles or GPU cycles can impact communication to the internet of your go boom messages to the con's local client if there is a delay or congestion. Whats worse is you may only be aware of it as rubber bullets with nothing obvious showing up in the Varyence and Delay.

And the cost for a call to MS Desktop support to open a trouble ticket then help you  run a live debug just to tell you your problem is your current video drivers: Priceless$

Check this link in the TechSupport forum and what happened to me recently:

 http://bbs.hitechcreations.com/smf/index.php/topic,335239.0.html

[Pand]

I don't disagree that it can cause problems, but at most it should still register as a hit and be transmitted to the server.  Unless you're scoring some packet loss the hits should eventually arrive although potentially late.

Will check out your other post and thanks for the info!

[hitech]

There are can not be any dropped packets. If you see a hit it will ALWAYS be scored on the  unless you have just discoed in which case you would no longer be playing.

HiTech

[earl1937]

There are can not be any dropped packets. If you see a hit it will ALWAYS be scored on the  unless you have just discoed in which case you would no longer be playing.

HiTech

The problem has to be my PC on my end! I have seen Colonel Pand land 9 kills in one sortie in a "B" model ponie, so the .50's must be working right, its just that I don't know enough to fix the problem. But, to the rescue, one of my squaddies to going to try to fix my problem. I can handle the flying issues's, just can't always fix tech problems. I am always impressed by the number of people playing this game that are computer experts!! Makes me feel like a 3rd grader.

[bustr]

I was shooting at point blank range for two weeks and either seeing a hand full of scattered sprites or nothing with the tracers just kind of being absorbed into the matrix around the con. After rolling back the video drivers I was sawing wings off again and seeing bright hit sprites close and at distance with visible damage effects.

The latest and greatest video drivers were causing some form of congestion in my PC at my end. It was such that upping the speed of my video memory to match the speed of my FSB caused game CTD. With the drivers rolled back I don't experience the CTD while the video memory is set to the FSB speed.

[Tank-Ace]

Yeah, as I understand it, a hit on your screen is registered as a hit, and sent to the server regardless of what appears on the enemy's screen. From what I've heard, when it happens is also irrelevant. Such as when you continue to take hits after you've been sent to the tower; you havent blown up on your opponents screen yet, so he keeps shooting. When he finally sees you die and stops shooting, you've already been dead for upto a few seconds. Add in the time it takes for the hit signals to stop reaching your computer, you've already been in tower for maybe 5-6 seconds, taking pings the whole time.

Just like warping, which also has its roots in lag and packet loss, only causes an issue with aiming, and not with doing damage, it really doesn't make sense that lag would cause issues with actually doing damage. Although I could see packet loss causing such issues, due to messages telling the server that a hit was made being lost.

[hitech]

Yeah, as I understand it, a hit on your screen is registered as a hit, and sent to the server regardless of what appears on the enemy's screen.

Correct

From what I've heard, when it happens is also irrelevant. Such as when you continue to take hits after you've been sent to the tower; you havent blown up on your opponents screen yet, so he keeps shooting. When he finally sees you die and stops shooting, you've already been dead for upto a few seconds. Add in the time it takes for the hit signals to stop reaching your computer, you've already been in tower for maybe 5-6 seconds, taking pings the whole time.

Not 100 %correct,  he is shooting and hits you multiple times. That burst of hits goes to the server, and the hits are enough to kill your plane, both those hits and the death of your plane are basically sent at the same time to the person being hit. We used to have people always complain that they were killed with 1 hit, but what was happening is that after your plane died on your front all the hits that killed you an were still in queue on your front end were not being played. We changed it so you hear all the hits that had been queued up. So most times you are just hearing the hits that killed your plane after you are in the tower.

Just like warping, which also has its roots in lag and packet loss, only causes an issue with aiming, and not with doing damage, it really doesn't make sense that lag would cause issues with actually doing damage. Although I could see packet loss causing such issues, due to messages telling the server that a hit was made being lost.

There are 2 different types of data transmission over the internet. UDP/TCP we use both types in AH. The key difference is what happens when a piece of data is lost. With UDP if a packet is lost it is gone forever, packets can even arrive out of order.  With TCP each packet has a sequence number, if a computer receives packets 8 9 11, it knows one was dropped. When each packet is received, the receiving computer sends message back saying it received the packet. With packet #10 the computer will send a did not receive message back to the send computer for it to resend packet #10. Packet 11 will not be processed until packet #10 arrives. If the sending computer does not receive an Acknowledgment of any packets it sent with in a certain period of time, it will resend the packet until it receives an acknowledgment.

This is a simple description of TCP , but the end result is data can not be lost. But it can be delayed. So in AH information that must arrive like hits is sent via TCP. Positional update information and voice are sent via UDP, because if a packet is dropped, you really don't want it holding up the next positional update that is sent with newer position.

[icepac]

So the waiting for the retransmission of a missing packet causes a lag much larger than just losing the missing packet itself and waiting for the next packet to update data?

There are more back and forth trips required for the server to request the missing packet and then for your computer to send it to the server?

UDP for the win.

[tunnelrat]

So the waiting for the retransmission of a missing packet causes a lag much larger than just losing the missing packet itself and waiting for the next packet to update data?

There are more back and forth trips required for the server to request the missing packet and then for your computer to send it to the server?

UDP for the win.

If AH was UDP only, there would be a keening banshee wail of hate and discontent over rubber bullets, etc... as hits would simply never be registered in the case of an interruption in data.

To put it even more primitively, TCP is like a telephone call.  You are connected with another party, and if at any point in the conversation you miss something or otherwise do not understand something, you can simply say "What?" and the other person will repeat themselves (unless you are talking to my sister, which is more like UDP, see below)

UDP is the equivalent of a public broadcast, ex: broadcasting over a loudspeaker...  you rattle off what you want to say... the guy chewing his nachos misses 1/4 of it, the old lady scrambling for her hearing aid misses half of it, and the guy with the whooping cough ruins it for everyone in close proximity.  But, the monologue is never interrupted, etc.

The more I learn about AH's netcode, the more impressed I am. 

[hitech]

So the waiting for the retransmission of a missing packet causes a lag much larger than just losing the missing packet itself and waiting for the next packet to update data?

There are more back and forth trips required for the server to request the missing packet and then for your computer to send it to the server?

UDP for the win.

Lag is really not a good term for the issue.

Warps/smoothness of rendering the other guys is the issue. Basically the new position arrives long before any retransmit of a previous position could occur.  Hence since you already now where the player is now, why would you want to know where he used to be.

HiTech



 

[tunnelrat]

Lag is really not a good term for the issue.

Warps/smoothness of rendering the other guys is the issue. Basically the new position arrives long before any retransmit of a previous position could occur.  Hence since you already now where the player is now, why would you want to know where he used to be.

HiTech

So (correct me if I am wrong here) an aircraft traveling in a straight line suddenly warps high and to the right...

If his last known position and heading (that his client relayed to the server) was 0 degrees, 0 climb, 300 MPH, the server will continue to send that to my client until it hears otherwise?

At some point that player made a maneuver (right turn + climb) , but network connectivity issues delay that update on my machine until he is already high and right... 

I am assuming that is basically what is going on behind the scenes when someone "lags" or "warps".

Is there a grace period of X sec/ms before someone is dumped?  Is that secret?

When you receive the "Switching to TCP" message (can't remember exactly what it is) does that ever happen and you maintain connectivity?  Every time I have seen it, it's just a prelude to a disco (which I assume is because that TCP switch-over is processed as a last ditch no matter what the actual issue is).

[bustr]

I will apologise for the bad attempts I've made over the years to describe the game in terms of UDP only for all communications.

 These past few repsonses from yourself HiTech have shined light where I suspect many have either entertained you beyond limit running off into left feilds not in our galaxy. Or driven you to slam your head into a wall over things like collisions, warping, lag switchs, rubber bullets and their various causes.

Of all of the above, the only one now that leaves me confused is the anatomy of rubber bullets. I think after your revelation finaly of TCP and bullet impact communication from client to client. We have been missing the boat in trying to describe and diagnose the issue.

TCP should insure we never get rubber bullets or whatever RB realy means in the game. From what you are saying about UDP and position update timing, RB almost would seem more like the issue of collisions and how the player on each side of the collision saw something completly different. If I'm sitting 100ft off the rear of a con emptying my magazines and seeing no hit sprites, then am I shooting into a delayed position of that con that my PC or internet connection is creating for me?

I experience RB from time to time but, other players have never described me as warping like some of my squadmates do to an extream. They still manage to shoot down other players with the bad warping from their end. When I experience RB I might be able to land a single kill per sortie and possibly have seen a hand full of hit sprites duirng that sortie. When I'm not experiencing it I can very often land hits on any plane I shoot at along with landing more than a single kill per sortie. When I experience RB, rebooting my router and PC very often fixes it. But, if the two Texas routers befor reaching the game server are acting up badly, I have to wait until they stop doing that to see hit sprites or man 88's and 17lb at GV bases for the evening.

Hitech can you help us understand what we have been trying to describe all of these years when we say "Rubber Bullets"?