Need feedback on CVARINFO, SetCVar and synced CVars

[Torr Samaho]

Since not too many people are monitoring the tracker, I'm using the forum to draw attention to a feature quite a few modders have been asking for and I need feedback on before I can include it in an official beta build.

I recently ported CVARINFO lump support and the ACS function SetCVar to Zandronum. This includes support for CVars that are automatically synced between server and clients. User CVars are not support for now though.

The only problem is that all of this is pretty much untested, so I need your help to find out whether it's working as intended.

Please check the tracker ticket for details.

[ZzZombo]

So far it works fine. If anything, backporting user console variables can be done seamlessly, I think.

[ForrestMarkX]

This breaks mods that use set in there config, for example if you called set samsara_armormode 2 in the cfg then the server will error out saying that the cvar already exists if the same cvar is present within cvarinfo

This also happens with clients who try to join with a clientside cvar that is set in there cfg

[Torr Samaho]

Please elaborate how this breaks existing mods. CVARINFO doesn't create any new variables unless it's instructed to do so.

[Ijon Tichy]

A couple mods I've worked on, such as Metroid Dreadnought and Dakka, have had a CVARINFO in them since 1.2, due to being cross-compatible between Zandronum and ZDoom. Because Zandronum didn't have CVARINFO support, it detected the lack of CVARINFO and used ConsoleCommand appropriately.
Now that CVARINFO is recognized and detected, the mods will use it instead of ConsoleCommand, but the console definitions are still there, and you get those lovely error messages.

Can't exactly expect Zandronum to do anything about that, you know.

edit: So yeah, the best mods to test this with at the time being are, as stated above, Dakka and Metroid Dreadnought, with a fresh INI.


edit2: As for the config thing, is CVARINFO handled before +exec lines? If not, there's the issue.

[KenFH]

Seems to me there is a pretty glaring unresolved problem here as of 2.1.2. For example, in Wrath of Cronos 1.8, if you try to set the cvars that are in its CVARINFO, such as WoC_GoldDeathAmount, you either get "Unknown command "WoC_GoldDeathAmount" if not prefixed by set, and the variable does not get changed, or "Script error, "wrathofcronosr1_8a2.pk3:cvarinfo" line #:" "2015-Aug-31 11:05:26 cvar 'WoC_GoldDeathAmount' already exists"" and the server FAILS TO START ENTIRELY.

This appears to be a longstanding Zandronum 2.0 deficiency related to .cfgs running before W_Init and the CVARINFO parser (which only runs later) treating already-existing cvars as a game-breaking error. Unless .cfgs are moved to run after CVARINFO initializes, the CVARINFO loader must handle pre-existing server settings gracefully, or there needs to be a way to set them up to run later from the server .cfg; as-is, it would be better not to parse CVARINFO at all (that would actually be a good workaround until it can be fixed properly.) There's relatively little point to having CVARINFO if server owners can't actually change the variables without resorting to manual rcon every time the server comes up.

[Torr Samaho]

This appears to be a longstanding Zandronum 2.0 deficiency related to .cfgs running before W_Init and the CVARINFO parser (which only runs later) treating already-existing cvars as a game-breaking error. Unless .cfgs are moved to run after CVARINFO initializes, the CVARINFO loader must handle pre-existing server settings gracefully, or there needs to be a way to set them up to run later from the server .cfg; as-is, it would be better not to parse CVARINFO at all (that would actually be a good workaround until it can be fixed properly.)

Sounds like a ZDoom issue to me. Is this any different there?

There's relatively little point to having CVARINFO if server owners can't actually change the variables without resorting to manual rcon every time the server comes up.

I backported this more than a year ago and AFAIR this is the first time somebody complains about this limitation. So it looks like not many have such a strong opinion about this.

[Ivan]

I think that rcon limitiation thing is nothing a config can't fix, right? I mean, it shouldn't be too hard.

[Marcaek]

I think a specialized error message instructing the user to clear cvars from their config would be helpful for mods that have cvar conflicts. Not everyone is going to know what to do when they can't join a server.

[Hypnotoad]

If it hasn't been mentioned already, it would be extremely useful if server configs could override anything defined in CVARINFO. I really wanted to use cvarinfo in my mods, but because it causes conflicts with the server config (at least it did last time I tested) I have little use for it currently for anything multiplayer.

[ibm5155]

you could set each player's cvar using clientside, so the server would have a diferente cvar than players (but, unfortnetly, there's no way to get that clientside data to server :( ) (if it's that what you mean).

Also, it would be nice if I could start a serverside script from a clientside script, this way I would be able to transfer clientside data to serverside :D
Also, I know my ticked got "ignored", but for that it would be nice to have a kind of global atribute, where it would sync the serverside atribute with the clientside atribute, so you don't need to pass a limited number of atributes with acs_execute to update the clientside atribute (that would be nice for my old flappy lost soul mod, where the clientside script must have an updated player list in order to show it on screen, it's a nice way to save internet packets, since functions like print or hudmessage tend to abuse from internet packets over some fast loop.

as example I'll show an example code below

Code: Select all

global int X;//maybe sync is a better name

script 1 open{
 delay(5);
 X=1;
}

script 2 open clientside{
 while(true){
  print(d:X);
  delay(1);
 }
}

OUTPUT:0 0 0 0 0 1 1 1 1 1 1 1 ...

OUTPUT without sync: 0 0 0 0 0 0 0 0 0 0 0 0 ...

in this case, idk what would happen if a clientside tries to modify X, it maybe could result in

Code: Select all

global int X;//maybe sync is a better name

script 1 open clientside{
 delay(5);
 X=1;
}

script 2 open {
 while(true){
  print(d:X);
  delay(1);
 }
}

OUTPUT:0 0 0 0 0 1 1 1 1 1 1 1 ...
or
OUTPUT: 0 0 0 0 0 0 0 0 0 0 0 0 ...

[KenFH]

Sounds like a ZDoom issue to me. Is this any different there?

Don't know, but considering part of Zandronum's point is better handling of multiplayer, and thus server-related features get less priority there, whereas Zandronum has a substantial and hopefully growing community of actual, long-term servers, I really don't think that's relevant. Especially since, from a server operator's perspective, the feature was better left unimplemented than implemented as it currently stands, and at least some modders are avoiding the feature as a result, while some server operators are less inclined to host mods that DO use it and therefore run into this problem. That's not a good situation whether zdoom remains broken or not.

I backported this more than a year ago and AFAIR this is the first time somebody complains about this limitation. So it looks like not many have such a strong opinion about this.

See the post above mine, which never got a reply, particularly:

edit2: As for the config thing, is CVARINFO handled before +exec lines? If not, there's the issue.

Also, talking about it among various server communities (e.g. Best-Ever, TSPG,) it's been a noticed, annoying problem with various mods for quite some time. However, as with above unreplied-to post, it seems to get blown off as a zdoom problem, and that itself is part of the problem. Another part would be the apparent widespread misunderstanding of what's going on and why it's a problem.

Bottom-line: It is impossible (literally impossible) to actually change variables that are specified in CVARINFO at cfg-time in a typical long-term server as-is. The best you can apparently currently do is, every time you bring your server up, manually sign into rcon AFTER it starts up and manually change every single variable you need changed. With a typical setup like best-ever, etc, that's pretty time-consuming compared to a normal server reload process for e.g. Quake, Unreal, etc. The only other server-owner alternative seems to be ripping the CVARINFO lump out of the wad and hosting that version, which would be very clunky; a patch wad wouldn't be able to remove the error. This wasn't the case before CVARINFO was ported over because it would just get ignored and you could actually successfully set the vars from the server .cfg file, which is how pretty much every other multiplayer game with servers works.

There are plenty of possible solutions here, the best of which might be to change the error to instead actually use the value the server admin set (which is what would be expected behavior.) Another would be to provide a way to get commands from the .cfg run AFTER W_Init and the rest of the startup code, and publicize it as a solution to this problem. Another would be to just make the error not prevent the server from running, though that would still leave it impossible to set the variables in the .cfg. Yet another would be to not parse CVARINFO. And another would be for mods to simply avoid CVARINFO like the plague, at least until it's fixed, which is what I'd recommend to mod authors for now, as in

If it hasn't been mentioned already, it would be extremely useful if server configs could override anything defined in CVARINFO. I really wanted to use cvarinfo in my mods, but because it causes conflicts with the server config (at least it did last time I tested) I have little use for it currently for anything multiplayer.

[Sean]

Also, it would be nice if I could start a serverside script from a clientside script, this way I would be able to transfer clientside data to serverside :D

Have you looked into RequestScriptPuke?

[Torr Samaho]

Let me try to summarize so that the important points don't get lost between walls of text:

• Not being able to set the value of CVARINFO defined with +exec is a strong limitation.
• This limitation is not restricted to the server, you can't do this to start a single player game with your preferred settings either.
• The limitation is inherited from ZDoom.

So, first one should check if this is still not possible in the latest ZDoom dev version. If this is not the case, I can backport what ZDoom did to lift the limitation. If ZDoom still has this limitation, somebody should make a feature request at ZDoom to lift the restriction. If ZDoom changes this, I can backport their change. If ZDoom insists on keeping he limitation, we can discuss whether Zandronum can deviate from ZDoom here based on ZDoom reasoning on keeping the limitation.

[Sean]

It works in ZDoom. I can sat CVARINFO CVars from a .cfg file.
I'll try and find the exact point where this was added...

Might be this? I think it is, but I have no idea :|

[ZzZombo]

https://github.com/rheit/zdoom/commit/3 ... 85d346cdf1
https://github.com/rheit/zdoom/commit/f ... b6a135ee27
https://github.com/rheit/zdoom/commit/4 ... 169ccc4d3b

But, will you release a new 2.x version for this?

[KenFH]

Let me try to summarize so that the important points don't get lost between walls of text:

• Not being able to set the value of CVARINFO defined with +exec is a strong limitation.
• This limitation is not restricted to the server, you can't do this to start a single player game with your preferred settings either.
• The limitation is inherited from ZDoom.

Actually, the limitation IS effectively limited to the server, as for SP, normal practice is instead to rely on the ini, which CAN load the variables in question, probably due to special, or at least different, handling. But with typical server farms, you instead don't have access to that method; there isn't even a way to upload a cfg to exec via rcon since the path to the cfgs is not known, and you can't put arbitrary commands on the commandline, either. That situation accounting for probably a majority of Zandronum servers hosted, it's the most important to address. Who would use +exec .cfg from the commandline to play singleplayer?

Either way, someone seems to have isolated fixes aimed at addressing the problem in the zdoom codebase - surprising, but there it is.

Side note: Using the map command in a cfg to set the initial map when not using a map rotation does not work (silent fail) on Best-Ever or TPSG; instead it always goes to MAP01 or E1M1. Changemap doesn't work either because it does nothing unless a map is already loaded when it runs.

[ibm5155]

Also, it would be nice if I could start a serverside script from a clientside script, this way I would be able to transfer clientside data to serverside :D

Have you looked into RequestScriptPuke?

didn't knew about this one :O
well, too bad it's limited to only net scripts :(, but, I could generate some security code that would block any kind of user puke

[Torr Samaho]

https://github.com/rheit/zdoom/commit/3 ... 85d346cdf1
https://github.com/rheit/zdoom/commit/f ... b6a135ee27
https://github.com/rheit/zdoom/commit/4 ... 169ccc4d3b

This was actually no the end: https://github.com/rheit/zdoom/commit/6 ... cb0e4193d1

I ported all of this to 3.0, so this should work as intended now, but needs to be tested carefully.

But, will you release a new 2.x version for this?

Right now it's no even decided whether there will be another 2.x release at all.

didn't knew about this one :O
well, too bad it's limited to only net scripts :(, but, I could generate some security code that would block any kind of user puke

It's crucial that clients can only puke net scripts. Otherwise a malicious client could arbitrarily execute scrips on the server.

Side note: Using the map command in a cfg to set the initial map when not using a map rotation does not work (silent fail) on Best-Ever or TPSG; instead it always goes to MAP01 or E1M1. Changemap doesn't work either because it does nothing unless a map is already loaded when it runs.

If this still is a problem in 3.0 with the backports I did today, please open a tracker ticket for this issue.

[ibm5155]

didn't knew about this one :O
well, too bad it's limited to only net scripts :(, but, I could generate some security code that would block any kind of user puke

It's crucial that clients can only puke net scripts. Otherwise a malicious client could arbitrarily execute scrips on the server.

A malicious user will Always find a way to exploit things, I still remember two cases, one was on bagel horde (also it was on zombie horde mod, but it got more evidente in bagel horde).
There was the invuse command that would give you a random item, but, if made something like invuse;invuse;invuse;invuse;invuse;... It would give you n itens...

Also on mortal kombat made by doomero, he made all the scripts of type net, he didn't knew the real use of the net, but soon, people discovered he did that and boom, the mod ended up in a mess abuse.

In this case, I could make a simple way to call another script by clientside, I would just need to make a clientside make a call to a net script, and that net script would redirect the call to another script from type void without net like

Code: Select all

script 1 (int arg1,int arg2,int arg3) NET{
 acs_execute(arg,0,arg2,arg3);
}

This is the kind of code that I'll actually use, but since, I know there're malicious users, I'll just add a "man in the middle" like code where it would filter users calls from script calls doing some security stuff

TO BE EDITED .