Since people from the community are often willing to make patches and fixes for open source projects like Nexuiz, I thought it would be useful to make a topic for those who are not core developers but make Nexuiz patches over the night to post their work in for adding it to the game. This should both make things in development easier and encourage the community to make and post patches for the game whenever they feel like doing such a thing. Should probably be a sticky too if moderators want to mark it as such.

Any kind of patch you made and believe is good enough to go in officially can be posted here for the devs to look at and apply if they believe it's the case. Since the game runs off SVN it's usually recommended that changes are made over the SVN version and posted as .patch files which can be generated with your SVN client (I use Tortoise SVN which works very well). Anything that helps with the game is useful... code changes, textures / models, sounds, even maps. So if you made anything interesting just upload the patch onto a file hosting website and post the link here with a description about the change if you wish.

To start off, this is my first code patch for Nexuiz (discussed it in #nexuiz.editing on irc tonight). This is a feature I wanted to see in the menus and since I wanted to give my first shot at making a code patch for the game I made a change which includes all weapons in the Mutators window to be played as arena. Currently in SVN there's only the Rocket Launcher and the MinistaGib / NixNex in that category. My patch makes the arena list complete and adds all the weapons to it so whoever makes a server can easily select any weapon to play with... most useful especially when someone wants to train theirselves with a certain weapon to gain a better skill with it

The patch can be downloaded from this link and a preview screenshot of the list over here.

You forgot laser.

One thing I'd really like to see changed: can you please use a download site that is not such an annoying nagsite? On my first attempt I could see it, but had to enable javascript for it, but then accidentally shut down my eeepc. On my second attempt, I cannot access the site at all.

Please use sites like http://paste.debian.net/ to upload patches made using "svn diff", if you do not have a better kind of webspace. I or someone else will then download them and put them on some "real" webspace, or put them into svn.

Filedropper is down. There are almost no good upload sites, but it's not relevant for patches.

Uploaded to paste.debian.net: http://paste.debian.net/21020/

[strike]I can provide upload space here:
http://nexuiz.kicks-ass.org/~blub/nexfiles

Just drop me a PM[/strike]

why the hell can't I use the 'strike' tag?

Improved the patch a bit, extended the weapon system to give menu QC more knowledge about the weapons, added a "this weapon can be used for climbing" field... now it looks like:



and is committed. Thanks!

Thank you for that site. The reason I used filedropper was because it was kind of the only hosting service I knew. That one seems much better, I noted it down and will attempt to use that from now one

And that looks good div, although arenas are made to be single weapons only so the & laser doesn't make it so much of an arena any more I think. It would probably be better if that got removed, and a weapon arena remained that weapon only without the laser. Or better off, under the Weapon Arenas: category make a "with laser" check box at the end separate from the weapon choice radio boxes, so if someone wants a certain arena weapon with the laser too they check that box separately... that would be the best way if you can make that change so not everyone is forced to play with the laser in arena mode nor miss the laser when playing with certain weapons like the Rocket Launcher if they don't want to.

Also with certain skins and resolutions the "Heavy Laser Assault Cannon & Laser" overlaps with "T.A.G. Seeker & Laser", attached screenshot here.. so that's another reason why Laser should be put separately as a check box to have shorter strings on weapons. Anyway the All Weapons mode is a great idea, many may want to play with all the weapons like in LMS that way

Either way I finished making another patch for the menus. I added a bunch of cvars to the menus which were not present or not properly arranged but are important to the game, and arranged and reordered a few settings a bit so they stick correctly in categories and are properly ordered now.

For now I added the patch here. If this file host is also bad please tell me so I can re-upload quickly in another place.

MirceaKitsune, I'm very happy to see you contributing . This thread was a very good idea, bringing attention to not only the possibility but the need for such organization of code contributions!

Nice work.

Speaking of contributons: the python interpreter is the part of Nexuiz now?

No, for security reasons

MirceaKitsune wrote:Either way I finished making another patch for the menus. I added a bunch of cvars to the menus which were not present or not properly arranged but are important to the game, and arranged and reordered a few settings a bit so they stick correctly in categories and are properly ordered now.

For now I added the patch here. If this file host is also bad please tell me so I can re-upload quickly in another place.

I don't really agree with much of the patch, but will see what parts I can apply.

First, the changes in the default settings - not sure if we really want that. Defaults are a touchy subject...

The reason for 4x multisampling only is that more doesn't look much better, 4x almost always works, and the amount of multisampling doesn't change fps much. However, if you select 8x multisampling and the GPU just supports 4x, you get no multisampling at all, which is why I chose not to use a slider for that, but only provide the safe 4x.

And decals time is so low because the engine is quite bad at decals (like, at the end of a surface) and showing them for longer just makes that more annoying.

Player setup behind servers and create - hm... not REALLY sure. But why not. Did it.

KH's official name is "Key Hunt", not "KeyHunt"... I wonder if any place says "KeyHunt", I'd rather change that.

The "Shadow" is actually a bot name, so it looks like you are editing part of the name. You read the fields as [BOT]Shadow, not as [BOT]Suffix...

With your moving down of antilag, and the other rearrangement, I agree and applied them to svn.

divVerent wrote:First, the changes in the default settings - not sure if we really want that. Defaults are a touchy subject...

I only changed one default, something for the view bobbing to work well. If I left it at 0.02 the view bobbing worked really bad (as I added the slider for it in Player Setup as it's a good effect, still turned off by default of course). I tried different settings but there is no value for cl_bobcycle that works well with cl_bob set to the current default of 0.02 so that's why I wanted to set it to 0.01 (otherwise the view bobbing will look like the player is limping). You will see that 0.01 is much better for cl_bob then 0.02 when setting cl_bobcycle to 0.5, so when you have time maybe you can test that too and see what's the best value for it.

divVerent wrote:The reason for 4x multisampling only is that more doesn't look much better, 4x almost always works, and the amount of multisampling doesn't change fps much. However, if you select 8x multisampling and the GPU just supports 4x, you get no multisampling at all, which is why I chose not to use a slider for that, but only provide the safe 4x.

First thing I wanted to change was the name Multisampling to Anti-Aliasing since that's the name most people are used to. I didn't even know what multisampling was until I seen it was the anti-aliasing setting while I was halfway on this patch today. Another thing is that people may want to set it to 2x instead of 4x to have good quality at higher performance, so maybe you can keep my slider and just set it to the 3 positions of Disabled, 2x, 4x? Or if not make 3 radio buttons for it and rename to Anti-aliasing, I think that could be good

divVerent wrote:And decals time is so low because the engine is quite bad at decals (like, at the end of a surface) and showing them for longer just makes that more annoying.

I have them set to 30 for many months and it works like a charm with almost no lag for me, even on crowded maps. People with higher-specs PCs can turn that up very well even higher then 30 as far as I tested, although 20 is very good too so thanks for leaving that on

divVerent wrote:KH's official name is "Key Hunt", not "KeyHunt"... I wonder if any place says "KeyHunt", I'd rather change that.

The reason I changed that button string from "Key Hunt" to "KeyHunt" is because the first version was too long and I noticed it got out of the button's boundaries with certain skins. KeyHunt in one word is shorter and fit a bit better in the button, although I'm not sure if it also sounds better or not now that I think about it

divVerent wrote:The "Shadow" is actually a bot name, so it looks like you are editing part of the name. You read the fields as [BOT]Shadow, not as [BOT]Suffix...

I thought that was the same thing as [BOT] but just added at the end of the name rather then beginning... thanks for correcting that then.

Also, my patch for Left Handed mode (Mirror image as I renamed that) fixes that checkbox which was broken. If you set the Video -> Left Handed checkbox to True in the current rev then turn it off, the image doesn't un-mirror any more. That's because the person who put it there copied it from the Multisampling checkbox which uses values of 1 and 4 while Left Handed is a cvar that should use 0 or 1.

I (personally) have no problem with structure except crosshairs should be RGBA (pallette is called RGBA) and then size should follow. The more anoying problem is that text strings goes out of button bounds or strings overlap each other (e.g. in mutators), but this probably should be reported to -z- or sev.

Anyway while I was at it I created another patch for the menus tonight which should fix more stuff and make things even prettier. To post a quick summary, these are the changes in this patch:

- I tested g_weapon_stay again and it seems the issue where the user is unable to get a weapon dropped by someone else if (s)he already has it is gone. Now, when g_weapon_stay is enabled, the user is unable to pick a weapon from the original location once he already has it, but is able to pick it up if another player / bot dropped it after dieing. So I decided Weapon stay is ready to go in the Mutators list.

- Removed the "+ laser" directive from the weapons arena for the time being. This needs to be done by manually putting a single "with laser" checkbox after the generated weapons list for the arena tab (just like the NixNex has) as in the way it was previously the laser is added only to certain weapons there which is not recommended as users may want to play a certain weapon arena without the laser. One would also ask "why is the Electro with a + laser and the Rocket Launcher not?" (and both the RL and Electro can jump / throw you up technically so that system was unfair). Also this made the strings too long, and having "weapon name + laser" for each entry there caused text to even overlap with certain skins on lower resolutions. If anyone can make that window set "g_weaponarena chosen-from-the-radio-buttons-weapon laser-from-separate-checkbox" that would be perfect... so for now I left weapon arenas without the laser as this seemed best.

(Just as a note, if the devs decide to deny only one of the above make sure not to deny the entire file and just the area of each individually, since each of the changes above are in the same file)

- Changed the Multisampling setting a bit again. I renamed it from Multisampling to Anti-Aliasing again as that's the name most people are used to and it's much more recommended it's labeled like that since as I said most people don't know what multisampling is and that it's the same thing as anti-aliasing. On the setting part I added three radio buttons for Disabled, 2x and 4x. I believe this should perfectly suit both my and Div's view on how the anti-aliasing setting should be like

- Fixed the broken "Left handed mode" checkbox again. Set its values correctly to 0 or 1 so now it can be enabled and disabled correctly again.

(Once again both of the changes above are in the same file, so if only one gets denied don't forget to deny it individually)

- Fixed a space in the Player Setup which makes it look nicer and better arranged again.

Patch can be downloaded here or here as code. So yeah, Div or another dev can apply what they believe from this when they read it tomorrow

As for the weapons: playing without a weapon that can be used to climb, e.g. MG arena, simply makes no sense. And doing a checkbox for this would be too hard, as it all has to go into a single string. So I kept the "& Laser" for now.

As for multisampling: I am not sure if every GPU+Driver that supports 4x also supports 2x. Thus I am reluctant to apply that without first evaluating which GPUs support what. Also, the name is supposed to be multisampling, as it is NOT anti-aliasing (which usually is referred to as FSAA, and works by rendering the whole screen at the double resolution, then scaling it doen). Multisampling only influences edges of polygons, and thus is much less fps costly.

Multisampling (FSAA) GPUS from Nvidia: http://us.download.nvidia.com/XFree86/L ... er-11.html
About ati. What I've gleaned from web, the first product to support multi-sampling was r300 chip in radeon 9500 pro.
http://ati.amd.com/products/radeon9500/ ... specs.html - look at smoothvision 2.0. Previous product radeon 9250 only had plain smoothvision.

divVerent wrote:As for the weapons: playing without a weapon that can be used to climb, e.g. MG arena, simply makes no sense. And doing a checkbox for this would be too hard, as it all has to go into a single string. So I kept the "& Laser" for now.

I for one am still willing to try and get it working that way as that's most correct and fair. Sadly I can't gather how to make a checkbox that takes a cvar, its currently set precedent value and ads another directive after. Maybe someone with more dev skills can find the maths for that in that section of the multiplayer file... that would really be a shame to not implement correctly.

There is another way too, though here a dev must work on it; create another cvar that, over anything that g_weaponarena is set to also adds the laser. Something like "g_include_laser" or "g_include_weapon name-here" but that knows to include the laser together with what g_weaponarena is set to (unless that's set to the laser itself). Otherwise that system will remain unfair... the rocket launcher cannot jump you without causing you heavy damage too for example as well as the Mortar.

So if anyone can implement that I'd be happy if one of the two methods could be somehow gotten to work. Guess it's not that bad if it stays like this but that would probably not be the best way... Div's choice

Well, I don't like the idea of g_include_laser etc. cvars, as it would basically make the g_weaponarena cvar no longer transparent.

The only way to combine this with a checkbox is custom loadcvar/savecvar functions that only look at thje laser part, or only look at the other part. But that'd be quite some extra work...

I'm working now on adding pain/death sounds system in q3/ut style... Also I want to add multiple gibs and blood colour per each playermodel... What about my idea?.. Would it be added later to official Nexuiz build?..

Pain/Death sound system is already in svn, check it out on the "Over the Lazy Dog" servers. Different gibs per player model would be simple, we just have no "gib" models for that (e.g. screws, metal parts for robot models).

Either way to further my series I made a 3rd patch (seems I found a good job at managing the menus ). This patch includes two changes in the Effects window which add two new features from cvars.

- Added Fog checkbox before Coronas so fog can be turned off from effects. By turning off fog in Silvercity for example I managed to improve my FPS by 6-7 points and fog was also noticed to make things go slower on Slimepit_Revisited so this should make things much easier for those who have slower PCs. There was an empty slot in the menu where this fits perfectly either way so yeah, don't see any reason not to since it's a setting anyone should be able to turn off.

- There is a cvar called r_shadows which allows ambient / skybox lightning to cast shadows from models in a perfectly vertical angle... completely separate from both Dynamic Lightning shadows and World Lightning shadows. r_shadows creates a very nice effects and allows shadows to be displayed anywhere on a map casted by ambient lightning which completes the shadows set.
I grouped it to the right together with the other two shadow settings. So if the devs agree I think that would be a pretty effect to be able to enable and disable at will from there. Please feel free to reorder and change the tags if need be however, I ordered them as best as I could but it may not be the best way.

Once again the two changes are totally unrelated but in the same file, so fi only one makes it yeah. Also the table size change from 3.5 to 3.25 is for the new Shadows checkbox to fit in (although that does make the Effects window look better either way so even if the shadows setting doesn't get in maybe you can keep that). Downloads here and here.

- Added Fog checkbox before Coronas so fog can be turned off from effects. By turning off fog in Silvercity for example I managed to improve my FPS by 6-7 points and fog was also noticed to make things go slower on Slimepit_Revisited so this should make things much easier for those who have slower PCs. There was an empty slot in the menu where this fits perfectly either way so yeah, don't see any reason not to since it's a setting anyone should be able to turn off.

Sorry, but fog is a touchy subject there. Being able to turn it off means getting an unfair advantage in game against others. Therefore, mappers and developer(s) agreed to having a way to force fog on the client. So even if you set that cvar to 0 in the menu, the game code will revert it to 1 when playing on a map with forced fog. Therefore, such a menu setting would appear "broken", and should better not exist at all.

There is a cvar called r_shadows which allows ambient / skybox lightning to cast shadows from models in a perfectly vertical angle... completely separate from both Dynamic Lightning shadows and World Lightning shadows. r_shadows creates a very nice effects and allows shadows to be displayed anywhere on a map casted by ambient lightning which completes the shadows set.

Hm... too bad this effect is very broken

If someone could fix the bug that the weapon model sometimes throws its shadow to someplace completely different from the rest of the player model, it'd be a very nice option. Or maybe let that option not throw a shadow of the weapon model at all, but just of the player model - would at least look a lot less stupid.

So basically, both options aren't in the menu for a reason... but now that you mentioned this topic - it'd be a great thing if someone could fix the r_shadows feature

divVerent wrote:Sorry, but fog is a touchy subject there. Being able to turn it off means getting an unfair advantage in game against others. Therefore, mappers and developer(s) agreed to having a way to force fog on the client. So even if you set that cvar to 0 in the menu, the game code will revert it to 1 when playing on a map with forced fog. Therefore, such a menu setting would appear "broken", and should better not exist at all.

The only advantage this gives is a higher FPS from what I seen. Everyone sees players very well in all (at least official) maps with fog and I never had fog making it harder for me to hit someone or see them correctly (except the lower fps in some cases). And if the fog is way too high in a map that's mainly the map's thing and configuration... I for one don't think fog can give a gameplay advantage unless it's set to a distance that can cover your FOV at least 90% from one point on the map to another one you look at. Some older video cards probably can't even support fog at all so yeah, this isn't something I agree with personally but if that's what everyone decided then yeah don't add it.

divVerent wrote:Hm... too bad this effect is very broken

If someone could fix the bug that the weapon model sometimes throws its shadow to someplace completely different from the rest of the player model, it'd be a very nice option. Or maybe let that option not throw a shadow of the weapon model at all, but just of the player model - would at least look a lot less stupid.

I did notice it does that in certain situations though I didn't give much attention to it. The reason I believe it does that effect is because player models cast shadows differently when you look down, so I think that's actually the player model shadow being casted over your in-hand weapon model (in which case it would even be correct since the player casts shadows over the gun). Probably needs checking a bit more in that case

I have Nexuiz 2.4.2 and I haven't see pain/death system there... But ok, I will look at svn for it... I can do some simple gibs myself and add it to game in md3 format... Also I need improved material system to make correct footsteps sounds and correct "smokepuffs" (bullet hit effects, sparks on metal etc...), so who want to help me with material system?..

More material types - near impossible.

In Q3 maps, we however can select "metalsteps" or "nosteps" as surface parameter.

It would already be a great help if someone looked at all our shaders, and set "surfaceparm metalsteps" to all metal shaders.

MirceaKitsune wrote:

divVerent wrote:Sorry, but fog is a touchy subject there. Being able to turn it off means getting an unfair advantage in game against others. Therefore, mappers and developer(s) agreed to having a way to force fog on the client. So even if you set that cvar to 0 in the menu, the game code will revert it to 1 when playing on a map with forced fog. Therefore, such a menu setting would appear "broken", and should better not exist at all.

The only advantage this gives is a higher FPS from what I seen. Everyone sees players very well in all (at least official) maps with fog and I never had fog making it harder for me to hit someone or see them correctly (except the lower fps in some cases). And if the fog is way too high in a map that's mainly the map's thing and configuration... I for one don't think fog can give a gameplay advantage unless it's set to a distance that can cover your FOV at least 90% from one point on the map to another one you look at. Some older video cards probably can't even support fog at all so yeah, this isn't something I agree with personally but if that's what everyone decided then yeah don't add it.

Some maps set exactly such view blocking fog, e.g. xyon and morfar-ctf, and disabling fog on these maps would be cheating. Silvercity's and Reslimed's fog sure is harmless. And if the GPU does not support fog, DP still uses it (vertex based) in a way that works on any GPU.

divVerent wrote:Hm... too bad this effect is very broken

If someone could fix the bug that the weapon model sometimes throws its shadow to someplace completely different from the rest of the player model, it'd be a very nice option. Or maybe let that option not throw a shadow of the weapon model at all, but just of the player model - would at least look a lot less stupid.

I did notice it does that in certain situations though I didn't give much attention to it. The reason I believe it does that effect is because player models cast shadows differently when you look down, so I think that's actually the player model shadow being casted over your in-hand weapon model (in which case it would even be correct since the player casts shadows over the gun). Probably needs checking a bit more in that case

Picture of the bug: http://emptyset.endoftheinternet.org/~r ... 973468.jpg
I am trying to fix it at the moment (fix attempt is committed): http://emptyset.endoftheinternet.org/~r ... f7d5e1.jpg

If the fix gets confirmed working, I'll add the menu option.

divVerent wrote:Some maps set exactly such view blocking fog, e.g. xyon and morfar-ctf, and disabling fog on these maps would be cheating. Silvercity's and Reslimed's fog sure is harmless. And if the GPU does not support fog, DP still uses it (vertex based) in a way that works on any GPU.

Hmm... one idea could be making a -map- property where fog could be marked as "necessary for the game to be fair" or ambient fog that someone can remove. So if the map would specify that certain fog surface / generator is necessary to block your view so it's not considered cheating the client would render it either way. Otherwise when the fog is just there so stuff looks nice allow it to be turned off from Effects.

Or better off, the game could calculate the distance and intensity of the fog and if it notices the fog can cover enough areas of the map in order for disabling it to be called cheating and seeing where you shouldn't, that certain fog would be immune to the fog setting and always on. Just random ideas

divVerent wrote:Picture of the bug: http://emptyset.endoftheinternet.org/~r ... 973468.jpg
I am trying to fix it at the moment (fix attempt is committed): http://emptyset.endoftheinternet.org/~r ... f7d5e1.jpg

If the fix gets confirmed working, I'll add the menu option.

Actually I was just updating Darkplaces from SVN and I seen this:

rev. 8554: r_shadows: use the parent entity's light direction for shadowing attached entities. Prevents tearing apart the weapon from its holder.

rev 8555: r_shadows 2: cast shadows always DOWN, ignore level lighting

Maybe a darkplaces dev or Div as he said above he'll try seen this and fixed it now?

That was me. I hope these changes work, but I need someone to confirm them. r_shadows 1 is supposed to actually work now, and r_shadows 2 is supposed to always project downwards now (so it doesn't wildly mess around like r_shadows 1 does if the map has a bad light grid, which q3map2 often causes). Maybe it would be good to have both options in the menu, but not sure.

And the problem with r_drawfog is: the server forces that cvar to 1 if forced fog is enabled and the map has fog. There is no other way to force it on... but if the server does that, the fog cvar WILL be 1 even if the client disconnects. That is the problem to fix, otherwise playing a "fog map" will turn r_drawfog 1 and your disabled fog goes away.

divVerent wrote:Picture of the bug: http://emptyset.endoftheinternet.org/~r ... 973468.jpg
I am trying to fix it at the moment (fix attempt is committed): http://emptyset.endoftheinternet.org/~r ... f7d5e1.jpg

If the fix gets confirmed working, I'll add the menu option.

What can I say, fantastisch