Supressing available weapon errors... cl_weaponsystem.qc confusion

I've recently revisited possible solutions to the problem I posted about a while back: [weapon name] is not available errors with no start weapons

Unfortunately, I am now even more confused. I've been attempting to re-compile Xonotic 0.6.0 from source in an attempt to remove the on-screen messages that are displayed when you attempt to switch to a weapon that isn't in your inventory. I've isolated the message to "cl_weaponsystem.qc", specifically this line (820):

Code:

            sprint(cl, strcat("The ^2", W_Name(wpn), "^7 is ^1NOT AVAILABLE^7 in this map\n") );

Yet when I change or remove this line, the messages persist. I've even tried completely removing the entire cl_weaponsystem.qc file from the source code (and all references to it so compilation won't fail)... and yet the messages remain.

To make things more confusing, there seems to be a variable that one can use to suppress these messages: hud_panel_weapons_complainbubble. But changing this from the default "1" to "0" doesn't seem to do antyhing.

Can anyone help me with this? I've spent around 4 hours on this already, and am just going in circles...

And yes, I know this is a cosmetic issue of no real importance, but the fact that I can't figure it out is driving me nuts...

Does it persist on local games too, or only on online servers? Because this code is serverside code, which means that you will get the message on all servers that do not have this line of code removed as you did.

As for the complainbubble, that's a clientside (CSQC) feature that shows an empty weapon slot in weapon list on your HUD with some text such as "Don't have" or "Out of ammo" or "Unavailable" overlaid. That code is in client/hud.qc.

I don't know why the "NOT AVAILABLE" console message isn't clientside, as that would allow localization of the string. But even if it were, you can not modify csqc code, it's a compatibility risk and darkplaces checks its hash and size to make sure that the client uses the code the server intended.

EDIT: Oh, I read your other post... If you want to use Xonotic as a tool to "visit" bsp maps, why not unbind the weapon binds? You can also suppress all the top-left messages with con_notify 0.

EDIT2: You did compile the qc files, didn't you?

Does it persist on local games too, or only on online servers? Because this code is serverside code, which means that you will get the message on all servers that do not have this line of code removed as you did.

I haven't tried online servers, only local games (which is what I'm using it for anyway). A clientside-only fix would be fine.

EDIT: Oh, I read your other post... If you want to use Xonotic as a tool to "visit" bsp maps, why not unbind the weapon binds?

That's plan B. But I really like the idea of being able to have weapons available, just not by default. That way I can hide weapons as easter eggs in the map, and still use it for regular play as well as just a walkthrough.

EDIT2: You did compile the qc files, didn't you?

I use dpkg-buildpackage to compile from source and build a deb all at once. I *assume* the qc files get compiled in this process, as the source directory I'm using has absolutely no binaries, and the final deb(s) that are created are fully-functional. I confess I don't understand the build process that dpkg-buildpackage uses, so I can't be 100%.

You can also suppress all the top-left messages with con_notify 0.

That is probably exactly what I want. I have no use for pretty much any of those top-left messages, so suppressing all of them would be fine. I'll try this first thing when I return home.

I don't know how dpkg-buildpackage works, are you sure it's possible to modify the sources and not have it work off the original source archive?

EDIT: Anyway, you don't have to rebuild the whole thing... Just compile fteqcc (I think running "make" in its directory is enough) then run fteqcc from inside the qcsrc/server directory. This will produce a file in qcsrc's parent directory called progs.dat, put that in ~/.xonotic/data and it should work fine. Don't forget to remove it when you're done testing!

con_notify 0 worked!! Thank you!

For future reference, dpkg-buildpackage just works by taking a source tree and building it according to rules you specify in a packaging directory. So yes, it does allow for changes to the source. I'd still really like to know why my original modifications didn't work, but at this point, I'm just glad the problem is solved. Plus, I wasn't keen on making changes that require recompilation anyway, as then I'd have to re-apply them manually with each new Xonotic release if I wanted to keep things up to date.

Thanks again for all your help.