From phatfil at optusnet.com.au  Fri Dec  1 05:50:45 2006
From: phatfil at optusnet.com.au (Philip Nelson)
Date: Fri, 1 Dec 2006 21:50:45 +1100
Subject: [quake3] rc3
In-Reply-To: <456D39AE.2020008@timedoctor.org>
References: <456CEFC0.3020604@timedoctor.org> <456D39AE.2020008@timedoctor.org>
Message-ID: <200612012150.46010.phatfil@optusnet.com.au>

On Wednesday 29 November 2006 18:41, Zachary Slater wrote:
> > More soon!

Updated windows build/installer:
http://whatsbeef.net/philip/ioq3/ioquake3_setup.exe


From vincent at cojot.name  Fri Dec  1 10:51:47 2006
From: vincent at cojot.name (vincent at cojot.name)
Date: Fri, 1 Dec 2006 16:51:47 +0100 (CET)
Subject: [quake3] sparc binaries
In-Reply-To: <BAY21-F17837860E696B1C2E98E92C8160@phx.gbl>
References: <BAY21-F17837860E696B1C2E98E92C8160@phx.gbl>
Message-ID: <Pine.LNX.4.64.0612011650380.8823@thorbardin.lasthome.solace.krynn>

On Mon, 9 Oct 2006, Georg Vogel wrote:

> hi,
> 
> are the binaries already uploaded, 'cause I can't find them on the homepage!
> Is there another to get hold of them?
> 
> Georg

Georg,

Recent binaries are now published on the www.ioquake3.org download page.. 
You might want to update the binaries you are using with the ones from 
ioq3.org..

Cheers,

Vincent


From daniellord at mac.com  Fri Dec  1 11:18:21 2006
From: daniellord at mac.com (Daniel Lord)
Date: Fri, 1 Dec 2006 08:18:21 -0800
Subject: RC3 works well on Debian Sarge but...
Message-ID: <B4930BE0-D579-4006-8E53-3031DFA0040B@mac.com>

I am running it as a server and using Mac OS X PPC and i686 clients.
I noticed a couple of things. Just noting them, not filing a bug  
report.  I'll see if I can track them down further and provided more  
detail.

Debian server:
1. my map rotation stops after a series of 12 and the 'nextmap vstr  
d1' seems to fail. I have to use rcon to exec vstr d1 to start the  
rotation over.

Playing the original Quake3 binary for PPC from Id has a few quirks  
(which may be unavoidable). Imention these because I thought I read  
ioquake3 should work with the original clients.
1. Sound during warmup: I use 'seta g_doWarmup 1'  and a buzzing  
sound appears in the background (quite annoyingly ) on some maps  
( enough that I think its a sound format issue) not a mapper's fault.
2. brightness starts out very high--almost washed out and I have to  
adjust the client.

Forgive me if these are either meddlesome, petty, or mentioned  
already elsewhere. Just as Tony did with the mail thread issue--feel  
free to school me.

Daniel


From bnoordhuis at gmail.com  Fri Dec  1 18:16:50 2006
From: bnoordhuis at gmail.com (Ben Noordhuis)
Date: Sat, 2 Dec 2006 00:16:50 +0100
Subject: [quake3] Weird mouse problem on Edgy
In-Reply-To: <200611181504.59069.arny@ats.s.bawue.de>
References: <f88c69fa0611170455u68c8d74v4d03be090073ea54@mail.gmail.com>
	 <455EC7A2.9090202@cs.byu.edu> <455EC8F0.1040500@cs.byu.edu>
	 <200611181504.59069.arny@ats.s.bawue.de>
Message-ID: <54885e060612011516h558977e9gb25c5f07ede58eee@mail.gmail.com>

On 11/18/06, Thilo Schulz <arny at ats.s.bawue.de> wrote:
> Yes I have had this problem too, though it seemed to appear after an update of
> my x libraries.

Probably not xlib but SDL since this bug only manifests itself when
compiling with sdl_glimp.c. Attached is a patch for ioquake3 that
works around it.
-------------- next part --------------
--- code/unix/sdl_glimp.c	2006-12-02 00:07:07.000000000 +0100
+++ code/unix/sdl_glimp.c.new	2006-12-02 00:06:48.000000000 +0100
@@ -1371,6 +1371,8 @@
 }
 
 void IN_Frame (void) {
+  // 061201 mis -- workaround for SDL mouse locking bug.
+  static qboolean consoleDown = qfalse;
 
   // bk001130 - from cvs 1.17 (mkv)
   IN_JoyMove(); // FIXME: disable if on desktop?
@@ -1384,10 +1386,19 @@
         && strcmp( Cvar_VariableString("r_glDriver"), _3DFX_DRIVER_NAME ) )
     {
       IN_DeactivateMouse ();
+      consoleDown = qtrue;
       return;
     }
   }
 
+  if (consoleDown) {
+    // warp mouse, don't grab it until the next frame
+    SDL_WarpMouse(screen->w / 2, screen->h / 2);
+    IN_DeactivateMouse();
+    consoleDown = qfalse;
+    return;
+  }
+
   IN_ActivateMouse();
 }
 

From arny at ats.s.bawue.de  Sun Dec  3 17:19:35 2006
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Sun, 3 Dec 2006 23:19:35 +0100
Subject: Rcon DoS
In-Reply-To: <20061203231550.fc289372.aluigi@autistici.org>
References: <20061203231550.fc289372.aluigi@autistici.org>
Message-ID: <200612032319.43111.arny@ats.s.bawue.de>

Hi Luigi,

On Sunday 03 December 2006 23:15, Luigi Auriemma wrote:
> I have a doubt about an instruction in the Quake 3 engine.
>
> Some months ago during the checking of the Quake 3 source code (in
> reality I noticed this thing some years ago, anyway) I saw the limitation
> of max 2 rcon commands for second in sv_main.c, and I thought it was just
> an anti-brute forcing instruction instead in the Changelog file it's
> identified as "fixing rcon being broken on NT/XP with > 23 days uptime
> (or so)"
>
> This limitation of 2 rcon for seconds allows some people to block the
> RCON service simply sending more than 2 rcon commands at second, so the
> valid commands of the admin will be ignored.
>
> I thought about this DoS already some months ago while I was writing a
> tool called multircon but I didn't considered a real bug so I simply
> left a comment in the runtime help and in the program's description.
>
> Anyway at the moment seems that people are exploiting this bug (reported
> by an admin and some other people) so what do you think about this rcon
> limitation? Isn't better to remove it?
> What is it's real purpose?

If this limitation really is in there, your concern is a valid one. I will 
take care of it in the next few days.

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061203/d5015d87/attachment.pgp>

From arny at ats.s.bawue.de  Sun Dec  3 17:52:37 2006
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Sun, 3 Dec 2006 23:52:37 +0100
Subject: [quake3] Re: Rcon DoS
In-Reply-To: <200612032319.43111.arny@ats.s.bawue.de>
References: <20061203231550.fc289372.aluigi@autistici.org> <200612032319.43111.arny@ats.s.bawue.de>
Message-ID: <200612032352.39714.arny@ats.s.bawue.de>

On Sunday 03 December 2006 23:19, Thilo Schulz wrote:
> If this limitation really is in there, your concern is a valid one. I will
> take care of it in the next few days.

We've discussed this "DoS" stuff in IRC. This limit is imposed to prevent the 
bruteforcing of rcon passwords that can be done easily using udp. At the 
moment, I don't see any easy way of removing that rcon limit without 
affecting security. Server admins should run their servers in "screen" to 
administrate their servers or use game-based administration features. Rcon is 
flawed by design.

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061203/52bc13ac/attachment.pgp>

From 0000spam at gmail.com  Sun Dec  3 21:40:27 2006
From: 0000spam at gmail.com (DD)
Date: Mon, 4 Dec 2006 03:40:27 +0100
Subject: [quake3] Re: Rcon DoS
In-Reply-To: <200612032352.39714.arny@ats.s.bawue.de>
References: <20061203231550.fc289372.aluigi@autistici.org>
	 <200612032319.43111.arny@ats.s.bawue.de>
	 <200612032352.39714.arny@ats.s.bawue.de>
Message-ID: <f88c69fa0612031840qb02a6fo77857cc407c53b77@mail.gmail.com>

Maybe adding the ability to allow rcon commands only from certain IP
block would help. Similar to banips, but like a whitelist, who can use
rcon and other remote features.

DD

On 12/3/06, Thilo Schulz <arny at ats.s.bawue.de> wrote:
> On Sunday 03 December 2006 23:19, Thilo Schulz wrote:
> > If this limitation really is in there, your concern is a valid one. I will
> > take care of it in the next few days.
>
> We've discussed this "DoS" stuff in IRC. This limit is imposed to prevent the
> bruteforcing of rcon passwords that can be done easily using udp. At the
> moment, I don't see any easy way of removing that rcon limit without
> affecting security. Server admins should run their servers in "screen" to
> administrate their servers or use game-based administration features. Rcon is
> flawed by design.
>
> --
> Thilo Schulz
>
>
>


From ntoronto at cs.byu.edu  Mon Dec  4 01:13:32 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Sun, 03 Dec 2006 23:13:32 -0700
Subject: [quake3] Re: Rcon DoS
In-Reply-To: <f88c69fa0612031840qb02a6fo77857cc407c53b77@mail.gmail.com>
References: <20061203231550.fc289372.aluigi@autistici.org>	 <200612032319.43111.arny@ats.s.bawue.de>	 <200612032352.39714.arny@ats.s.bawue.de> <f88c69fa0612031840qb02a6fo77857cc407c53b77@mail.gmail.com>
Message-ID: <4573BC8C.2070202@cs.byu.edu>

DD wrote:
> Maybe adding the ability to allow rcon commands only from certain IP
> block would help. Similar to banips, but like a whitelist, who can use
> rcon and other remote features.

If you could do that, you might also make the limit apply 
per-connection. Of course, a dedicated script kiddie could always 
commandeer a few hundred zombies...


From ntoronto at cs.byu.edu  Mon Dec  4 01:21:46 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Sun, 03 Dec 2006 23:21:46 -0700
Subject: I could swear it wasn't there before...
Message-ID: <4573BE7A.8060204@cs.byu.edu>

While translating cg_view.c to Python (yes, it's going very well now, 
I've got it rendering the map and I'm receiving snapshots), I discovered 
a funny block of code that I could swear wasn't there before Quake 3 was 
GPLed:

    if (cg_timescale.value != cg_timescaleFadeEnd.value) {
        if (cg_timescale.value < cg_timescaleFadeEnd.value) {
            cg_timescale.value += cg_timescaleFadeSpeed.value * 
((float)cg.frametime) / 1000;
            if (cg_timescale.value > cg_timescaleFadeEnd.value)
                cg_timescale.value = cg_timescaleFadeEnd.value;
        }
        else {
            cg_timescale.value -= cg_timescaleFadeSpeed.value * 
((float)cg.frametime) / 1000;
            if (cg_timescale.value < cg_timescaleFadeEnd.value)
                cg_timescale.value = cg_timescaleFadeEnd.value;
        }
        if (cg_timescaleFadeSpeed.value) {
            trap_Cvar_Set("timescale", va("%f", cg_timescale.value));
        }
    }

This apparently adjusts timescale toward 1 if cg_timescaleFadeSpeed is 
nonzero. Aside from the fact that the logic is wacked (why do *any* of 
it when cg_timescaleFadeSpeed is 0?), it doesn't work very well. From 
what I can see from cvs.icculus.org, it's been there since the source 
was released.

I don't want it in mine - it's just ugly cruft and nonsense. Who uses 
this? Is it for machinima or something?

Neil



From 0000spam at gmail.com  Mon Dec  4 01:23:15 2006
From: 0000spam at gmail.com (DD)
Date: Mon, 4 Dec 2006 07:23:15 +0100
Subject: [quake3] Re: Rcon DoS
In-Reply-To: <4573BC8C.2070202@cs.byu.edu>
References: <20061203231550.fc289372.aluigi@autistici.org>
	 <200612032319.43111.arny@ats.s.bawue.de>
	 <200612032352.39714.arny@ats.s.bawue.de>
	 <f88c69fa0612031840qb02a6fo77857cc407c53b77@mail.gmail.com>
	 <4573BC8C.2070202@cs.byu.edu>
Message-ID: <f88c69fa0612032223s64023ec2xe3d2cca66d854b93@mail.gmail.com>

White list or per-connection limits are best way it seems. DDoS is a
different monster, no fixes to the code can prevent someone from doing
that. Only solution in that case is either null-routing or hosting the
server at providers who specialize in that area, usually for IRC
shells.

DD

On 12/4/06, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> DD wrote:
> > Maybe adding the ability to allow rcon commands only from certain IP
> > block would help. Similar to banips, but like a whitelist, who can use
> > rcon and other remote features.
>
> If you could do that, you might also make the limit apply
> per-connection. Of course, a dedicated script kiddie could always
> commandeer a few hundred zombies...
>


From bnoordhuis at gmail.com  Thu Dec  7 05:50:03 2006
From: bnoordhuis at gmail.com (Ben Noordhuis)
Date: Thu, 7 Dec 2006 11:50:03 +0100
Subject: Patches for three bugs
Message-ID: <54885e060612070250n22a3f85cu19fba73295913e0d@mail.gmail.com>

Dear all,

I submit for your approval a collection of small bug fixes:

1. https://bugzilla.icculus.org/show_bug.cgi?id=2945 -- Mouse locks
when using console in windowed mode (SDL)

To reproduce:

- compile IOQ3 against SDL
- start it in windowed mode
- open the console
- move the mouse outside the window
- close the console

The mouse is now locked to the horizontal plane and cannot be moved more than
approximately 45 degrees in both directions. The cause is likely a bug in SDL
or xlib. This patch works around it by warping the mouse to the center of the
window before grabbing it again.

2. https://bugzilla.icculus.org/show_bug.cgi?id=2946 -- Cursor
misplacement in console after scrolling

To reproduce:

- open the console
- type something until the text begins to scroll
- scroll back

Character zero becomes unreachable due to a miscalculation in the engine. This
also applies to the different messagemodes. Said bug also exists in vanilla
1.32 Q3A.

3. https://bugzilla.icculus.org/show_bug.cgi?id=2863 --  Can't use DEL
key for binds

Existing bug report. Patch submitted that fixes the issue.

Sincerely,

Ben


From ntoronto at cs.byu.edu  Thu Dec  7 14:02:35 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Thu, 07 Dec 2006 12:02:35 -0700
Subject: [quake3] Patches for three bugs
In-Reply-To: <54885e060612070250n22a3f85cu19fba73295913e0d@mail.gmail.com>
References: <54885e060612070250n22a3f85cu19fba73295913e0d@mail.gmail.com>
Message-ID: <4578654B.8000505@cs.byu.edu>

Ben Noordhuis wrote:
> Dear all,
>
> I submit for your approval a collection of small bug fixes:
>
> 1. https://bugzilla.icculus.org/show_bug.cgi?id=2945 -- Mouse locks
> when using console in windowed mode (SDL)
>
> To reproduce:
>
> - compile IOQ3 against SDL
> - start it in windowed mode
> - open the console
> - move the mouse outside the window
> - close the console
>
> The mouse is now locked to the horizontal plane and cannot be moved 
> more than
> approximately 45 degrees in both directions. The cause is likely a bug 
> in SDL
> or xlib. This patch works around it by warping the mouse to the center 
> of the
> window before grabbing it again.
>
> 2. https://bugzilla.icculus.org/show_bug.cgi?id=2946 -- Cursor
> misplacement in console after scrolling
>
> To reproduce:
>
> - open the console
> - type something until the text begins to scroll
> - scroll back
>
> Character zero becomes unreachable due to a miscalculation in the 
> engine. This
> also applies to the different messagemodes. Said bug also exists in 
> vanilla
> 1.32 Q3A.
>
> 3. https://bugzilla.icculus.org/show_bug.cgi?id=2863 --  Can't use DEL
> key for binds
>
> Existing bug report. Patch submitted that fixes the issue.
>
> Sincerely,
>
> Ben

Very cool. Those first two have been bugging me for a  while now.

Neil



From ntoronto at cs.byu.edu  Mon Dec 11 21:41:11 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Mon, 11 Dec 2006 19:41:11 -0700
Subject: Quick question
Message-ID: <457E16C7.30300@cs.byu.edu>

What does the "ref" in "refEntity_t" stand for? Refresh?

Neil



From arny at ats.s.bawue.de  Tue Dec 12 01:28:59 2006
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Tue, 12 Dec 2006 07:28:59 +0100
Subject: [quake3] Quick question
In-Reply-To: <457E16C7.30300@cs.byu.edu>
References: <457E16C7.30300@cs.byu.edu>
Message-ID: <200612120729.01786.arny@ats.s.bawue.de>

On Tuesday 12 December 2006 03:41, Neil Toronto wrote:
> What does the "ref" in "refEntity_t" stand for? Refresh?

I think it is "reference".

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061212/1eba0043/attachment.pgp>

From daniellord at mac.com  Tue Dec 12 01:42:21 2006
From: daniellord at mac.com (Daniel Lord)
Date: Mon, 11 Dec 2006 22:42:21 -0800
Subject: [quake3] Quick question
In-Reply-To: <457E16C7.30300@cs.byu.edu>
References: <457E16C7.30300@cs.byu.edu>
Message-ID: <6F90C801-A70F-49F5-8457-472D55C4D57B@mac.com>

I think they are adding a prefix to indicate its a reference  
(pointer) rather than a structure the same way they (and is common  
practice) use a suffix _t to mean type.

On Dec 11, 2006, at 18:41, Neil Toronto wrote:

> What does the "ref" in "refEntity_t" stand for? Refresh?
>
> Neil
>



From phaethon at linux.ucla.edu  Tue Dec 12 02:55:52 2006
From: phaethon at linux.ucla.edu (Frederick Lee)
Date: Mon, 11 Dec 2006 23:55:52 -0800
Subject: [quake3] Quick question
In-Reply-To: <457E16C7.30300@cs.byu.edu>
References: <457E16C7.30300@cs.byu.edu>
Message-ID: <20061212075552.GC28398@linux.ucla.edu>

On Mon, Dec 11, 2006 at 07:41:11PM -0700, Neil Toronto wrote:
> What does the "ref" in "refEntity_t" stand for? Refresh?
> 
> Neil

I always thought it stood for Reference in the sense of a template or
comparison point, as in "JPEG Reference Library" or that 1kg block of
iridium-platinum used as the references unit of mass.  I usually
visualize an oil painter using his/her thumb as a (size) reference.

I really ought to study the cgame code in more depth.

-Fred


From 0000spam at gmail.com  Tue Dec 12 04:07:15 2006
From: 0000spam at gmail.com (DD)
Date: Tue, 12 Dec 2006 10:07:15 +0100
Subject: Max cvars
Message-ID: <f88c69fa0612120107u1a0554d8oca7cf741ecf20ea7@mail.gmail.com>

What is max number of cvars in quake 3? Is there any difference
regarding this between 1.32 and ioq3?

All i found is 256 bytes max cvar size before overflow. Would be bad
to increase this to 1024 or even 8192?

DD


From ntoronto at cs.byu.edu  Wed Dec 13 20:33:30 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Wed, 13 Dec 2006 18:33:30 -0700
Subject: Python performance report
Message-ID: <4580A9EA.2020904@cs.byu.edu>

System: 1.66GHz Intel Core Duo laptop with frequency scaling, Intel 
945GM graphics, Ubuntu 6.10.

On this system, with com_maxfps set to 60, Python is doing fine at low 
latencies, and mostly fine at high.

Here's some background. I've got the Python client game loaded and 
rendering the map, all players, all items, and some effects like rocket 
explosions. Most of the sounds play. A significant part of all this is 
player prediction, which I'll go over now. It's actually rather 
annoying, but kind of cool at the same time.

If you remember Quake before QuakeWorld, you might remember that it was 
impossible to play online without a really good connection. The reason 
is that the snapshots your client got were interpolated between to get 
your current position. The snapshots, of course, had some delay. The end 
result is that, when you moved, it would have to bounce your move off of 
the server before you actually saw it. If you want to see what it's 
like, you can make Quake 3 do this by setting cg_nopredict to 1. Things 
like rocket fire and bullets are still like this.

Player prediction compensated for that, and has been included since. 
Here's the short version: for every frame rendered, the client starts 
with a fresh player state from the snapshot and *plays back every move 
you've made that the server hasn't seen yet*.

Yeah, so that's rough on the CPU. Your client plays back about "ping * 
FPS / 1000" moves. If you ping 500 and your FPS is 60, it does 30. 
According to my profiling, the hardest part of moving a player is a 
trace (collision detection), and your average player move makes 3 or 4 
calls to trace: to find the ground, to move him forward, to slide him 
against a wall or another player, and to find the ground again. At 30 
moves per frame, 100 trace calls is pretty expensive.

Contrast this to the server game, which only has to make *one* move per 
player move. The client game is definitely a sucker for punishment.

The good news is that Python is doing fine proxying all those trace 
calls, and that the traces themselves take half the time it takes to 
render a frame when you ping 500. Python does get choppy before a native 
DLL does, but at normal pings (sub-200) and normal frame rates 
(sub-120), it'll perform just fine on current hardware. Also, I now have 
no worries whatsoever about Python's performance on either the client or 
the server.

Couple of tidbits:

1) I've implemented cg_latentSnaps (from Unlagged), and it was way 
easier than in 1.27. Somebody seriously cleaned up cg_snapshot.c. This 
cvar allows you to simulate lag. The client game simply requests 
snapshot number "current - cg_latentSnaps".

2) I've added com_laptop, which, if 1, causes Sys_Sleep(0) to be called 
at the end of the (busy-wait) rendering loop. It makes Quake 3 a little 
more laptop-friendly, and also lets you see the *real* amount of CPU 
Quake 3 takes on your performance meter. (Otherwise it's always 100%.)

Neither of these are in the main trunk, of course, but they ought to be 
considered.

Neil



From langer.markus at gmail.com  Thu Dec 14 06:08:32 2006
From: langer.markus at gmail.com (markus langer)
Date: Thu, 14 Dec 2006 12:08:32 +0100
Subject: [quake3] Python performance report
In-Reply-To: <4580A9EA.2020904@cs.byu.edu>
References: <4580A9EA.2020904@cs.byu.edu>
Message-ID: <8a0e0ccf0612140308x7b9c5ee2i943449beb10d730b@mail.gmail.com>

where can i get this python stuff?

markus

On 12/14/06, Neil Toronto <ntoronto at cs.byu.edu> wrote:
>
> System: 1.66GHz Intel Core Duo laptop with frequency scaling, Intel
> 945GM graphics, Ubuntu 6.10.
>
> On this system, with com_maxfps set to 60, Python is doing fine at low
> latencies, and mostly fine at high.
>
> Here's some background. I've got the Python client game loaded and
> rendering the map, all players, all items, and some effects like rocket
> explosions. Most of the sounds play. A significant part of all this is
> player prediction, which I'll go over now. It's actually rather
> annoying, but kind of cool at the same time.
>
> If you remember Quake before QuakeWorld, you might remember that it was
> impossible to play online without a really good connection. The reason
> is that the snapshots your client got were interpolated between to get
> your current position. The snapshots, of course, had some delay. The end
> result is that, when you moved, it would have to bounce your move off of
> the server before you actually saw it. If you want to see what it's
> like, you can make Quake 3 do this by setting cg_nopredict to 1. Things
> like rocket fire and bullets are still like this.
>
> Player prediction compensated for that, and has been included since.
> Here's the short version: for every frame rendered, the client starts
> with a fresh player state from the snapshot and *plays back every move
> you've made that the server hasn't seen yet*.
>
> Yeah, so that's rough on the CPU. Your client plays back about "ping *
> FPS / 1000" moves. If you ping 500 and your FPS is 60, it does 30.
> According to my profiling, the hardest part of moving a player is a
> trace (collision detection), and your average player move makes 3 or 4
> calls to trace: to find the ground, to move him forward, to slide him
> against a wall or another player, and to find the ground again. At 30
> moves per frame, 100 trace calls is pretty expensive.
>
> Contrast this to the server game, which only has to make *one* move per
> player move. The client game is definitely a sucker for punishment.
>
> The good news is that Python is doing fine proxying all those trace
> calls, and that the traces themselves take half the time it takes to
> render a frame when you ping 500. Python does get choppy before a native
> DLL does, but at normal pings (sub-200) and normal frame rates
> (sub-120), it'll perform just fine on current hardware. Also, I now have
> no worries whatsoever about Python's performance on either the client or
> the server.
>
> Couple of tidbits:
>
> 1) I've implemented cg_latentSnaps (from Unlagged), and it was way
> easier than in 1.27. Somebody seriously cleaned up cg_snapshot.c. This
> cvar allows you to simulate lag. The client game simply requests
> snapshot number "current - cg_latentSnaps".
>
> 2) I've added com_laptop, which, if 1, causes Sys_Sleep(0) to be called
> at the end of the (busy-wait) rendering loop. It makes Quake 3 a little
> more laptop-friendly, and also lets you see the *real* amount of CPU
> Quake 3 takes on your performance meter. (Otherwise it's always 100%.)
>
> Neither of these are in the main trunk, of course, but they ought to be
> considered.
>
> Neil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20061214/292f3154/attachment.htm>

From tjw at webteam.net  Thu Dec 14 13:04:30 2006
From: tjw at webteam.net (Tony J. White)
Date: Thu, 14 Dec 2006 12:04:30 -0600
Subject: [quake3] Python performance report
In-Reply-To: <4580A9EA.2020904@cs.byu.edu>
References: <4580A9EA.2020904@cs.byu.edu>
Message-ID: <20061214180430.GI28123@morbo.webteam.net>

On Wed, Dec 13, 2006 at 06:33:30PM -0700, Neil Toronto wrote:
> 1) I've implemented cg_latentSnaps (from Unlagged), and it was way easier than 
> in 1.27. Somebody seriously cleaned up cg_snapshot.c. This cvar allows you to 
> simulate lag. The client game simply requests snapshot number "current - 
> cg_latentSnaps".

Is this necessary now that cl_packetdelay and sv_packetdelay are in the
engine?

> 2) I've added com_laptop, which, if 1, causes Sys_Sleep(0) to be called at the 
> end of the (busy-wait) rendering loop. It makes Quake 3 a little more 
> laptop-friendly, and also lets you see the *real* amount of CPU Quake 3 takes 
> on your performance meter. (Otherwise it's always 100%.)

Is Sys_Sleep() just a wrapper for win32 Sleep() and posix usleep()?
Does calling it with 0 just help in process scheduling?

-Tony



From ntoronto at cs.byu.edu  Thu Dec 14 13:40:51 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Thu, 14 Dec 2006 11:40:51 -0700
Subject: [quake3] Python performance report
In-Reply-To: <20061214180430.GI28123@morbo.webteam.net>
References: <4580A9EA.2020904@cs.byu.edu> <20061214180430.GI28123@morbo.webteam.net>
Message-ID: <45819AB3.9010909@cs.byu.edu>

Tony J. White wrote:
> On Wed, Dec 13, 2006 at 06:33:30PM -0700, Neil Toronto wrote:
>   
>> 1) I've implemented cg_latentSnaps (from Unlagged), and it was way easier than 
>> in 1.27. Somebody seriously cleaned up cg_snapshot.c. This cvar allows you to 
>> simulate lag. The client game simply requests snapshot number "current - 
>> cg_latentSnaps".
>>     
>
> Is this necessary now that cl_packetdelay and sv_packetdelay are in the
> engine?
>   

Holy behind the times Batman!

Very cool. Better granularity than mine, too. They only appear to work 
in a real client/server situation, though. I'll have to see if Eclipse 
will let me tweak my run script like that. Hmm...

(Eclipse, no kidding. With the C and Python plugins, I have the perfect 
IDE for this project.)

>   
>> 2) I've added com_laptop, which, if 1, causes Sys_Sleep(0) to be called at the 
>> end of the (busy-wait) rendering loop. It makes Quake 3 a little more 
>> laptop-friendly, and also lets you see the *real* amount of CPU Quake 3 takes 
>> on your performance meter. (Otherwise it's always 100%.)
>>     
>
> Is Sys_Sleep() just a wrapper for win32 Sleep() and posix usleep()?
> Does calling it with 0 just help in process scheduling?
>   

Yes, it's a wrapper. Calling the sleep function on either system with 0 
gives the process back to the scheduler so that it's free to let the CPU 
idle if it has nothing better to do. Here's the code from common.c:

    // we may want to spin here if things are going too fast
    if ( !com_dedicated->integer && com_maxfps->integer > 0 && 
!com_timedemo->integer ) {
        minMsec = 1000 / com_maxfps->integer;
    } else {
        minMsec = 1;
    }
    do {
        com_frameTime = Com_EventLoop();
        if ( lastTime > com_frameTime ) {
            lastTime = com_frameTime;        // possible on first frame
        }
        msec = com_frameTime - lastTime;
        if (com_laptop->integer && msec < minMsec) {
            // Mitigate the effects of this busy wait loop on the CPU
            Sys_Sleep(0);
        }
    } while ( msec < minMsec );
    Cbuf_Execute ();


It only calls Sys_Sleep(0) if the frame hasn't taken its allotted time. 
Now that I think about it, kicking the process off to the scheduler 
could alter the amount of time the loop took, which means msec should 
probably be recalculated.

Running the event loop in response to a timer event would be much more 
robust, but this code does so much I don't understand that I don't want 
to muck with it that much.

Neil



From ntoronto at cs.byu.edu  Thu Dec 14 13:44:40 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Thu, 14 Dec 2006 11:44:40 -0700
Subject: [quake3] Python performance report
In-Reply-To: <8a0e0ccf0612140308x7b9c5ee2i943449beb10d730b@mail.gmail.com>
References: <4580A9EA.2020904@cs.byu.edu> <8a0e0ccf0612140308x7b9c5ee2i943449beb10d730b@mail.gmail.com>
Message-ID: <45819B98.6010901@cs.byu.edu>

markus langer wrote:
> where can i get this python stuff?
>
> markus

If you mean the Python-embedded Quake 3 engine, it's on my hard drive 
and you can't have it yet. :p If you just want the language, go to 
python.org. Unless you're on Linux: then it's in your distribution's 
repository, and there's a decent chance you already have it. I recommend 
checking out pygame after doing the tutorials. It's nicely abstracted 
and easy to use.

If you already speak a couple of programming languages you can pick up 
Python in about a day. There's just no reason not to.

</evangelism>

Neil



From monk at rq3.com  Fri Dec 15 20:15:42 2006
From: monk at rq3.com (monk at rq3.com)
Date: Fri, 15 Dec 2006 18:15:42 -0700 (MST)
Subject: MD4 support in ioq3 as a patch?
Message-ID: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>

Hi y'all.  It was suggested that someone on this mailing list a while back
was interested in implementing MD4 support in ioq3.  Now that ioq3's got a
patch system set up, it would be nice to offer an optional patch for MD4
support.

Is anyone interested in this anymore?

For those who haven't heard about MD4 all that much, here's some linkage:

http://gongo.quakedev.com
http://gongo.quakedev.com/md4.html
http://gongo.quakedev.com/files.html

I've talked with Gongo recently and while he has no time or interest in
finishing his work, he does fully support this.


From druska at gmail.com  Fri Dec 15 21:10:50 2006
From: druska at gmail.com (Dave)
Date: Fri, 15 Dec 2006 21:10:50 -0500
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
Message-ID: <db0795730612151810n3329d888n677e3e9955a36b11@mail.gmail.com>

I like this idea. On gongo's website he claims that its difficult to develop
md4's because there are no available build tools.
I'm really just wondering if there will be support for Maya, because newer
versions of Maya don't really support md3's.

Nice idea though!

On 12/15/06, monk at rq3.com <monk at rq3.com> wrote:
>
> Hi y'all.  It was suggested that someone on this mailing list a while back
> was interested in implementing MD4 support in ioq3.  Now that ioq3's got a
> patch system set up, it would be nice to offer an optional patch for MD4
> support.
>
> Is anyone interested in this anymore?
>
> For those who haven't heard about MD4 all that much, here's some linkage:
>
> http://gongo.quakedev.com
> http://gongo.quakedev.com/md4.html
> http://gongo.quakedev.com/files.html
>
> I've talked with Gongo recently and while he has no time or interest in
> finishing his work, he does fully support this.
>
> From what I've gathered, the work seems to be about 95% done.  He outlined
> a few of the spots that need "finishing" and I was able to get the latest
> version of the renderer code from 'im.  I am not a skilled coder which is
> why I am trying to gauge interest in this.
>
> I do admit that part of my motivation is to use MD4 support in an existing
> Q3 project/mod, but I'd rather see something that can be easily integrated
> in ioq3 for everyone to use.  Most of the artists I've talked to have
> ragged on Q3 and MD3 for lack of skeletal animation support.  Since
> everyone and their mother seems to be using ioq3 as the basis for turning
> Q3 mods into standalone projects, it seems only logical that any type of
> skeletal animation support be provided to work seamlessly with ioq3 as a
> patch.
>
> The best part of MD4 as far as I can tell is the extra support for the
> artists' tools.  The 3dmax exporters and apparently the MD4 importer also
> has preliminary support for HL and HL2 animation files.
>
> Yes, I know that Xreal has support for MD5 and that kind of fun stuff.  I
> haven't really pursued that avenue, yet.  I figured if there were no
> interest whatsoever in MD4, I could pursue that route instead.
>
> If anyone is interested, I will provide what help I can, copies of my
> correspondence with Gongo, the latest code I have access to, someone able
> to create HL art assets to test the MD4 importer, etc.
>
> Thanks for your time!
>
> Monk
> www.rq3.com
>
>
>


-- 
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20061215/2ca342ad/attachment.htm>

From linuxmanmikec at gmail.com  Fri Dec 15 21:22:28 2006
From: linuxmanmikec at gmail.com (LinuxManMikeC)
Date: Fri, 15 Dec 2006 21:22:28 -0500
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <db0795730612151810n3329d888n677e3e9955a36b11@mail.gmail.com>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
	 <db0795730612151810n3329d888n677e3e9955a36b11@mail.gmail.com>
Message-ID: <4561ec380612151822o21bf1c4bq5d126a8274af1e09@mail.gmail.com>

I had been looking into this myself.  Already work going on for MD4,
at lest the version that was in Star Trek Voyager: Elite Force (aka...
MDR).  I read that someone found the MDR code in the GPL Quake 3 code
and (if I remember correctly) it was fully functional.  Anyway, check
the changelog for renderer/tr_model.c.  There has been work going on
with the MDR format already.  And again, if I remember correctly, it
is working.

http://svn.icculus.org/quake3/trunk/code/renderer/tr_model.c

On 12/15/06, Dave <druska at gmail.com> wrote:
> I like this idea. On gongo's website he claims that its difficult to develop
> md4's because there are no available build tools.
> I'm really just wondering if there will be support for Maya, because newer
> versions of Maya don't really support md3's.
>
> Nice idea though!
>
>
> On 12/15/06, monk at rq3.com <monk at rq3.com> wrote:
> > Hi y'all.  It was suggested that someone on this mailing list a while back
> > was interested in implementing MD4 support in ioq3.  Now that ioq3's got a
> > patch system set up, it would be nice to offer an optional patch for MD4
> > support.
> >
> > Is anyone interested in this anymore?
> >
> > For those who haven't heard about MD4 all that much, here's some linkage:
> >
> > http://gongo.quakedev.com
> > http://gongo.quakedev.com/md4.html
> > http://gongo.quakedev.com/files.html
> >
> > I've talked with Gongo recently and while he has no time or interest in
> > finishing his work, he does fully support this.
> >
> > From what I've gathered, the work seems to be about 95% done.  He outlined
> > a few of the spots that need "finishing" and I was able to get the latest
> > version of the renderer code from 'im.  I am not a skilled coder which is
> > why I am trying to gauge interest in this.
> >
> > I do admit that part of my motivation is to use MD4 support in an existing
> > Q3 project/mod, but I'd rather see something that can be easily integrated
> > in ioq3 for everyone to use.  Most of the artists I've talked to have
> > ragged on Q3 and MD3 for lack of skeletal animation support.  Since
> > everyone and their mother seems to be using ioq3 as the basis for turning
> > Q3 mods into standalone projects, it seems only logical that any type of
> > skeletal animation support be provided to work seamlessly with ioq3 as a
> > patch.
> >
> > The best part of MD4 as far as I can tell is the extra support for the
> > artists' tools.  The 3dmax exporters and apparently the MD4 importer also
> > has preliminary support for HL and HL2 animation files.
> >
> > Yes, I know that Xreal has support for MD5 and that kind of fun stuff.  I
> > haven't really pursued that avenue, yet.  I figured if there were no
> > interest whatsoever in MD4, I could pursue that route instead.
> >
> > If anyone is interested, I will provide what help I can, copies of my
> > correspondence with Gongo, the latest code I have access to, someone able
> > to create HL art assets to test the MD4 importer, etc.
> >
> > Thanks for your time!
> >
> > Monk
> > www.rq3.com
> >
> >
> >
>
>
>
> --
> Dave


From arny at ats.s.bawue.de  Sat Dec 16 08:05:06 2006
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Sat, 16 Dec 2006 14:05:06 +0100
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
Message-ID: <200612161405.10135.arny@ats.s.bawue.de>

On Saturday 16 December 2006 02:15, monk at rq3.com wrote:
> Hi y'all.  It was suggested that someone on this mailing list a while back
> was interested in implementing MD4 support in ioq3.  Now that ioq3's got a
> patch system set up, it would be nice to offer an optional patch for MD4
> support.
>
> Is anyone interested in this anymore?

There already *is* working MD4 support and it has been in ioq3 for ages.
The md4 support that is included features full support for MD4 models from 
Star Trek Voyager - Elite Force. Please check the file 
http://svn.icculus.org/quake3/trunk/md4-readme.txt?rev=729&view=markup for 
more information.

> I do admit that part of my motivation is to use MD4 support in an existing
> Q3 project/mod, but I'd rather see something that can be easily integrated
> in ioq3 for everyone to use.  Most of the artists I've talked to have
> ragged on Q3 and MD3 for lack of skeletal animation support.  Since
> everyone and their mother seems to be using ioq3 as the basis for turning
> Q3 mods into standalone projects, it seems only logical that any type of
> skeletal animation support be provided to work seamlessly with ioq3 as a
> patch.

There should be only one system that most people will agree on. And that is 
the system where best modelling and animation support exists for.

> If anyone is interested, I will provide what help I can, copies of my
> correspondence with Gongo, the latest code I have access to, someone able
> to create HL art assets to test the MD4 importer, etc.

Sorry to say it, but at the moment I am not particularly interested. If - and 
only if - someone came up to work on this and make Gongo's or anyone else's 
model format work like a charm on ioq3 I'd be willing to take my EliteForce 
stuff out and have ioquake3 go with that one instead. But atm, as far as I 
can tell Gongo's modelling format suffers from the same problem as 
EliteForce's does: lack of application support to create animations. Keep in 
mind, that with EliteForce there already are loads of models that could 
potentially be used.

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061216/5db84f14/attachment.pgp>

From ntoronto at cs.byu.edu  Sat Dec 16 18:43:30 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Sat, 16 Dec 2006 16:43:30 -0700
Subject: Impotent code in cgame
Message-ID: <458484A2.9090500@cs.byu.edu>

1) CG_SpawnRailTrail returns immediately if cent->pe.railgunFlash is 
qfalse. Then it sets cent->pe.railgunFlash to qtrue. Besides being 
stupid, this is the only place that railgunFlash is ever set to qtrue, 
so CG_RailTrail is never called from here.

Rail trails are always drawn in response to an EV_RAILTRAIL event. If 
someone ever does get CG_SpawnRailTrail to work they'll have double rail 
trails. I recommend removing CG_SpawnRailTrail and playerEntity_t's 
railgunFlash altogether.

I believe CG_SpawnRailTrail was historically an attempt to make the rail 
trail appear to originate from the muzzle.

2) cg_runroll and cg_runpitch don't actually do anything. Here's the 
code that uses them, from CG_OffsetFirstPersonView:

    delta = DotProduct ( predictedVelocity, cg.refdef.viewaxis[0]);
    angles[PITCH] += delta * cg_runpitch.value;
   
    delta = DotProduct ( predictedVelocity, cg.refdef.viewaxis[1]);
    angles[ROLL] -= delta * cg_runroll.value;


At this point, cg.refdef.viewaxis is all zeros, so the dot product is 
zero, and the angles aren't changed. In my Python implementation, I had, 
you know, ignorantly made it work, and it looks terrible and jerky. I 
recommend removing it altogether, along with the cg_runpitch and 
cg_runroll cvars.

There are other impotent bits I've come across but I recommend leaving 
in. EV_DEBUG_LINE and EV_STOPLOOPINGSOUND are never generated by the 
server game, but somebody might find them useful.

I'll post more of these as I find them and they frustrate the heck out 
of me. :)

Neil



From 0000spam at gmail.com  Sun Dec 17 21:23:15 2006
From: 0000spam at gmail.com (DD)
Date: Mon, 18 Dec 2006 03:23:15 +0100
Subject: Excellent wings over invisible player
Message-ID: <f88c69fa0612171823o111f9e6fy2d0054076df765f7@mail.gmail.com>

Quake 3 draws Excellent wings over player's head if two kills are made
in less than 'CARNAGE_REWARD_TIME'. Problem is, when player is using
INVIS powerup this sprite may reveal players location.

If you want to fix this in ioquake3, code is in code > game > g_combat.c:

				// add the sprite over the player's head
				attacker->client->ps.eFlags &= ~(EF_AWARD_IMPRESSIVE |
EF_AWARD_EXCELLENT | EF_AWARD_GAUNTLET | EF_AWARD_ASSIST |
EF_AWARD_DEFEND | EF_AWARD_CAP );
				attacker->client->ps.eFlags |= EF_AWARD_EXCELLENT;
				attacker->client->rewardTime = level.time + REWARD_SPRITE_TIME;
			}

Fix would be:
if ( !attacker->client->ps.powerups[PW_INVIS] ) {

...(code above)

}

Thanks to Skidm at rk for pointing this out on my server. :)

Still i am interested, if someone knows, what is max allowed number of
CVARS in (io)Q3?

DD


From ntoronto at cs.byu.edu  Sun Dec 17 21:54:21 2006
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Sun, 17 Dec 2006 19:54:21 -0700
Subject: [quake3] Excellent wings over invisible player
In-Reply-To: <f88c69fa0612171823o111f9e6fy2d0054076df765f7@mail.gmail.com>
References: <f88c69fa0612171823o111f9e6fy2d0054076df765f7@mail.gmail.com>
Message-ID: <458602DD.6070806@cs.byu.edu>

DD wrote:
> Still i am interested, if someone knows, what is max allowed number of
> CVARS in (io)Q3?
>
> DD

cvar.c says:

#define    MAX_CVARS    1024

And, fascinatingly, it stores cvar names in a hash table, so doubling 
both MAX_CVARS and FILE_HASH_SIZE wouldn't result in a performance 
penalty. I'm not sure why that hasn't been done yet.

Neil



From 0000spam at gmail.com  Sun Dec 17 22:10:29 2006
From: 0000spam at gmail.com (DD)
Date: Mon, 18 Dec 2006 04:10:29 +0100
Subject: [quake3] Excellent wings over invisible player
In-Reply-To: <458602DD.6070806@cs.byu.edu>
References: <f88c69fa0612171823o111f9e6fy2d0054076df765f7@mail.gmail.com>
	 <458602DD.6070806@cs.byu.edu>
Message-ID: <f88c69fa0612171910l430249acsac1e8a0ec26a9097@mail.gmail.com>

On 12/18/06, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> DD wrote:
> > Still i am interested, if someone knows, what is max allowed number of
> > CVARS in (io)Q3?
> >
> > DD
>
> cvar.c says:
>
> #define    MAX_CVARS    1024
>
> And, fascinatingly, it stores cvar names in a hash table, so doubling
> both MAX_CVARS and FILE_HASH_SIZE wouldn't result in a performance
> penalty. I'm not sure why that hasn't been done yet.
>
> Neil

Thanks, somehow i missed it. Some games use 2048, if i am not
mistaken. Maybe even quadrupling would be possible...

I forgot to mention before... Visible icons over invisible players
also occur for gauntlet kills, impressive award and team defend,
assist and capture.

DD


From monk at rq3.com  Mon Dec 18 10:16:44 2006
From: monk at rq3.com (monk at rq3.com)
Date: Mon, 18 Dec 2006 08:16:44 -0700 (MST)
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <200612161405.10135.arny@ats.s.bawue.de>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
    <200612161405.10135.arny@ats.s.bawue.de>
Message-ID: <2933.64.81.110.230.1166455004.squirrel@mail.rq3.com>

Thanks for the responses thus far!

To address Thilo's concerns:

MD4 support via EF.  I'm not sure I understand.  You mention MDR as being
the same thing as MD4, but the information I got seems to disagree?  In
fact the information I have to the contrary I got from the very same site
you pointed me to:

http://synapse.vgfort.com/skinning.php

Specifically:

"The mdr file is a compressed collection of several md3 files."
...
"You don't have to make your files mdr they can be md3 and it will still
work. So you could use all your model files as md3 and have no problems."

The only information that I can find is that the models were originally
animated with bones and whatnot and then exported/compiled into the MDR
format.  Which "is a compressed collection of several md3 files."

I didn't send the MD4 email out to personally attack your work on EF or
IOQ3 and I'm sorry if you took it that way.  It was not my intent and I
was only going on the information I had at hand.  I mention this only
because you seem to be taking it as a personal attack?

> There should be only one system that most people will agree on. And that
> is the system where best modelling and animation support exists for.

Maybe, but I'm more of the thought of offering choice.  If someone has the
option to choose what fits them best, why make it harder for them by only
endorsing one 'official' format?

I suppose part of the problem is that there's no way for a layman like me
to look at the implemented features at:

http://www.ioquake3.org/?page=status

And somehow know to look at:

http://svn.icculus.org/quake3/trunk/md4-readme.txt?rev=729&view=markup

Even then, the information at the sites listed don't particularly mention
skeletal animation and list Milkshape3D as the main tool for working with
this format?  I'm looking at some of Gongo's MD4 downloads:

http://gongo.quakedev.com/files.html

...and seeing a bunch of different versions of the exporter for 3DSMax
plus the source for someone to modify to work with any other versions, I
suppose.

As stated, the other tool on the page, skl2md4, apparently has preliminary
support for working with HL and HL2 SML/MDL files.  Get that
tweaked/fixed/completed and that opens up all the tools and plugins made
for the HUGE HL/HL2 artist community.  Heck, you might even be able to
modify that code to import HL/HL2 files directly into the MD4 renderer on
the fly.

That seems like decent present application support and excellent potential
application support.  If there are other MDR plugins besides the ones for
Milkshape3D, heck, that EF skinning tutorial should link to 'em!

I am sad you're viewing this as an MD4 versus MDR thing.  If someone got
MD4 working as an unsupported "patch" for IOQ3 to be posted at:

http://www.ioquake3.org/?page=patches

...you'd be willing to take your stuff out of IOQ3?  Why?  I just don't
understand why you'd have to do that or even want to do that.  It seems
like you're taking this personally and I'm not sure why.  But I am sorry
as, again, it's not my intent to pop on this discussion list and say, "ha
ha, let's get MD4 working and force Thilo to rip out all his MDR work from
IOQ3!"

No, really, this is NOT my intent.  And I'm sorry it's somehow being
perceived this way.

"Sorry to say it, but at the moment I am not particularly interested."

Ok, no harm no foul!

---------------------------

Ok, if MDR is more than just a collection of compressed MD3's and does
support skeletal animation, is anyone willing to try and whip up some more
support/tool programs for it?  Plugins, importers/exporters, that kind of
thing?

I'm approaching this from the standpoint of a guy trying to entice content
developers to make stuff for my mod/game.  Be it Reaction, Western Quake
3, Navy Seals Quake 3, Urban Terror, whatever.  So far MD4 seems to be one
of the best bets because it appears to offer so much support in getting
content from various places actually in to a format I would be able to
use.

I need to be able to butter up some animator and show them, yes, you can
use X and Y to produce animated models for this project.  And they will
work with the programs you already use.  Maya support would be nice, but I
do not know what that would entail.

The only other thing I can think of that might work as far as support and
"mindshare" would be the MD5 support in Xreal.  Due to Doom 3 and it being
"new".  But I don't know what kind of support's there... does it just load
static models?  I see the guy can also load Lightwave objects, which is
neat too.  But does he have support for skeletal animation and whatnot?  I
just don't know.

Gongo's MD4 work seems, to me, to still be one of the most promising
solutions to the "get more artists to work on Q3-based projects" problem
that I have run into over the years.  Hopefully someone on this list will
have enough interest to finish 'er off.  Either way, I am also looking
anywhere else I can for interested parties.  Man, used to be you could
find a coder willing to work for mountain dew... ;)

Again, thanks for your time.

Monk.


From nightmare at int13h.com  Mon Dec 18 10:30:29 2006
From: nightmare at int13h.com (Nightmare)
Date: Mon, 18 Dec 2006 15:30:29 +0000
Subject: Irix Patches
Message-ID: <20061218153029.00000f0d@BlueThing>

Hello all,

Sorry for the awesomely late patches for IRIX, our resident porting guru has just had a kiddie so he is going to be a little busy for a while. The latest branch of the source is fantastic by the way, it actually seemed to resolve one of the main issues with running this on IRIX (the video files were causing it to core) but it seems to work fine now.

I have a -03 release build running on my 300mhz Octane MXE (4mb texture ram) system great, its churning out about 30-50fps at low detail on q3dm7, very playable. The only outstanding problem I have at the moment is a rather minor issue of the botlib causing a coredump as soon as a bot spawns, I shall set my debugger on that tonight with any luck. Other than that is a very clean build so kudos to the dev team, thanks for giving us a working Quake 3 source for our old dinosaurs. Might have to run a few servers on our 16CPU Origin box =]

I have attached the diff file, I hope it doesn't cause any problems with the rest of the source, it's basically just makefile / q_platform changes and an #ifndef in sdl_glimp.c for some multitexture bits that IRIX doesn't have.

Oh the one thing that might make you ponder is the clean2: changes at the bottom of the Makefile, basically IRIX's built in rm wont process that amount of arguments in one hit so I have split the objs into a few lines. Hope that's not a problem.

Cheers, keep up the great work!
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irix.diff
Type: application/octet-stream
Size: 4747 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061218/ceefc3dd/attachment.obj>

From nightmare at int13h.com  Mon Dec 18 10:41:58 2006
From: nightmare at int13h.com (Nightmare)
Date: Mon, 18 Dec 2006 15:41:58 +0000
Subject: [quake3] Irix Patches
In-Reply-To: <20061218153029.00000f0d@BlueThing>
References: <20061218153029.00000f0d@BlueThing>
Message-ID: <20061218154158.0000019a@BlueThing>

Sorry missed a part of the diff.. [attached]

Dave

On Mon, 18 Dec 2006 15:30:29 +0000
Nightmare <nightmare at int13h.com> wrote:

> Hello all,
> 
> Sorry for the awesomely late patches for IRIX, our resident porting guru has just had a kiddie so he is going to be a little busy for a while. The latest branch of the source is fantastic by the way, it actually seemed to resolve one of the main issues with running this on IRIX (the video files were causing it to core) but it seems to work fine now.
> 
> I have a -03 release build running on my 300mhz Octane MXE (4mb texture ram) system great, its churning out about 30-50fps at low detail on q3dm7, very playable. The only outstanding problem I have at the moment is a rather minor issue of the botlib causing a coredump as soon as a bot spawns, I shall set my debugger on that tonight with any luck. Other than that is a very clean build so kudos to the dev team, thanks for giving us a working Quake 3 source for our old dinosaurs. Might have to run a few servers on our 16CPU Origin box =]
> 
> I have attached the diff file, I hope it doesn't cause any problems with the rest of the source, it's basically just makefile / q_platform changes and an #ifndef in sdl_glimp.c for some multitexture bits that IRIX doesn't have.
> 
> Oh the one thing that might make you ponder is the clean2: changes at the bottom of the Makefile, basically IRIX's built in rm wont process that amount of arguments in one hit so I have split the objs into a few lines. Hope that's not a problem.
> 
> Cheers, keep up the great work!
> Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irix2.diff
Type: application/octet-stream
Size: 463 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061218/0b32c937/attachment.obj>

From tim at ngus.net  Mon Dec 18 10:44:47 2006
From: tim at ngus.net (Tim Angus)
Date: Mon, 18 Dec 2006 15:44:47 +0000
Subject: Irix Patches
In-Reply-To: <20061218154158.0000019a@BlueThing>
References: <20061218153029.00000f0d@BlueThing> <20061218154158.0000019a@BlueThing>
Message-ID: <4586B76F.8050309@ngus.net>

Nightmare wrote:
> Sorry missed a part of the diff.. [attached]

Better to stick this in bugzilla really (http://bugzilla.icculus.org/), 
patches to the mailing list have a habit of vanishing into places where 
they get forgotten about. Thanks for your efforts.


From nightmare at int13h.com  Mon Dec 18 11:25:45 2006
From: nightmare at int13h.com (Nightmare)
Date: Mon, 18 Dec 2006 16:25:45 +0000
Subject: [quake3] Re: Irix Patches
In-Reply-To: <4586B76F.8050309@ngus.net>
References: <20061218153029.00000f0d@BlueThing>
	<20061218154158.0000019a@BlueThing>
	<4586B76F.8050309@ngus.net>
Message-ID: <20061218162545.000053a1@BlueThing>

Tim Angus <tim at ngus.net> wrote:
> Better to stick this in bugzilla really (http://bugzilla.icculus.org/), 
> patches to the mailing list have a habit of vanishing into places where 
> they get forgotten about. Thanks for your efforts.
> 

Cheers, I have added it (Bug #2966).
Dave


From arny at ats.s.bawue.de  Mon Dec 18 11:53:27 2006
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Mon, 18 Dec 2006 17:53:27 +0100
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <2933.64.81.110.230.1166455004.squirrel@mail.rq3.com>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com> <200612161405.10135.arny@ats.s.bawue.de> <2933.64.81.110.230.1166455004.squirrel@mail.rq3.com>
Message-ID: <200612181753.38535.arny@ats.s.bawue.de>

On Monday 18 December 2006 16:16, monk at rq3.com wrote:
> MD4 support via EF.  I'm not sure I understand.  You mention MDR as being
> the same thing as MD4, but the information I got seems to disagree?  In
> fact the information I have to the contrary I got from the very same site
> you pointed me to:

In q_files.h, compare the structures for the MDR stuff and id's original MD4 
stuff. You will notice that they are nearly identical. So yes, MDR is the 
same as MD4 except for some minor differences.

> "The mdr file is a compressed collection of several md3 files."

That information is wrong then. It is a skeletal animation format.

> I didn't send the MD4 email out to personally attack your work on EF or
> IOQ3 and I'm sorry if you took it that way.  It was not my intent and I
> was only going on the information I had at hand.  I mention this only
> because you seem to be taking it as a personal attack?

TBH.. I fail to see how one can come to the conclusion from my posting that I 
judged your first email as a personal attack. This simply is not the case.

> > There should be only one system that most people will agree on. And that
> > is the system where best modelling and animation support exists for.
>
> Maybe, but I'm more of the thought of offering choice.  If someone has the
> option to choose what fits them best, why make it harder for them by only
> endorsing one 'official' format?

This is not ioquake3's way. The official project policy is not to have too 
much code in there that needs to be maintained.
This is also the reason why mp3 support is only there as a patch.

> I suppose part of the problem is that there's no way for a layman like me
> to look at the implemented features at:
>
> http://www.ioquake3.org/?page=status

Hmm.. maybe it should be included in the feature list.

> As stated, the other tool on the page, skl2md4, apparently has preliminary
> support for working with HL and HL2 SML/MDL files.  Get that
> tweaked/fixed/completed and that opens up all the tools and plugins made
> for the HUGE HL/HL2 artist community.  Heck, you might even be able to
> modify that code to import HL/HL2 files directly into the MD4 renderer on
> the fly.

Yes ok, that is a plus for Gongo's stuff.

> I am sad you're viewing this as an MD4 versus MDR thing.  If someone got
> MD4 working as an unsupported "patch" for IOQ3 to be posted at:
>
> http://www.ioquake3.org/?page=patches
>
> ...you'd be willing to take your stuff out of IOQ3?  Why? 

Why? Because I simply do not see this as an MD4 versus Thilo thing. If MD4 is 
the better solution, there is no question, MDR should be kicked out. I didn't 
develop this stuff for the sake of a new model format but just needed it for 
my EliteForce project and back then I thought ioquake3 could make use of a 
finished MD4 support so I submitted a patch. I wasn't even aware of Gongo's 
work back then.

> "Sorry to say it, but at the moment I am not particularly interested."

Read this line together with the context that I supplied in my first answer. I 
was saying that I am not interested in doing any work on this stuff because I 
have other things in my mind right now and the MDR stuff just works.

> Gongo's MD4 work seems, to me, to still be one of the most promising
> solutions to the "get more artists to work on Q3-based projects" problem
> that I have run into over the years.  Hopefully someone on this list will
> have enough interest to finish 'er off.  Either way, I am also looking
> anywhere else I can for interested parties.  Man, used to be you could
> find a coder willing to work for mountain dew... ;)

It maybe really is promising. My point is: If someone writes a patch that 
applies cleanly to ioquake3's codebase, it has a higher chance of getting 
integrated to ioquake3 than if someone just requests this feature, which is 
almost zero in the latter case. In the end, Zakk or Timbo decide over its 
inclusion.
If it is to be included, we need to be sure that the code for it is 
maintained, reasonably clean and well worked out.
So and before and if you write an answer, keep in mind: I'm neither angry, nor 
sad nor anything else. I'm just stating the things the way they are :)

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20061218/2f20e8b7/attachment.pgp>

From zakk at timedoctor.org  Mon Dec 18 13:25:46 2006
From: zakk at timedoctor.org (Zachary Slater)
Date: Mon, 18 Dec 2006 10:25:46 -0800
Subject: [quake3] MD4 support in ioq3 as a patch?
In-Reply-To: <200612181753.38535.arny@ats.s.bawue.de>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com> <200612161405.10135.arny@ats.s.bawue.de> <2933.64.81.110.230.1166455004.squirrel@mail.rq3.com> <200612181753.38535.arny@ats.s.bawue.de>
Message-ID: <4586DD2A.6020109@timedoctor.org>

I didn't remember that MDR and MD4 are similar, in any case, now that we 
have the patches page I think more model formats supported via it is a 
good idea.
-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From tim at ngus.net  Mon Dec 18 13:30:16 2006
From: tim at ngus.net (Tim Angus)
Date: Mon, 18 Dec 2006 18:30:16 +0000
Subject: MD4 support in ioq3 as a patch?
In-Reply-To: <4586DD2A.6020109@timedoctor.org>
References: <55796.63.150.173.150.1166231742.squirrel@mail.rq3.com>
	<200612161405.10135.arny@ats.s.bawue.de>
	<2933.64.81.110.230.1166455004.squirrel@mail.rq3.com>
	<200612181753.38535.arny@ats.s.bawue.de>
	<4586DD2A.6020109@timedoctor.org>
Message-ID: <20061218183016.c7bc2ad7.tim@ngus.net>

On Mon, 18 Dec 2006 10:25:46 -0800 Zachary wrote:
> I didn't remember that MDR and MD4 are similar, in any case, now that
> we have the patches page I think more model formats supported via it
> is a good idea.

There is perhaps even a case for backing out the existing skeletal
support and adding it to the patches repository. Just a thought.



From nightmare at int13h.com  Tue Dec 19 09:33:39 2006
From: nightmare at int13h.com (Nightmare)
Date: Tue, 19 Dec 2006 14:33:39 +0000
Subject: [quake3] Just a q...
In-Reply-To: <Pine.LNX.4.63.0512062226070.9056@thorbardin.lasthome.solace.krynn>
References: <Pine.LNX.4.63.0512061103050.9056@thorbardin.lasthome.solace.krynn>
	<4395DFB3.2040405@wanadoo.fr>
	<200512062037.51657.ludwig.nussel@suse.de>
	<Pine.LNX.4.63.0512062226070.9056@thorbardin.lasthome.solace.krynn>
Message-ID: <20061219143339.000068e3@BlueThing>

I get this exact issue on IRIX (mips) when spawning a bot in the game. My debugger makes it to that line too botlib/l_precomp.c:1800

PC_EvaluateTokens(source = 0x10c510d0, tokens = 0x10cc087c, intvalue = 0x0, floatvalue = 0x7ffedc50, integer = 0) ["l_precomp.c":1800, 0x1010ab4c]

v->floatvalue = t->floatvalue;

Values :
v->floatvalue = 7.89921175592437700e-227
t->floatvalue = 0.00000000000000000e+00

Using version : 1.33_SVN1013M

Cheers,
Dave

On Tue, 6 Dec 2005 22:30:12 +0100 (CET)
vincent at cojot.name wrote:

> On Tue, 6 Dec 2005, Ludwig Nussel wrote:
> 
> > Why didn't I come to this conclusion? :-)
> 
> :)
> 
> > Please check whether the attached patch fixes it. It uses memcpy
> > instead of the strange double* cast.
> 
> Your patch fixes it!!! :) I can now bring up the UI of the optimized (-O1) 
> release on Solaris/Sparc!!! :)
> 
> That's what I like about Solaris on Sparc, it usually makes code crash 
> where none has crashed before (no wonder they provide /usr/lib/0 at 0.so.1 to 
> try to make it more friendly.. :) :) :) :) ).
> 
> It still crashes when starting a game, though:
> 
> Program received signal SIGSEGV, Segmentation fault.
> PC_EvaluateTokens (source=0xb7ff18, tokens=0xc, intvalue=0x0, floatvalue=0xffbfc4d8, integer=0) at ../botlib/l_precomp.c:1800
> 1800                                            v->floatvalue = t->floatvalue;
> (gdb) bt
> #0  PC_EvaluateTokens (source=0xb7ff18, tokens=0xc, intvalue=0x0, floatvalue=0xffbfc4d8, integer=0) at ../botlib/l_precomp.c:1800
> #1  0x000d1734 in PC_DollarEvaluate (source=0xb7ff18, intvalue=0x0, floatvalue=0xffbfc4d8, integer=0) at ../botlib/l_precomp.c:2325
> #2  0x000d1c8c in PC_DollarDirective_evalfloat (source=0xb7ff18) at ../botlib/l_precomp.c:2586
> #3  0x000d1dec in PC_ReadDollarDirective (source=0xb7ff18) at ../botlib/l_precomp.c:2641
> #4  0x000d1f00 in PC_ReadToken (source=0xb7ff18, token=0xffbfd330) at ../botlib/l_precomp.c:2735
> #5  0x000d2400 in PC_ExpectAnyToken (source=0xb7ff18, token=0xffbfd330) at ../botlib/l_precomp.c:2870
> #6  0x000cb020 in ReadValue (source=0xb7ff18, value=0xbeedbc) at ../botlib/be_ai_weight.c:63
> #7  0x000cb10c in ReadFuzzyWeight (source=0xb7ff18, fs=0xbeedb0) at ../botlib/be_ai_weight.c:89
> #8  0x000cb4d0 in ReadFuzzySeperators_r (source=0xb7ff18) at ../botlib/be_ai_weight.c:215
> #9  0x000cb50c in ReadFuzzySeperators_r (source=0xb7ff18) at ../botlib/be_ai_weight.c:223
> #10 0x000cb938 in ReadWeightConfig (filename=0x1c71cb4 "bots/phobos_i.c") at ../botlib/be_ai_weight.c:369
> #11 0x000c1988 in BotLoadItemWeights (goalstate=9, filename=0x1c71cb4 "bots/phobos_i.c") at ../botlib/be_ai_goal.c:1697
> #12 0x000825fc in SV_GameSystemCalls (args=0x1c71c9c) at ../server/sv_game.c:743
> #13 0x00094ef8 in VM_CallInterpreted (vm=0x955eb8, args=0xffbfebb0) at ../qcommon/vm_interpreted.c:548
> #14 0x00094324 in VM_Call (vm=0x955eb8, callnum=9) at ../qcommon/vm.c:769
> #15 0x00082e74 in SV_GameCommand () at ../server/sv_game.c:971
> #16 0x0005a624 in Cmd_ExecuteString (text=0xffbfed58 "addbot phobos 1.000000 free 2000") at ../qcommon/cmd.c:667
> #17 0x00059cdc in Cbuf_Execute () at ../qcommon/cmd.c:220
> #18 0x0005e564 in Com_Frame () at ../qcommon/common.c:2736
> #19 0x00126dc0 in main (argc=16, argv=0xffbff6bc) at ../unix/unix_main.c:1414
> 
> Best regards,
> 
> -- 
> ,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
> Vincent S. Cojot, Computer Engineering. STEP project. _.,-*~'`^`'~*-,._.,-*~
> Ecole Polytechnique de Montreal, Comite Micro-Informatique. _.,-*~'`^`'~*-,.
> Linux Xview/OpenLook resources page _.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'
> http://step.polymtl.ca/~coyote  _.,-*~'`^`'~*-,._ coyote at NOSPAM4cojot.name
> 
> They cannot scare me with their empty spaces
> Between stars - on stars where no human race is
> I have it in me so much nearer home
> To scare myself with my own desert places.       - Robert Frost
> 
> 
> 


From 0000spam at gmail.com  Fri Dec 29 04:33:02 2006
From: 0000spam at gmail.com (DD)
Date: Fri, 29 Dec 2006 10:33:02 +0100
Subject: g-bot.c > G_RemoveRandomBot is buggy
Message-ID: <f88c69fa0612290133m4ce1c14dy2a62f55379c5b35d@mail.gmail.com>

This is used in conjunction with bot_minplayers, removing bots to keep
players number same as bot_minplayers, not counting spectators.
Problem is when custom bots use certain fun names and Q_CleanStr is
not working properly on or with them.

2 examples (without "") of errors when server tries to kick them:

"^1P^3u^4^2M^1p^3K^2i^1N^3a^2T^1o^3R"
Player PuMpKiNaToR is not on the server

"Mu ^1v.2"
Usage: kick <player name>
kick all = kick everyone
kick allbots = kick all bots

This was outputted into console. I was wondering who is trying to kick
some player all night. :)

I fixed the problem on our servers by kicking them by client number
instead of going thru all this name cleaning mess. Here is my fix, you
can use it in ioq3 or silently ignore it.

NEW CODE:
/*
===============
G_RemoveRandomBot
===============
*/
int G_RemoveRandomBot( int team ) {
        int i;
// DD   char netname[36];
        gclient_t       *cl;

        for ( i=0 ; i< g_maxclients.integer ; i++ ) {
                cl = level.clients + i;
                if ( cl->pers.connected != CON_CONNECTED ) {
                        continue;
                }
                if ( !(g_entities[cl->ps.clientNum].r.svFlags & SVF_BOT) ) {
                        continue;
                }
                if ( team >= 0 && cl->sess.sessionTeam != team ) {
                        continue;
                }
// DD           strcpy(netname, cl->pers.netname);
// DD           Q_CleanStr(netname);
                // DD kick by clientnum instead
                trap_SendConsoleCommand( EXEC_INSERT, va("clientkick
%i\n", cl->ps.clientNum) );
                return qtrue;
        }
        return qfalse;
}


OLD CODE:
/*
===============
G_RemoveRandomBot
===============
*/
int G_RemoveRandomBot( int team ) {
	int i;
	char netname[36];
	gclient_t	*cl;

	for ( i=0 ; i< g_maxclients.integer ; i++ ) {
		cl = level.clients + i;
		if ( cl->pers.connected != CON_CONNECTED ) {
			continue;
		}
		if ( !(g_entities[cl->ps.clientNum].r.svFlags & SVF_BOT) ) {
			continue;
		}
		if ( team >= 0 && cl->sess.sessionTeam != team ) {
			continue;
		}
		strcpy(netname, cl->pers.netname);
		Q_CleanStr(netname);
		trap_SendConsoleCommand( EXEC_INSERT, va("kick %s\n", netname) );
		return qtrue;
	}
	return qfalse;
}

dyn
vogonhq.com


From ludwig.nussel at suse.de  Fri Dec 29 05:34:52 2006
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Fri, 29 Dec 2006 11:34:52 +0100
Subject: [quake3] g-bot.c > G_RemoveRandomBot is buggy
In-Reply-To: <f88c69fa0612290133m4ce1c14dy2a62f55379c5b35d@mail.gmail.com>
References: <f88c69fa0612290133m4ce1c14dy2a62f55379c5b35d@mail.gmail.com>
Message-ID: <200612291134.52222.ludwig.nussel@suse.de>

DD wrote:
> I fixed the problem on our servers by kicking them by client number
> instead of going thru all this name cleaning mess. Here is my fix, you
> can use it in ioq3 or silently ignore it.

Your fix is appreciated. A unified diff would be much easier to
review and apply though. See http://www.ioquake3.org/?page=help for
instructions how to create one.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/