how can this change cause that bug?

[davidlallen]

So, I uploaded my first XCOM2 mod today and immediately got bug reports. I can't figure out how the change I made could have caused these problems.

 

http://steamcommunity.com/sharedfiles/filedetails/?id=628798650

http://www.nexusmods.com/xcom2/mods/328/?

 

 

I have overridden the XcomCharacterCustomization class which is used to display the soldier customization panel. I made one global search and replace change. Whenever BodyPartFilter.FilterBySomethingAndSomething is called, I changed it to call FilterByGender only. This way, all armors including civilian and specialized (eg, Bradford and Tygan) can be equipped.

 

That is the only change I made. Because all these functions use private variables I had to override the whole class. I have attached the changed file; you can diff it against the original to see what I mean. There doesn't seem to be any other way to make this change, since subclasses can't access private variables in the parent class.

 

As a result of this change, the color palettes are all displayed as black, as you can see in these two pictures. (I hope.) In the first picture, the color chooser palette is just black. It still works; that is, you can see the soldier's hair color change to the right values as you mouse over the different sqares even though you are mousing over black. In the second picture, the current primary armor, secondary armor, hair and eye colors should be filled in but they aren't. Furthermore, dragging with the left mouse no longer rotates the character.

 

http://imgur.com/o4usnFM

http://imgur.com/wpUT1B4

 

How else can I make this change? Or, how can the change that I made cause these two problems? Any help will be greatly appreciated.

[davidlallen]

I cannot figure out why other classes can be replaced without side effects, but replacing XComCharacterCustomization has these side effects. Could it be because another class specifically calls "new" on the original class and keeps a static reference to it? See XComPresentationLayerBase.uc, where it does:

 

new(self) class'XComCharacterCustomization

 

If that is getting a static reference to the original class, but the rest of the game is using my subclass, that may explain why parts of the subclass dialog are not working. But, this is just a guess. A one file mod really should not be that hard.

 

I'm afraid I need Amineri/FxsRMcFall, but once I figure it out I can put it in a guide.

[kosmo111]

Well I don't know for sure, but I could imagine part of the issue might be that some of these fields may not be designed to allow the parts returned by your new filter. Voicepacks for example.

 

Now XCom may be smart enough to only look for voicepacks that soldiers can use, or maybe the filters were designed with that intent in mind. I'm sorry I don't have a better answer, but I wouldn't be surprised if those filters are somewhat required to get stable output (without other changes that is). I would try swapping the fliters line by line and see which one is causing you issues-- maybe you just need to use the default filter for a few options.

[davidlallen]

I am not sure if you looked at the screenshots in the OP. The color palette chooser now comes up all black, instead of with the preview colors it has normally. This can't be related to whether particular fields don't accept certain parts.

 

Your suggestion of reducing the changes one by one is an interesting idea. Actually what I will try (in ~6 hours from now) is to compile the script with *no* changes. I am pretty sure that if I simply extend the class, while changing *nothing*, this same problem will happen. That is, I bet that any subclass of this main class will cause the same failure.

[kosmo111]

I saw the screenshots, and its possible that this will always happen. That being said, you may be surprised by the sorts of undefined behavior that can occur when something is technically allowed but unexpected. Especially if it ends up being an issue somewhere in the native code.

 

Hope you are able to narrow it down.

[davidlallen]

 

 

That being said, you may be surprised by the sorts of undefined behavior that can occur when something is technically allowed but unexpected.

Not anymore :-)

[FxsRMcFall]

Looking at your override class, my off the cuff guess is that you did not remove config vars from your override class. The one that looks like it might have an effect is "UIColorBrightnessAdjust". Config vars that don't have an assignment in the INIs default to 0.

 

In general leaving variables that conflict with base class vars is bad, but in some cases due to data hiding we might not have left you a choice. If your change is limited to just the methods that specify the body part filter delegate, I would recommend only overriding the methods that use that field. Let inheritance handle the rest.

[davidlallen]

Thanks! That was definitely part of the problem. There is a variable:

var const config float UIColorBrightnessAdjust;
Removing that line from my copied class file solved the problem shown in the screenshots. But, two more points.

 

a. That doesn't solve all the problem. There are a number of veteran only menu choices, such as Attitude, and some of the pattern and facepaint submenus. Even for an experienced character, these are greyed out when my mod is active, with the tooltip that says "Gain more experience to use this option". There aren't any other config type variables. I tried replacing the two references to IsVeteran() in the class with just true, but that did not help. Can you suggest how to fix this part?

 

b. I want to explain why I did it this way. You probably know the complaint. This class and many other classes are full of private variables. Private variables aren't available to subclasses, and therefore, any function which refers to the private variables can't be subclassed. I spent a few hours trying to figure out which functions I could subclass and which not; but it is so frustrating that eventually I gave up and copied the whole thing. For classes which will be modded, can you please limit the use of private variables, or even better, use the standard OO technique of getters and setters? This way, I don't need to access the private variables in my functions and I can just extend the few functions I want.

Edited February 23, 2016 by davidlallen

[eXecator]

Have you tried leaving the XComCharacterCustomization alone and to override the X2SimpleBodyPartFilter class? I image you could get the desired result from overriding the offending filter functions.

[davidlallen]

Thanks for the suggestion. That leads in a different bad direction. The X2SimpleBodyPartFilter class functions are also used by the rookie generator. So, if I change those class functions, then rookies wind up wearing the civilian or advent armor. The original mod took that approach, and all the users complained of this. So I need to affect the character customization dialog only.

 

Any suggestion for a different approach, which doesn't affect rookies, would be welcome. I am out of ideas.