Pages: 1 ... 8 9 [10] 11
  Print  
Author Topic: 0.8.5 Bugs  (Read 135784 times)
Virus
Guest
« Reply #225 on: January 26, 2012, 01:52:56 PM »

saw this:
) ps37ctf being played / jumping walls is possible as normal on the server
) shuffle voting successful
) ps37ctf restarts / no one can jump on the walls now

seems only temporary for the shuffled game

Probably the server admin just tweaked manually the gravity and has fixed physics. See if it does the same bug when just doing a map_restart. If that's the case, this is just a normal bug, which should be fixed with g_gravityModifier in the next release.

tested like this:

) other map was on
) voted ps37ctf / can't jump walls
) voted map_restart / can't jump walls
) later ps37ctf is on as part of the map rotation / can jump walls

This shows changed gravity?
Code:
pul1ctf:
--------
Timelimit hit.
...
Full lag compensation is ON!

ps37ctf:
--------
Blue hit the capturelimit.
...
Server: g_gravity changed to 800 <<<<<<<
Full lag compensation is ON!

----------------
Also tested on a second server. Here I can jump walls whatever vote I to see the map.

Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #226 on: January 26, 2012, 01:55:18 PM »

You can set a different value for each map inside the .bsp/.map. Just set a "gravity" key on worldspawn (that's what Gig suggests. It does not affect other maps in any way).

Still it's not a good idea to try to force g_gravity to a certain value as a mapper, (frame-dependant-) physics should be up to the admin to decide.
Logged

This space is for rent.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3763


Trickster God.


« Reply #227 on: January 26, 2012, 02:01:32 PM »

AFAICT, no map has the gravity setting set among the default OA maps. Not even ps37ctf(2).
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #228 on: January 26, 2012, 02:36:21 PM »

I suppose the gravity setting is part of the mapper's taste.
E.g. a mapper may set a lower gravity in a space map... but also making mapsdesiged to emulate 125 fps physics while using accurate physics instead may be a lecit use of it, I suppose.

Of course, one may take in account that a server using 125 fps physics in a map with the gravity tweaked to emulate 125 fps physics, too... would make even higher/longer jumps than expected.
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #229 on: January 26, 2012, 04:27:41 PM »

@Virus: I can imagine that the first server you are referring to is using "accurate" physics with tweaked gravity (pmove_float 1, g_gravity 756), while the second server is using fixed 125 fps physics with default gravity (pmove_float 0, pmove_fixed 1, pmove_msec alien g_gravity 800 -gravity may simply be omitted-).

The result is more or less the same, but in the first case a map restart -that does not trigger the rotation script- resets the gravity to 800 and you cannot do that jump anymore, while in the second case the gravity is always 800 and so you do not experience the problem.

You can try these settings playing locally (pmove changes are immediately effective), and try what happens after you do a map_restart.

About the console log you posted: could you please post a little more detailed log? It seems that "Server: g_gravity changed to 800" is done after the end of the ps37ctf match but before the next map loading... but usually it should be done after map loading, to be sure it is keeped. Isn't somewhere in the log a gravity changed to something less than 800?

Explaination about the various kinds of physics: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics
Map rotation script example that -along with other things- changes gravity: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Configuration_examples/Weapon_rotation#Changing_gravity_and_speed

UPDATE (I thought this, but I forgot to write it): Anyway, with 0.8.alien the new g_Gravitymodifier feature will workaround this problem of automatically resetting to default gravity.
« Last Edit: January 26, 2012, 05:21:13 PM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #230 on: January 26, 2012, 04:38:30 PM »

tested like this:

) other map was on
) voted ps37ctf / can't jump walls
) voted map_restart / can't jump walls
) later ps37ctf is on as part of the map rotation / can jump walls

This shows changed gravity?

Yes, it's a perfect example.

When admin try to tweak g_gravity by himself, he has to set it after the map loading, such as:

Code:
seta maprotation1 "map ps37ctf2; seta g_gravity xxx; seta nextmap vstr maprotation1"
seta nextmap "vstr maprotation1"

So the adjustement of the gravity only takes place in the case of a map rotation, when the variable is called (with vstr), so when you do anything that bypasses the map rotation (such as map_restart, map, shuffle - that calls map_restart btw, and warmup too because at the end of warmup it does a map_restart), you lose the gravity setting because the gravity setting is contained in the map, and reset at the map loading.

Of course, one may take in account that a server using 125 fps physics in a map with the gravity tweaked to emulate 125 fps physics, too... would make even higher/longer jumps than expected.

Indeed Gig is right, but only if the server enables framerate-dependent physics. With pmove_float, it would be ok for everyone, no way to jump higher. But this would only fix the problem for one map, all the others won't get the benefits, and the servers admins don't want just a few selected maps to have the right 125 physics while most others (like q3 maps) don't.

Another solution would be for the game engine to totally ignore the gravity setting contained in the maps, this way, servers admins could set one g_gravity for all maps. But the problem is that some maps set a different gravity, and this is part of the gameplay. Currently, no OA map use a different gravity as Neon_Knight pointed out, but in the past there were, such as Void4, and there are a few third-party maps that use a different gravity too.

The best solution is a gravity modifier or a pmove_float behavior modifier (both would have pretty much the same result and application). The gravity modifier has been chosen and implemented by sago007, and I think that it's a perfect solution, because it will work on every map, even third-party maps. Plus it can be tweaked to simulate other physics such as 333 fps-physics. Could be fun too.
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #231 on: January 26, 2012, 05:18:29 PM »

Yes, gravitymodifier should do the trick. It is a good improvement. Obviously, it will not fix everything under every single situation.

Example 1:
We know that "g_gravity 756 @accurate" is very similar to "g_gravity 800 @125fps", but this is thanks to trials by someone, AFAIK, not due to a specific math calculation. In other words: we don't know how to calculate how to simulate 125fps physics (while using accurate physics) for a map designed with a gravity different than 800. And the same will apply to g_gravitymodifier: we can assume that 800:756=1:x, then (756*1)/800, then we can suppose that g_gravitymodifer 0,945 should be the right setting to emulate gravity 800 @125fps physics under accurate physics (I haven't tried yet)... but if the starting gravity is different than 800? Who knows?

Example 2:
g_gravitymodifier will not change at map_restart, and will be changed at the next step of map rotation script only (if the admin changes it at that step!)... okay. But if you callvote for a map out of the script, you will keep the old gravitymodifier on the new map, until the map rotation script will be triggered. If the gravitymodifer is simply used to emulate 125fps physics on maps designed for gravity 800 (probably, it will be its most common use), it should be allright... but if that was used to do something strange, weird results may happen. E.g. you have a map which has got g_gravity 600; admin sets g_gravitymodifier to 1.333 because he does not like the "low gravity" effect (and the map does not contain fundamental jumps that would not be possible with 800 gravity)... people votes for another map, which has got 800 gravity, and gravitymodifier will remain 1.333, thus emulating 1066 gravity and potentially making that map unplayable. This is not a very probable scenario, but may happen and this is just an example to say that g_gravitymodifier is useful but is not a magic wand for everything.
« Last Edit: January 27, 2012, 07:50:32 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #232 on: January 27, 2012, 07:30:12 AM »

@Gig: indeed, someone should do some maths about the physics calculations to make sure that g_gravityModifier should work in any scenario, but I guess it should, since it's a multiplier, and framerate-dependent physics pretty much work the same as a multiplier to the gravity. But rigorous maths should clears this out. Or at least some testing, I'll see if I can do some.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #233 on: January 27, 2012, 10:33:47 AM »

framerate-dependent physics pretty much work the same as a multiplier to the gravity.
But the multiplier varies with g_gravity (and sometimes 91 fps is better than 125 fps).

There is a good explanation here:
http://www.psycco.de/125fps/UpsetChaps%20Quake3%20Guide%20-%20Why%20Your%20Framerate%20Affects%20Jumping.htm
The second graph in the first post is wrong but the second post explains everything.
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #234 on: January 27, 2012, 12:59:52 PM »

Thank's for the link Sago but I know these calculations, but these calculations demonstrate the influence of variating framerate, but not the gravity (or as it is called in this paper, the acceleration).

Theoretically, framerate and gravity are two constants that are dependent on each others. If we multiply one, then the other gets the same multiplier theoretically. This is why I think it should end up the same.

If I remember well, the reason why players jump higher with 125 fps-physics is that theoretically it "skips" some frames. Hence, we could say that the concrete effect is to raise the acceleration/gravity. So fixing framerate, but raise acceleration/gravity should do the same result, whatever the gravity is set to (because the framerate-dependent physics are also proportional - I think - to the gravity).

Now this is not a formal demonstration so this assumption (gravity and framerate-dependent physics correlation) could be wrong.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #235 on: January 27, 2012, 01:15:24 PM »

In the calculations on the page the gravity is defined as 800. One can change the gravity instead of the framerate in the calculations.

I thing I remember that at g_gravity = 600 you jump higher with maxfps=90 than maxfps=125 because the rounding errors goes the other way.
Logged

There are nothing offending in my posts.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #236 on: January 27, 2012, 04:19:45 PM »

The first 12 ones are shown in the menu if I remember well (there's not yet a support for a scrollbar in this menu), but the voteconf.txt file is limited to 170 lines exactly, any more lines are not read at all. This limit should also be removed if possible.
I have not yet found a good way to communicate a longer list. I do it for maps but that is not without trouble.

voteconf should not be limited to 170 lines. It should be limited to 4096 bytes. A number chosen because it should be able to hold 12 entries, also the current trap_-functions are not that effective at reading files and the token-functions needs to work on a single buffer. Remember that an entry might contain an exec-command that are much more effective for larger scripts.

The main reason I haven't added custom votes with parameters is because I do not know how to present them properly in the UI. And I believe that they should be presented in the UI.
Logged

There are nothing offending in my posts.
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #237 on: January 27, 2012, 04:21:28 PM »

Cmon guys: be creative!

it is not about authors intention, it is about GPL!
If he had the idea in mind, that his map should stay as he created it, he had choosen one of those "watch but don´t touch" licences microsoft offers.
But he had choosen the GPL.

Grab god_ps37ctf and be happy. i just moved the walls 8 units down. no more serverside settings to make this map enjoyable (btw: this version prevents rail campers and has more possibilities Wink ).

Just dl, include it and all is fine:
http://download.tuxfamily.org/openarena/upload/god_ps37ctf.pk3

btw: no reason to worry: oa_ctf4ish was changed too. Cheesy

pps: if you still like ps37ctf you could also change the wall Wink
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #238 on: January 27, 2012, 05:59:36 PM »

@sago:

About g_gravity, I'll see if I can make some calculations.

About voteconf.txt, indead that may be the case (limitations to the number of characters and not the lines), but I'm already using variables and only doing vstr (much more cleaner anyway in a voteconf file that to define everything in the file), but I'm still limited: I'm mainly using it to callvote different gametypes and configs, and I'm currently limited because of the voteconf. Anyway that's better than nothing, but it is still a limitation that prevent creativity unleashing Wink

About variables substitution, I understand your point, but I think that custom callvotes do not necessary have to be presented in the UI since they are special functions dedicated to power users (do you know of any new player that may callvote a custom setting? even most power users do not use them yet nor know their existence). So if at least it work in console, it's pretty much perfectly fit the targeted audience and application (advanced options for advanced users). And anyway, if the admin really want it to fit in the GUI, he can still convert its callvote in a version without variables substitions but with more entries.
Another argument is that many mods add their own callvote functionalities without making them show in the GUI, but the functionality is here if needed and I think that's all that is needed.
Plus, there is a possibility to input a description, so if we get a command such as /callvote custom help <command> that shows the description of the custom vote entry, everything's ok.

So, I do understand your point of trying to open the new functionalities to everyone, but I think that trying to fit callvote custom with variable substitution into the GUI is overkill and unnecessary. One thing at a time. And variable substitution would really be a GREAT feature!

@Peter Sillie: thank you for editing the map, it indeed fix the problem with this map, but as I pointed out before, it does not solve it for every map. I still support the g_gravityModifier Wink
Logged
Peter Silie
Member


Cakes 2008
Posts: 610



« Reply #239 on: January 27, 2012, 06:13:22 PM »

@Peter Sillie: thank you for editing the map, it indeed fix the problem with this map, but as I pointed out before, it does not solve it for every map. I still support the g_gravityModifier Wink

As Neon_Knight said before: it is a bad mapping behaviour to make maps depending on a frame rate.
There are some reasons to do so (the mapper does not know how his brushes/entities will be used), but usualy brushes as made as in ps37ctf just should be lowered 8 units to make them usable for players.
Still have in mind, that FPS125 isn´t the default value on stock q3 - it depends on your hardware. if you made a map, which is just playable on 125 (or 333 which is more obvious), you made a bad map.

btw: i don´t know a further oa map  which has the same prob as ps37 has. any examples?
Logged
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #240 on: January 28, 2012, 01:59:03 AM »

btw: i don´t know a further oa map  which has the same prob as ps37 has. any examples?

Well, there is the classical one in oa_dm3: in the the rail gun room, you can take a shortcut to the mega health (and the railgun) at 125 fps. Normally you have to jump onto the lower part of the construction that supports the rail gun, but at 125 fps you can jump straight onto the higher part of the construction and get to the mega health much quicker. I have attached a screen shot to indicate the exact place.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #241 on: January 28, 2012, 02:53:18 AM »

As Neon_Knight said before: it is a bad mapping behaviour to make maps depending on a frame rate.
There are some reasons to do so (the mapper does not know how his brushes/entities will be used), (...)

Exactly, that's the main reason why I say that editing a map is not a longterm solution, because now that the map is edited, maybe there are new tricks that were not possible before, and this is an infinite cycle...

The problem is not that maps are not playable, but that tricks are limited, because most tricks are found using 125 fps. There are even more tricks at 333 fps, but one has to keep in mind that 125 fps was the official minimal requirement for defrag competitions, so historically this explains the prevalence of 125fps-physics for tricks.

And about other examples, I can cite oasago2 where there are some jumps (like from the shotgun to bridge and shotgun to railgun) that are only possible with >= 125fps-physics. And we can continue with a very long list of examples for nearly every map...
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #242 on: January 28, 2012, 08:45:31 AM »

Considering that rounding errors change way depending from gravity AND fps (Sago said that with gravity 600 you jump higher @90 fps than @125 fps), using gravitymodifier to emulate 125fps physics would mean to set it lower than 1 in that case. Uhm...

Maybe the only advise we can say to mappers it to design new maps with "accurate" physics in mind?

About hidden custom votes... even if not in the menu, I think all possible custom votes should be listed at least in console (maybe the thirteenth line in the list in the menu may simply say "type xxxx in console for complete list"?). But I don't know how to face the problems sago mentioned.

Sago, a curiosity: I tested that now timelimit -1 does not immediately end the game anymore (good). But does it act as infinite, as 1, or what?
Ps: that timilimit 1000 limit over that "x minute warning" sound is not played anymore by the client, is an hardcoded value or is related with some cvar?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #243 on: January 28, 2012, 05:58:44 PM »

@Sago and Gig: About g_gravityModifier, yes I think you're both right. Indeed, the rounding function is not linear, so that g_gravityModifier (which is linear) can't really simulate the rounding error of framerate-dependent physics for every value of g_gravity.

But anyway, that's a nice workaround meanwhile some get the genius idea that could fix it all.

And why not implement an artificial rounding error to simulate framerate-dependent physics from accurate physics? I know this may seem to defeat the purpose at first, but in the end, it would move the rounding error from the clients to the server, so that every player will get the very same physics. In the end, it would attain the goal: framerate-independent physics?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #244 on: January 29, 2012, 06:38:13 AM »

And why not implement an artificial rounding error
A broken solution could emulate a broken system but is that really what we want?

pmove_fixed is still an option that forces consistent rounding errors based on pmove_msec although with risk of frameskips.

But does it act as infinite, as 1, or what?
It affects as "disabled" (0 = Off) or "infinity" (0 = Infinity) depending on your point of view.

On a side note OAX r294 does now allow scripts per map/gametype. So you can now have your disable_ replace_ g_gravity and other variables as you desire and have them processed no matter how you change map.

Also note that the g_gravityModfier is also meant as a way to start a low gravity server that works relative to the map and not just a way to break physics again. 
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #245 on: January 30, 2012, 04:14:30 PM »

Sago, I noticed your post here about voting fix. I asked you there, but probably it is better to ask you here instead of there.

Do you mean that fix this would fix the light voting feature? In this case, we could restore it as default (instead of the classic voting you reintroduced for 088), and invert the dmflag you created to manually set lightvoting, to manually set standard voting instead. What do you think? If we want to do that inversion, it is better to do it before an official release uses that dmflag in a certain way (to avoid later confusion)...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #246 on: February 03, 2012, 09:38:25 AM »

Sago, I noticed your post here about voting fix. I asked you there, but probably it is better to ask you here instead of there.
Personally I prefer classic voting. Anyway this have an importance close to 'none' on the importance scale.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #247 on: February 03, 2012, 05:54:38 PM »

Does this mean that 088 will use classic voting by default, and it will be possible to use "fixed" (in the meaning of bug-less) light voting using the dmflags? I thought light voting were preferred and you wished to make them default again... anyway, for me it's the same: I was mostly worried about changing default and dmflags behavior in later version may cause confusion... but if you say they will remain this way, I suppose it should be okay.


Anyway, can you confirm me that voting fix you mentioned is about the "famous" bug that was mysterious... and that the fix will be in 088?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Virus
Guest
« Reply #248 on: February 05, 2012, 07:59:39 AM »

The solution I came to based on the code:

  * Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored).
  * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read.
  * Changed default g_voteMaxTimelimit to 1000

An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000.

I normally advice against infinity time limits. The engine will boot all clients and restart itself if the game takes to long (several days) to prevent internal variables to overflow.


Doesn't the fix against overflow in the check
Code:

  if ( (level.time - level.startTime)/60000 >= g_timelimit.integer )
in g_main.c + no announcements beyond 1000 minutes already solve the problem?

Code:
/*
==================
allowedTimelimit
==================
 */
int allowedTimelimit(int limit) {
    int min, max;
    min = g_voteMinTimelimit.integer;
    max = g_voteMaxTimelimit.integer;
    if(limit<min && limit != 0)
        return qfalse;
    if(max!=0 && limit>max)
        return qfalse;
    if(limit==0 && max > 0)
        return qfalse;
    return qtrue;
}

g_vote.c
Negative timelimits are blocked if g_voteMinTimelimit>=0. Very big timelimits don't matter if the engine ends before earlier - right?

So having g_voteMaxTimelimit = 1000 does block timelimt=0 in the third condition without need as voting timelimt 0 is not evil.
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4378


WWW
« Reply #249 on: February 09, 2012, 04:48:32 PM »

Three different things:
1) Sago, did I understood correctly that in 088 lightvoting is fixed but disabled by default?

2) Have you read Virus' post?

3) Do you know what means that "WARNING: Server is not allowed to set pmove_float=1" message that I sometimes find in client's console?

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Pages: 1 ... 8 9 [10] 11
  Print  
 
Jump to: