You can use a Harmony prefix in the property getter ofI just discovered that for multiple mods which assign
UIConfig.DoNotUseGeneratedPrefabs, the value of the last mod in the load order will be used. This will cause conflicts with other mods higher up in the load order which have a different value for
UIConfig.DoNotUseGeneratedPrefabsthat will block any further attempts of editing the property as a workaround
Understandable.Some of the issues with switching between XML and generated code in the same movie are,
1. The code gen doesn't work like that. The generated code needs to have/know all the types and instances while generation. Essentially it needs to say "this string variable in this TextWidget is binded to this string variable in SPInventoryVM(for example)". And it needs to say this like "_textWidget.Text = _dataSource.HeroLabelName" for example. So it needs to know the specific type, instance and variable name. If it cannot know it, needs to get it in runtime, and that's reflection, what we're trying to avoid. So it goes from most parent to bottom, not individually separate.
2. The generated code needs to have direct references to the instances it is creating. Since it needs to add children, set it's ids, set it's visual properties like Size, Sprite etc. So it needs to say, "Ah, I'll be adding a TextWidget FooBar and it's size is this, it'll have this as a Brush and it'll have this amount of Children etc." Changing that into a different widget with an overriding xml and adding new children or changing it's type, will break other references to FooBar and it's children. In the generated code FooBar might have 3 children and a widget higher up might be referencing it's second child like
HigherUpWidget.WantedChildWidget = WantedChildWidget as ListPanel;
So even though the FooBar and WantedChildWidget is overriden from the xml, they're referenced in the code. This will result in an error.
There are more issues like these but I don't want to make this post too long.
It boils down to the auto generated Widgets being the smallest units of UI modification.Currently they're separate. The code is generated from the XML but after that there is no connection between the two. We cannot use XML in generated code and generated code cannot use XML.
Agree.This will still be the case if we only used the xml. Since if we change related stuff in the xml like type names, hierarchies, Brush/Sprite names etc.(depending on how the mod accesses/modifies them). If there are no changes to the xml, there will be no changes in the generated code.
Yea, it wasn't checked whether it's needed to do the switching to XML in cascade. This will complicate things, because we'll need to know the affected Widgets all the way down.I'm not sure what you mean with this. The code is generated from the xml and it goes through multiple automated generation stages before the deployment. So neither the xml or the generated code is outdated. I think this is happening not because the "SettlementNameplates" xml's content is different than the generated code, it's because only the "SettlementNameplate" is using the xml and the rest of the game is using the generated code.