What we need is developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers!

Seriously: the currently *active* people in Nexuiz development, apart from me, are:

• Morphed (weapon/item modelling, graphics, effects)
• [-z-] (graphics, web site, UI design)
• Blµb (QuakeC, mostly client side (big thanks for that), but not experienced on the server side)
• LordHavoc (engine, but he's also busy with another project (Darkwar) and, of course, work)
• Tenshihan (sound effects)

So if I left, we'd have NO MORE active server QuakeC developer, and NO MORE developer who looks into engine matters on a regular basis. This would make the project die. We therefore REALLY need about two extra QuakeC developers, and at least one extra engine developer, better would be two. Things should never be depending on a SINGLE person, you know.

I spend way too much time for this, and some people being extremely thankful and supporting (Mr. "three capital letters" knows what I mean) do make me question whether it is really worth the effort. Also, any bug report goes to ME. Often people even report "high priority bugs" that are actually features we simply do not have. I will have to stop responding or even reading bug reports posted on IRC. Post your bug reports and feature requests on sourceforge, IN THE APPROPRIATE SECTION (there IS a feature requests tracker too!). I will retreat into the internal Nexuiz development channel and stop reading #nexuiz and #alientrap, so stop posting possibly important stuff there.

You guys put too much pressure on a single person, and I may end up leaving if nothing is going to change with this project.

To conclude and also name other needs, we URGENTLY need:

• AT LEAST one extra engine developer (who should be good at reading/debugging C code, and have a basic clue about OpenGL, no enhanced knowledge needed for a start). Anyone who does not know OpenGL yet is of course welcome too, there's many things that can and should be done for the engine that do not require knowing OpenGL.
• AT LEAST two extra QuakeC developers (and one of them should learn how EXT_CSQC works, read its documentation, try out stuff, and talk to Spike and LordHavoc about unclear stuff - knowledge of reading C is a good bonus here, of course).
• AT LEAST one modeler who is capable of making player models for the game. Our lack of modelers is the primary reason why we still have the player models of Nexuiz 1.0(!). Note that Blender is now also possible to use for making player models, due to my bugfixes to the HL2 SMD exporter, and MD3 model format support.
• AT LEAST one animator who can make 3D player model animations. The latter two can be the same person
• AT LEAST one person who can make skins for player models. Can of course be the same as the modeler.
• As for concept art, I suppose we do have skilled people for that on the forum. Go ahead posting concepts, once we have our modeler and animator, we can put them into the game.

Speaking of pressure - do not put too much pressure on Morphed either. The hagar trail is NO LONGER RED. Stop complaining to him about it.


edit by -z-:

Check out the following FAQ to learn how to get started programming for Nexuiz.

Once you get your development environment setup, checkout the project tracker to find some programming tasks you'd like to take a whack at. When you feel like you've got something going, submit a patch for review.

Of course, you are not limited to the tracker, you can submit patches based on your own ideas but there is no guarantee they'll be accepted.

As always, you can find extra help on IRC. #alientrap on irc.anynet.org

Woah, were you channeling Steve Balmer for a minute there?

I can do basic modeling, currently working on a playermodel.

I think I can offer myself as a modeler. I have enough experience with modeling (as good as it gets pretty much) that I'm able to create anything. I can of course be an animator and I can try creating skins (if this is meant as textures). I am learning animation and currently texturing as well so sooner or later I will be good enough for that as well.
All I've been doing, however, is through Maya and with Maya's system mainly for high-poly movies. Meaning, I have not worked with games more than exporting my flag model, and helped out a bit together with Morphed and Div0's SMD exporter for Blender (and learned Blender a bit in the process ).

But yeah, I can assist I suppose now. But the most important thing would be programmers.

Yes, and I hope the SMD exporter will help in getting the people we need.

divVerent wrote:As for concept art, I suppose we do have skilled people for that on the forum.

I'd really like to make more models myself, but I have little to zero experience. I have to finish this first model anyway, before I can say, if I can do more.
Hopefully I'll be able to complete at least my first three concepts. That would be nice.

Things I can do:
- mapping although this is irrelevant to the problem
- some minor coding
- image processing, this does not mean I am an artist though

Unfortunately I spend a long time away from home working. It does mean I could pop in on most of the people on this forum as I work all over Europe (anyone in Paris this week?) but does mean I can't be expected to put time into something at short notice as I might be elsewhere.

Nexuiz is atypical for an open source project as it is a game. Whereas projects like Linux, OOo and the big desktop environments are able to get resources thrown at them by large companies who can see a way of making money out of them, these companies aren't interest in games. It falls to entirely volunteer input and as it doesn't accomplish anything productive, no one desperately sees the need to add a feature/bugfix out of necessity, it's just because they like playing the game. So, if you like playing Nexuiz, what can you do to make it better?

Can you link to a todo list from this thread? I'd be interested to see what's on it at the moment and it may be that some other people reading can pick out things that they can do.

@Ed: http://www.alientrap.org/wiki/pmwiki.php?n=Main.Todo

Hope this will do.

It's really time that this was said, div !

However, I am feeling that the knowledge about the game engine and server code is extremely concentrated on very few persons. Back then in v2.4 times when I tried to learn QuakeC in general (in order to write server side code) I had to gather information from "dead" resources (quakesrc wiki) that only happened to be in an online cache to get started in QuakeC at first. Then, I was standing there with a HUGE PILE of code (the nexuiz server code base), which is barely documented. At the beginning I didn't even know where which function was called (by the server engine) and where everything started. It is simply a huge code base that a new coder is exposed to. Sure, a lot of stuff actually doesn't need explaining, once you know the basic concepts. I do also understand why there basically are no in-source-doc-blocks (like "Javadoc" in Java sources or whatever you'd want to call it), since the code changes so much and fast that it is hard to keep it up.

What I am suggesting to you div0: once the next release, you and other guys who I meant with the "concentrated knowledge" should extend the nexuiz dev wiki with information (so like having a "documentation session" instead of "coding session"), e.g.

- one PERMANENT copy of quakeC knowledge (should probably suffice if a copy of the quakesrc wiki content that is still cached somewhere gets there) so that developers who know C already can get a grasp about QuakeC
- explaining a few key concepts, such as the functions called by the engine, and how nexuiz modified the usual way it. what I am talking about are methods like ClientConnect(), the spectator/observer thing, how the gamemodes work (e.g. I have not a fucking clue how the CTF code works, it is not really understandable in less than 5h of reading and debugging code), how CSQC works (including the needed parts that need explanation on the engine side), how the weapon system works, among quite a few other things I can't even think of right now. I am not asking for detailed descriptions, but rather for the concepts.

While doing this, I think a great help would be a developer who starts from scratch and tries to understand things while coding.

I'd love to help with code, but am of no use as of yet (maybe a year or two ) since I just started learning C++... *sigh*

Extending the documentation puts even more work on Div. That is not a solution. One solution is to try to recruit quakeC devs by looking for the emails to old or current quake mods and emailing them requesting assistance.

I, a few months ago, emailed everyone I could find in the field (including intel devs) of porcedural terrain generation (projected) on a sphere (AKA: "Seamless space to plaentary flight). I got many responses (some talking about the tech to do it and what docs to read to learn how to program and render such objects) and one, the developer of Ad Astra, said he'd donate code and help out the vegastrike devs if they would email him (also note: I explaind the GPL and such). I informed the vegastrike devs and they didn't get back to him and the VS forum admin kept deleting my post about that.

So, emailing people with the skills can work... and nexuiz is a project that I think would welcome new devs rather than ignoring the possibility of one .

(VS is like a cathedral in it's dev cycle really... secracy and no communication)

I think once I get home I will see if I can find still working mail accounts of those with quake C knowlege.

GreEn`mArine wrote:It's really time that this was said, div !

However, I am feeling that the knowledge about the game engine and server code is extremely concentrated on very few persons. Back then in v2.4 times when I tried to learn QuakeC in general (in order to write server side code) I had to gather information from "dead" resources (quakesrc wiki) that only happened to be in an online cache to get started in QuakeC at first. Then, I was standing there with a HUGE PILE of code (the nexuiz server code base), which is barely documented. At the beginning I didn't even know where which function was called (by the server engine) and where everything started. It is simply a huge code base that a new coder is exposed to. Sure, a lot of stuff actually doesn't need explaining, once you know the basic concepts. I do also understand why there basically are no in-source-doc-blocks (like "Javadoc" in Java sources or whatever you'd want to call it), since the code changes so much and fast that it is hard to keep it up.

What I am suggesting to you div0: once the next release, you and other guys who I meant with the "concentrated knowledge" should extend the nexuiz dev wiki with information (so like having a "documentation session" instead of "coding session"), e.g.

- one PERMANENT copy of quakeC knowledge (should probably suffice if a copy of the quakesrc wiki content that is still cached somewhere gets there) so that developers who know C already can get a grasp about QuakeC
- explaining a few key concepts, such as the functions called by the engine, and how nexuiz modified the usual way it. what I am talking about are methods like ClientConnect(), the spectator/observer thing, how the gamemodes work (e.g. I have not a fucking clue how the CTF code works, it is not really understandable in less than 5h of reading and debugging code), how CSQC works (including the needed parts that need explanation on the engine side), how the weapon system works, among quite a few other things I can't even think of right now. I am not asking for detailed descriptions, but rather for the concepts.

While doing this, I think a great help would be a developer who starts from scratch and tries to understand things while coding.

Though, if you have a zip of the backuped QuakeC guide... could you provide a link for us all .

One solution is to try to recruit quakeC devs by looking for the emails to old or current quake mods and emailing them requesting assistance.

This is a good suggestion. This is something I was considering doing for Nexuiz mapping at one point, trying to find and contact various Quake mappers to see if they would be interested in Nexuiz. But I didn't think of developers. This makes sense for finding QuakeC developers.

you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

I assume most of the qc devs is idling in #qc at irc.anynet.org

GreEn`mArine wrote:you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

Then tell us how to solve the problem, great master.

Do you really think it is MORE likely to find developers who are willing to rewrite it all in another language? I really doubt that.

And Quake C isn't THAT bad with the FTE extensions, and work is being done in getting more of the extensions to work in the engine.

GreEn`mArine wrote:you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

What do you program in?

Here's a letter which I will be sending out in a few min:

Hi. I was wondering if you would be interested in helping out a opensource game called Nexuiz. It's a quake based game that has had a number of releases over the years and uses quake C for it's game code and regular C for it's engine code as it uses the darkplaces engine. Most things are good with it; it supports bump and normal mapping and reflective shaders, texture blending shaders etc (though it doesn't support fur shaders yet). The maps are well made and have good flow. All of it, including the art and maps and models, are GPL. It even has a fork of GTK radiant and q3map2 as of a month ago now tailored to it's specifications. I enjoy making maps for the game, it permits the creation of everything from space junk to nice accurate castles... and supports PNG (in addition to TGA and jpeg) as a texture format... which I like because thats what I use to make my own textures (which are all GPL aswell).

The one problem is that it now has only one main developer (divverent) and about three part time contributors. Div has alot of pressure on him and needs help. As it is now he does both most of the quake C additions and the engine adaptions. Nexuiz needs more quake C and normal C coders (and could use a modler, animator, and all that jazz too). I myself make about one map per month or two for nexuiz (I've made 24 so far) but I can't code in either of the languages (I'm a perl coder) and it's difficult for me to wrap my head around quake C as it's so diffrent for me. I also make some (GPL) music from time to time so I guess I'm more of an "artist" than anything else. Anyway, this is a pretty advanced game as far as opensource releases go, I was wondering if you or anyone you know of could lend a hand.

Note: Their website is Nexuiz.com and www.sf.net/projects/nexuiz . There are some videos, download packages (including source in the zip), and a forum. The game runs on linux, windows, and mac (and recently div ported gtkradiant to the make system and removed unneeded dependancies so that will be able to be ported everywhere too).

Thanks for reading this
--Mike--

divVerent wrote:Then tell us how to solve the problem, great master.

Do you really think it is MORE likely to find developers who are willing to rewrite it all in another language? I really doubt that.

And Quake C isn't THAT bad with the FTE extensions, and work is being done in getting more of the extensions to work in the engine.

I'll give you a cookie next time if you can talk to me in one sentence not being sarcastic and hostile, but anyway. I'm better than that, so I'll just ignore it. Or even better .. returning it? Yes.

The fact that quakeC is not that good is something I am complaining about - true, but NOT because I want the language to be changed (I know this won't ever happen), but because I want to point out that this merely requires that the ones who know the traps and pitfalls, or let's say specialties of this language, DOCUMENT these, so that a programmer who still knows proper 20+ year old languages (sry for sarcasm here) like C can understand it.

But I'll give up here. Simply the fact that I say it will make you ignore it. I don't see any documentation happen. I also don't see many NEW coder NEW to quakeC helping out.

I've sent the mails to all the people I could find on planetquake.gamespy.com.

@Poison:

I took the liberty to correct some spelling errors:

Hi. I was wondering if you would be interested in helping out a opensource game called Nexuiz. It's a quake based game that has had a number of releases over the years and uses quake C for it's game code and regular C for it's engine code as it uses the darkplaces engine. Most things are good with it; it supports bump and normal mapping and reflective shaders, texture blending shaders etc (though it doesn't support fur shaders yet). The maps are well made and have good flow. All of it, including the art and maps and models, are GPL. It even has a fork of GTK radiant and q3map2 as of a month ago now tailored to it's specifications. I enjoy making maps for the game, it permits the creation of everything from space junk to nice accurate castles... and supports PNG (in addition to TGA and jpeg) as a texture format... which I like because thats what I use to make my own textures (which are all GPL aswell).

The one problem is that it now has only one main developer (divverent) and about three part time contributors. Div has a lot of pressure on him and needs help. As it is now he does both most of the quake C additions and the engine adaptions. Nexuiz needs more quake C and normal C coders (and could use a modeler, animator, and all that jazz too). I myself make about one map per month or two for nexuiz (I've made 24 so far) but I can't code in either of the languages (I'm a perl coder) and it's difficult for me to wrap my head around quake C as it's so different for me. I also make some (GPL) music from time to time so I guess I'm more of an "artist" than anything else. Anyway, this is a pretty advanced game as far as opensource releases go, I was wondering if you or anyone you know of could lend a hand.

Note: Their website is Nexuiz.com and www.sf.net/projects/nexuiz . There are some videos, download packages (including source in the zip), and a forum. The game runs on linux, windows, and mac (and recently div ported gtkradiant to the make system and removed unneeded dependencies so that will be able to be ported everywhere too).

Thanks for reading this
--Mike--

Btw what do you mean with: (though it doesn't support fur shaders yet).
In this sentence: it supports bump and normal mapping and reflective shaders, texture blending shaders etc (though it doesn't support fur shaders yet) ?

Is it four, or for?
Otherwise it's good.

EDIT: Lool, too late

GreEn`mArine wrote:

divVerent wrote:Then tell us how to solve the problem, great master.

Do you really think it is MORE likely to find developers who are willing to rewrite it all in another language? I really doubt that.

And Quake C isn't THAT bad with the FTE extensions, and work is being done in getting more of the extensions to work in the engine.

I'll give you a cookie next time if you can talk to me in one sentence not being sarcastic and hostile, but anyway. I'm better than that, so I'll just ignore it. Or even better .. returning it? Yes.

The fact that quakeC is not that good is something I am complaining about - true, but NOT because I want the language to be changed (I know this won't ever happen), but because I want to point out that this merely requires that the ones who know the traps and pitfalls, or let's say specialties of this language, DOCUMENT these, so that a programmer who still knows proper 20+ year old languages (sry for sarcasm here) like C can understand it.

But I'll give up here. Simply the fact that I say it will make you ignore it. I don't see any documentation happen. I also don't see many NEW coder NEW to quakeC helping out.

How about you code some needed things for nexuiz, or make some more maps, or models, or animate some things, or make avaiable the documentation you know of, or join in on the emailing campaign. You shouldn't be hating on Div, he's tired enough of TVR's demands and arrogant remarks and even those make him think "is it worth it", as in: 'with all the crap these players give, is it worth helping them by developing the game they play further'. See, when you are not nice to the sole dev, he may decide to "get back" at you by just stopping developing the game...

... and you know what happens then? The people that were whining and being arrogant and complaining.. they DONT pick up the slack and DONT start implementing what they were demanding and begging for... they don't have the "time" to learn the language etc... because they really don't want to help out at all... they just go onto another game (kinda like how when OSX came out all those ... how should I say... people who wear THICK BLACK RIMMED GLASSES jumped ship from linux to mac (which was a good thing for linux: it would have never been accepted in buissness and government and military with all the no-contribution thick black rimmed glasses mac lovers still attached to it).

So: email quake C devs, modelers, etc or implement some of these needs yourself for nexuiz.

You can use my email I posted up there. I've emailed about 50 people in the last hour.

AI: it's "fur shaders". They are the things that tell the engine to create realistic looking grass (the engine creates more surfaces as necessary) in COD4 and Quake3.

Btw, I've decided to help out on the modeling and animation front.
I am currently working on the flag models, and they will also teach me how to create models for Nexuiz which I will later take to go into player models. I've also planned re-doing the portals for the Port-O-Launch and the ammo for machine gun and mortars. (As it's stated on the Nexuiz todo). Then rigging Ivan's models.
But yeah, having a few more people would be cool as doing all these things by oneself will take some time.

Oh btw, also I'm working on a Documentation about how to create models for Neuxiz, all kinds of models, not just player models.

EDIT: Ah, fur, now I understand. I thought it was a misspelling from a German word

GreEn`mArine wrote:you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

I understand what you're saying, but I'm not sure how that would affect our actions with regard to this topic. Are you suggesting that we should find QuakeC developers who are willing to write QuakeC documentation?

@Mike: If you were informed correctly, I implemented quite a lot of features (tournament mod) which basically completely made their way into the nexuiz source code, about which I am happy. From there on, I was constantly hazed by divverent when ever there was a bug related to code I had submitted, even though the code in SVN now doesn't actually have more than 20% in common with what I submitted, as it got modified a lot (actually the modifications did make sense and I'm happy they are there). Still, I received the blame for whatever broke in the code. I don't even say that I am not responsible for anything he was talking about. There are so many things in the code that have side effects on other things (<insert-blame-on-global-variables-and-procedural-programming-style-here>) which you can never see as a newbie. And since there was no documentation about the global variables, how can one expect from me to check every single one of them. The nexuiz server code is simply not comprehensible as a whole without massive studying efforts.

Apart from that, I am having so much going on in my RL that I can not put any more work into coding anymore myself. Back then when I had the time to do the major coding work for the mod, I was really a newbie to QuakeC and the nexuiz code base, so my complaints about that programming language or lack of documentation I posted above come from exactly that experience, a experience in which I had to ask around "how does this work, how does that work" and many many hours of repeatingly reading of code to understand things, I mean basic principles like what happens when a player connects, and other things.

My basic proposition here is that, imo, it might not be enough to catch the old school quake-c coders. I mean, we'll see how your attempts will go - and I'm hoping the best, really. But getting new coders is important as well. The Nexuiz community does have do many computer scientists, who, however, do not touch Nexuiz source code. Most of the don't because of the lack of time, sure. But the ones who do, or even the casual gamers/coders, might want to give it a shot if the learning curve was flatter. I'm sure about that.

If I were to tell a friend (many of them are computer scientists jsut as me) to try to write a modification for the game, they would give up soon, because the only thing that would make you stick to understand that huge code base is pure devotion to the game.

If the dev wiki was to be extended by the things I mentioned, I'd be happy to contribute the things I still remember.

GreEn`mArine wrote:The fact that quakeC is not that good is something I am complaining about - true, but NOT because I want the language to be changed (I know this won't ever happen), but because I want to point out that this merely requires that the ones who know the traps and pitfalls, or let's say specialties of this language, DOCUMENT these, so that a programmer who still knows proper 20+ year old languages (sry for sarcasm here) like C can understand it.

If it is just about the language itself (and its common usage patterns), I'll do it, although I won't document it from ground zero, but rather for people who already know C or JavaScript. Documenting what curly braces do is left to the others

The functions Quake exports (or DarkPlaces extends) are documented quite well, though, so I see no need to do that again. Although I wish there was a wiki with that information, so I could fix the few things that are wrong or outdated there (and document common pitfalls, e.g. vectoangles not matching makevectors).

And as for "QuakeC developers" - I phrased that wrong in the original posting. Any experienced C coder will easily be able to work with QuakeC, after knowing the pitfalls.

Dokujisan wrote:

GreEn`mArine wrote:you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

I understand what you're saying, but I'm not sure how that would affect our actions with regard to this topic. Are you suggesting that we should find QuakeC developers who are willing to write QuakeC documentation?

This is a good idea. I mean, there already is quite a bit of documentation about the language itself, it is probably even enough, and most of it covered. However, CSQC is not really covered much. And the Nexuiz server code base is a big system as well.

Let's compare the situation with programming language like PHP and a huge extensible CMS written in it, like Typo3. Just because of having a documentation of the language won't help any1 who would like to write Typo3 extensions. If there wasn't that much of documentation about this, not a single person who is not a typo3 developer for a long time or even since the start of it, would develop extensions. The same goes for Nexuiz. The language QuakeC is documented about right (see http://www.gamers.org/dEngine/quake/spe ... c-menu.htm and http://quakery.quakedev.com/qwiki/ ). But the system using it, Nexuiz, lacks it, imo.

divVerent wrote:If it is just about the language itself (and its common usage patterns), I'll do it, although I won't document it from ground zero, but rather for people who already know C or JavaScript. Documenting what curly braces do is left to the others

The functions Quake exports (or DarkPlaces extends) are documented quite well, though, so I see no need to do that again. Although I wish there was a wiki with that information, so I could fix the few things that are wrong or outdated there (and document common pitfalls, e.g. vectoangles not matching makevectors).

If it's about the wiki, you might consider the http://quakery.quakedev.com/qwiki/
Or, make extended use of the Nexuiz dev wiki.

Edit: this http://quakery.quakedev.com/qwiki/ is not having much structure, I added the list of built-in functions and the link to the "what already exists about CSQC" to the main page.

GreEn`mArine wrote:

Dokujisan wrote:

GreEn`mArine wrote:you DO realize, I hope, that quakeC developers are dying out, which is just natural because there is nothing new anymore to do with quakeC, and that's for a good reason. The language sucks big time imo.

I understand what you're saying, but I'm not sure how that would affect our actions with regard to this topic. Are you suggesting that we should find QuakeC developers who are willing to write QuakeC documentation?

This is a good idea. I mean, there already is quite a bit of documentation about the language itself, it is probably even enough, and most of it covered. However, CSQC is not really covered much. And the Nexuiz server code base is a big system as well.

Let's compare the situation with programming language like PHP and a huge extensible CMS written in it, like Typo3. Just because of having a documentation of the language won't help any1 who would like to write Typo3 extensions. If there wasn't that much of documentation about this, not a single person who is not a typo3 developer for a long time or even since the start of it, would develop extensions. The same goes for Nexuiz. The language QuakeC is documented about right (see http://www.gamers.org/dEngine/quake/spe ... c-menu.htm and http://quakery.quakedev.com/qwiki/ ). But the system using it, Nexuiz, lacks it, imo.

The first documentation you cite is harmful and incomplete. It describes QuakeC as it originally was, not the QuakeC we use now (thanks to DarkPlaces and FTEQCC).

The Quake wiki - I will refer to that in my documentation too, as it does provide useful info.

And any decent coder will easily be able to work with the Nexuiz source, it isn't like it's extremely complex. Some patterns used in it (or in the QuakeC language) may be a bit weird, but I will describe them in the OUNS wiki page.

Jitspoe seems to be happy to donate some textures:
jitspoe[AT]yahoo[DOT]com

A lot of the stuff was made with Filter Forge. I have the sources
here: http://dplogin.com/files/mediasource/textures/ - the high-res (hr4)
textures should all be GPL. Some of the low res textures may not be
(I'm trying to re-work all of the game content to be GPL). If you have
filter forge, you can re-generate the textures at any resolution with
bump maps and stuff.

- jitspoe

I've been playing the game on and off and lurking the forums (thus the postcount). I'd like to be of some help, but I have no knowledge in QuakeC nor C. I'm not a programming/scripter newbie though, I know LUA and XML, but not the 'lower' level languages such as C and C++. I guess my question is an estimation how long it would take to learn QuakeC/C from a scratch to the extent I could be of any help.