Progs.dat can read client's vars?

[ChOwW]

[frag.machine]

[Spike]

theres two ways to do it.
1: csqc.
2: krimzon_sv_parseclientcommand and cvar expansion - stuffcmd(player, "cmd clientcvar $cvarname\n");

[ChOwW]

[Cobalt]

Afaik, there is no way to do this in plain vanilla qc. There were some other kinds of code that I saw years ago regarding the big endian architecture
that can compile in regular QC and they were used to blank out the IP addresses in the status command.....but not sure if they can do stuff like this or not. In legacy ctfbot, there is a feature called : ' Fixed FOV ' which when is set, merely uses stuffcmd to place the clients fov setting to be 90 in either post think or prethink for the player. CSQC may be a better way of accomplishing your requirements though.

[Seven]

[Baker]

[Spike]

stuffcmd(self, "this string has a \" in it");


stuffcmd has no return value. like I said, you need to use KRIMZON_SV_PARSECLIENTCOMMAND in order to read it, which will only happen after a delay, because it needs to basically bounce off the client before the server can actually see the response. QC does not have blocking calls like that, it would be too easy to exploit.

[Seven]

Thank you Baker for your suggestion.
Where would I use these alias lines ? Is this inside QC or autoexec ? I have not seen such line formats yet...

If your method (which I still not fully understood) can only restore the original cvar setting after map change,
it would not be good, because then all other original Quake´s centerprint messages in that map would also last 10 sec.


Hello Spike,
I was hoping that you could maybe tell me how to make use of KRIMZON_SV_PARSECLIENTCOMMAND in this context. I never made use of this extension before and dont know how it works.
I am a person who needs to see an example to learn it and beeing able to convert it to different things.
That makes it sometimes hard using a new extension without knowing how the syntax in a used condition is.

Thank you all for your help and efforts.

[Baker]

[Spike]

[Seven]

Thank you very much Spike and Baker for your detailed answers.
I now understand that it is in general not a good idea to try to read client cvars from the server side.
That is why QC-mods should not mess with client cvars at all.
I will rethink my idea and most probably skip it.

Thank you again for your lessons.

[Baker]

Seven, the "right" way to do what you want to do here.

Centerprint it 3 times, 2.9 seconds apart. Then you don't have to mess with anyone's cvars. And if they have a dumb scr_centerprinttime value like 1, that's on them.

[Or find some other way to display your message. Or eliminate the idea entirely Maybe you should say what this idea is?]

[Seven]

Hello Baker,

yes, I also thought about why not use a small function with a centerprint loop and a nextthink value to cover the 10 sec.
But I thought that centerprints bring automagically that "notify" sound with them. Just like the one from the start map skill settings message.
It always "beeps"
But then I looked into the maps ent file and discovered that the sound is not engine sided hardcoded to centerprints.
There are even 3 possible sounds available.
Default is without sounds, so this "workaround" should be an easy way for doing it.
Thank you for your suggestion Baker.

It has something to do with the "small mod compilation". A SSQC sided version of a map introduction text.
But the more I think about it, the more I think that this would annoy people.
Maybe I should switch to bprint instead (which is only visible in console for the interested user).
But who knows for which other purpose this thing will end...
Anyhow, it helped me to learn a bit more about QC. And that was defenitely worth the trouble.
Thank you again Spike and Baker for sharing your knowledge to the ones in need.

Best wishes,
Seven

[Seven]