MirceaKitsune wrote:The headphone friendly mode is much better indeed, although I think the volume is still lower at a distance for the taunts.

It sure is not, but taunts that come from your own entity do seem louder as they count as ambient sounds. This has nothing to do with distance, just with who says it.

Either way I still believe there should be a way to turn them off, radio voices sound very different directionally then non-directionally no matter how they are tweaked or optimized. To me they now sound as if someone is speaking the taunts from their location, not a radio any more.

Isn't that what the taunts SHOULD be? I mean, why should the enemy be able to speak in my team radio channel? That's the one thing I don't get.

Many will certainly want to disable them, and I don't see anything wrong in applying the above patch to allow them to do that if they wish.

If you don't want to implement the full patch maybe you can just implement the cvar, even if it will be enabled or disabled by default or not have a checkbox in the Audio menu. That cvar is all I ask for... I hope I'm not being too hard headed on this, its just that it took me a full day of work to make the auto-voice system as I intended and feel as if this makes them something completely different from what they should be, and don't sound good at all either. That cvar doesn't hurt anyone, and it's an option which will surely be used by many people. I'm certain that in the future many players would request a switch for the directional taunts anyway. So if you want to please implement that cvar at least, to give an alternative to those who want them in the original way.

btw, the Headphone Friendly Mode has a small issue and doesn't stick between game restarts and also turns itself off once you apply it and revisit the menu.

I still do not see why anyone would want to hear constant voice spam of taunts without even being able to know where they come from.

The issue with the headphone friendly mode should be fixed now.

divVerent wrote:Isn't that what the taunts SHOULD be? I mean, why should the enemy be able to speak in my team radio channel? That's the one thing I don't get.

divVerent wrote:I still do not see why anyone would want to hear constant voice spam of taunts without even being able to know where they come from.

Many people do want to hear them in the radio even if they don't know where they are coming from. UT has them that way and everyone uses them and likes them. I know you probably don't like hearing them that way and find such taunts annoying, but there are many players who do like them playing globally very much. I'm certain that at least 40% of the users here would say they want to have taunts playing that way if asked. It would make them happy if they could enable them to work like in UT and other games I think.

UT did show another way who the taunts came from, but that's too much work to code. It showed the avatar and name of the player while playing the taunt. That way would be okay too.

divVerent wrote:UT did show another way who the taunts came from, but that's too much work to code. It showed the avatar and name of the player while playing the taunt. That way would be okay too.

I see now. In the case of UT2k4 however when someone fragged someone else you only heard the voice and it showed who fragged in the console text near the chat, and Nexuiz has such a console at the top of the screen as well saying who killed who so with them being non-directional they would work like in UT2004. I also remember playing at least another DM game which worked the same way (taunts played globally and you only seen who fragged who in the on-screen console), but that's been a long time ago and I fully forgot.

Another problem with your patch is that you only changed how auto taunts play. That's stupid. Regular taunts should play none different from automatic ones. That's why the cvar now is called cl_taunt_directional.

And the problem is - with non-directional regular taunts, you indeed don't know who they are coming from.

Sorry about that mistake, indeed auto and non-auto taunts alike should play the same way. And thanks. Hopefully one day we'll have better frag indicators as well like UT99's with avatars and a name for each frag... I'll actually try to look into it sometime and see how that could be done like.

Regarding the Headphone Friendly checkbox the issue still seems to be there and it still turns itself off in the latest version once enabled. Not sure if that may require a fresh SVN to work instead.

Just to clarify something for me and anyone else who might be wondering. Are you gonna hear both teams taunts or just your own team (in case of DM of course everyone would be heard). I think that it's obvious you should only be able to hear your own teams taunts.

ai wrote:Just to clarify something for me and anyone else who might be wondering. Are you gonna hear both teams taunts or just your own team (in case of DM of course everyone would be heard). I think that it's obvious you should only be able to hear your own teams taunts.

You can hear everyone's taunts even in team games but I think that's correct. When someone from the enemy team frags someone from your team they'd want the opposing team to hear it as well, but that depends on opinions again. Don't wanna cause any more headaches so don't mind me and do what you believe is best, although personally I think that is against the purpose of taunts and they should play for both teams / everyone, as taunts are meant to be heard between enemies first of all.

MirceaKitsune wrote:Sorry about that mistake, indeed auto and non-auto taunts alike should play the same way. And thanks. Hopefully one day we'll have better frag indicators as well like UT99's with avatars and a name for each frag... I'll actually try to look into it sometime and see how that could be done like.

Regarding the Headphone Friendly checkbox the issue still seems to be there and it still turns itself off in the latest version once enabled. Not sure if that may require a fresh SVN to work instead.

It requires a fresh svn engine. Do you have that?

Yes, the latest engine update fixed it. Anyway there were still a few small changes on my mind so I made another misc patch with a few tiny changes and corrections mainly for eye candy. Patch HERE and HERE. Changes I posted in it are:

- Fixed two tiny things in the menus... a spacer between two unrelated settings in Video and better reordered some settings in Audio.

- Added one extra height row to the Mutators window since the new Camping Rifle is now present in the auto-generated Weapon Arena list and the new row it created pushed a checkbox out of bounds.

- Attempt to add some discrete color code to the default BOT prefix to make bots stand out more easily in the score board. I thought might look a bit better though it could be a stupid idea if not.

- Attempt to add a slightly bigger multiplier for the item respawn particle effects for the eye candy, so more particles are generated when an item respawns for nicer looks.

- Made bodies require a little bit more damage before they gib, as I think they gibbed too easily most of the time and that looked odd. I tested a few rounds with bots this way and I think the body gibbing is more close to normal now.

Talking about gibs ... isn't weird that models coming from a big explosion become gibs when it touches the floor or a wall, instead of becoming gibs with that explosion? bug or feature ? Please see the slow motion part of this video

mand1nga wrote:Talking about gibs ... isn't weird that models coming from a big explosion become gibs when it touches the floor or a wall, instead of becoming gibs with that explosion? bug or feature ? Please see the slow motion part of this video

I have seen that as well, yes. Bodies gib whenever they hit the floor or walls at a small speed though I wasn't sure if that's left on purpose or unoptimized (reason why I didn't look into changing it). I do believe the speed-based damage to bodies needs to be much more tolerant however, as bodies gib from falling from the smallest height.

After a few looks through the code I managed to make another patch which is the basic implementation of a feature that many people wanted, custom weapon-based crosshairs. I managed to find the file in which this code is to reside and coded a simple way so whenever you switch the weapon a new set of crosshairs settings are applied.

Before looking into my patch be warned that the code is very long and unoptimized, but it does work as it should without any issues. This is an experimental patch and not meant to be applied to the SVN yet, mainly as it doesn't have a menu implementation since I couldn't figure that one out. The reason I put it here is that I managed to get most of it working but don't know how go any further, so if this feature is to be implemented someone with more experience then me probably needs to take a look at it and fix what's left.

The way I have implemented this so far is by having the client replace the default crosshair cvars with other cvars every time you switch to a new weapon. For example, lets say you are holding the laser and switch to the shotgun. When the shotgun is selected, the cvar "crosshair" is replaced with the cvar "crosshair_shotgun", "crosshair_color_red / green / blue" with "crosshair_shotgun_color_red / green / blue" and so on for all sub settings of the crosshair for each individual weapon. Not sure if there's a better possible method but as I said I created the best thing I knew which actually works.

There are two things which need to be done before this patch can be considered functional. First is for the code to be optimized somehow so it won't be so long in View.qc. There are probably variables which need being declared somewhere else, parts which are better off in other locations... those who are more familiar with the code know here. Second is for a menu patch to be created, I have implemented the cvars for each weapon but don't know how to change the crosshair selector in the menu to match this new feature (the crosshair selector will need to be moved in the Weapon Settings sub-window of Player Setup as in this picture).

I'll probably try to add more tomorrow but until then feel free to modify this as it should be done and if someone can find a way to make a working menu patch as well this is all that's needed. Patch HERE and HERE. Hope the necessary optimizations can be made so this can be implemented in the SVN

[EDIT] Made more changes to this today. Removed separate string declarations which helped reduce the length of the code to half of what it was previously. Added crosshair_default which is the crosshair which gets applied when the crosshair_custom cvar is off, but unfortunately this only applies after you turn off the crosshair_custom cvar and switch to a new weapon, while the correct implementation is for it to apply it automatically on cvar change. Included menu changes which moves crosshair settings to the Weapon Setup window left of the Weapon Priority list... leaves Player Setup a bit empty but it's the only way to implement this in the menu (still no functionality over individual weapons though). Added nicer looking defaults for different weapon crosshairs.

This patch really is too messy, especially the changing the engine cvars, and the huge if list for all weapons.

Better do NOT use the engine's crosshair drawing then, but instead implement the crosshair using drawpic() in CSQC.

Also, it would be good to provide weapon specific crosshairs that actually match the weapon (like in tribes 2), and not just let the user choose them. We don't have matching crosshairs for most weapons yet.

Another thing: do not EVER do such a list of ifs for every single weapon. It makes adding new weapons hard.

Instead, use a loop on the weapon number, and get weapon info using the get_weaponinfo() function.

An example can be found in server/miscfunctions.qc, readplayerstartcvars()

divVerent wrote:This patch really is too messy, especially the changing the engine cvars, and the huge if list for all weapons.

Better do NOT use the engine's crosshair drawing then, but instead implement the crosshair using drawpic() in CSQC.

Also, it would be good to provide weapon specific crosshairs that actually match the weapon (like in tribes 2), and not just let the user choose them. We don't have matching crosshairs for most weapons yet.

I'll try to take a look at the CSQC option and see if I can move things there. And the current default crosshairs I provided are randomly made, the next thing I was planning to do was setting the best matching crosshair for each weapon once the patch is up and working. I do however want to allow every user to manually change the crosshair for each weapon, but until a way in the menus is found the cvars from the console would have to do (or manually editing defaultNexuiz.cfg).

divVerent wrote:Another thing: do not EVER do such a list of ifs for every single weapon. It makes adding new weapons hard.

Instead, use a loop on the weapon number, and get weapon info using the get_weaponinfo() function.

An example can be found in server/miscfunctions.qc, readplayerstartcvars()

Thanks for the info, I will keep that in mind. The problem here is that in order for each weapon to get its crosshair cvar its difficult to specify a cvar in a loop. For example crosshair_laser_color_red, I'm not sure how to make it know to take "crosshair_(get weapon name here)_color_red" for that.

divVerent wrote:Also, it would be good to provide weapon specific crosshairs that actually match the weapon (like in tribes 2), and not just let the user choose them. We don't have matching crosshairs for most weapons yet.

From a users point of view a simple option to enable/disable this feature and a good set of default would be fine. You know people WILL want to adjust those weapon crosshairs so it has to be configurable after all
The real question is what should depend on the gun? crosshair, CH-size/color, fov, zoomfov for example are usual combinations in other games iirc

MirceaKitsune wrote:Thanks for the info, I will keep that in mind. The problem here is that in order for each weapon to get its crosshair cvar its difficult to specify a cvar in a loop. For example crosshair_laser_color_red, I'm not sure how to make it know to take "crosshair_(get weapon name here)_color_red" for that.

There should be functions that map the weapon number to names and the other way round..

MirceaKitsune wrote:Thanks for the info, I will keep that in mind. The problem here is that in order for each weapon to get its crosshair cvar its difficult to specify a cvar in a loop. For example crosshair_laser_color_red, I'm not sure how to make it know to take "crosshair_(get weapon name here)_color_red" for that.

The same way it builds "g_start_weapon_(get weapon name here)"...

I managed to make a for() loop which gets your weapon type so the long code was finally removed. I renamed the cvars to use numbers instead of weapon names and based the code on weapon numbers now, both because it's easier (names had spaces which didn't fit well in cvars) and makes the system more adaptable to new weapons. Also added better default crosshairs for the moment.

I still left the system based on cvar changes however, as I had issues getting drawpic() working. I'm wondering though, is it really a bad idea to leave them working off the client crosshairs however? The only problem with making them working off cvar_set is that the code -looks- a bit too hackish I think, but from a technical point of view that works very well and probably it's best to leave the client handle crosshair rendering. Please change it if anyone can get a better method working however and that is indeed a bad way. New patch HERE and HERE

Code: Select all

               float j; //Custom weapon crosshairs
               for(j = WEP_FIRST; j <= WEP_LAST; ++j)
               {
                       e = get_weaponinfo(j);
                       if(!cvar("crosshair_custom"))
                       {
                               // this gets executed for every weapon. Why?
                       }
                       else if(j == activeweapon)
                       {
                               // and this gets executed only once
                       }
               }


This is known on DailyWTF as the "for-case paradigm". Don't use it. Remove the loop, do e = get_weaponinfo(activeweapon) once.

Also... use e.netname as weapon name. Don't use these numbers in the cvars any more, they're irritating to players.

I made an attempt to reduce the amount of overlapping text, especially concerning centerprint(). My first proposal is at:

http://paste.debian.net/25637/

It modifies the handling of centerprint(), which is used for a lot of stuff, like "you were fragged by", team messages, MOTD, etc...

In order to try it, you have to start a local server, because SVN servers will push their client side progs to you.

* The centerprint texts are now usually printed below the scoreboard. In case the text wouldn't fit on the screen it will be shifted up, so that it is just above the bottom.
* To avoid jumping of the text it is always below the scoreboard, even it is not visible.
* The centerprint can now easier overlap with the chat box... there is not enough free space.
* I moved the scoreboard down a bit, because it was overlapping with the event log.
* The patch is purely client side. I also started cleaning up the server code, but that is rather cosmetic.

divVerent wrote:This is known on DailyWTF as the "for-case paradigm". Don't use it. Remove the loop, do e = get_weaponinfo(activeweapon) once.

Also... use e.netname as weapon name. Don't use these numbers in the cvars any more, they're irritating to players.

Yeah, the for loop was a big mistake of mine. Anyway I ran into some block and probably found a bug as well... it seems that weapons.netname is broken in the client code. To test, replace the if(last_weapon != activeweapon) statement with the following one in View.qc:

Code: Select all

   if(last_weapon != activeweapon) {
         e = get_weaponinfo(activeweapon);
         print(strcat("Test", e.netname)); //Test

      weapontime = time;
      last_weapon = activeweapon;
   }

Now go into the game, switch some weapons then pick up new ones. You will only see "Test" being printed in the console, but no weapon name as it should. I tried every alternative... replaced e = get_weaponinfo(activeweapon); with e = get_weaponinfo(1); (which should return the laser), different print() methods for the test, a different new entity other then e, but this doesn't seem to work. If I write e.message instead of e.netname however it returns the name of the map I'm on and its author, weirdly enough. I don't know if this is a bug or not but I looked at everything and it should be working correctly but it doesn't.

Did you add a call to RegisterWeapons() to the initialization of the client?

That fixed it, thanks. Created the 4th version of the patch as requested, which does optimize the code as well as possible I think. Also found a way to compress some code in choosing between defaults and customs, and changed the default crosshair buttons and menu to use crosshair_default_* instead of crosshair_* which is more suitable now. New patch HERE and HERE. This can probably be implemented in SVN by now with crosshair_custom defaulting to 0 until the menu can be figured out as well.

RoKenn wrote:* The centerprint can now easier overlap with the chat box... there is not enough free space.

Maybe wordwrap chat text at less than 69 (?) characters.

Alien wrote:

RoKenn wrote:* The centerprint can now easier overlap with the chat box... there is not enough free space.

Maybe wordwrap chat text at less than 69 (?) characters.

The problem is that centerprint is used for a bunch of different purposes, also the MOTD, which can be quite long. If I split the text into more lines, the vertical overlap would get even worse for long MOTDs.

A simple "you were fragged by someone-who-has-a-long-name-to-show-you-that-he-sucks" will show up above the chat box anyway.

I already thought about not showing the scoreboard after connecting, only the MOTD. But then even more people would join the wrong team, probably.

I meant CHAT box.

Alien wrote:I meant CHAT box.

*walks away to attend a reading course*

I will have a look at that. The question is if it helps. The MOTD lines often nearly cover the whole line, so it will still overlap and the other messages ("fragged by" and team messages) will be above it anyway. And making the lines too short can make important(*) messages disappear too fast.

It's a bit difficult to test all varieties, because I either have to run a local server, or go to a 2.4.2 server, which doesn't have the new scoreboard.

Another idea to solve the vertical overlap of the MOTD would be to automatically reduce its font size if an overlap would occur otherwise.

(*) maybe I should hook a small censor bot into the Say command that swallows irrelevant chat, when some people again confuse Nexuiz and IRC.

I looked at wrapping the chat box. Basically I would have to wrap after 33 characters (including the name) to avoid overlapping on my screen (width 1280). So I left that as it is.

Instead I fixed a stupid bug and also shifted the message to the center in case of very small scoreboards (like in the campaign).

Here's the patches:

Client: http://paste.debian.net/25839/
Server: http://paste.debian.net/25838/

Note that these are basically independent and the server patch is mostly cosmetic (just removed newlines at the end).

Remade the custom crosshair patch so it matches some modifications done in the Weapon Settings menu a few days ago. Link 1, 2. Also wanted to know what Div intends to do with this patch so I know if to keep working on it or not. Will it be added to SVN or must the menu chooser be figured out as well first?