[quake3] Greetings

monk at rq3.com monk at rq3.com
Wed Apr 9 00:48:52 EDT 2008


[please do not mistake my length of emails for me being angry or
flaming--I'm just verbose!]

The mod that I work on, Reaction Quake 3 (now called "Reaction"), is
basically a port of the Quake 2 mod Action Quake 2 to the Q3 engine.  It
had a source release of AQ2 version 1.52.  Many many projects (40+ that I
know of) sprang forth and added a ton of different features and options.

By the time we started making RQ3, the concept of "AQ2" was muddied by the
playerbase.  In north america, the "standard" was one fork.  In europe,
the "standard" was another fork.  The RQ3 team is comprised of people from
all over the world (had an Aussie for a while too).

How to reconcile what we were making with what people thought we should be
making?  The way I approached this was to set a baseline of the original
AQ2 1.52 featureset.  Whatever else we did, we had to replicate the
gameplay of AQ2 1.52.  Once we had that down, it didn't matter if we
extended the gameplay to emulate any of the forks as long as it was
configurable by the server admin.

The point was that no matter what, we had that one baseline that everyone
could fall back to.

When you discuss shoving a new syscall down everyone's throats, to me I am
interpreting this as a programmer talking.  A programmer doesn't want a
ton of extraneous fluff in their code.  If the code's not being used, why
keep it around?  Tight, easy-to-read code is the ideal.

However, from an end-user or mod-creator perspective, you can't take
advantage of what's not available.  Adding a new syscall or extending ioq3
is not the same thing as changing the default behavior and compability,
right?  It's the same situation as though some mods weren't using some
syscalls.  Is that a reason to remove them?  Do they hurt anything by
being available to be used?  Not in my mind.

In RQ3 we added a bunch of new map entities and abilities; breakable
glass, exploding things when shot, door handles that moved, etc.  If I
recall correctly, we were able to easily modify the existing mapping tool
(gtkradiant?) to expose the new functionality for our mod.

Adding new syscalls and abilities to ioq3 shouldn't be a problem.  As long
as someone knows how to use them, they will be using them with full
knowledge that using them will break their game's compatibility with
baseq3 1.32.

It's not your job to make sure mod creators or someone forking ioq3 makes
their game work on baseq3 1.32.  It's your job to make sure ioq3 doesn't
break existing, legacy mods. (hehhe "job", you know what I mean...)  As
long as extending ioq3 doesn't break anything and it works on most (all,
ideally) platforms, I don't see why you couldn't include new things.

Sure, propose an extension, discuss its merits, decide if it's something
that people are wanting or using in the real world.  Don't just include
every ol' thing of questionable value.  But ioq3 is such a solid base, if
there's a demand or inclination to expand its abilities, why not?  As long
as ioq3's stated goal of improving the q3 game engine without breaking
background compatibility is met, good times!

Older mods won't magically use the new extensions, so they could never
magically stop working on baseq3.  With RQ3, when we added new things like
cvars and whatnot, we popped RQ3 in the names.  As example, some related
cvars:

g_allowvote
g_RQ3_vote_waittime
g_RQ3_maxClientVotes

If a coder or mod team can't figure out that using something like
"trap_S_ioq3_SoundDuration()" is going to make their mod not work on
baseq3 1.32 code, then they probably shouldn't be coding to begin with.

Anyway, that's my thoughts on it.  As long as ioq3 runs things that ran on
baseq3 1.32, there's no reason not to extend it--as long as there's a
rational, consistent method for the extensions.  Something that makes
sense to you guys doing all the work.  ;)

Monk.

> On Tue, Apr 08, 2008 at 03:48:09PM +0200, Ludwig Nussel wrote:
>> > If I add a new syscall to tremulous, should I also add it to ioq3?
>> >
>> > For instance, I'm currently in the process of adding a new syscall
>> > trap_S_SoundDuration().  Should this be added to ioq3 even though
>> > it isn't used by ioq3's cgame/ui?
>>
>> Well, if that's the syscall every mod developer always wanted and
>> noone can live without anymore I guess it would be fine. I can't
>> judge though.
>
> Yeah, that's the problem.  All I know is that I need it for Tremulous.
> I guess zakk has to decide if it is worth shoving down everyone else's
> throats :)





More information about the quake3 mailing list