Page 1 of 1

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

PostPosted: Fri Nov 09, 2018 11:25 am
by Matt
Here's the relevant test ZScript:
Code: Select allExpand 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 allExpand view
user string hd_loadout1="";
user int hd_load20=0;


Expected:
Typing "give Loadout1Butts" the first time will output
Code: Select allExpand view

butts

and all subsequent give calls will output
Code: Select allExpand view
butts
butts


Actual:

Typing "give Loadout1Butts" the first time in every new session will output
Code: Select allExpand 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.

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

PostPosted: Sat Nov 10, 2018 1:03 am
by Matt
This is not restricted to CustomInventory pickup calls, as the same thing happens with the following:
Code: Select allExpand 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;
    }
}

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

PostPosted: Sat Nov 10, 2018 1:12 am
by Graf Zahl
Please post a runnable example, not script fragments.

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

PostPosted: Sat Nov 10, 2018 1:13 am
by 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.

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

PostPosted: Sat Nov 10, 2018 1:59 am
by 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.

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

PostPosted: Sat Nov 10, 2018 2:24 am
by Graf Zahl
phantombeta wrote: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.

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

PostPosted: Sat Nov 10, 2018 3:46 am
by 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.

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

PostPosted: Sat Nov 10, 2018 4:09 am
by 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.

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

PostPosted: Sat Nov 10, 2018 4:20 am
by Rachael
Graf Zahl wrote:This actually is a property of several things that were just added because people "needed" them.


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

Graf Zahl wrote: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.

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

PostPosted: Sat Nov 10, 2018 4:39 am
by 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.