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

[hairlessorphan]

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

 

I agree with this, too, except I kind of feel like it's often the only resort.

 

I know about hooking UIListeners, but I have yet to figure out how I can get a free-floating object instantiated and registered to non-UI events without going through the UI. And going through the UI seems super hacky to me, because the behaviors I'm trying to effect are object behaviors, not view behaviors.

[tracktwo]

With the expanded dlc info class hinted at in the official mod support thread, we might be getting some new, more appropriate "entry points" into the game in an update. Yeah, I agree that using the ui listener is often a hack, but like someone else said on another thread: better to have impure code that does the right thing than code that doesn't play nicely with others. Religious adherence to something like MVC concepts isn't going to help anyone when all the mods are incompatible with each other. And there is a surprising amount you can do without overrides. But not everything, I know :) I have issues in some of my own mods that I can't solve perfectly using just listeners, but I do feel that compatibility is worth those minor bugs.

[TeamDragonpunk]

Honestly, what we should be using is an enterprise service bus, but I figured that would be too much to ask.

[hairlessorphan]

With the expanded dlc info class hinted at in the official mod support thread, we might be getting some new, more appropriate "entry points" into the game in an update. Yeah, I agree that using the ui listener is often a hack, but like someone else said on another thread: better to have impure code that does the right thing than code that doesn't play nicely with others. Religious adherence to something like MVC concepts isn't going to help anyone when all the mods are incompatible with each other. And there is a surprising amount you can do without overrides. But not everything, I know :smile: I have issues in some of my own mods that I can't solve perfectly using just listeners, but I do feel that compatibility is worth those minor bugs.

 

It's not clear to me that we'd be avoiding all that many mod conflicts even with listeners, just because once everyone's hooked up a listener, all bets are off again. EDIT: I mean, when you talk about MVC principles, the reason it's a principle in the first place is because it minimizes what you have to touch to effect an object behavior change. In the case of promotions, there are (at least) 3 UI objects you need to hook into, which is 3x opportunities for conflicts. Even if each opportunity to bonk each other is smaller, you might make up for it by just multiplying the total number of opportunities.

 

The whole thing feels like an exercise in just arbitrarily choosing which principles to violate with hacks and guesses. But now I'm just whining instead of trying to help. My first thought was we should really have a megaframework that overrides ALL the base classes and adds event hooks and a real API. But that's not going to be remotely useful until after the base game source is more settled (i.e. we're not looking at frequent patches).

Edited February 19, 2016 by hairlessorphan

[tracktwo]

Mods will always run the risk of conflicting with each other regardless of what technique you're using: if your mod replaces all swords with lightsabers and mine replaces them all with rubber chickens we're obviously not going to be compatible (until the glorious light chicken mod arrives, obsoleting both).

 

But I don't see how the technical solution of the ui listeners as an entry point would ever introduce any such conflicts as there is no limit on the number of mods that can attach to the same listener, and the listener events themselves don't change any game state. Whereas overriding definitely does cause specific problems just by virtue of using an override, even if two mods would otherwise be completely independent but happen to override the same class. Do you have a specific example of what kind of conflict you get from the listeners? one that wouldn't be a problem with some other technique?

[hairlessorphan]

Do you have a specific example of what kind of conflict you get from the listeners? one that wouldn't be a problem with some other technique?

 

A couple. I'm not sure you wouldn't get it with another technique, or rather more to the point I'm not sure there are more or fewer potential conflicts. But stuff that will happen:

 

1) Public vars on the event-triggering UI get manipulated in unfriendly ways.

-- the general case mod conflict. Happens with overrides, not avoided by UI listeners

 

2) Listeners append or remove UI items.

-- the motivating scenario of MVC principles, which cause the following issues

 

2a) Mods that listen for all vanilla UI events that trigger object state change to intercept it get mangled by mods that add a new UI element that triggers that object state change

-- problem distinct to the UI listener approach. This is actually why the M and * exist in MV*, and would be solved here by exposing events on the objects

 

2b) Mods that listen for all vanilla UI events that trigger object state change get mangled by mods that trigger that object state change after hooking some unrelated UI element

-- silent failures, inconsistent states ahoy! Also solved by exposing events on the M

 

2c) Mods that listen to a specific UI element get mangled by mods that remove that UI element

-- obv. Again, solved by exposing events on the M

 

These last ones are inherent to the UI listener approach, and they may be harder to track down. "Your mod works sometimes." It comes from us needing to hook to View events as an indirect entry point to the thing we really want. In a vacuum, they may seem like corner cases, but if everyone is hooking UI events, it stops being so corner-case-y.

[davidlallen]

Returning to the original subject of this thread (sorry it has been very useful), I still claim that the sdk files are out of date. I simply copy one of the files out of sdk, XComGameState_HeadquartersXCom.uc. I rename the file and change the class declaration line, and add one logging line. Now I compile. A line which I did not change at all gives an error. I have attached the file. Please diff the file against your sdk copy of the file and tell me if you can find why it should be an error.

 

C:\Steam\steamapps\common\XCOM 2 SDK\Development\Src\DlaArmorOptions\Classes\DLA_XComGameState_HeadquartersXCom.uc(2116) : Error, Redefinition of function GetUnstaffedEngineers differs only by return type

 

Yes, this class is marked native. Does this mean it is unmoddable period? I want to change one function but it's full of private variables and I get this snowball effect trying to remove the privates.

Edited February 20, 2016 by davidlallen

[hairlessorphan]

Good news and bad news. I'm just not sure which is which...

 

Confirm that your file is identical to the one in my SDK SrcOrig except for the class declaration (obv new name) and two `log calls.

 

However, my compile failures are totally different than yours, and have to do with standard OOP stuff.

 

1) Can't override final functions (analogous to Java's final, C#'s sealed).

 

2) Some fields are privatewrite, which seems to be a problem at compile-time because some static functions get a local reference to the base class (XComGameState_HeadquartersXcom XComHq) and then try to modify the privatewrite fields on it, and your child class isn't allowed to do that.

 

Probably some more based on stuff like this. I'm not seeing your function signature compiler errors, though.

[davidlallen]

Thanks for trying it out, I agree I am not sure if your result is good or bad. I do get scads of *warnings* on the file, one for every private variable. If there were only warnings, I could keep going. I get one error, which I quoted above. Are your results *warnings* or *errors*?

 

Where else can I even look to find out what is wrong, or what the expected type of GetUnstaffedEngineers is?

[hairlessorphan]

Thanks for trying it out, I agree I am not sure if your result is good or bad. I do get scads of *warnings* on the file, one for every private variable. If there were only warnings, I could keep going. I get one error, which I quoted above. Are your results *warnings* or *errors*?

 

Where else can I even look to find out what is wrong, or what the expected type of GetUnstaffedEngineers is?

 

Errors.

 

I get all the warnings, too, but those are all name collisions. Expected.

 

I don't think trying to debug GetUnstaffedEngineers will help, because like I said the return on your posted script above is the same as mine.

 

I'd honestly try verifying the SDK. Not sure where things went pear-shaped, if it's compiling against some XComGame.u somewhere else, or what.