stop with the 'sv_fps 30' ffs


(Lekdevil.NL) #41

When I \ref pause when connected to my sv_fps 30 test server, the timer doesn’t stop, but keeps counting down for about 10 seconds, and then jumps back to the original pause time. It does seem however (but I haven’t tested this thoroughly), that a \ref unpause starts the match again at the correct time setting.


(www.ninemil.com) #42

nah that’s a 1.02 thing, it was fine beforehand.


(Majin) #43

:twak:


(Lekdevil.NL) #44

Sorry, but I just tested it with a 1.00 server (ET 2.55 win-x86 May 27 2003) and a 1.01 server (ET 2.55 win-x86 Jun 24 2003) and both show the same behavior.

Also, when running the server at sv_fps 40, the timer doesn’t seem to recycle at all, but just keeps counting down.


(-)iw(-Death) #45


(Lekdevil.NL) #46

By the way, here’s a demo (1.01 server, sv_fps 30): sv_fps30-pause-bug-1.01.zip. Then again, as I said I think this particular bug is strictly cosmetic, as the timer does resume at the correct time after an unpause. I haven’t tested the other issues yet, though.


(ShanK-fOO) #47

This is the best thread I’ve seen on any ET-related forum to date.
Actual discussion and facts and knowledge exchange… keep it up


(weasel) #48

Server frames != client frames. The server runs at a set framerate. As bani has stated, due to a few broken items, this has to be 20fps for everything to function the way it’s intended to. One extra frame means 50ms, regardless of how many frames your video card is drawing. It does make a difference.


(Fusen) #49

yeah I’d have to agree… :huh:


(colic) #50

More than anything, wide sweeping posts like the topic of this one are damaging to the extreme, and because of your obvious status in the community people take your word as gospel, the yes boy posts here are a perfect example. It’s due to that very same reason that the l33t kiddie configs that have ruined competitive RTCW are widely accepted, despite their exceedingly under hand content. Rather than the knee jerk reaction, perhaps if you stood back a bit, did a bit of reading then you might find that you were wrong, and as a result take the wonderful oppourtunity you have in ET Pro to set the situation right and everyone in the community would benefit as a result…[/quote]

You dont make much sense realy. What has someone agreeing with someone got to do with config files and ruining competivie wolf?

Its the competition hosts who decide on the cvar restrictions so dont blame people who make the configs! :blah:


(Rain) #51

Flamethrower range is increased (about 1m for normal cases, although you can get it farther by bouncing the flames off of something else, since this makes them go faster (try g_debugbullets 4)) Neither bani nor myself has made it as far as looking into what’s actually going wrong with the flamechunks yet, since we won’t be fixing the framerate dependencies for the upcoming release of ET Pro. (Too many things to look at and not enough time to test them before release.)

On covert ops uniform stealing: What you describe isn’t necessarily framerate related. When stealing a uniform, the progress is updated a fixed amount of time instead of minding what the actual delta between frame times is, so upping sv_fps will change the amount of time it takes a covert ops to steal a uniform. It takes 50 frames for a covops to take a uniform, so normally it takes 5050 = 2500ms, but at 30fps it’ll take 5033.3 = 1667ms, a fairly significant difference.

I think the pausing bug is mostly cosmetic, since the timer problems while paused should be reset when the match is unpaused.

There are definitely some scripting interactions that need to be looked into–the ‘wait’ command in map scripts always waits x ms, even though waits are often used to delay something by X frames (mostly when spawning.) This probably isn’t a problem unless you want to decrease sv_fps for some reason, though. Still, more digging and testing needs to be done to find everything.

There are a lot of prediction problems (mostly carried over from RtCW), and there may be some framerate dependencies here, but I don’t think that’s the case… I have made several prediction fixes in ET Pro, but none of them have been framerate-related (just about everything uses time deltas there, since the physics code runs every client frame as well…)


(Korollary) #52

No word on fixing this for RTCW and/or ET ? I heard that in Europe they were using higher sv_fps for competition; I suppose they would need that patch.

Thanks to Bani for publicly announcing this for the benefit of the community. Of course that community gets to know what these cvars do in the first place from unofficial sources such as Bani, instead of the developers who even leave the vintage Q3 cvars around.


(www.ninemil.com) #53

Yeah tis a good thread Shank, even if it took a bit of narcing to get it going.

Understand what you’re saying about covert Rain, yeah that is a big diff. Would it be difficult to fix? It can’t be id level content if it’s the covert, so shouldn’t be too hard to pull apart if SD make it easy enough for you with the source?

Flamerthrower’s an unfortunate side effect, and sounds complicated to fix. Atm it’s not seeing much use in the league we run, but that may change. Any thoughts on whether you’ll get a time to look at it for a later release?

This pause thing seems to be giving different people different results. Since 1.02 we’ve found the timer keeps counting, but resets itself properly when the match restarts. Prior to that it was fine, and the results were consistant on both the GAME bookables we used to use for clan practices, and the league servers we host for Savage. Could this be dependant on something else as well as sv_fps?

Colic: I am a competition host, so it’s kinda important to me :wink: If something goes out in the game default, it’s extremely difficult to get people to accept you changing it, even if the benefits are obvious. Here we have a server var that makes a huge difference to game playability, and although there appears to be a few things holding it back, I’m still convinced the benefits outway the problems. The quicker these thgins can be fixed, the better the benefits for everyone. If you want a good idea of what’s possible with sv_fps 30, fire up Q3 CPM at some point and go for a few speed runs round a map, you’ll get a shock :slight_smile:


(rgoer) #54

(ShanK-fOO) #55

i think if everyone knows up front in a league/ladder what the gameplay effects are, namely that…

  • flamer range is slightly longer
  • covertops can steal pants faster
  • matches will pause and unpause properly, but the timer display is b0rked

…then it’s fine to use a tweaked sv_fps in a league/ladder.

The clans themselves will vote with their participation, or lack thereof, in such a L/L.


(Rain) #56

Well, part of the problem is that we aren’t sure of ALL of the effects yet… It needs further investigation (and, ideally, most of the fixes could happen along the way.) These are just some very noticable changes that we DO know about.


(toksic) #57

Is there a connection between sv_fps and snaps?
Am i right if i assume snaps is the max. amount of frames a client will request and sv_fps the max. amount of frames the server will send?

If yes, why do the leagues require snaps=40 and sv_fps=30?

And as somebody already asked, whats up if is set sv_fps to 40?

thx


(www.ninemil.com) #58

The extra data required at 40 completely outweights the shorter client <> server round trip. Generally buggers the server up, especially when a lot of servers have to limit to 10-13k maxrate per client to keep below their data usuage limits. (Obviously when you cap lower than the amount of data the client requires the client’s perspective of the game world fucks up)

snaps to sv_fps is banded, so if you’ve set snaps 20 on a sv_fps 30 server you only get the equivilent of snaps 15, which is a bit of a cunt :slight_smile: Not sure where the snaps 40 thing came from, some thing about being a multiple of 20 and also being more than 30, so thoeritically being a ‘safe’ setting to use, back when people were unsure about how it all worked. Not sure why, it doesn’t work like that, you don’t get anymore snaps than sv_fps afaik, or if you do it’s duplicate data.

If you want a safe setting for snaps, leave it at 40, it’s higher than anything likely to be set and as such should hit the cap set by the server and result in proper data flow. This is true certainly for Q3 and JK engine games; I’m sure someone will jump down my throat if it isn’t for Wolf/ET :slight_smile:


(Rain) #59

As far as I know, the server will not send more snapshots than sv_fps every second. There’s no data there to send for the extra packets, since the server hasn’t run a frame yet and advanced all of the world entities.

On top of that, the server (at least used to) cap snaps at 30, so setting it higher does absolutely nothing at all.

And as somebody already asked, whats up if is set sv_fps to 40?

thx

Still broken, although worse in most cases. Probably won’t trigger the pause bug, though.


(www.ninemil.com) #60

Rain: afaik the 30 cap went out with 1.16n, so it depends what version of the netcode licensees got from id. It’s still f00ked in terms of game feel above 30 tho anyway.