That is a string and not some int and it does not get parsed to that either in code. PhysicalPhenomena.xml has a few objects that get used for such things and "AcidGas80" is one of them with gas density 80. The breath is merely using an object blueprint from the xml.

You can use "AcidGas" and change the "Density" attribute of the "Gas" part of it to get what you want.

Ty, figured it was just a string name but wasn't sure if there was some funky parsing I wasn't seeing going on, also had no clue where it was from since I didn't know what the PhysicalPhenomena file was for.

Originally posted by The_MixMaster™:

Ty, figured it was just a string name but wasn't sure if there was some funky parsing I wasn't seeing going on, also had no clue where it was from since I didn't know what the PhysicalPhenomena file was for.

A lot of things are written in the XML as blueprints, probably so it is easy to create new things and change values without having to get into the code. XML modding is basically the first step for many people who get into modding Qud afaik and you can do quite a lot with it.

A lof of "things" are not directly coded in C# but in XML and C# then uses those blueprints for the gameworld or the things with mechanics attached to them that are actually in the code. Anything extended from something "basic" (like a gas) is usually not in the C# code, but you can still manipulat the created object in there.

So what is public override string GetGasBlueprint() => "AcidGas80"; doing anyway? I understand it's pulling the AcidGas80 part from the xml file, but in the parent class it's just an empty lambda function that doesn't seem to have any code attached to it anywhere else?

Originally posted by The_MixMaster™:

So what is public override string GetGasBlueprint() => "AcidGas80"; doing anyway? I understand it's pulling the AcidGas80 part from the xml file, but in the parent class it's just an empty lambda function that doesn't seem to have any code attached to it anywhere else?

Where are you even finding that? In my CorrosiveBreather there is:

That is not doing any pulling form XML, but simply sets the string for any child class of BreatherGas child class, so the base class can use that returned string. The parent class has the virtual method GetGasBlueprint() that expects the children to overwrite it. That method is e.g. used in BreatheGasInCell(), which passes the returned string to Cell.AddObject().

The XML pulling stuff happens after that call, which uses GameObject.Create() with a string (and other stuff) to create GameObjects via a factory method from said blueprints found in the XMLs. There are a couple of places that uses that GameObject.Create() to create stuff from XML blueprints and many things just have some string written to be used by that factory method.

The GameObject itself is really only created when you use the ability and it fills cells. Before that it does not exist and there is only some string to be used to find the blueprint. If you want to change the density per code and do not want to create some blueprint in the XML, you got to change the parameters after that GameObject is created.

That Gas object e.g. has Density that you can change, though how it is currently used you would need to change the creation, since it is directly added to the cell. The Cell class has another AddObject() that uses an already created GameObject instead of a string to create one, so you could create one yourself, change its parameters and then add it to the cell instead.

Ah my decompiler is just making things harder for me then it looks like. Seeing what it's supposed to be, it now makes sense. Ty.

The acidgas override you've posted is basically the same thing written differently, but if the base class has no code using the method that is pretty weird. Does showing method calls not work in your decompiler?

The base class had it used, I just expected that if it was going to return a value then it would take that value as a parameter instead of just overriding the value inside via polymorphism or something.

It looks very much like an "abstract" method that is supposed to be overwritten and just returns "null" so the methods using it have some catch for that. There is just no "base gas" that is used and it always expects the children to provide their own gas name for creating those gases.