Toolbox technical questions here, please

[davidlallen]

I suppose we will make another thread like this one:

https://forums.nexusmods.com/index.php?/topic/3912666-2016-03-17-patch-sdk-changes/

[Zyxpsilon]

Hey -- did Abeclancy actually made that Git-Repository transfer of the OrigSRC Class-Files from the Feb 5th initial release??

[abeclancy]

Hey -- did Abeclancy actually made that Git-Repository transfer of the OrigSRC Class-Files from the Feb 5th initial release??

 

Not yet, though I still have all the files on hand ready to go! I think I might just go and do it, though I might ask FxsRMcFall if I can, or if there is some sort of copyright notice they would like displayed on it. It would just be so nice to have all the changes layed out for everyone!

[davidlallen]

I am not a lawyer, but I *highly* recommend getting a specific email/forum post/something from a fxs dev saying it is ok. (Personally I highly doubt they will grant it, but maybe I am wrong, and they don't mind having all their source code online for any competitor to see.)

 

EDIT: the patch isn't live yet afaik, but here is a thread to discuss about it:

 

https://forums.nexusmods.com/index.php?/topic/4112090-2016-05-12-patch-sdk-changes/

Edited May 12, 2016 by davidlallen

[johnnylump]

Yes, so we can maintain a semblance of keeping this on topic, please take further discussion of the patch to another thread. Thanks.

[Zyxpsilon]

Sorry for Hi-Jacking the LWS-Toolbox thread, JL... this patch "switcharoo" for AH-DLC activation has everyone (modders) on the edge of their seats! :wink:

 

Back OT.. any plans on a more "modular" Toolbox, btw.

 

For example, there are some gameplay features "changes" (12 Men Squads being the major aspect that actually broke other LoadOut mods, at least in principles) along with the core Mod-Options + Tuple context that (IMHO) should be somehow isolated from each other.

Edited May 12, 2016 by Zyxpsilon

[Amineri]

Sorry for Hi-Jacking the LWS-Toolbox thread, JL... this patch "switcharoo" for AH-DLC activation has everyone (modders) on the edge of their seats! :wink:

 

Back OT.. any plans on a more "modular" Toolbox, btw.

 

For example, there are some gameplay features "changes" (12 Men Squads being the major aspect that actually broke other LoadOut mods, at least in principles) along with the core Mod-Options + Tuple context that (IMHO) should be somehow isolated from each other.

 

If you mean "Are we going to break Toolbox into 4 or 5 separate mods?", then we have no plans to right now. Managing 7 mods is enough for me ... that's a lot of possible combinations to troubleshoot, plus a lot of different forums to keep up with, and mods to update with patches.

 

In terms of separating out the class overrides, arguably the UI changes to support 12 soldiers in squad select is one of the core features. Unfortunately, there's no option at run-time to enable/disable class overrides in the general case. Where I've been able to, I've avoiding using the class override system in favor of extending the class and swapping it run-time (PerkPack actually will support this option). Unfortunately UISquadSelect is triggered in such a way that run-time swapping of the UIScreen class just isn't possible -- otherwise I would have done so on the LeaderPack.

 

The Tuple thing is isolated -- we made it a separate mod script package for that very reason. The ModOptions was another case like SquadSelect -- called from too many places and in ways difficulty to intercept to swap in a new one at run-time.

[Zyxpsilon]

Gotcha.. it's a rational technical hurdle which has more obstacles to "adaptative" solutions than meets the un-informed eyes like mine.

 

I guess, the only other way to maintain compatible Mods directed (in particular) to SquadSelect duties falls on the shoulders of whomever has already tackled extensive variations of these HUD assets (ShowMeTheSkills by ²²², being just one essential i enjoy having).

 

When it comes to overrides.. i'm at a lost for precisions while the mystery of magic phrases used by many people to qualify their own mods (( NO overrides have been used! )) pushes that reasonable frustration even further more.

 

Oh well. If only i had 25 years less on the counter -- i could possibly start learning HOW to properly code my ideas.

[Amineri]

I'll try and explain it in simple terms :)

 

As an example, I'll mention a couple of things coming up in PerkPack, which I was able to implement without so many explicit class overrides. However, I still needed to provide some measure of the functionality needed.

 

There were two particular cases where this came up :

1) UIArmory_Promotion -- the thing that displays the perks. We're going to have a lot more perks, so I built a new perk tree. Probably not a big surprise :)

2) Ability bar -- with more abilities (like from LeaderPack, etc), we're crowding the 15 ability limit. So we needed some solution handle 16+ active abilities on a soldiers.

 

In both of these cases I I built a solution that swaps out the relevant class at run-time, rather than using the built-in class override system. What's the difference?

 

1) Built in class override.

This is built into the game Engine itself. It's not code that resides in XComGame.upk, but in Engine.upk and Core.upk -- these are Epic's Unreal Engine packages that Firaxis has altered. What happens is that they overrode the Spawn and new functionality, so that when code requests to create one type of class, it actually builds another (child) class instead. Neat, and it effectively changes all instances where it's created, for those places in code that are hard to get to.

 

The problem is that only one mod can override in this fashion, and there's no clean way to disable it, save requiring your player to go into and edit config files -- messy.

 

2) Replace the calling instances.

This is more similar to what I did with LeaderPack, which has no explicit overrides (but does so indirectly at run-time). For PerkPack and the ability bar, for instance, instead of an explicit class override like above, I use a listener that listens for the UITacticalHUD to be created, then digs into that and finds the UITacticalHUD_AbilityContainer, and swaps it out for my customized version. The advantage here is that I can use an in-game configuration menu to turn that off and revert back to "default". Which can be either the base-game version, or one supplied by another mod.

 

In all the cases where I can, this is what I do. However, in some cases option 2 isn't available, either because the code where the class is created is buried someplace inaccessible (like SquadSelect) or there are just too many places that call it. In that case I either have to resort to option 1, or abandon the functionality.

[Zyxpsilon]

See, this is exactly the kind of acute details & principles that only super-coders (like you) can grasp enough to give some rational powers over any serious attempts at making gimmicky solutions worth inclusion in whatever Mods.

 

In theory (from a long gone past of Cobol school times for me), the inherent difficulties with compiled resources is that THEIR "static" design can only go thus far within conceptual customization. We can only strike at available code structures (++) and nothing else. The good lessons to get from XC2 (scripts & all) is that certain features aren't really obvious to the "common man" and that even Unreal Engine also has its own specific methods (which are again adapted to Firaxis plans), IMO.

 

Hacky Class Overrides included! ;)