how can this change cause that bug?

[eXecator]

Well that's unfortunate.

 

Maybe you can modify the X2SimpleBodyPartFilter in a way, that he will check if the soldier customization screen is open. Depending on if that's the case or not, he will act as usual, or like you want him to.

[davidlallen]

That is an interesting thought! Is there a one line function I can make from any scope, which will tell me whether a specific window is open?

[eXecator]

That's the part where I'm not of any help. I think I saw something somwhere which did something with top of screenstack or anything ;)

[davidlallen]

Yeah, me neither. :mad:

Edited February 25, 2016 by davidlallen

[davidlallen]

 

 

Maybe you can modify the X2SimpleBodyPartFilter in a way, that he will check if the soldier customization screen is open.

I could kiss you. Except, this is a public forum and that would be weird. Your suggestion works. This is a completely stupid way to mod, but it does work. The magic line is:

 

if (`SCREENSTACK.HasInstanceOf(class'UICustomize'))

 

I reverted the XComCharacterCustomization class to default, added this code in X2SimpleBodyFilter where needed, cleaned up the unwanted override from local XComGameEngine.ini, and it worked perfectly.

 

I'll go through the publishing steps tomorrow, but this is now working.

 

There is absolutely no reason the original code should have caused this problem. There has got to be something I am misunderstanding about the way class overrides work, or there is an actual bug in the game. How can overriding the whole class cause certain fields to display blanks? You can see this in post #1, which also includes the non-working single file mod.

 

The second screenshot shows all the fields at the top blank, such as name, kills, etc. So this data isn't being picked up. Once this data isn't picked up, then the screen thinks the character is a rookie (or at least, "not a veteran") so the veteran options are all greyed out. How can this possibly happen?

[eXecator]

Very nice!

 

 

This is a completely stupid way to mod, but it does work.

 

 

Agreed. I think we are quite deep in DesperationWonderland, but I guess thats XCom baby. :laugh:

[FxsRMcFall]

Catching up with this thread, the majority of these issues could be resolved by changing all our privatewrite vars to be protectedwrite. Since function call overhead is a huge issue, in unreal script the recommended best practice is to use type specifiers instead of getters / setters. Unreal script is a really old, really weird scripting language and inheritance can get tricky when you start hiding delegates fields, config vars, events, and other base class elements with your override class.

 

Luckily, the path forward is clear. It would be relatively simple to relax those type specifiers a lot to help everyone out.

[davidlallen]

I wasn't aware of this function call overhead. Is there a concept of "inline"? That would be another way to avoid overhead.

 

But TBH, I don't see how protectedwrite is messing me up. If my file has successfully overridden every call to the parent class via the ini file, then every call to the original parent class which sets a protectedwrite variable is setting *my* variable, and everything should work. How is the old parent class getting activated? It seems that some calls to set the local variables Unit and UnitRef must still be getting handled by the parent class, when they should all be going to my class. What have I misunderstood?

 

Also, previously you explained that my config values were not getting set by the ini file, and I could workaround that by removing my declaration of these two variables. That did solve part of the problem, but in retrospect, I don't understand that either. Why should the user need to worry about another ini file with a different name, just because I overrode the class? If I knew to provide this other file, how would they know to modify mine instead of the (no longer used) base one?

[FxsRMcFall]

Unreal script does not have an inline concept and does not have an optimizing compiler even if it did have one. Would be nice to have, but if we were going to go that far I'd rather just integrate another scripting language.

 

The type specifiers matter because I don't believe overriding class variables is well defined. I'm not actually sure on that because we never do it in our own code and I haven't dug into the VM to see what the expected behavior is. Our intended purpose for the override classes was for modders to use inheritance to modify behaviors / functions only and only define new variables in the new classes, which data hiding makes more difficult.

 

Regarding the config variables, they are set using INI sections with a this syntax: [<PackageName>.<ClassName>]. A new class (which you are creating) would require a new section to define its config variables. So, the reasons it was necessary are pretty specific to Unreal and how config files work / are cached internally.

[davidlallen]

Thanks for the info, sorry to keep driving this. Neither privatewrite variables nor lack of a config file explain the second problem I saw, where the soldier name and kill count are unset, as shown here:

 

http://imgur.com/wpUT1B4

 

Something is setting the unit variable in the original class, when it is supposed to be setting the variable in my override class. If I have missed this in your explanation, I apologize; please try one more time.