[mitsubishi]

I've changed the layout of drawping output, it's on the left top corner of the screen. It could be distracting to setups having the map there but I believe it's way more readable now(it can be changed and has a different default, see below) (and no different short/long versions) . fontsize var is still in and it appears it correctly rescales it each time it's used the way it's coded.

zip updated (on 1st post).




ah forgot to say, spike is also replacing the word 'flux' to be more scientifically valid


oh. and silly little addition: cl_drawclockshowseconds can show the seconds on the clock, 0 by default.




it also avoids some divisions by zero now (crashing it) and nonsensical results in case of miss-setting the vars to nonsensical values.




oops I realized not only the map is top left by default but also some hitting messages (that I have myself disabled). I updated it with the position changed above the 'little man' on bottom left and a 'pos' var to change its position along the left and top and
left.

I changed pos var to posx and posy vars, slightly more nerdy but way more intuitive.



oops the default position is distracting of the chat, brought a big higher.



pos vars were a mess, fixed.


renamed average to mean
defaults changed to 2 and 10, I believe it's more accurate to shorten them (especially for TS lagging by default on round change). I thought of putting them on 1 and 2 or 2 and 4 but maybe too short, anyway whatever, they can be changed to anything anyway.

This post has been edited by mitsubishi: 16 November 2009 - 11:42 AM

[Ultradie]

Passwords won't save when I connect through qtracker

[QA RS| SubJunk]

Isn't there a fix for the gamma bug now? I thought there was. It's not fixed in this version Any chance you could apply it?

[mitsubishi]

what is the gamma bug?

do passwords save on other .exes that way?

edit: qtracker has a "save this password" checkbox underneath the password field. it saves them here.

This post has been edited by mitsubishi: 16 November 2009 - 11:08 AM

[QA RS| SubJunk]

On a lot of people's computers, when you exit UrT it doesn't set the gamma back to what it was, so everything on the screen is too bright and you have to go into the NVIDIA settings to reset it. I thought there was a patch for it, but maybe I was wrong.

[mitsubishi]

I believe that's the common result if the game crashes. Does it happen to you each time?


BTW, a nice utility is QuickGamma. It changes gamma from the taskbar without having to go to NVIDIA menu.
http://rapidshare.co...kGamma.exe.html

[QA RS| SubJunk]

mitsubishi, on 16 November 2009 - 07:36 PM, said:

I believe that's the common result if the game crashes. Does it happen to you each time?


BTW, a nice utility is QuickGamma. It changes gamma from the taskbar without having to go to NVIDIA menu.
http://rapidshare.co...kGamma.exe.html

Yes it happens to me every time whether it crashes or not, and has ever since I started playing the game, on Windows XP, Vista and 7, with 3 different video cards, 2 different motherboards, as well as on my best friend's computer and my wife's... Some people probably just don't notice it.
Thanks for the link, will try it

[mitsubishi]

that's weird, I never see it happening unless I see a crash (on several computers / .exes).

edit: hence I wouldn't see much point in hacking it to return it to a 'normal' value on quit. it's supposed to do that already.

This post has been edited by mitsubishi: 17 November 2009 - 02:08 PM

[mitsubishi]

ok, I changed the way the ping meter internally collects data from raw integer summation to dynamically enlarging pointers. It doesn't have memory allocation checks which is a bit "ninja", so let me now if you see any weird behavior because of it (zip updated on 1st post). (I could add memory allocation checks but the way this runs (looping endlessly) would make checking an unreadable mess; I want to take my chances with trusting it; but I guess I'll have to do it if in the real world it does create problems). (found a way actually)

It should be now more accurate since instead of using the 'previous mean' (having been found from the last round) to find spikes and standard deviation, it now directly goes and enumerates the collected data at the end of an interval to do all calculations properly at the same time drawing from the same data pool. Max Spike due to this should now show a stable high number from each interval (instead of gradually going up all the time and being partly unreadbale).




actually, I found a meta-ninja way to do it(mem alloc check) simply, reuploaded.


and oops, I had max spikes (after the change) not resetting, fixed.

This post has been edited by mitsubishi: 17 November 2009 - 04:47 AM

[Gnorkh]

I've been using your latest build - mainly for trying out the OpenAL sound - and it runs very well.

The sound quality is noticeably better. Are there possibilities to configure OpenAL? The indication of distances is more precise, but it's a bit too much: while the level of sounds/events which happen some meters away from you is good, the sounds which are next to you (shooting, bullet impact, ..) are very loud.

This post has been edited by Gnorkh: 18 November 2009 - 01:14 PM

[mitsubishi]

these are the vars from ioquake3's documentation:

s_useOpenAL - use the OpenAL sound backend if available
s_alPrecache - cache OpenAL sounds before use
s_alGain - the value of AL_GAIN for each source
s_alSources - the total number of sources (memory) to
allocate
s_alDopplerFactor - the value passed to alDopplerFactor
s_alDopplerSpeed - the value passed to alDopplerVelocity
s_alMinDistance - the value of AL_REFERENCE_DISTANCE for
each source
s_alMaxDistance - the maximum distance before sounds start
to become inaudible.
s_alRolloff - the value of AL_ROLLOFF_FACTOR for each
source
s_alGraceDistance - after having passed MaxDistance, length
until sounds are completely inaudible
s_alDriver - which OpenAL library to use
s_alDevice - which OpenAL device to use
s_alAvailableDevices - list of available OpenAL devices

I can't claim I understand them all.

[mitsubishi]

another small update, cl_drawFPS is included:




It's equivalent to ping meter. It can show max FPS drop (instead of ping spike) and goes again through standard deviation and mean drops as in equivalent values in ping meter.


It may be more accurate than the mod's FPS meter (on its base value on the top) because it goes through the calc each global loop (each frame) while the mod probably goes through it every 4 frames (if judged by the cgame code).
Also, it should be taken into account that frames per second in the game are very related to networking and generally the way the game works; if there is no frame, there is no information send for example (this relation of FPS with gameplay is the reason the mod has FPS limited).


source 7z also updated.



zip in 1st post updated with the above change.




their positioning can be a tough issue but they can be moved around a lot with cl_drawfps/pingposy/x (their resolution can be highered but it's already a bit high). I've put them by default above the 'health status' pic at the moment. I personally have them on the top left (assuming hit msgs disabled) though the second may have to go a bit lower 'cause its distracted by the voting text.


note: a 'this might be built with a buggy compiler' is a wrong warning which has been fixed by ioq3 and will be uploaded next update. no point doing it before since it's just a warning text changing.

This post has been edited by mitsubishi: 18 November 2009 - 09:35 PM

[mitsubishi]

This now also has a snaps / second meter, a more esoteric approach to meters that shouldn't be that useful to the majority of players.




An extra indication is 'Delayed' snaps, those are the throttled snaps by the server to save bandwidth based on sv_maxrate and rate (e.g. you will a lot on 10000 rate / sv_maxrate on a big server).

Extrapolation and dropped packets can not be shown, at least not easily. This is because those are handled by the cgame portion which is mod code, not easily accessible by the client.




A very interesting indication coming from this meter is that snaps locked at 20 in urt (or on baseq3) show a constant deviation of 2-3 SPS. This is not the case on 25 or 125 where the number is solid and it again trembles on 40 or 60. I suspect it may be better for the mod to put it on 25 or something else stable but not sure. a thread for this is here: http://forums.urbant...haps-important/

[grapefruit (old)]

Hmm, can't seem to start this build .. double-click = nothing happens, not even an error message. I tried the " ioquake3-urt .exe mainly for technical support " one and it worked on first attempt, what might be the problem ? My CPU is sempron 2300+ (you can see why i want the optimization) and GPU GF 7600 GS. Using XP. I don't know exactly what would be vital info but the logfile (if that indeed is the logfile just says this)

ioquake3-urt 1.36-urt win_msvc-x86 Nov 20 2009
----- FS_Startup -----
Current search path:
C:\Documents and Settings\myusernamewascencoredfromhere\Application Data\Quake3/q3ut4
E:\UrbanTerror41\q3ut4\zpak000_assets.pk3 (7933 files)
E:\UrbanTerror41\q3ut4\zpak000.pk3 (99 files)
E:\UrbanTerror41/q3ut4

----------------------
8032 files in pk3 files

If someone has an idea how to fix this then would be greatly appreciated.

[mitsubishi]

well it does attempt to run so no issue with downloading; no idea. are the files/positions of file in order? it seems to be related to that.