Pilot Archive
Thread: Ship Cruising Bug Drops to 0 speed and then back to full power
Page 7 of 7
spatuluk
Wed Mar 09, 2005 9:30 am
#80
the sudden speed drop always happens to me on any fighter I use, but not the booster thing. I don't recall it ever happening during a dogfight, just when I'm travelling in a straight line for any length of time.
Swagga
Wed Mar 09, 2005 10:59 am
#81
I use a Saitek joystick - happens to me all the time, both in fighters and MP ships.
One thing I've noticed is that there's a tendency for the erratic flight that happens to NPC fighters to end just before I "rubberband" - let's say I'm in Kessel and I'm fighting TIEs. They start flying normally, then behave erratically after a bit, making turns and twists that they weren't making before, and you can't seem to hit them if you're lining up the sight with the predictor target (I've noticed you can hit them at this time by aiming right on, or just ahead of the fighter, though). If you watch them carefully, they seem torubberband after a bit, and then their flightreturns to normal - and then about a second later, my ship rubberbands as well.
My guess isthat it's related to server-client synchronization, but it could bemany other factors I'm not aware of, or those I'm not willing to consider - such as having to upgrade my cable connection.
Maybe a new joystick is in order for me 
Tyyylowyspetily
Fri Mar 11, 2005 11:32 am
#82
My vote is for some sort of server "boundry" issue. I notice this happens at the same point in space, each and every time that point is crossed. Try this out:
Jump to tatooine space, miner's yard I think is the name of the HP.
Head for the dust cloud and large group of Valarian and Hutt Kimos.
En route, your throttle will cut out, then kick back in.
This is only one example. I happen to rememeber this one in particular, because I ground out the lower tiers of pilot on those spawns, and made the trip several times each day. I don't think it's a coincidence that the bug appears at particular regions, and I also think that the other item I have observed, which is that enemies "redraw" at the same instant the throttle cuts out, indicate a server boundry of some sort has been crossed.
padren
Fri Mar 11, 2005 1:46 pm
#83
One thing is for sure:
Whether its lag, space boundries, or Venusians, the 'throttle down' is definately code caused. Maybe the 'delag' rubberbanding code and the boundry crossing code use the same 'drop you in' code and it drops you in at a x,y,z but with no speed vector data, forcing you to reaccelerate.
Even if the rubberbanding can't be fixed (where x,y,z pop back to old or server based values) the throttle down should be fixable.
Just a side note, and it may be naive, but in any fps twitch game that I've played over the internet (which are few) I have not experienced the level of network trouble that is caused in swg (rubberbands, drunken bees, nohit'ems etc). Granted, swg has more to deal with in its load balancing of sheer user count per area, loading and unloading of people into shared regions, etc, but to say that 'lag is lag' ignores that networking code can often be improved to some degree.
And a side side note, (since its late and I am really tired) it would be really great if the game told you when it suspects the connection is flaking out. I always have my stats box up (frame rate, ping speed, lost packet info box) and while I never once saw a lost packet noticed, I do get the 'impossible to hit' bug where you shoot, and the client side effect of shields is seen, but nothing registers on the server so the enemy shields don't go down. If the client sees you hit, it should be able to anticipate that the server will report it soon. When it doesn't, consistently for a few rounds, it would be nice if it forced a server to client synch and cross-checked by throwing a bit of data back and forth.
We can't blame SOE for people's connections to their servers, but I think the effects of these connections of varying quality can be managed better in the code.
Whether its lag, space boundries, or Venusians, the 'throttle down' is definately code caused. Maybe the 'delag' rubberbanding code and the boundry crossing code use the same 'drop you in' code and it drops you in at a x,y,z but with no speed vector data, forcing you to reaccelerate.
Even if the rubberbanding can't be fixed (where x,y,z pop back to old or server based values) the throttle down should be fixable.
Just a side note, and it may be naive, but in any fps twitch game that I've played over the internet (which are few) I have not experienced the level of network trouble that is caused in swg (rubberbands, drunken bees, nohit'ems etc). Granted, swg has more to deal with in its load balancing of sheer user count per area, loading and unloading of people into shared regions, etc, but to say that 'lag is lag' ignores that networking code can often be improved to some degree.
And a side side note, (since its late and I am really tired) it would be really great if the game told you when it suspects the connection is flaking out. I always have my stats box up (frame rate, ping speed, lost packet info box) and while I never once saw a lost packet noticed, I do get the 'impossible to hit' bug where you shoot, and the client side effect of shields is seen, but nothing registers on the server so the enemy shields don't go down. If the client sees you hit, it should be able to anticipate that the server will report it soon. When it doesn't, consistently for a few rounds, it would be nice if it forced a server to client synch and cross-checked by throwing a bit of data back and forth.
We can't blame SOE for people's connections to their servers, but I think the effects of these connections of varying quality can be managed better in the code.
Page 7 of 7