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

[davidlallen]

So the first hotfix is out yesterday. Today I copied several of the uc files from the sdk into my mod directory and compiled them *without any changes* and they give errors. It seems that the hotfix updated some compiled script files in the game, but didn't update the corresponding source files in the sdk. Now, where am I supposed to get valid source to, you know, *modify*?

 

For example, compiling X2StrategyGameRulesetDataStructures.uc gives, error on line 756, redefinition of function IsFirstDay differs from original. Also compiling XComGameState_HeadquartersXCom.uc gives error on line 2116, redefinition of function GetUnstaffedEngineers differs only by return type

 

These are lines I *did not change* and they *do not compile*. If they aren't going to keep the source files in the sdk up to date, how are we supposed to mod anything?

[FxsRMcFall]

We *are* actually updating the SDK, including script files, when we update the base game. We didn't change that class though... so something else is going on there. Luckily, the errors you're getting are pretty easy to track down - compare the function signatures of your override class to the base class to see how they differ, then update your override to match. Seeing the differences, it might also give a clue as to what local process caused it to be different.

 

One important note: when compiling the SDK compiles most script packages *including* base game ones, so script errors are caused by local UC files only and not an interaction with some script package we distributed. Also, the entire team is avoiding making function signature changes to base game classes. Even though we are sharing everything needed to update mods with such a change, we don't want mods to have to update themselves when we update the base game.

[davidlallen]

Thanks for the suggestion, and I am glad to know that the team will resist changing interfaces.

 

In the two files I mentioned, I *did not change* the functions with these errors. All I did was copy the whole file out of the sdk directory, change some *other* functions, and compile. Of course I would have preferred to extend only the one or two functions I was changing instead of pasting the whole file. But as I am sure you know, most of the classes make extensive use of private variables with no getter/setter, and subclasses cannot refer to private variables. So for most non-trivial mods, we have to copy the entire file.

 

Avoiding the use of private variables or only referring to them with getters/setters would be a big help here.

 

What else can cause the errors I mentioned, in lines I did not change? If it is helpful, I can zip the two files I changed and attach them here. But, there is other ModBuddy data related. What is the best way to post data related to a failing compile?

[FxsRMcFall]

Since we didn't update that class, I think you are probably running into a limitation in the script compiler and the timing is just coincidental. if you copied the class exactly then there may be additional challenges due to the fact that the class you are copying is native.

 

For sure something we could look at, but I am confident it is not related to the hotfix / SDK update.

[hairlessorphan]

Yeah, it turns out that after Steam updates the SDK, you can go into SrcOrig and sort by Last Modified, and you'll see which scripts were updated.

 

Helpful for figuring out if your mod(s) are affected.

[davidlallen]

if you copied the class exactly then there may be additional challenges due to the fact that the class you are copying is native.

What does a "native class" mean? How can I tell whether a class is native? I have given the exact class names and functions generating these errors in the OP.

 

 

it turns out that after Steam updates the SDK, you can go into SrcOrig and sort by Last Modified, and you'll see which scripts were updated.

 

That is better than nothing; but it still requires extensive diff to find out if I *care* whether the file was modified. The common case seems to be a bulk copy/paste required due to private variables, with only a couple of lines changed.

 

Then I would have to try something like Linux diff/patch to re-apply my changes to the new file. But of course I can't get the diffs, because now the old file is *gone*.

 

... Oh, wait, is this why the default mod template contains a copy of all the 1900-odd uc files? Wow, that sounds right, and we have been telling modders to delete all those because they are useless junk. Not so useless, really.

[hairlessorphan]

 

That is better than nothing; but it still requires extensive diff to find out if I *care* whether the file was modified. The common case seems to be a bulk copy/paste required due to private variables, with only a couple of lines changed.

 

Then I would have to try something like Linux diff/patch to re-apply my changes to the new file. But of course I can't get the diffs, because now the old file is *gone*.

 

... Oh, wait, is this why the default mod template contains a copy of all the 1900-odd uc files? Wow, that sounds right, and we have been telling modders to delete all those because they are useless junk. Not so useless, really.

 

 

The private variable thing, honestly, is halfway our own fault. We're re-implementing the class contract when we extend the class, and if in practice we're just bulk-copying because private vars, what we're saying in principle is "we're going to re-implement this class by copying the original implementation, bugs and all."

 

Which then makes it our responsibility to debug and maintain...

 

Not sayin' we have a better option, just sayin' we're doing what we can under the terms the SDK dictates, and one of the clauses in that contract is: you can't hook these vars, you can only make your own version. I mean, that's what the definition of a private class member is. That's why the private access modifier exists.

Edited February 19, 2016 by hairlessorphan

[eXecator]

 

What does a "native class" mean? How can I tell whether a class is native?

 

 

Native classes are declared with the native specifier like this:

class XComGameState_CampaignSettings extends XComGameState_BaseObject native(Core);

 

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

[davidlallen]

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?

[eXecator]

 

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?

 

 

I'm not an unrealscript-beast, but I would see the native specifier as a strong discouragement to modify a classes behaviour.

 

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.