We NEED more developers!

[take_this_cup_of_poison]

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.

[ai]

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

[Dokujisan]

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?

[GreEn`mArine]

@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.

[divVerent]

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.

[GreEn`mArine]

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.

[GreEn`mArine]

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.

[divVerent]

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.

[take_this_cup_of_poison]

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

[Tassu]

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.