X2AbilityToHitCalc doesn't seem to affect anything for me

[GrimyBunyip]

I've been trying to edit various functions inside X2AbilityToHitCalc, namely finalizehitchance

but none of my edits seem to be having any effect on the game.

 

I tried disabling all mods besides the the one making the edit, and deleting the config folder.

I've also traced the function calls for finalizehitchance through other uc files, and it definitely seems like finalizehitchance should be called where I would expect it to.

 

I'm hoping to see if anybody has any thoughts why this might be the case.

[davidlallen]

Sorry if it's basic, but did you spread `log calls through your code to ensure it is being called, and check XComEngine.ini to make sure your overrides have survived the ini building process?

[GrimyBunyip]

Sorry if it's basic, but did you spread `log calls through your code to ensure it is being called, and check XComEngine.ini to make sure your overrides have survived the ini building process?

yes to both

log calls and redscreen calls never popped up, it's like the code isn't being called at all.

[GrimyBunyip]

what looks like is going on, is that I can call logs right before:

 

AbilityState.LookupShotBreakdown

 

LookupShotBreakdown is inside a native class (XcomGameState_Ability), so I can't drop any logs inside the native class.

 

what is odd, is that the native class still calls X2AbilityToHitCalc, which is NOT native

and any logs I put inside X2AbilityToHitCalc, or any other changes I make there, will not affect the game itself.

 

Is it just that code in native classes aren't reflected in the source code? Or I can't even indirectly affect native classes through other classes the native one calls.

[davidlallen]

I am not sure this is the same problem but it may be:

http://forums.nexusmods.com/index.php?/topic/3825825-how-can-this-change-cause-that-bug/page-3&do=findComment&comment=35403650

[Amineri]

My suspicion is that the problem is because you are trying to override a parent class.

 

There are 10 other classes that extend X2AbilityToHitCalc. X2AbilityToHitCalc itself is an abstract class :

class X2AbilityToHitCalc extends Object
	abstract;

so it's not even going to ever be instanced with new -- so the class override just isn't going to work.

 

The class override isn't an "automagical" fix it -- all it does is replace one type of class with another when the new or Spawn functions create class instances. It doesn't figure out how to make the other 10 classes that extend X2AbilityToHitCalc use your new version.

 

For example :

class X2AbilityToHitCalc_Hacking extends X2AbilityToHitCalc config(GameCore);

Fixing it at run-time to make the Hacking extension use your new override version would be a somewhat minor miracle ^_^

 

I'm not sure what a good solution is here, short of either a total overhaul replacement of XComGame.upk or doing class replacement on all 10 child classes of X2AbilityToHitCalc.

[aggies11]

As amineri said, it's likely to due with the specifics of overriding and how object inheritence etc all work.

 

A way I find helpful of thinking of it. X2AbilitytoHitCalc.uc is actually NEVER used by the game. What it is is a specification for a "generic" kind of toHitCalc object, a blueprint if you will.

 

It's actually the CHILD SUBCLASSES of X2AbilitytoHitCalc.uc (eg. X2AbilitytoHitCalc_standardaim or X2AbilityToHitCalc_StandardMelee etc) that are used in the game. They follow this specification or blueprint of the parent on how to "properly" setup/create the idea of a "toHitCalc" object.

 

So if you want to change something and have it show up in the game, you have to change one of those subclasses. However you can't actually change a class/object in the game(at least in the terms we mean in this thread), but you can REPLACE it with one of your own, via the Override feature of the XCOM 2 mod system. Now you can't just replace it with any old class, the replacement class has some rules. Specifically you have to extend the class you are going to replace, for the override to be valid (I believe this is true as I think I ran into it myself).

 

Which means if you want to change any of the hit calculations on say the standard weapon shot (used by many/most weapons in the game) then you will need to replace the X2AbilitytoHitCalc_StandardAim class in the game. You do this by writing your own class and extending X2AbilitytoHitCalc_standardaim. You then override/replace (not in the XCOM 2 modding sense, but in an object oriented programming sense) any functions/methods in this class with your own version you write (with changed behavior). So for example, I'm tinkering with the RNG distributions used in the toHitCalculations. So in my mod I need to REPLACE the InternalRollForAbility() function with my own version, that does things a bit differently. So I have to write my own class, extend StandardAim, provide my own version of InternalRollForAbility, and then make sure my override is set via the appropriate config (Engine?) file, the details of which you can look up in the class override example.

 

Now if you do all the above, it will work, however there is probably something interesting you will notice. Your changes will only show up on overwatch shots and grenade throws. This is because the above system will replace all StandardAim objects in the game, with your replacement, but only those that are created in the code using the "new" operator. As it turns out, for whatever unknown reasons, many of the standard weapon abilities actually have there toHitCalc object created in a different way, that avoids the above system. But that is info for another time/discussion (and is present in other threads) once you get the above working.

 

So TLDR - Overriding/replacing the PARENT CLASS of an object used in the game, will have no effect on that object in the game. The child class in the game's reference/dependence on it's PARENT class is not changed by the XCOM2 override system. You have to actually override/replace the class used in the actual game (the CHILD) itself. Now if the changes you want to make are actually in code specified in the PARENT CLASS, then it's a bit trickier as you need to familiarize yourself with the rules of Object Oriented Programing on what properties/functions of the parent class does a child class inherit, and how you can change/override/ "hide" that behavior. Some of that can be language dependent.

Edited March 13, 2016 by aggies11