Well said. I completely agree.<br><br><div class="gmail_quote">On Tue, Apr 8, 2008 at 11:48 PM, <<a href="mailto:monk@rq3.com">monk@rq3.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[please do not mistake my length of emails for me being angry or<br>
flaming--I'm just verbose!]<br>
<br>
The mod that I work on, Reaction Quake 3 (now called "Reaction"), is<br>
basically a port of the Quake 2 mod Action Quake 2 to the Q3 engine. It<br>
had a source release of AQ2 version 1.52. Many many projects (40+ that I<br>
know of) sprang forth and added a ton of different features and options.<br>
<br>
By the time we started making RQ3, the concept of "AQ2" was muddied by the<br>
playerbase. In north america, the "standard" was one fork. In europe,<br>
the "standard" was another fork. The RQ3 team is comprised of people from<br>
all over the world (had an Aussie for a while too).<br>
<br>
How to reconcile what we were making with what people thought we should be<br>
making? The way I approached this was to set a baseline of the original<br>
AQ2 1.52 featureset. Whatever else we did, we had to replicate the<br>
gameplay of AQ2 1.52. Once we had that down, it didn't matter if we<br>
extended the gameplay to emulate any of the forks as long as it was<br>
configurable by the server admin.<br>
<br>
The point was that no matter what, we had that one baseline that everyone<br>
could fall back to.<br>
<br>
When you discuss shoving a new syscall down everyone's throats, to me I am<br>
interpreting this as a programmer talking. A programmer doesn't want a<br>
ton of extraneous fluff in their code. If the code's not being used, why<br>
keep it around? Tight, easy-to-read code is the ideal.<br>
<br>
However, from an end-user or mod-creator perspective, you can't take<br>
advantage of what's not available. Adding a new syscall or extending ioq3<br>
is not the same thing as changing the default behavior and compability,<br>
right? It's the same situation as though some mods weren't using some<br>
syscalls. Is that a reason to remove them? Do they hurt anything by<br>
being available to be used? Not in my mind.<br>
<br>
In RQ3 we added a bunch of new map entities and abilities; breakable<br>
glass, exploding things when shot, door handles that moved, etc. If I<br>
recall correctly, we were able to easily modify the existing mapping tool<br>
(gtkradiant?) to expose the new functionality for our mod.<br>
<br>
Adding new syscalls and abilities to ioq3 shouldn't be a problem. As long<br>
as someone knows how to use them, they will be using them with full<br>
knowledge that using them will break their game's compatibility with<br>
baseq3 1.32.<br>
<br>
It's not your job to make sure mod creators or someone forking ioq3 makes<br>
their game work on baseq3 1.32. It's your job to make sure ioq3 doesn't<br>
break existing, legacy mods. (hehhe "job", you know what I mean...) As<br>
long as extending ioq3 doesn't break anything and it works on most (all,<br>
ideally) platforms, I don't see why you couldn't include new things.<br>
<br>
Sure, propose an extension, discuss its merits, decide if it's something<br>
that people are wanting or using in the real world. Don't just include<br>
every ol' thing of questionable value. But ioq3 is such a solid base, if<br>
there's a demand or inclination to expand its abilities, why not? As long<br>
as ioq3's stated goal of improving the q3 game engine without breaking<br>
background compatibility is met, good times!<br>
<br>
Older mods won't magically use the new extensions, so they could never<br>
magically stop working on baseq3. With RQ3, when we added new things like<br>
cvars and whatnot, we popped RQ3 in the names. As example, some related<br>
cvars:<br>
<br>
g_allowvote<br>
g_RQ3_vote_waittime<br>
g_RQ3_maxClientVotes<br>
<br>
If a coder or mod team can't figure out that using something like<br>
"trap_S_ioq3_SoundDuration()" is going to make their mod not work on<br>
baseq3 1.32 code, then they probably shouldn't be coding to begin with.<br>
<br>
Anyway, that's my thoughts on it. As long as ioq3 runs things that ran on<br>
baseq3 1.32, there's no reason not to extend it--as long as there's a<br>
rational, consistent method for the extensions. Something that makes<br>
sense to you guys doing all the work. ;)<br>
<br>
Monk.<br>
<div class="Ih2E3d"><br>
> On Tue, Apr 08, 2008 at 03:48:09PM +0200, Ludwig Nussel wrote:<br>
>> > If I add a new syscall to tremulous, should I also add it to ioq3?<br>
>> ><br>
>> > For instance, I'm currently in the process of adding a new syscall<br>
>> > trap_S_SoundDuration(). Should this be added to ioq3 even though<br>
>> > it isn't used by ioq3's cgame/ui?<br>
>><br>
>> Well, if that's the syscall every mod developer always wanted and<br>
>> noone can live without anymore I guess it would be fine. I can't<br>
>> judge though.<br>
><br>
> Yeah, that's the problem. All I know is that I need it for Tremulous.<br>
> I guess zakk has to decide if it is worth shoving down everyone else's<br>
> throats :)<br>
<br>
<br>
<br>
</div><div><div></div><div class="Wj3C7c">---<br>
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org">quake3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50" target="_blank">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a><br>
<br>
<br>
</div></div></blockquote></div><br>