Well i think it should be easy for you to take to code from here: http://forums.alientrap.local/viewtopic.php?p=52190#52190 and adjust it to your current code as I do not have the nex sources avavilable right now.

Done, now the non-custom crosshair uses the older cvars. I also renamed the switch to cl_per_weapon_crosshairs as you said in an earlier post, as that is indeed the most descriptive name possible. Patch HERE and HERE. Now I really think this patch is ready to go in

Looks better now, however:

Code: Select all

-192,6 +191,10 @@
float view_set;
float camera_mode;
vector camera_offset, current_origin, mouse_angles, current_camera_offset, new_angles;
+
+string wcross_wep;
+float wcross_alpha, wcross_style, wcross_custom;
+vector wcross_color, wcross_size;
void CSQC_UpdateView(float w, float h)
{
   entity e;
-295,9 +298,26 @@
   }

   if(last_weapon != activeweapon) {
+      :wcross_recheck
+      wcross_custom = cvar("cl_per_weapon_crosshairs");
+      if(!wcross_custom)
+         wcross_wep = "normal";
+      else {
+         e = get_weaponinfo(activeweapon);
+         wcross_wep = e.netname;
+      }
      weapontime = time;
      last_weapon = activeweapon;
   }
+   if(wcross_custom != cvar("crosshair_custom"))
+      goto wcross_recheck;
+   wcross_style = cvar(strcat("crosshair_", wcross_wep));
+   wcross_color_x = cvar(strcat("crosshair_", wcross_wep, "_color_red"));
+   wcross_color_y = cvar(strcat("crosshair_", wcross_wep, "_color_green"));
+   wcross_color_z = cvar(strcat("crosshair_", wcross_wep, "_color_blue"));
+   wcross_size_x = cvar(strcat("crosshair_", wcross_wep, "_size")) * 24;
+   wcross_size_y = cvar(strcat("crosshair_", wcross_wep, "_size")) * 24;
+   wcross_alpha = cvar(strcat("crosshair_", wcross_wep, "_color_alpha"));

Why do the stuff within if(last_weapon != activeweapon) ? if you move the code to an better place you can make it simpler, easier to understand and less error prone.

I'do it like this:

Code: Select all

-295,9 +298,26 @@
   }

   if(last_weapon != activeweapon) {
      weapontime = time;
      last_weapon = activeweapon;
   }
+   string wcross_wep; // strings are "" on init (do not keep this comment :P )
+   float wcross_alpha, wcross_style;
+   vector wcross_color, wcross_size;
+   if(cvar("crosshair_per_weapon"))
+      e = get_weaponinfo(activeweapon);
+      wcross_wep = e.netname;
+   }
+   wcross_style = cvar(strcat("crosshair_", wcross_wep));
+   wcross_color_x = cvar(strcat("crosshair_", wcross_wep, "_color_red"));
+   wcross_color_y = cvar(strcat("crosshair_", wcross_wep, "_color_green"));
+   wcross_color_z = cvar(strcat("crosshair_", wcross_wep, "_color_blue"));
+   wcross_size_x = cvar(strcat("crosshair_", wcross_wep, "_size")) * 24;
+   wcross_size_y = wcross_size_x;
+   wcross_alpha = cvar(strcat("crosshair_", wcross_wep, "_color_alpha"));

That reduces the code, removes all global variables, gets rid of the update problem, makes it easier to read and i doubt its slower. It also does away that strzone which did not have had an matching strunzone (basicly a memory leak..) because the string is only used locally. I'd also name this cvar just 'crosshair_per_weapon' its shorter and IMO closer to the other cvars and acutally enables people to find it by chance via tab completion when changing the variables from the console..

The menu changes are a bit mood as long as there is no menu to change all the settings. Maybe you can take a look at how the radar & waypoint or weapon-priority 'sub window' is done and move/add all the crosshair stuff into a "crosshair window", so you have the current settings and per gun in the window?

Done what you said above except the menus. The reason I was keeping everything in that if(last_weapon != activeweapon) statement was that I was being too careful to only execute what was necessary every frame, but now that I look again that was pointless and it doesn't cause any harm this way and makes things much better. Re-check the links in my post above for new patch location.

The menus have a longer story. My initial idea was putting the crosshair selector left of the priority list in the Weapons window as well, and when weapon based crosshairs were in use have the weapon you select in the priority list be the one the crosshair selectors adjust for (see this illustration I made a while ago). That would require heavy coding however, so unless we can get something like that working there's no point in moving the crosshair selector from Player Setup and just leaving that toggle checkbox for the cvar is good for now. Besides, moving them would leave Player Setup very deserted as well so for now I think the menu should be applied like this and later on we may look at a way to get stuff working like in that picture I linked.

I think its good enough for now, i changed it slightly and did commit this: http://pastebin.com/d34572c9d
The menu is however sub optimal and needs further changes!

I think the menu change you propose would not even be that much/hard to code. For example the server list has some similar dependencies. I'm just not sure if its a good way to present those settings. Its not really clear that you have to click the list to set the weapons crosshair. Maybe it would help to exchange the left/right parts and move the crosshair stuff lower so that the dependency is easier to see/feel. Maybe i find some time during the weekend for those menu changes, please say something in case you also try your luck at them.

I think all that would be needed is to turn the complete crosshair stuff into a own control (like the weaponslist itself) and the weaponslist would need an entity 'pointer' to this control. In the lists onclick method you would then tell the CH control which weapon was clicked and it would check the per_weapon setting and if enabled then basicly load the right values (much like the drawing code does now) and displays them. Does not sound hard..

Thanks a lot for committing it, I feel relieved to finally see it applied I will let you know if I manage to get anything regarding the menus working, they do indeed need better changes although I don't think I can do something that big at my level of knowledge.

My belief is that the Weapon Setup window is the best place for the crosshair settings to be at. There's no reason to make a new window just for the crosshairs... in this form crosshairs are kind of a weapon property and I think their place is surely there. The weapon priority list would be the best thing to set them from, it would be pointless to make a new weapon list somewhere else just for the crosshairs rather then using the same one for many purposes. The weapon you have select in the priority list would be the one the adjusters would adjust the crosshair for.

We would find ways to somehow indicate that what you select in the priority list influences the weapon crosshairs... or people would figure it out by theirselves. Also later on, every weapon you select in the priority list (which by the way should probably be renamed to "Weapon List" as it would serve many purposes) should display a nice looking picture like an avatar of the weapon with a short description of it in the window. That would look beautiful I think, although a bit later on

Anyway I couldn't resist making a few more changes for today about 3 more things I had on my list. I fixed a small menu arrangement in Audio and I also attempted to change two firing types which I wanted to propose here (been planning to do this for a short while).

The first firing type I wanted to change was the hagar's alt fire, because after testing a bit I noticed that the bouncing rockets are hardly able to hit and that firing type is completely useless for the hagar. I changed the hagar's firing type in this patch so instead of bouncing rockets it sends faster spread rockets but with less damage... probably not the best idea but as I said I thought it would be important to have a firing type which can actually hit someone. My initial wish was to make it shoot 5 spread rockets in a row like a shotgun with a refiring rate of probably 2-3 seconds, but I couldn't do that so I thought this could be useful for now. Certainly no one used this firing type until now so no one would likely miss it, but I dunno.

The second firing type I changed was the crylink's alt fire which I made a bit more spread. It was hard to hit with it at close range and in general so this new spread should make its firing type a bit more useful at average distances I think. Patch HERE and HERE.

Actually the weapons are quite nicely balanced at the moment and changes to them would need proper testing which can take a lot of time. The hagar secondary is not so much a firemode to attack with but to help you control or clean out certain spots (as you can shoot around the corner) i'm not sure if it should be changed at all but if so then i'm against changing it into something too similar to existing stuff (both the shotgun and crylink primary have 'shotgun patterns')
As for the crylink secondary, i think currently it hits the sweet spot were the primary firemode can be too hard to hit at mid range due to peoples movement but the secondary will be quite easy to hit. If we were to raise the spread it would do less damage at this range and i think that would be bad.

I'll see to start with the crosshair menu changes later the day..

Yeah these changes were probably too quick and not as helpful as I thought. As an idea, maybe the hagar alt. fire could send rockets which bounce but when they hit the place they bounce from they also explode there as well (hit the the surface, explode there like normal hagar fire but the rocket continues one more time and explodes disappearing in the next surface). As for the crylink's, it still acts a bit like a sniper I think (aim carefully and hit well in the right spot), but it is usable and good I guess.

Anyway I updated and love the menu changes you made for now. A separate checkbox for crosshair colors is a great idea, as I seen some games which have custom crosshairs but the color stays the same (of course everything should be still customizable so yeah). The size and alpha could be global, although I'm not sure if alpha falls under the category of the color or not.

Anyway as you told me to ask you whenever I attempt to make a new change. I'm going to try and move the crosshairs from the latest SVN into the left part of the Weapon Setup window again. I've done it before (still have it in a older patch) so it shouldn't be long... I'll post here when I'm ready if that's ok.

Ok done it. Moved the crosshair adjusters from the latest rev in the Weapons window left of the weapon list. Patch HERE and HERE. The empty space under the crosshair adjusters is where I said yesterday that an avatar and description of the weapon which is selected from the weapons list should appear as well, which would also make it easier to understand that what you select in that list also adjusts for the crosshairs.

At the moment there's still a small problem in the new adjusters you set up however. With "Per weapon crosshairs" enabled, if you adjust the size or alpha that modifies these settings for each weapons crosshair. That should probably still remain disabled until we can have every adjuster there (the crosshair buttons, size slider, alpha slider, R G B sliders) working for every individual weapon depending on what you have set up.

Also I think the color overrider cvar should be named similar / after the custom crosshair cvar. That one is "crosshair_per_weapon", so the per-weapon-crosshair-color setting should probably be named "crosshair_per_weapon_color" or "crosshair_color_per_weapon" or something similar so it still derives from that.

The bouncing you describe is exactly how the crylink primary works

I'l take a look at your patches when i have some time..

Yeah, the crylink's does that so I think the one for the hagar should probably do the same thing. Back to the crosshairs anyway, I was planning to setup the new sizes for the defaults and seen a new patch was committed which adds weapon based crosshair files for each weapon. I'm not sure but I think that may probably not be such a good idea, and instead all weapon crosshairs could be left running from the classic crosshairs list including the defaults (crosshair1,2,3,etc.tga).

More weapon specific crosshairs do need to be added, but personally I'd go with adding them by modifying the crosshairX.tga files already there with better images. Separate .tgas for the weapon's name would probably get in the way as they would be hidden and unusable for any other weapon from the menu (unless they would also be present through the crosshair buttons in the menu as well so all crosshairs are selectable and usable). If per-weapon crosshair files are indeed better to use then sure, but I think that should probably be given a second thought as it may make the game less customizable if not added to the menus too and add unnecessary complexity. Just my thoughts...

MirceaKitsune wrote:At the moment there's still a small problem in the new adjusters you set up however. With "Per weapon crosshairs" enabled, if you adjust the size or alpha that modifies these settings for each weapons crosshair. That should probably still remain disabled until we can have every adjuster there (the crosshair buttons, size slider, alpha slider, R G B sliders) working for every individual weapon depending on what you have set up.

No, that's intended. That way, you can still adjust the size globally, while keeping the relative size difference as set up by the cvars. Note that the code MULTIPLIES the sizes, it does not simply override.

As for separate TGAs - well, we simply have too many crosshairs already. Too many image controls will slow the menu down noticably, we can't have 50 crosshairs in it. If anyone REALLY wants to use that crosshair, he can do "crosshair nex".

That's why the special ones should not be selectable generally.

I see then. Well as long as every weapon's crosshair type is overridable as well to use the menu crosshairs with the cvars everything is good I guess... maybe unique gun crosshairs could be a better idea after all I shall try to make some better crosses for each weapon a bit later in Photoshop.

As for the size and alpha being global, Esteel and me (if I understood what he meant right) were planning to try and make the crosshair adjusters work for every weapon from a list and adjust the crosshair of each gun from the menu. Not sure if and when we'll get that working although it's certainly worth a try, so maybe we can use that instead (my idea again is priority list selection = crosshair the sliders adjust).

Some changes to the Key Hunt HUD. Patch - here

Softened the two tga's, they now look less jagged - KH icons here

Moved the code from client/View,qc to client/sbar.qc with the CTF HUD code

Simplified it

Added three new cvar's

sbar_flagstatus_margin 10 // pixel distance between ctf/kh icons
sbar_flagstatus_border "8 100" // pixel distance between ctf/kh icons and the lower left/right corner
sbar_flagstatus_size_kh "49 112" // pixel size of the kh flags

Use sbar_flagstatus_right 1 to move the KH/CTF icons to the right. The icons may over print the weapon selector.

Note - I have used GetTeamRGB(COLOR_TEAM1), these can be replaced with the actual vectors.

Code: Select all

COLOR_TEAM1 (red) '1 0 0'
COLOR_TEAM2 (blue) '0 0 1'
COLOR_TEAM3 (yellow) '1 1 0'
COLOR_TEAM4 (pink) '1 0 1'

You really shouldn't registercvar saved cvars from QC. They won't get saved when not playing.

Better enter them into defaultNexuiz.cfg, and do something sensible if they are not set.

Created a new set of crosshair textures for the guns... still not perfect but more usable for now. They are a bit different then some of the shapes Div intended so I hope that's ok, I think I used some good and useful styles for now. I ripped and modified a few of the menu crosshairs as well but suited them to what they should be.

You can apply these temporarily even if they will be replaced later on to at least change the current simple images in the SVN. Apply the defaultNexuiz.cfg as well to match size and color changes correctly, and of course feel free to further modify these images and submit them if you wish. Patch can be found HERE.

divVerent wrote:You really shouldn't registercvar saved cvars from QC. They won't get saved when not playing.

Better enter them into defaultNexuiz.cfg, and do something sensible if they are not set.

I copied some 'sensible' code from client/teamradar.qc

A new patch here

I've also modified the ctf hud icons, and added another cvar sbar_flagstatus_size_ctf "64 64" // pixel size of the ctf flags

I changed all the ctf *.tga sizes, they are now 64 * 64 pxels, uncompressed - here.

The cvar 'sbar_flagstatus_pos' is no longer needed for the csqc hud, although it's needed when connected to 2.4.2 server.

The icon position no longer relies on the value of sbar, I find it annoying when I change huds and the ctf/kh icons move up/down. If the icons are in the lower left or right they could overlap the mini scoreboard (left) or the mini deathmatch overlay (right).

Whilst adding the cvars to defaultNexuiz.cfg I noticed that sbar_alpha_bg is in it but not used, and sbar_alpha_fg is not in it, but used in client/sbar.qc and client/View.qc. I'll investigate how they are used in the Darkplaces hud.

sbar_alpha_fg & sbar_alpha_fg are both defined in darkplaces/sbar.c

The new cvar's are
sbar_flagstatus_margin 10 // pixel distance between ctf/kh icons
sbar_flagstatus_border "8 100" // pixel distance between ctf/kh icons and the lower left/right corner
sbar_flagstatus_size_kh "49 112" // pixel size of the kh icons
sbar_flagstatus_size_ctf "64 64" // pixel size of the ctf icons

If sbar_flagstatus_margin is -ve and sbar_flagstatus_border_y is also -ve then you can reverse the order of the icons.

Edit: Removed a major typo from kh hud, updated the patch.

For the time being I have created another patch which implements a new feature that some of us wanted to see: Own footstep sounds on any server, regardless of the g_footsteps cvar. This new cvar is called cl_own_footsteps and allows one to hear their own (and only their own) footstep sounds on any server unless g_footsteps is enabled in which case you hear everyone's like before.

I know some devs didn't care about this feature and may see it as something pointless, but some of us want to hear our footstep effects a lot as it was discussed in another topic many months ago. The reason footsteps were made a mutator and disabled by default was so other peoples locations wouldn't be given away while walking, and since this enables local steps only that can still be prevented and those who want to hear footstep effects while walking are happy as well.

Patch can be found HERE and HERE. I hope it's alright and this feature can be implemented for those of us who want it

victim wrote:

divVerent wrote:You really shouldn't registercvar saved cvars from QC. They won't get saved when not playing.

Better enter them into defaultNexuiz.cfg, and do something sensible if they are not set.

A new patch here

It seems the registercvar calls are still there. Some can be safely removed, some others like sbar_flagstatus_pos not. I guess you will need to add the "seta" prefix to these cvars on defaultNexuiz.cfg.

Yet another update to the Key Hunt code http://paste.debian.net/26735/

A change to the behaviour of the Key Hunt hud. Now it only dislays the status of your keys and your teams keys. It no longer displays any details of the keys held by the other team(s).

The code has been simplified into one function - kh_update_client(). The array has been removed and replaced with a simple float using a bitfield.

Key hunt can now be played with more than 16 players.

Edit: Updated the pastebin URL

victim wrote:A change to the behaviour of the Key Hunt hud. Now it only dislays the status of your keys and your teams keys. It no longer displays any details of the keys held by the other team(s).

I'd say thats an mistake. The other keys status IS vital information. Like you see that the 'blue' team already has two keys then your team can forget the yellow team for the moment and concentrate on the blue team, and getting their keys.
If you only see your own teams keys it could be that see on keys at all.. so which team to go after? There is an higher chance to get an key and prevent the team from winning if you go after the team that already has two keys.
my 2 cents

The current Key Hunt hud:

100% alpha key, the keys that you are holding
40% alpha key, the key is held by another player (from any team)
an outline, the key has been dropped

The new Key Hunt hud:

100% alpha key, the keys that you are holding
40% alpha key, the key is held by a member of your team
an outline, the key has been dropped or held by another team

It will be possible to extend this info. As there are a maximum of four teams, thus a maximum of four keys. Which needs 16 bits to represent them, plus 4 bits for your own keys. Giving a total of 20 bits, leaving 3 spare bits.

Made a few more changes to the own footsteps patch to update it to the latest SVN and fix a few things I had forgotten. New LINK 1 and LINK 2 here. I'd like to know a verdict on this patch as well if that's ok, to know if to keep it updated or not. Are there any other changes required, or is this feature not going to be implemented at all even the cvar?

My first CSQC patch, YAAAAAYYY

Shows the Ready-restart countdown clientside now (also plays the sound clientside). When you are a player, you'll still see the countdown as centerprint. When you are spectating/observing you will see the countdown as info-line in the upper right corner.

This allows much smoother count-downs when having packetloss!

Patch file here

Next patches to come from me (well, at least they are planned, I lack time unfortunatly, but I'm on it...):
- Do the same for the timeout messages
- Add a 2nd mode to g_chat_nospectators that allows spec chat to be seen only during warmup stage but not during match stage (atm it is either 0=always see spec chat, 1=never see spec chat)
- Once I have enough understanding: Making the nexbeam clientside, this has two advantages:
1) You can allow a command line cl_oldnexgunbeam 0/1 that will help the Nexuiz ladder to get rid of the "hack" pk3 file that replaced effectinfo.txt, This cvar could set the nexgun beam to be v2.4.2 style. When this is handled in CSQC you can even enable the prettier SVN beam again when watching/recording demos
2) Clientside nexgun shot prediction: draw the beam (and play the sound) immediately on servers that use g_antilag, to be a "better" visible representation (e.g. cl_predictnexgunbeam, defaults to 0 of course)

MirceaKitsune wrote:Made a few more changes to the own footsteps patch to update it to the latest SVN and fix a few things I had forgotten. New LINK 1 and LINK 2 here. I'd like to know a verdict on this patch as well if that's ok, to know if to keep it updated or not. Are there any other changes required, or is this feature not going to be implemented at all even the cvar?

I'm not sure whether this works, but could it be possible that you do this feature entirely in CSQC ?

+ game_starttime_multiplied = ReadLong();
+ game_starttime = game_starttime_multiplied / GAME_STARTTIME_PRECISION;

Juse use ReadCoord/WriteCoord, that's 4 bytes too, and has exactly the accuracy that float has anyway.

- Once I have enough understanding: Making the nexbeam clientside, this has two advantages:
1) You can allow a command line cl_oldnexgunbeam 0/1 that will help the Nexuiz ladder to get rid of the "hack" pk3 file that replaced effectinfo.txt, This cvar could set the nexgun beam to be v2.4.2 style. When this is handled in CSQC you can even enable the prettier SVN beam again when watching/recording demos

ONLY if this can be restricted server side, so that only ladder servers allow this sort of cheating. If the server can restrict it - sure.

2) Clientside nexgun shot prediction: draw the beam (and play the sound) immediately on servers that use g_antilag, to be a "better" visible representation (e.g. cl_predictnexgunbeam, defaults to 0 of course)

The hardest part will be reliably handling the refire delay with it. Other than that, good idea, and could be 1 by default, if it uses the server's state of g_antilag.

GreEn`mArine wrote:I'm not sure whether this works, but could it be possible that you do this feature entirely in CSQC ?

This feature is entirely CSQC code, although it has to be written in the server code but it's only sent to who it must.

mand1nga wrote:

victim wrote:

divVerent wrote:You really shouldn't registercvar saved cvars from QC. They won't get saved when not playing.

Better enter them into defaultNexuiz.cfg, and do something sensible if they are not set.

A new patch here

It seems the registercvar calls are still there. Some can be safely removed, some others like sbar_flagstatus_pos not. I guess you will need to add the "seta" prefix to these cvars on defaultNexuiz.cfg.

What else needs to be done to this patch?

I'm assuming my Key Hunt / Capture The Flag modifications are actually wanted, or should I stick to the day job!

The KH changes are very much rejected, as you show less info than there is now.

I agree with esteel: "I'd say thats an mistake. The other keys status IS vital information."

Another way to show it would be numbers, like, "Red: 2 keys, Blue: 1 key, Yellow: 1 key".

Or, a HUD like:

*red key icon* *red key icon*
*blue key icon*
*yellow key icon*

where your own team is highlighted in some way.