OT:
This also includes the independent physics and change of internal quakeworld scheduler in both fuhquake and ezquake. Why is it allowed at all?

Force someone who plays with a new modified client (who never played with the old ones, or who perform less good with older, well all does but some players does not because they have not yet explored the power the new ones gave) to play with a old non-modified client (fuhquake not included in "OLD" client. (I have no knowledge of what category mqwcl should be put in but i know that fpsdrops in mqwcl makes bad movement speeds) See if he can play at the same level. I Think not, Because her way of adapting to the game itself comes in with a different approach and she will learn it from the new world order which are currently settled by the client and server developers. The old players will have to re-learn and drop experience-level.

[...]
Ofcourse the most experienced players in movement and aim will be able to perform really good (i doubt dag, interceptor etc would play bader but some really would). But the new ones that came from nothing to something big. Will these players stand a chance versus someone more experienced? Logical not. The hole idea of changing to much stuff in the client really makes me sad because new players which have not seen the old way of playing don't have to adapt to the new thing. Backward compatibleness with the old way will not be gathered, And we will get new players exploiting new features which have not been around for long. Notice the disclaimer of independent physics for example.

It states the physics will be different then the standard? Well it really does not go into deep understanding that someone using it will always gain 100% speed no matter what fps he have, so if something using it and start dropping fps (ruskie for example) he will lag around and hard to hit but he will not lose speed himself. If he used a old client his playing style would be _VERY_ vulnerability in conjunction of fpsdrops. But because of the 'fix' he actual plays better because no one can hit him. This is something that is really noticed on povdmm4. And it really ANNOYS me. Doing same thing in for example mqwcl would just mean you are very EASY to hit.

It really makes no sense to me why someone should be able to play with better basic condition because of the use of client. That's really not a argument but the point is that i want all players to play with the same condition. Changing this very feature (a.k.a bug) may alter old players playing style and thus changing the game itself and the learning curve will start all over from the start. If this was diablo2, the player with most experience points would drop ALOT of experience and go down in level because of theese major changes.

Ofcourse this hole extraordinary line of reasoning may be wrong but i still belive it's easier to perform better in fuh,ez then others.

Best regards,
Raket

It states the physics will be different then the standard? Well it really does not go into deep understanding that someone using it will always gain 100% speed no matter what fps he have, so if something using it and start dropping fps (ruskie for example) he will lag around and hard to hit but he will not lose speed himself. If he used a old client his playing style would be _VERY_ vulnerability in conjunction of fpsdrops. But because of the 'fix' he actual plays better because no one can hit him. This is something that is really noticed on povdmm4. And it really ANNOYS me.

I've must have expressed myself bad. I'm sorry for the convince. What i mean that physfps (because it works in cunjuction with independent fps) itself introduces different mathematical expression itself rather then turning it of at all. Using any /maxfps >= 77 && physfps 77 && cl_independentfps 1 /* orwhatever it's named */)

If you are using this and some program in the background makes a syscall which is the scheduled by the kernel it self the independent fps will not react to the losing of fps because it will flood down the server with a constant stream of 77 fps rather then dropping to a stream of 50 (let's say we have a drop down to 50fps) fps which it would have with a client not supporting, dropping fps means loss in speed because of a not constant flood. However these syscalls may or may not be noticed at all in some clients because the independent fps will flood server with 77fps regardless of what fps the player himself see on his screen and will interpolated it to the player making it easier for him to move around etc.

(Really offtopic)
This is a real problem when using a recent kernel which have a different scheduler then older linux kernels (Don't even try to tell me that for example vsync works at all in 2.6 because it does not, either we get a kernel panic or very unstable fps, escpescial with the svgalib package). What quakeworld does in Windows is that it push the system away and move all lame stuff out of the scheduler (or may move it to another part which have very low priority (That's why you get bad fps when alt+tab in windows, it goes to a sleep scheduler) The scheduler in modern quakeworld clients in linux (for example, may be the same for some windozes) can't push the syscalls for the graphics but for the scheduler taking care of what fps is sent to the client because it's always the same


I think it may be something like this:

Normal client:
77/100% speed....<fps lag lol>... 50fps reporterd... (speed goes down to 90%).... 77 fps reported (speed goes up, but not up to 100% again, rather 99.50 or something because of the drop)

"Modern" Client
77/100% speed... <fps lag lol> ... 77/100% fps reported regardless of whatever fps was in the lag time, the procedure would only go into this state in the client if there was _REAL_ packetlost/U_REMOVE_ON_UPDATE, still reporting 77fps/100% speed..

This is not exactly how it works, but something similair to this must be here.

There's the different. And it's so wrong because it emulates a lag-like frame rather then a fpsdrop because of the indepedent / physfps setting. (Donno which one that triggers it though, it could aswell be the use of realtimeclock rather then gettimeofday() in quakeworld which never counts wrong regardless of what cpuload /syscalls got called we got at all )

Strange things happens and it really annoys me.

It's exploiting the nature.

Lets take the example:

"Superclient" uses the hardwareclock (realtimeclock) to calculate the frames per second (rather the then gettimeofday() which drifts in time if we got to much load or use some syscalls). If we connect this hardware clock to the cl_physfps function in quakeworld it means that the physical movement in quakeworld (eg, what triggers how long, high, fast you jump/move, even calculating time between when rockets can be shooted).

syscalls to hardware clock doesnt have a thing todo with memory or cpuload at all, it will regardless of what load you got always return the right value.


Let's say we put this "atom-clock" into the client and bind it to the physfps / independentfps features.

As everything else in the client is _NOT_ bind to the hwtimer (fps obvious arent because the graphics is drawn by the graphic card and not by the clock). You get something else then what you are shown. You are infact getting more then you see, You can't see it with your eyes, or feel it while playing because you are so used to it. You switch back to qwcl or mqwcl (--nohwtimer in win32x/winxp/etc) and thinks the clients are slow and everything is getting very hard. Movement is very fluctated (eg slow speed etc) if you are on a unstable setup (most linux users for some reason are, they use 'smart' deamons eating cputime which takes cpu usage from qw so it counts wrong and introduce bad speeds, this really doesnt apply to qwcl as it does to mqwcl but it does some.)

What ezquake seems to do is to fix it in a rather stupid way rather then really taking care of real problem at all. Making it harder for other shit to play versus it.

This is because the interval is counted using gettimeofday() in the older clients which is a _real_ process rather then superultradelux clock which have nothing todo what is drawn on your monitor.

Hope this is enough.

I don't really claim this is true but it gotta be something like this. Otherwise fuhquake / ezquake would have the strange movement on clients with unstable setups.

Is it bad? I think. Most players think not since it makes it possible to play on shitty setup. Quake was made for dos then ported to windows.. The Win9x port to quakeworld was optimized. It doesnt drop fps unless you fuck up badly.

Hope you can see my logic. And hope it's true.

...because the independent fps will flood server with 77fps regardless of what fps the player himself see on his screen...

OK enough offtopic.

What if you get a fluctuating drop to 100fps in your client when you have physfps 77 and maxfps 154?

Does the client still say to server it have fps 77? What if this "drop to 100fps" is not a drop to 100fps, rather a drop to 30fps but a avg 100fps? Are we sure the packetrate (77fps) changes to 30fps according to that? If it did. You mathematical lose speed (jumps shall be longer, higher and you should be easier for attacker to get down), but apparently you don't.

Please tell me if I'm wrong. (IN PM on irc) - lets stop this OT.