OpenArena Message Boards

Can someone please offer me a solution to a noob who keeps switching teams to be on my because im better then him? Its really annoying!!! if i wanted to fight bots i would play by myself! and if anyone knows the admin of "ctf4ish only (tonido^) please ban artur for his stupid behavior! even when we had 4 ppl he kept switching to be on the winning team and everyone had to rebalance which was fucking annoying(and he sucked,cuz he would do is just go for the bfg, so no matter who he was paired with, that team started losing) Or at least turn on voting for the server so we can kick ppl like that. But why isnt there something that limits you to 3 team switches a minute and make switching to spec not count but switching from spec to a team count. or something similar because you cant always kick but you can always run into assholes who ruin your day >:(

I have had the same thing happen from time to time where a noob follows me around like a lost little puppy dog. I first try and explain to them that it ruins the game some then switch back others don't. The ones that don't I will kick if I can if I can't I just leave or treat it as a pratice match and just pratice moves or jumps. Also don't let people like them or any other of the many types of aholes ruin your day because they are not worth it, it's best to just move on and not give them what they crave most attention.

There is already g_TeamForceBalance, server-side, which is meant to prevent this kind of behaviour.
It's rarely used online because sometimes you like to have some flexibility to change teams, added to the annoying 5secs delay each time you switch.
Maybe this mechanism could be improved, but I haven't much thoughts for it yet.

Anything forced sucks (85fps emulation on ur 085 servers caca? :/). Just kick whoever joins the winning team, or ban them after a couple times.

pmove_float 1, as it is default in OA 0.8.5, so physics may seem low if you come from 081 with high fps.

Just to bring me up  to date: what was the necessary solution to fix this on .85 servers with pmove_float 1?

Reduce g_gravity (maybe 756 is the correct value, default 800).

Or not fix it, we can also consider this isn't really an issue. Maybe lower gravity can be more fun, but for now I simply adjust it to 790 on specific maps which have uncrossable parts otherwise.

This is the reason for asking.
It is not as funny as before, if you play ps37ctf without being able to jump on top of the bridge ;)

Is that what the option in the 'create multiplayer game' menu does? One of the possibilities is 'Fixed framerate 125Hz'.

Which is a little bit too high.
On ps37ctf you can get on the wall by just jumping against it, when you get on the highest point of your jump you step on. Most ppl do that on 081 as well, but in with some good timing it's also possible to jump on without loosing your speed (you get on at once instead of hitting the side as well). This is a key factor in the gameplay on that map (especially in instantgib). I get it right about 3/5 times I try on an 081 server, but never managed in 085 yet... Keep loosing my speed completely every time I jump on it.
So if you could just emulate the 125fps....

Could you make a 081 demo of it ? I'm stone so I'd prefer to see to get the idea.

HEY! dont hijack my rant with your talk about gravity!

That option sets pmove_fixed to 1 and pmove_msec to 8 (8 milliseconds per frame makes 125 frames per second).

Edit: explanation

The server calculates player movement in discrete steps to be able to synchronize all players in a game. This means it must round players actual positions to some discrete value. Because the amount of information a client sends to the server depends on its frame rate, clients running at different FPS will get their positions rounded differently. This means the original OpenArena physics were frame rate dependent, and in practice this means you can jump higher than usual at some com_maxfps values and lower than usual at other values. This gives players with a good graphics card an unfair advantage over other players because they can crank com_maxfps up to the sweet spot values of 125 or even 333 and make jumps other players can't. You can still activate these physics by setting pmove_float and pmove_fixed both to 0.

To solve this problem they made the server round all players positions in the same time interval, independent of the amount of data the clients send to the server. By changing the time interval on the server you get the same effect as by changing com_maxfps on the client, but for all clients simultaneously. In practice this means all players get the same physics and can jump the same height. This is fixed frame rate physics and can be activated by setting pmove_float to 0, pmove_fixed to 1 and pmove_msec to the time interval (1 for 1000 fps, 2 for 500 fps, 3 for 333 fps, 4 for 250 fps, X for 1000 / X fps). This sounds wonderful but there are still rounding problems which occur when the clients run at much lower frame rates than the server is set for, resulting choppy movement (you can try this out yourself locally: set pmove_float to 0, pmove_fixed to 1, pmove_msec to 3 and com_maxfps to 62 and you're choppy).

The final solution was to avoid rounding errors all together by calculating the player positions in a different way. This is the default accurate physics and can be activated by setting pmove_float to 1.

Hmmmmm.
If there is pmove_float 1, it should have same physics like i had in .81 with com_maxfps 125 or in .85 with pmove_float 0, pmove_fix 1, pmove_msec 8 (as long as my hardware is fast enough to do the 125 fps)?

If so, i can´t believe, because it is much harder to enter the wall on ps37ctf with .85 then doing it in .81 settings till now.
Players fault, wrong server settings all over the world, something wrong in all configs or maybe just a codebug?

Is there a .85 server without gravity settings, where i can do this jump?

No, pmove_float uses real Quake 3 physics without rounding every frame. For maps with standard gravity this means the players will jump higher than with 90 fps but lower than 125 fps and a lot lower than 333 fps. On a low gravity map like void4 players will jump higher than with 125 fps but lower than 90 fps.

The name is because it transfers positions in floating-point format instead of integers. No further tweaking was done to make it feel like 90 fps or 125 fps, it hits somewhere in between. One can play with g_gravity to get it to feel like a different framerate.

Yes, your own :)

Just start the game in skirmish mode and select 'physics: framerate dependent' in the map settings screen. That gives you the original .81 physics. The new accurate physics (pmove_float 1) is not the same as frame rate dependent physics because there are no rounding errors anymore, and it's those rounding errors that make you jump higher.

Edit: added a little explanation to avoid confusion.

http://easy-upload.nl/f/9eXgoIPk
Run it in 081, in 085 it errors about it's item range ([0-60] or something).

Thanks, that was what I'm looking for. Already thought that the gravity couldn't be the real solution to this, like most admins are applying now :)

Well, the pmove_fixed solution has its drawbacks also (ie. the choppy movement of players with low com_maxfps values), they didn' t come up with pmove_float for no reason.

The real problem is that the 125 fps frame rate dependent physics became so embedded in the quake scene that scores of maps were designed around the assumption that all players run their clients at com_maxfps 125. This wasn't a big problem as long as there weren't any graphics cards around that could run at 333 fps, but frame rate dependent physics at 333 fps is ridiculous (333 fps jump height example (http://www.youtube.com/watch?v=6z7cyRh2eWg)).

So pmove_float really is technically the correct solution and fiddling around with g_gravity is just a band aid for not having to redesign the old maps. (Another solution would be to server side cap com_maxpfs at 125, but that would still put players with hardware that can't produce 125 fps at a severe disadvantage.)

Summary:
on .85 servers the solution for the 125 fps problems is pmove_fixed to 1 and pmove_msec to 8.
This "emulates" com_maxfps 125 on server side for all hardware which can produce 125 fps min (if not, you get some chops during the game - like lag?).

pmove_fload 1 would be the right choice, but because many maps are designed for the com_maxfps 125 settings, it just works in theory.

Now i realy understand, why most ppl do not like .85: it destroys gameplay on many maps and thie solutions or workarounds just dirty ones - from players view!

Why was it done? The gameplay is much different from .81, because the maps don´t work as they did before. I thought, oa should be as compatible as possible :( (no offense, just curious!)

http://openarena.ws/board/index.php?topic=1908.msg25366#msg25366

And

http://openarena.ws/board/index.php?topic=3806.0

May help.

EDIT: This post, too. At your own risk.

http://openarena.ws/board/index.php?topic=3756.0

Because nowadays people with even better, modern hardware can set com_maxfps to 333 and make even higher jumps than all the people running at com_maxfps 125 in OA .81. As long as the in-game physics are frame rate dependent, players are caught in an arms race to get the fastest possible graphics card. Fixed frame rate physics was a nice try but it made online games unplayable if there were noobs with wrong com_maxfps or cl_maxpackets settings on the server.

So the choice was between three evils:
1) Do nothing and let the hardware fetishists rule the game because they can jump higher and thus further with their killer hardware.
2) Go on with pmove_fixed and ruin the game for newcomers and seasoned players having to play with newcomers because of wrong client settings or insufficient hardware.
3) Introduce pmove_float and solve all of the above, but limit jump heights (and thus distances) to under what people playing 125 fps physics are used to.

You pick the lesser evil ;)...

And... ahm... ¿what would be the good?

Ehh? Destroying all graphics cards in the world that are capable of producing more than 125 fps would be the only possibility to maintain the status quo and keep the game engine as it was.

The quake 3 engine is more than 11 years old and I think no one back then expected that it would ever be run on 3d accelerated hardware capable of putting out 333 frames per second (which gives the graphics card a mere 3/1000 of a second to render an entire frame, and that at today's insane resolutions). At the time the engine was written, not even the most sophisticated and expensive graphics workstation in the world was capable of such performance.

Hmm, in a couple years we'll all be running 1000fps :O
Though the 1000fps jumps suck, but you can slide on every floor :P

But seriously, it's actually amazing to notice the development in calculation power like this.

The trick is to make a little script that enables you to select different com_maxfps, cl_maxpackets and cl_mouseaccel settings with a single key press so you can quickly switch to the 'special options' fps of choice before doing your 'impossible' trick and go back to normal fps so you can remain in control of your movement.

This way you get the advantages of specific com_maxfps settings without any of the disadvantages (like overshooting pads set for 125 fps physics), and this is also the reason why something has to be done about it, be it pmove solutions or com_maxfps caps.

Which means, that we have to put our hands on some maps to make them compatible with .85...

There's also the option of improving the 125hz and 91hz choices, but that's left to Sago.

BTW, in the CPMA competitive guide (which a lot of people like to refer as the "level design 101" guide) it's stated that designing maps with framerate-dependant jumps in mind are a bad idea.

EDIT: Fixed a wording mistake.

There is also the option of building a 'gravitational constant' cvar into the engine that should be multiplied to g_gravity when in pmove_float 1 mode. Just set this server cvar to the right factor and the problem would be fixed for all maps with standard 800 gravity without having to do dirty hacks with g_gravity in the map rotation.

I personally think this would be the most elegant solution to emulate 125 fps physics in pmove_float physics mode (it also wouldn't interfere with the fixed frame rate and frame rate dependent physics modes at all).


Hehe go and tell that to the defrag guys, but you better put on some protective gear first, just in case... ;)

sago, could you implement such kind of solution?
i have this old maps in mind, which can´t be edited by us...

I guess Sago implemented something like that (http://openarena.ws/board/index.php?topic=3806.msg34192#msg34192) in OAX (http://openarena.ws/board/index.php?topic=1908.0).

BTW, this is the part found in the guide which I was talking about, thankfully saved here (http://www.goodstuffmaynard.com/portfolio/other/cdg/index.html), since the Promode Wiki dissappeared.


And I know (http://openarena.ws/board/index.php?topic=2170.msg28443#msg28443) the level of douchiness the "competitive" people (a.k.a. the "Stop Having Fun Guys (http://tvtropes.org/pmwiki/pmwiki.php/Main/StopHavingFunGuys)", people who give a bad name to the competitive people who are really nice, I tend to call them the "Adon"s -if they're good and arrogant- or "Dan Hibiki"es, -if they're both bad and arrogant- as opposed to the "Ryu"s) can reach. :)

(BTW, click the SHFG link at your own risk, you might have your life ruined forever when you start navigating that wiki. Personal experience. -.-)

I've been playing around with oaxB47 for a bit. If udi's g_gravity value of 756 is right then the correct g_gravityModifier factor should be 756/800 = 0.945 which does feel like 125 fps physics to me when I play pmode_float 1 (maybe the jumps are slightly too high, got to test more).

So I guess the correct solution would be for the server admins to start a grassroots action to get b47 elevated to the status of an official patch and get cracking with pmove_float 1 and g_gravityModifier 0.945. If there isn't a real release coming soon that is... ;)


Oh noo, another time sink (in other words a great site, thanks) :)

We can speed up that release if we could get more texture artists to help with the texture replacements for the Q3/TA maps. :S That's the main objective for 0.9.0.

Would a code-only 0.8.6 patch release be out of the question, considering it would probably silence a lot of the criticism about the physics change and keep the player community alive?

It's a shame we can't use Paul Marshall's xcsv_bq3hi-res.pk3 by the way...

This article reminds me of the character Jermany from Pure Pwange in everyway.

Also these type of people rage hard and it is funny as see in the youtube videos below

http://www.youtube.com/watch?v=-rAtlp2dDPU

http://www.youtube.com/watch?v=D70Hxro_agU&feature=relmfu