after hotfix, some sdk uc files don't compile !?

[hairlessorphan]

 

The private variable thing, honestly, is halfway our own fault.

 

I'm not sure it is "halfway". Maybe 10% :-). For the 3-4 classes I have tried to modify, this happens every time. I want to extend one function. It uses a private variable. I attempt to cleanup by making this variable not private. That affects two other functions. One of those functions uses a different private variable. The whole thing snowballs. After an hour I throw up my hands and copy the whole class.

 

From the unrealscript reference: Native Indicates that "this class uses behind-the-scenes C++ support".

 

These classes are guaranteed to be unmoddable. If a modder is interested in modifying such a class, they should immediately abort and choose a different approach, which doesn't touch that class. Is that correct?

 

 

That doesn't sound correct to me. I think it's more like: this class has a dependency on native (not scripted) code. If you choose to extend this class, you will either also take on a dependency to native code (which will behave in ways unknown to you, because you don't have the source or documentation), or you will have to re-implement the stuff the native code did, which may not be possible.

 

Proceed with caution.

 

I will absolutely blame Fxs for not really giving us a strong, extensible API. It turns out, though, that doing that kind of thing is hard. And the naive approach (which Fxs chose) is to say, "well, we'll just let modders override classes wholesale; in theory that gives them access to everything without forcing us to write safe API's to everything" (Amineri has referred to this in her scripts as, "the nuclear option"). But that approach comes with exactly the pitfalls you're coming across now, and this is why it's considered "naive."

 

Knowing this, if we (modders) choose to take that on, and then we step on a mine, that's halfway our own fault.

 

TL;DR: the SDK, as-is, makes it easy to change about 10% of the things we want to change, and it makes it possible but dangerous to change about 90% of the things we want to change. If we wanna try anyway, that's on us.

[eXecator]

 

[...] the SDK, as-is, makes it easy to change about 10% of the things we want to change, and it makes it possible but dangerous to change about 90% of the things we want to change. If we wanna try anyway, that's on us.

 

 

Sounds about right. Of course there are different levels of dangerous. And while we are long march away from an ideal API, we are still in a comparatively save spot to what other modding endeavours might have faced.

 

I suspect that many of the things that we want to change will get 'best practice' solutions in the near future.

[davidlallen]

In general class overriding seems to be asking for trouble. I will always look for a way to extend and not modify in the first place. Hopefully most stuff can be achieved by adding/modifying Template instances.

 

I guess it depends what mod you want to make. If you want to add a weapon, templates are great. If you want to change the UI or game behavior, there doesn't seem to be any alternative.

 

In the OP, I am attempting to change one game behavior. Suppose I have a classed character (any non-rookie) and I put them into the character pool. Then, next game they show up from the character pool as a rookie. When they get promoted, their class is now random, which many people now find annoying. (Any nickname is most likely no longer class-appropriate, for example.) So I want to change the function that chooses the class when a rookie ranks up, to look in the character pool. If a character with that name is there, use the pool class instead of choosing.

 

This is not amenable to templates. Or if it is, I fail to understand how (which is certainly possible).

 

How would you do it? You can see BuildCharacterDeck and SelectNextSoldierClass in the classes in the OP.

[hairlessorphan]

 

In general class overriding seems to be asking for trouble. I will always look for a way to extend and not modify in the first place. Hopefully most stuff can be achieved by adding/modifying Template instances.

 

I guess it depends what mod you want to make. If you want to add a weapon, templates are great. If you want to change the UI or game behavior, there doesn't seem to be any alternative.

 

In the OP, I am attempting to change one game behavior.

 

 

The UI actually seems to be the most mod-friendly component of XCOM2, actually, due solely to the existence of UIListeners.

 

The thing to remember is you're not changing one game behavior. Once those vars are private, what you're actually doing is rearranging the internal gears of an entire class.

 

You could argue that this game behavior shouldn't require rearranging all the internal gears of this class. I would totally agree. But this is the script we've got.

 

This may seem like a semantic distinction, but I would argue that it's actually super important to accept this difference, because it prepares you for the difficulties that await.

[davidlallen]

OK, I would love to learn. In the game, there are multiple ways a character can be promoted but let's say we only want to affect the promote button in the after mission screen. If the character is a rookie, and his name is in the character pool, then I want to fetch the class from the pool and use that instead of letting the game assign one randomly.

 

I can write the code which looks in the character pool and fetches the class. OK, I can "steal" this code from the "character pool uniforms" mod on workshop :-)

 

How do I get in between the button press and the character configure screen where the rookie will be displayed with the new class?

[eXecator]

 

How would you do it?

 

 

I dont know. Haven't done anything in the UI yet.

 

Instead of changing the actual choosing-function maybe you can get away with being faster and having already promoted that rook using 'XComGameState_Unit'.RankUpSoldier( - , 'classOfYourChoosing' ). This might work if you can identify the leveling-up early enough.

[hairlessorphan]

 

 

How would you do it?

 

 

I dont know. Haven't done anything in the UI yet.

 

Instead of changing the actual choosing-function maybe you can get away with being faster and having already promoted that rook using 'XComGameState_Unit'.RankUpSoldier( - , 'classOfYourChoosing' ). This might work if you can identify the leveling-up early enough.

 

 

That would be funny. You could try to hook a UIListener to the after-action report screen's OnInit, iterate through the soldiers, and automatically rank up the ones that are in the character pool.

 

That would basically invisibly promote the soldiers. The player wouldn't have any in-game alert (well, maybe you could spawn your own custom UI window to tell the player), because in theory by the time the after-action screen started displaying the soldiers' stats, that soldier would not be eligible for a promotion anymore.

[davidlallen]

I am not sure I would call it "funny". A player may wonder why all four characters ranked up, but only two of them have the promote button, and why they changed weapons from the assault rifle they were just carrying to some other weapon. I want to hook after the promote button is clicked, before the character customization screen comes up. Maybe hooking something on the initialization of the customization screen? But how to hook the particular case that this is coming from the after mission screen?

[hairlessorphan]

I am not sure I would call it "funny". A player may wonder why all four characters ranked up, but only two of them have the promote button, and why they changed weapons from the assault rifle they were just carrying to some other weapon. I want to hook after the promote button is clicked, before the character customization screen comes up. Maybe hooking something on the initialization of the customization screen? But how to hook the particular case that this is coming from the after mission screen?

 

I don't know if you can (easily). That may not be something exposed by the existing API.

 

The hard way, I'm guessing (without the code in front of me), would be something like:

 

1) create a new GameState object that will cache info for you

2) hook a UIListener to the After-Action screen that replaces the Promote button with your own Promote button that looks exactly the same and calls the same events, except it ALSO sets a var in your custom GameState object that says, "I am coming from After-Action!"

3) hook a UIListener to the Soldier customization screen that reads from the custom GameState object. If var == "I am coming from After-Action!", then set var == null and do the character pool search and promote.

 

A lot of code. Not even sure it would work, tbh.

[tracktwo]

IIRC you can extend native classes, but your subclass can't itself be native. Attempting to do so will crash the game because the engine will try to look up the corresponding native data structures for the class and of course not find any.

 

A lot of the existing game classes do this: there is a non native XComFoo class that extends the native class XComFooNativeBase.

 

But in general I agree with eXecator: never override anything except as a last resort.