Stuttering 1.1 problems What is going on at ED??

[WhiskeyRomeo]

Fly low to the ground - you'll see it.

I did a low level tour of the Crimea/Caucasus @ 200ft AGL making sure to hit the big towns and a few airfields. No stutters in a server where others were seeing stuttering.

 

Tested this tonight as host (since I can't seem to get stutter working for me)

(2) Is the stutter also present when the aircraft are parked on the ramp, not moving, nested in close to one another as they would be while flying formation?

Tentative answer is no stutters by the 3 clients in my game when parked very close to each other on ramp.

 

edit:

after reading jabog32_zillion's post I went and checked my Lock On\Config\network\config.lua and then my Network options I found I was actually using the 33.6kbps setting. I must not have reset that option when I did my last 1.1 re-install.

abog32_zillion may really be onto something here.

[SilentEagle]

WE have already tested all the available speeds....

 

NO dice!

[WhiskeyRomeo]

Actually I'm more interested in seeing if I CAN get my system to stutter like the rest of you.

 

Still NO dice!

[LawnDart]

jabog32_zillion,

 

You are definitely on to something here!!! Good job! We ran tests using "pingPeriod" of 1 ,2 and 3 (it won't take anything else and reverts back to a 1 if you enter a different number). Not sure if the "stats" set to true or false makes any difference yet, but a "pingPeriod" of 2 and downstream/upstream of 12000 helped a lot although it didn't by any means get rid of the stutter, but it greatly reduced it to a level almost flyable!

 

Question: What exactly is "pingPeriod"?

 

When we have it set to anything other than a "1" it doesn't give you the ping times in game (everyone has a "0" ping). Could someone define what this does. We know it has inluence on the stutter now, but not sure what the values represent.

 

We weren't able to get rid of the stutter, but it's so much reduced we were able to do some of our maneuvers at least. Lets keep working on it! (I feel like I'm a beta tester here... Oh, wait, the game is not beta... Ooops! :icon_redf ).

 

Here are the things we changed from default in the config.lua (config/network/ folder):

 

gameTimeout = 10;

pingPeriod = 2;

maxPacketSize = 500;

playerName = "Yourname";

idleTimeout = 120;

stats {

enable = false;

file = "Temp/mp_log.txt";

};

chat {

height = 95;

log = true;

delay = 10000;

};

serverFiles = {

[1] = "./Bazar/Names.lua";

[2] = "./Bazar/Racks.lua";

[3] = "./Bazar/Types.lua";

[4] = "./Config/Weapons/Guns.lua";

[5] = "./Config/Weapons/DrawInfo.lua";

[6] = "./Config/Weapons/Bombs.lua";

[7] = "./Config/Planes/Pylons.lua";

[8] = "./Config/Planes/Damage.lua";

[9] = "./Config/Planes/AIControl.lua";

[10] = "./Config/Export/Export.lua";

[11] = "./Config/View/Server.lua";

[12] = "./Config/View/Labels.lua";

[13] = "./Config/World/World.lua";

};

configList = {

["xDSL 128/128 Kbit/s"] = {

downstream = 12000;

upstream = 12000;

};

["xDSL 1024/128 Kbit/s"] = {

downstream = 128000;

upstream = 16000;

};

["Modem 56.6K"] = {

downstream = 5000;

upstream = 3000;

};

["LAN 10 Mbit/s"] = {

downstream = 500000;

upstream = 500000;

};

["LAN 100 Mbit/s"] = {

downstream = 5000000;

upstream = 5000000;

};

["xDSL 256/128 Kbit/s"] = {

downstream = 32000;

upstream = 16000;

};

};

client {

port = 10308;

type = "JaBoG32";

server = "217.84.20.194";

serverList = {

[1] = "217.84.20.194";

[2] = "217.162.225.132";

[3] = "66.165.113.50";

[4] = "70.25.211.213";

[5] = "217.162.224.125";

};

};

server {

port = 10308;

name = "LockOn Server";

maxPlayers = 32;

type = "xDSL 256/128 Kbit/s";

interface = "All interfaces";

};

[Slammin]

I was experimenting with those values when serving with 1.02 and from what I could tell, pingperiod made a huge difference as far as server stability. I think this parameter sets the interval at which the server pings the clients to check their latency. I also played around with the max packetsize as well, and setting it to a lower value seemed to stop some of the 'server killer effect', where someone on a really slow dialup would crash the server.

 

Speaking of a different kind of latency, everyone should use this tool:

http://downloads.guru3d.com/download.php?det=951

 

Set your video card to a value of 64 and if you had any video related micro-stutters, this should fix it.

[LawnDart]

Speaking of a different kind of latency, everyone should use this tool:

http://downloads.guru3d.com/download.php?det=951

 

Set your video card to a value of 64 and if you had any video related micro-stutters, this should fix it.

 

Tried it and it didn't help me at all. Might be different for other people though? I still had the "game (terrain) stutter" just as much with a vaule of 64 as with 248, but thanks for the tip anyway.

 

We've narrowed it down to "pingPeriod = 1" in the config.lua (\config\network\ folder) to be the major problem with stuttering so far. We flew tonight at a setting of 2 and the stutter is still there, however only about a tenth of what it was before!

 

Any further insights are welcomed! The Virtual Tbirds (a.k.a unofficial "final-release-beta testers") will keep testing in the meantime!! :cool:

 

LawnDart

[zaGURUinzaSKY]

I am having some of the most pronounced versions of this problem. Every 2-3 seconds there's about a 0.1s studder, for me it seems as if the whole sim is coming to a halt where the ground is of course the easiest thing for ppl to spot but the planes are stopping as well.

 

Same problem here, on internet multiplayer, without multiplayer, with any graphic setting to LOW and 800x600, in ALL CONDITIONS, ALWAYS.

[Mike Cinch Perry]

Just my feeling about this!!!!!

 

Why is it that ED is not, posting to any of our post about the stuttering? Do they know about it and just want to ignore the problem? Or the know about it and are trying to fix it? All of the pilots in the Vert Thunderbirds have been spending night and day to try to get it where we can fly like we did in 1.02 but with the stuttering we cant. It's not a Hardware thing, so whats is going on.... I love lock on esp before 1.1 but I thought 1.1 was going to be the best with all the talk about it thru the web site here and abroad. But all I see is that I wasted $35.00 on something that is not flyable. I have an Alienware system, Very Very High End system... One of the best for the money. So If 1.02 was so rock solid why is 1.1 like it is. Why the change to all LUA files? What was changed that would cause a Host not to see the stutter but the client to see it? Was 1.1 tested with starforce before release? Was 1.1 tested in close formation like the VFTC & the Virt ThunderBirds Fly?

Or was it just tested for Combat. If you by chance just for combat, then that was not a good choice.... lots of people use lockon for formation flying, Just alone on one week we had 10,000 hits to our web site and about 20 people going out to buy Lock On just because they have seen videos like ours. So It looks like that the Vert Thunderbirds are doing Ed a favor and making more sales for ED on 1.1, but here we sit with just a hope and a prayer that someone will atleast answer our posts, instead of asking someone to fix their sig on the fourms!!

 

All we ask is some info in this subject, hell everyone else is getting answers to their questions, but us! Dont think that is good for both ED nor for the people that are waiting for the purchase of 1.1, Many people waiting for 1.1 to go on sale again said they were not going to get it till the see some type of a fix for the stutter! Do you blame them? I dont, I kick my self for running out and Downloading it on first release, I schould have waited a little longer! But Ed got my money, With no answers to our posts, I believe that ED is just saying we got your money and leave us alone!! But enough said!

 

All we ask is for some answers and a fix thats it!

 

Thanks for you time

 

Mike "Cinch" Perry

[Nasder]

I have experienced stutter once... I turned off "on access scan" on my antivirus and the stutter was gone. But this was not online. I am yet to try online out, need to find a nice person/crew who have 1.1 and does only coop.

[Burner_Tbird2]

I think it should be known the studder does not show up on a track replay of a multiplayer session. This info combined with the fact that there is no studder in SP and that changing the PingPeriod has a dramatic affect on studder means that it is a net code issue.

 

Now our biggest lead is the PingPeriod so if anyone has any speculation as to how this value relates to the net code :cough: :beta testers: :cough: :developers: :cough: :cough: this would be a big help. Just from my own tests it looks like PP changes the standard period that a ping signal is compared against. When PP was changed to 2 or 3 in some tests I got a ping of 400+ in others 0 so I believe in certain instances it can actually evaluate the ping ie 400+ and in others it deems it as so high that it is a time out so to speak and gives a 0 value.

 

Now I would think the ping is being fed into some kind of interpolate program where a normal ping, ie under 100, is producing the studder output. A zero ping sends the interpolate program into a default mode of some kind where studder is much less, but of course still prevalent.

 

Another possibility is that the PP value itself is the driver for the interpolate program and the 0 ping is just a side effect of this. But that's a question easily answered by someone with access to the source code :cough: :cough:

 

It seemed to me that the higher the PP the less studder is seen in the sim as a whole but the more "classic lag" is apparent in the lead plane. At a PP=1 the lead is solid but the studder is out of control. That is how we decided on a PP=2 it seems to be the best compromise between the two extremes and allows us to actually perform simple loops and rolls again.

 

I think the next step for us is to tweek the PP into the decimal range between 2-3 I think this is possible as I have seen the program reset its PP value to a very long decimal in the sub 1 range (why it did this I can't remember the circumstances but it did)

 

And of course my theory on the interpolate program is just that, so anyone with more insight please correct me :)

[Jetfire]

Yeah, I bought 1.1 quite a while back, but since I had problems with it online and other events happenning, I just put 1.1 away for awhile. I'm having the same problem with stutter, I get about a 20% (5-6) fps drop, and I tested a few things in the network config file. Lawndart is onto something about the pingPeriod. It seems pinging the server causes the fps drop.

[jabog32_zillion]

To the Ping Period,

 

We dont know for sure, but as it sounds its the period for pinging the host... JaBoG32_Schleudersitz and JaBoG32_Viper came up with it when they set up the JaBoG32 Dedi Server.

 

The up and downstream settings of 11000 are of course by no means recommendable for 56K Modem users or ppl with any connection less than 128 k, its basically just a reduced 128/128 setting which rounds up to 90/90...

 

Also it is generally recommeded for ALL CLIENTS to use the SAME SETTINGS, although for me it helped me even on Servers where other people definitly didn't use the same settings so it might also help the individual in his online adventures.

 

Also reading more of this thread, it seems to me we should generally distinguish between Stuttering caused by to high graphics Settings and Stuttering caused by a to slow server/client connection. The latter is generally described as warping but it is possible that what used to be warping in 1.02 can now in 1.1 also be experienced as a regular stuttering.

 

For me the Online symptoms are:

 

-A Stuttering in regular intervalls that makes the landscape roll my way then stop then continue, and so forth...

 

- A Stuttering every time a text event occours... ie.

"Blue JaBoG32_Zillion kill Blue JaBoG32_Zillion by Aim120C" :) (beware it happens)

 

Hope ED can do something or give advice

 

regards

 

JaBoG32_Zillion

[GGTharos]

No, it is generally NOT reccomended that all clients use the same settings.

 

This used to be true when the LOMAC netcode was Synchronous. Now it is asynchronous and you should you really run at 128/128 or your speed, if it is less.

[LawnDart]

No, it is generally NOT reccomended that all clients use the same settings.

 

This used to be true when the LOMAC netcode was Synchronous. Now it is asynchronous and you should you really run at 128/128 or your speed, if it is less.

 

Care to elaborate a little more on that? What would you recommend for the host (5Mbit cable) and clients ranging from DSL to cable with less bandwidth? How did the ED testers "test fly" FC when you got it to work fine?

 

LawnDart

[GGTharos]

My point here is that there's zero reason to force peopleplaying with a modem to use anything other than their modem speed ;)

 

Everyone else can stick to 128/128 (Whereas the server needs to be maximized for throughput)

[Slammin]

Me thinks 'asynchronous' is the key reason, as you've pointed out GG. Before, an incorrectly configured modem player was definitely a server killer. Sounds like this may have been fixed.

 

If communications are asynchronous now, that would definitely be a plus I would think.

 

I guess I will fire up a server and see firsthand what gives. I would love to use some of the online missions I've created that have events happening long enough that I did'nt have to restart them until I got home from work (when the server didn't crash).

 

Expect a new ground pounding A-10/SU25t FC server up this weekend!

[Slammin]

I just fired up my old 1.02 server because I was curious and this is what I have in my config.lua:

 

pingperiod = 1;

maxPacketsize = 1152;

 

 

Thing is, I don't remember what the default maxPacketsize used to be, but I'm sure it was a value greater than 1152, because I am sure that I've only tried values smaller than the default.

 

I really think if we nail down an optimum maxpacketsize, we will get rid of the stutter, but at what expense, is the question.

 

I will do some experimenting with FC and my server as soon as I get some time.

[GGTharos]

Ok, thanks Slammin.

 

I don't think that'll cut it though, this stuttering is ... just wrong. I mean, it's not that you warp, it's that your whole gaeme stutters - why is the network thread (for pinging the host from the client) blocking the rest of the game?

 

Not right, know what I mean?

[Slammin]

Might be a Windows Priority thing, might be that there is too much info to pass in a maxPacketsize=500 (FC default), and position update packets are being fragmented. My guess is the latter. I'm certainn with 1.02 the maxpacketsize was much larger.

 

LockOn uses about 4 times the bandwidth that IL-2 uses and I'm sure this is because there is a lot more to calculate; Sam sites scanning, clients scanning with radar, etc.

 

I'm going to install on my server here and do some tests, but seeing that my server (which I haven't run in awhile) was set to pingperiod = 1, but my maxpacketsize was adjusted to a non-default value, I suspect that maxpacketsize is the parameter we need to be testing with.

[GGTharos]

Well, my point here is that this shouldn't be happening at all; wether packets are being fragmented or not, it shouldn't be causing stutter on YOUR screen. It shouldn't be STOPPING graphical display. By all accounts, this doesn't cause any warping at all, either, so the network thread -presumably- contiues just fine during this, and something's holding up the generation of the video frame itself. Or maybe I'km wrong altogether ;)

 

 

I've got a squadmate who's running 1.1 with hyperthreading on, and RAMBUS. I wonder if either of those or both are a factor here. He's not getting any stuttering.

[LawnDart]

Our latest findings include: MaxPacketsize of anything lower or higher than 500 seems to either do nothing or make the game run worse. For a while it seemed smoother running at 384, but that was only temporarily. Also, in our missions we don't have any A/I what-so-ever, only 8 client aircraft at the most and that's it, so the stutter isn't based on the amount of information needed to be xfered I think.

 

Also, the network code or game seems to run really smooth and very precise while at the same time stuttering, so it's not the case of poor code or hardware IMO, but something is hogging the xfer from the host to each client.

 

PingPeriod has a huge impact and the only thing we've found that we can say changes the stuttering noticeably. We've also found that the host can leave his set at 1, while each client adjusts theirs to a 2, 2.2xxx, 2.5 or 3 and it will reduce their stuttering (regardless of what the server has). Seems each client can adjust theirs individually so to speak without any influence from the server...

 

LawnDart

[GGTharos]

Okay, please GIVE UP this thought that the transfer to the client is somehow affected until you can prove it; this should NOT cause the drawing of the screen to stop, it should cause -warping- of the other aircraft. Not STUTTERING. YOU send your position to the server, NOT the other way around.

 

This problme isn't so simple - good job on finding that it's related to the host-server ping, but beyond that, some deep interaction is happening with parts of code that it's not supposed to. That's my best guess, anyway.

[Slammin]

Man, I felt so alone when I went through all this when I was hosting and it is good to have you guys test with me. Granted, my primary issue was server crashing. And like you all know, this micro-stuttering wasn't an issue with 1.02.

 

Though I admit I still have not experienced it, I gotta say that I haven't been in a situation where I think I should see it either, but I trust you that it is there. Perhaps I should join you guys for some formation flying.

 

I just installed FC on my server. Gotta get all the activation stuff going now, but again, I will test as much as I can here as well.

[Slammin]

Okay, please GIVE UP this thought that the transfer to the client is somehow affected until you can prove it; this should NOT cause the drawing of the screen to stop, it should cause -warping- of the other aircraft. Not STUTTERING. YOU send your position to the server, NOT the other way around.

 

This problme isn't so simple - good job on finding that it's related to the host-server ping, but beyond that, some deep interaction is happening with parts of code that it's not supposed to. That's my best guess, anyway.

 

 

Since I have not been in a situation where I experience thise stutter, I kind of lead to a 'local machine' issue, which is why I posted the link to that latency tool. It really did do wonders for me in the past. Still, I doubt it will help here though. This might be more than just a local PC resource issue.

 

Let's try to find out what we can.

[aceflier]

Guys have a look at what comes up in google.

 

http://www.google.com/search?hl=en&lr=&safe=off&q=starforce+stutters

 

Almost every game u see with SF on it u can find stutters. Worth a look at least. I find it odd at least. Im all for copy protection but when it interferes with the gameplay its got to go.

 

And, I never got my question answered weather or not the Beta testers used a build with starforce on it.