does it happen more or less often with 0 ?Noobie wrote:It happens with pmove_fixed 0 too (tested on ND80 grotto).bani wrote:can anyone reproduce the scoreboard problems when pmove_fixed is 0? does it only happen when pmove_fixed is 1?
ET Pro 3.0.10 testbugfix released
Moderators: Forum moderators, developers
What is default setting for pmove_fixed? if its 0, then Yes I have this problem all the time, and I never added that setting to my server or client configs.bani wrote:can anyone reproduce the scoreboard problems when pmove_fixed is 0? does it only happen when pmove_fixed is 1?
{Zer0}'s House of Torment 67.19.67.118:27960
{Zer0}'s RTCW server 67.19.67.119:27960
Now Lets Go Kick Some ASS
And thats an Order.
{Zer0}'s RTCW server 67.19.67.119:27960
Now Lets Go Kick Some ASS
And thats an Order.
Just for the record, is it b_fixedphysics as in, It was broken first, but we fixed it(repaired), or as in It was variable first, but now it's fixed(static)?
Setting fixedfps to 333 makes you pull off some really weird stuff , I never knew trickjumping was so fps dependant. Setting it to 999 won't allow any trickjumping to happen at all, which wouldn't be so nice if someone would set that on a server .
Setting fixedfps to 333 makes you pull off some really weird stuff , I never knew trickjumping was so fps dependant. Setting it to 999 won't allow any trickjumping to happen at all, which wouldn't be so nice if someone would set that on a server .
another bug??
I dont know if this is abug but done this on oasis:
startet my own dedic lan server w/ etpro 3.0.10
spawned allies
constructed comm post
bomed da wall then jumped into the old city waterpump but it wasnt built
so i wanted to go back and i cant!! there was like a wall!!
After a few deads i pressed jump so i moved up and there was like a lil window where i could go trough...
ok look the demo plz and tell me its not a b_u_g!
http://home.arcor.de/basicman1/DEMOS/20 ... asis.dm_83
startet my own dedic lan server w/ etpro 3.0.10
spawned allies
constructed comm post
bomed da wall then jumped into the old city waterpump but it wasnt built
so i wanted to go back and i cant!! there was like a wall!!
After a few deads i pressed jump so i moved up and there was like a lil window where i could go trough...
ok look the demo plz and tell me its not a b_u_g!
http://home.arcor.de/basicman1/DEMOS/20 ... asis.dm_83
- IdNotFound
- Posts: 197
- Joined: Wed Dec 03, 2003 8:21 pm
- Location: Brazil
- Contact:
Fixed as in "it should never be dependent on client fps and we are so leet we fixed it just for you", I guess...V6.Sven wrote:Just for the record, is it b_fixedphysics as in, It was broken first, but we fixed it(repaired), or as in It was variable first, but now it's fixed(static)?
Setting fixedfps to 333 makes you pull off some really weird stuff , I never knew trickjumping was so fps dependant. Setting it to 999 won't allow any trickjumping to happen at all, which wouldn't be so nice if someone would set that on a server .
About the 999 fps, you might wanto to check this article out... To save you some time, 333 is the leetest you can get. Not sure if there is some ABSURD value higher than that or with 4 digits that can do better, nor if the engine can support 4 digiits But for vanilla Quake III Engine, 333fps is still the highest achieved framerate so far that could perform good jumps I guess...
Anyway, the article (not mine, but pretty good. could be added to the ETPro Documentation of b_fixedphysics IMO)...
Why Your Framerate Affects Jumping
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html
nZ/IdNotFound
NaZGûL TeaM Leader
SAWL Tech Staff
NaZGûL TeaM Leader
SAWL Tech Staff
Don't know if this should count as a bug, but anyhow:
When using b_optimizeprediction and having a fps higher than 333 it f***s up movement. At 500fps steady i move very choppy and slow, as if i had 3-4 fps. Trying to cap fps higher makes mine stop somewhere around 570fps, and then it won't update anything i do (all movement except mouse is "frozen") until my fps drops below ~570 or i pull down my console. This is totally independent of pmove_fixed and/or b_fixedphysics.
And to the fps/jumping link in the post above: seems like a load of bull to me. It doesn't explain why certain fps works good and others don't. According to that model both 125fps and 333fps are "bad" fps.... gg wp.
ps. does anybody know why the fps that work for jumping actually work?
When using b_optimizeprediction and having a fps higher than 333 it f***s up movement. At 500fps steady i move very choppy and slow, as if i had 3-4 fps. Trying to cap fps higher makes mine stop somewhere around 570fps, and then it won't update anything i do (all movement except mouse is "frozen") until my fps drops below ~570 or i pull down my console. This is totally independent of pmove_fixed and/or b_fixedphysics.
And to the fps/jumping link in the post above: seems like a load of bull to me. It doesn't explain why certain fps works good and others don't. According to that model both 125fps and 333fps are "bad" fps.... gg wp.
ps. does anybody know why the fps that work for jumping actually work?
the q3 engine can't handle really high framerates, it tries to flood the server with too many commands and some get dropped.
this is a fundamental q3 engine design issue that affects all q3 based games, and is not easily fixed.
with b_fixedphysics though, there's no point in having com_maxfps higher than your monitor's refresh rate since you'll move the same regardless of fps.
It wasnt really ever a widespread problem with ET before b_optimizedprediction, since not many people could easily get 333fps. They can now
And the fps link does explain q3's fps-based jumping distance issues perfectly. It's accumulate rounding errors as the link explains and the code demonstrates.
One of the things b_fixedphysics does is no longer round movement, so there are no rounding errors to accumulate. This comes at the cost of slightly higher bandwidth due to the way the q3 network protocol works.
this is a fundamental q3 engine design issue that affects all q3 based games, and is not easily fixed.
with b_fixedphysics though, there's no point in having com_maxfps higher than your monitor's refresh rate since you'll move the same regardless of fps.
It wasnt really ever a widespread problem with ET before b_optimizedprediction, since not many people could easily get 333fps. They can now
And the fps link does explain q3's fps-based jumping distance issues perfectly. It's accumulate rounding errors as the link explains and the code demonstrates.
One of the things b_fixedphysics does is no longer round movement, so there are no rounding errors to accumulate. This comes at the cost of slightly higher bandwidth due to the way the q3 network protocol works.
- KingJackaL
- Posts: 666
- Joined: Thu Jan 08, 2004 3:47 pm
- Location: ChCh, NZ
- Contact:
No, that link DOES explain it. Make sure you read ALL the posts - even the last one adds new information that is needed to understand the problem.abrrad wrote:And to the fps/jumping link in the post above: seems like a load of bull to me. It doesn't explain why certain fps works good and others don't. According to that model both 125fps and 333fps are "bad" fps.... gg wp.
ps. does anybody know why the fps that work for jumping actually work?
maybe its just me then. 43, 55, 76, 111, 125, 250 and 333 enables me to jump on the "big boxes". 166, 142 and 83 don't, even though they should accumulate more positive error than 43.
111, 250 and 333 should be generating negative error, still they work like a charm. 125 shouldn't generate any error at all.
What am i missing here?
111, 250 and 333 should be generating negative error, still they work like a charm. 125 shouldn't generate any error at all.
What am i missing here?
where did you get the idea that 125 would generate no error at all?
where did you get the idea that 333 would generate negative error?
here's the calculated accumulated error:
where did you get the idea that 333 would generate negative error?
here's the calculated accumulated error:
Code: Select all
fps +error
--- -------
30 6.67
31 3.87
32 21.00
33 16.67
34 10.35
35 3.29
37 9.08
38 23.68
40 27.00
41 13.17
43 11.47
45 6.67
47 30.34
50 33.00
52 21.54
55 16.82
58 8.07
62 3.97
66 38.67
71 34.42
76 24.16
83 20.24
90 6.67
100 67.00
111 58.67
125 50.40
142 34.79
166 20.24
200 135.00
250 134.40
333 133.86
500 134.80
/me no programmer
So i had to look up some basics on the c++ thingie to understand it.
800/125 = 6,4 slip on my part should generate negative error?
800/333 = 2,402 --> remainder 0,402 --> negative error?
But looking at the chart, why don't all those fps that generate more positive error than 43fps work? As i said, for me, 43/55/76/111/125/250/333 work jumping on to big boxes, the others don't.
So i had to look up some basics on the c++ thingie to understand it.
800/125 = 6,4 slip on my part should generate negative error?
800/333 = 2,402 --> remainder 0,402 --> negative error?
But looking at the chart, why don't all those fps that generate more positive error than 43fps work? As i said, for me, 43/55/76/111/125/250/333 work jumping on to big boxes, the others don't.