[DeMS]

mitsubishi, on 01 June 2010 - 10:31 AM, said:

Important networking remarks I have gathered:

• Timenudge: Maybe allow it to go at least to -20 for competitive players (it increases responsiveness in exchange for visual jerkiness) (positive values (that we have now) increase visual smoothness in exchange for input/gameplay responsiveness). In terms of 'hits' it's a complex matter since it can both be argued that jerkiness = 'hits lost'/visual smoothness = 'hits improved' and that jerkiness = 'better latency and hence maybe better hits'/ positive timenudge = 'local lag'. It may depend on the person or mood on what's best in a case.
  
• This is in the list already but it's in this family: cl_packetdup: allow it to go to 0 for potential lower overheads (it may not be very important potentially but some perfect connections should not need it at all). Personally I find it very irritating on negative values (with eventual only negatives to gameplay) so it's fine as it is for me but I suspect others operate differently. Unless -10 would be bearable..
  
• This has been addressed by TwentySeven already: maybe increase cl_maxpackets allowable for higher responsiveness/better 'hits' latency: it has been increased for 4.2 to 125.
  
• This has been discussed by TwentySeven already: maybe allow higher sv_fps/snaps for higher gameplay responsiveness: 27 is afraid to increase it. I suspect because it may increase load tremendously (CPU and network load). I believe it should be increased in 2010: conservative approaches can be just up to 25 *very conservative IMO. Or up to 40 (conservative but very noticeably higher).

None of these are bugs, 'must dos' or personal suggestions, mainly remarks for further development.

But they may be hugely affecting gameplay (well, maybe not packetdup).

You would need sv_fps to rise at the same pace as snaps for it to affect gameplay. Else it doesn't feel too different.

I've tested that on sof2, which afaik has a similar networking system (ask apoxol :P)

[GlaD-slackin]

Stanley, on 01 June 2010 - 04:16 PM, said:

Don't know if anyone else has said this because I didn't read the whole thread, but I've been running the 64-bit client from the UrT site (not tried with either ioBumpy or mitsubishi's version), and I've never had this problem.

up higher in the thread someone mentions its a distro/release specific issue(ubuntu 10.4 or something)

[mitsubishi]

something tells me we're gonna forget a lot in here: (read the forum!)

the +vstr function is buggy; once you use it simultaneously with itself in two different scripts it stops functioning properly.

Bug Report

a functioning workaround or fix is to remove the 'if pushed' part altogether.

like here:

                        v = Cvar_VariableString( Cmd_Argv( 1 ) );
                       //pushed = qtrue;
                        break;
                case '-':
                        // we check this because otherwise key release would fire even in the console...
                        //if(pushed) { //ioq3-urt workaround: commented; this is almost a bug since it doesn't let a _second_ bind work properly
                                v = Cvar_VariableString( Cmd_Argv( 2 ) );
                                //pushed = qfalse;
                        //}
                        break;
                default:
                        Com_Printf("Cmd_PVstr_f: unexpected leading character '%c'\n", Cmd_Argv( 0 )[0]);

--

good example of the bug:

Nexu, on 26 February 2010 - 07:36 AM, said:

Happens when you call another script while another +vstr script is active. Here is an example how to reproduce this 'problem':

set cg_fov "110" // standard value for this test

set do_zoom_on          "ut_zoomin;    cg_fov 90;  set do_zoom vstr do_zoom_off"
set do_zoom_off   	"ut_zoomreset; cg_fov 110; set do_zoom vstr do_zoom_on"

set do_crouch_on        "+movedown; set do_crouch vstr do_crouch_off"
set do_crouch_off 	"-movedown; set do_crouch vstr do_crouch_on"

bind MOUSE2 "+vstr do_zoom_on do_zoom_off"
bind ALT "+vstr do_crouch_on do_crouch_off"

Test sequence:

• Press and hold mouse2 button
• Press ALT and release it
• Release mouse2 button

Result: FOV is still 90
Expected result: FOV should go back to 110

This post has been edited by mitsubishi: 01 June 2010 - 06:00 PM

[Mod ObScUrE]

^True I have it tested on mitsu's build and it works flawlessly there.

[H0i]

Bug list updated again.

[GlaD-slackin]

What about a bug tracker? wouldn't that be WICKED simpler and much much much more organized? Every major project that was successful that I have seen used some form of a proper bug tracker. The forums thing is just so dis-organized and such a pain in the butt to maintain, bug trackers are made to do this specifically, very very easily. Here you have many threads and posts repeating and sprawled out, a bug tracker lets you keep track of all the bugs in an organized fashion and then markem off as they are completed(so both the devs and community can see what is going on, clearly and in an organized fashion)

[Yas]

Slackin, on 01 June 2010 - 09:18 PM, said:

What about a bug tracker? wouldn't that be WICKED simpler and much much much more organized? Every major project that was successful that I have seen used some form of a proper bug tracker. The forums thing is just so dis-organized and such a pain in the butt to maintain, bug trackers are made to do this specifically, very very easily. Here you have many threads and posts repeating and sprawled out, a bug tracker lets you keep track of all the bugs in an organized fashion and then markem off as they are completed(so both the devs and community can see what is going on, clearly and in an organized fashion)

i've proposed this a few times, infact i posted it in this very thread and it got deleted.

would be nice to have though.

[GlaD-slackin]

It got deleted? but why? seem's like a good and valuable, non trouble causing suggestion.

Also: any update on if we can play UrT with passport and vanilla q3? I think it would be a shame if I couldn't use normal q3 to play anymore.(I get better fps in vanilla q3)

This post has been edited by Slackin: 02 June 2010 - 12:56 PM

[H0i]

The first part of the thread was deleted, until the suggestions came. I can suggest a bug tracker but it's up to the engine guys, I think it was done before and it didn't work well.

I don't know if you can play with q3 and passport, but you can try to name the iourt .exe the same as the q3 exe, so the drivers will think it's q3 (I heared that it will optimise some things for the engine if you do this).

[GlaD-slackin]

H0i, on 02 June 2010 - 03:38 PM, said:

I don't know if you can play with q3 and passport, but you can try to name the iourt .exe the same as the q3 exe, so the drivers will think it's q3 (I heared that it will optimise some things for the engine if you do this).

1.) renaming iourt.i386 to q3.i386 will make NO DIFFERENCE in performance at all.... only in windows would that even be remotely possible.

2.) So vanilla q3 will no longer run UrT as of 4.2? or at least not with passport?

3.) Since 4.0 came out there has not been a public bug tracker for UrT, if it was tried before it was long, long ago. Bug trackers are by far the best way to .... track bugs! lol There are tons of them out there, and they have made leaps and bounds in improvements over the last 4 years.

This post has been edited by Slackin: 02 June 2010 - 05:08 PM