[3.6.0] CVar.GetCVar...Set* not saving to ini?

[Matt]

Here's the relevant test ZScript:

Code: Select all • Expand view

class Loadout1Butts:CustomInventory{
    states{
    pickup:
        TNT1 A 0{
            A_Log(cvar.getcvar("hd_loadout1",player).getstring());
            cvar.getcvar("hd_loadout1",player).setstring("butts");
            A_Log(cvar.getcvar("hd_loadout1",player).getstring());
        }stop;
    }
}
class Load20Boobs:CustomInventory{
    states{
    pickup:
        TNT1 A 0{
            A_LogInt(cvar.getcvar("hd_load20",player).getint());
            cvar.getcvar("hd_load20",player).setint(80085);
            A_LogInt(cvar.getcvar("hd_load20",player).getint());
        }stop;
    }
} 

and CVARINFO:

Code: Select all • Expand view

user string hd_loadout1="";
user int hd_load20=0;

Expected:
Typing "give Loadout1Butts" the first time will output

Code: Select all • Expand view


butts

and all subsequent give calls will output

Code: Select all • Expand view

butts
butts

Actual:

Typing "give Loadout1Butts" the first time in every new session will output

Code: Select all • Expand view


butts

but will work fine for the rest of that session alone, even if I start a new game.

Same thing with the integer version, mutatis mutandis.

Also if I give this item and then check the cvar's value from the console, the console will return the original value even though the CVar...Get* function will return the new value.


I have only tried this in Debian, in case this is an issue with where the ini is stored on a given OS.

[Matt]

This is not restricted to CustomInventory pickup calls, as the same thing happens with the following:

Code: Select all • Expand view

class Loadout1Butts:Inventory{
    override void attachtoowner(actor other){
        super.attachtoowner(other);
        other.A_Log(cvar.getcvar("hd_loadout1",other.player).getstring());
        cvar.getcvar("hd_loadout1",other.player).setstring("butts");
        other.A_Log(cvar.getcvar("hd_loadout1",other.player).getstring());
        destroy();
    }
}
class Loadout1ButtsW:Weapon{
    default{weapon.slotnumber 1;}
    states{
    select:
        TNT1 A 0{
            A_Log(cvar.getcvar("hd_loadout1",player).getstring());
            cvar.getcvar("hd_loadout1",player).setstring("butts");
            A_Log(cvar.getcvar("hd_loadout1",player).getstring());
        }
        TNT1 A 1 A_Raise();
        wait;
    deselect:
        TNT1 A 1 A_Lower();
        wait;
    fire:
        TNT1 A 1;
        TNT1 A 0 A_Refire();
    ready:
        TNT1 A 1 A_WeaponReady();
        wait;
    }
}

[Graf Zahl]

Please post a runnable example, not script fragments.

[phantombeta]

The problem seems to be with GetCVar. Using FindCVar, setting CVars works fine, but GetCVar doesn't seem to actually set the CVar properly.

[Matt]

The script fragments in the OP were sufficient to be run once placed in zscript and cvarinfo files, but here's everything from both posts.

[Graf Zahl]

The problem seems to be with GetCVar. Using FindCVar, setting CVars works fine, but GetCVar doesn't seem to actually set the CVar properly.

The problem is with user CVARs. Please don't ask me what this was supposed to achieve, the code is all Greek to me. It only appears to save the global reference CVAR for these, which of course is empty.

But since I don't even understand half of this stuff and the other half appears to be somewhat broken and ill-conveived I am passing on this one.
In my opinion the entire user CVAR feature needs to be excised and dumped into the deepest bowels of hell, because it's so poorly implemented.

[Rachael]

The idea behind user CVARs is to allow every player in a multiplayer game to have their own independent setting of a CVAR. Like server CVARs, each player's copy is sync'd to every other player, and therefore any CVAR that is marked such is suitable for both demos and multiplayer. Allegedly, in order to call a user CVAR in ACS, the player has to be the activator. I am not sure how it's supposed to work in ZScript, ideally it would be something like "GetPlayer(0).GetCVar("some_user_cvar").Set("whatever")"

Things this is good for, particularly, are player-defined preferences, such as player control, visuals, vanity, etc.

[Graf Zahl]

I wasn't talking about what this is used for but how it is implemented. The entire CVARINFO feature doesn't look fully thought through and suffers from several problems as a result.
It's like building a house without a solid foundation. This actually is a property of several things that were just added because people "needed" them.

The biggest problem, of course, is that it was shoehorned into the INI save format without giving it any useful structure at all. And user CVARs are a story of their own when it comes to this.

[Rachael]

This actually is a property of several things that were just added because people "needed" them.

That describes much of GZDoom at this point. >_<

The biggest problem, of course, is that it was shoehorned into the INI save format without giving it any useful structure at all. And user CVARs are a story of their own when it comes to this.

This has always needed fixing, in my opinion. There is no reasonable way that loading all CVARs from all mods has ever made sense to me.

[Graf Zahl]

Yes, and for the second one there is an open report. The main problem here is that I have no idea how to manage configurations that are both local to a mod but share other parts with more global settings.

This gets particularly bad if multiple mods with custom settings are loaded on top of each other.
It's like I said, the system was never really thought through. The feature was just implemented without ever bothering with the consequences.