[quake3] Greetings

[Patrick Baggett]

Well said. I completely agree.

On Tue, Apr 8, 2008 at 11:48 PM, <monk at rq3.com> wrote:

> [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 :)
>
>
>
> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20080409/da9b3e5b/attachment.htm>