[quake3] Greetings

[monk at rq3.com]

> Other than that I think it is a very good idea to create a second,
> more progressive version of ioquake3. I'd love to contribute to that,
> e.g. by adding per-pixel lighting, ambient occlusion, etc.

I would wonder if a fork is a good idea?  This is the situation we
currently have with XReaL et al.  Forks with extra goodies.  But everyone
tends to go back to the base ioq3 for bugfixes and to build with.

Would people keep a fork sync'ed up?  And how would the fork distinguish
itself from other fork projects?  Would the fork start breaking
compatibility or lose the ability to run on other operating systems and
platforms?

If the base ioq3 were extended, it would be valuable because:

1) the code would always be up-to-date, no need to merge in fixes
2) you don't split mindshare between the "original" and "new" (marketing
thinking, 'ere?  one-stop shopping?)
3) it would force any extensions to take into account the many platforms
that ioq3 already runs on (one of the great values for us in ioq3 over,
say, XReaL or one of those .NET ports)
4) it would force any extensions to take into account being able to run
existing baseq3 media, i.e. XReaL supports neat things but does NOT
support older lightmapped maps so our existing content (and pretty much
all existing Q3 content) is not available for use in that engine

If you extend ioq3 and it doesn't hurt backward compatibility, is there a
good reason to fork?  If people just don't like that idea, ok, I get it. 
But forking seems like it would just require more maintenance and might
end up splitting attention.

Anything the list discusses that they don't want to include in the base
ioq3 or can't come to a consensus on, they can always publish as a patch
like is currently done, I'd think.

Monk.