ET Pro 3.0.10 testbugfix released

Official ET Pro announcements here...

Moderators: Forum moderators, developers

User avatar
bani
Site Admin
Posts: 2780
Joined: Sun Jul 21, 2002 3:58 am
Contact:

Post by bani »

Noobie wrote:
bani wrote:can anyone reproduce the scoreboard problems when pmove_fixed is 0? does it only happen when pmove_fixed is 1?
It happens with pmove_fixed 0 too (tested on ND80 grotto).
does it happen more or less often with 0 ?
DG
Posts: 513
Joined: Thu Jul 24, 2003 4:16 am

Post by DG »

bani wrote: caveat: b_fixedphysics 1 also takes slightly more bandwidth for players (160bytes/sec). this is nothing for broadband, but might affect dialup users.
for players is this 160b/s in total yes?
User avatar
bani
Site Admin
Posts: 2780
Joined: Sun Jul 21, 2002 3:58 am
Contact:

Post by bani »

300bytes/sec. this might affect 56k players.
DG
Posts: 513
Joined: Thu Jul 24, 2003 4:16 am

Post by DG »

yeah 300bytes/s would be roughly 8% of their bandwidth, or about 4% of ISDN. Might not sound like much but it's a bloody lot when bandwidth is so low.

b_fixedphysics SUCKS :twisted:


;)
User avatar
Badhabit
Posts: 312
Joined: Sat Oct 26, 2002 9:09 pm
Location: Boise, Idaho

Post by Badhabit »

bani wrote:can anyone reproduce the scoreboard problems when pmove_fixed is 0? does it only happen when pmove_fixed is 1?
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.
{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.
Image
User avatar
V6.Sven
Posts: 86
Joined: Fri Jan 23, 2004 10:12 am
Location: Netherlands!

Post by V6.Sven »

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)? :roll:

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 :?.
sniKer
Posts: 4
Joined: Sat Apr 24, 2004 4:07 am

another bug??

Post by sniKer »

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! :!: 8)
http://home.arcor.de/basicman1/DEMOS/20 ... asis.dm_83
User avatar
IdNotFound
Posts: 197
Joined: Wed Dec 03, 2003 8:21 pm
Location: Brazil
Contact:

Post by IdNotFound »

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)? :roll:

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 :?.
Fixed as in "it should never be dependent on client fps and we are so leet we fixed it just for you", I guess... ;)

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
Image nZ/IdNotFound
NaZGûL TeaM Leader
SAWL Tech Staff
abrrad
Posts: 7
Joined: Tue Jun 22, 2004 1:18 am

Post by abrrad »

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?
User avatar
bani
Site Admin
Posts: 2780
Joined: Sun Jul 21, 2002 3:58 am
Contact:

Post by bani »

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 8)

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.
User avatar
KingJackaL
Posts: 666
Joined: Thu Jan 08, 2004 3:47 pm
Location: ChCh, NZ
Contact:

Post by KingJackaL »

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?
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.
dA*Rogue
Posts: 201
Joined: Fri Dec 26, 2003 3:18 am

Post by dA*Rogue »

Physics should NOT be FPS dependent...I hope 1 becomes the default setting in time.
abrrad
Posts: 7
Joined: Tue Jun 22, 2004 1:18 am

Post by abrrad »

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?
User avatar
bani
Site Admin
Posts: 2780
Joined: Sun Jul 21, 2002 3:58 am
Contact:

Post by bani »

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:

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
abrrad
Posts: 7
Joined: Tue Jun 22, 2004 1:18 am

Post by abrrad »

/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.
Locked