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

These bugs do plan to be resolved, when they can be.

Moderator: GZDoom Developers

Post Reply
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

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

Post by Matt »

Here's the relevant test ZScript:

Code: Select all

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

user string hd_loadout1="";
user int hd_load20=0;
Expected:
Typing "give Loadout1Butts" the first time will output

Code: Select all


butts
and all subsequent give calls will output

Code: Select all

butts
butts
Actual:

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

Code: Select all


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.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

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

Post by Matt »

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

Code: Select all

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;
    }
}
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

Please post a runnable example, not script fragments.
User avatar
phantombeta
Posts: 2084
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

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

Post 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.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

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

Post 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.
Attachments
bb.zip
(686 Bytes) Downloaded 243 times
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post 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.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

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

Post 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post 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.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

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

Post 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post 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.
Post Reply

Return to “On Hold Bugs”