Compiling against code in a different mod?

[bunnytrain]

SOLVED: It's a bit complicated, but I found a solution that shouldn't be affected by load order issues, and it allows ModA's presence to be optional even if ModB ultimately wants to call into ModA!

 

BIG CAVEAT is that I haven't tested the "keeps working without ModA" part to the point where I'd stake my reputation on it.

 

Let's use the example from down below. Mod B wants to call into Mod A. So the source file structure inside Mod A looks like this:

Src
    --> ModA
        --> Classes
            --> ModA_UIScreen.uc
    --> ModC
        --> Classes
            --> ModC_Interface.uc

Here's the class declaration for ModA_UIScreen:

class ModA_UIScreen extends UIScreen implements(ModC_Interface);

In order to make Mod A compile, you just need to add lines into XComEngine.ini for Mod A:

[UnrealEd.EditorEngine]
+EditPackages=ModC 

Now for Mod B.

 

The file structure inside Mod B it looks like this:

Src
--> ModB
    --> Classes
        --> ModB_UIScreenListener.uc
--> ModC
    --> Classes
        --> ModC_Interface.uc

Here's what ModB_UIScreenListener.uc looks like:

class ModB_UIScreenListener extends UIScreenListener;

event OnInit(UIScreen Screen)
{
    local ModC_Interface ModA_ScreenInstance;
    ModA_ScreenInstance = ModC_Interface(Screen);
    if (ModA_ScreenInstance != none)
    {
        // Now you can do stuff in Mod A using the interface specified by Mod C!
    }
}

defaultproperties
{
    // This part is still the same though. It doesn't seem to affect things if there is no ModA module.
    ScreenClass = class'ModA.ModA_UIScreen';
}

In order to make Mod B compile, you just need to add lines into XComEngine.ini for Mod B:

[UnrealEd.EditorEngine]
+EditPackages=ModC

At this point, the two mods should work independently and together. Both mods will have a ModC.u file in their outputs, so the point about load order not mattering is because ModC.u should be the same if you started with the same files.

 

My reason for using an Interface to bridge the gap is that it lets you use the exact same shared files (ModC) in both places, while hiding ModA's inner workings from ModB. This means that as long as the ModC files you built with are the same, load order shouldn't matter and both ModA and ModB will be able to bind to the same set of interfaces.

 

Exciting stuff.

 

-------------------------------------------

 

I'm been looking through both UDK and Xcom 2 documentation, but I can't find any information on attempting this sort of thing. Maybe someone here might know?

 

The gist of it is this: I have a mod (ModB) that builds on stuff from another mod I wrote (ModA). So if the package ModA has some class declared like :

class SomeUIClass extends UIScreen;

And then ModB wants to do something like:

class SomeUIListener extends UIScreenListener;
var SomeUIClass ParentScreen;
event OnInit(UIScreen Screen)
{
    ParentScreen = SomeUIClass(Screen);
    // ...and so on
}

defaultproperties
{
    ScreenClass=class'SomeUIClass';
}

If they were in the same mod and same package, this would "just work," but if I want to have them in different mods (because the first mod is standalone and the second mod would depend on the first mod) then I keep running into a problem where the compiler can't compile against the base game + ModA. I've tried various things from listing multiple packages in the INI files to copying the files from the first mod into SrcOrig, and a few other crazy ideas, but nothing has worked so far. If there's some way to do it, this would be huge because it would let modders build on each others' code.

 

Is there any way to make this work?

Edited March 4, 2016 by bunnytrain

[davidlallen]

Good question. This has been discussed in a few other threads also, without any solution. There is a second problem you have to consider. What if you are successful in compiling mod B and you distribute it, and then a player without any mods installs only B. What can happen? Probably nothing good. Or, if A comes in several incompatible versions, and the player has only an old version of A installed.

 

Although it defeats the idea of modularity you are aiming at, you may have to copy the mod A files into your mod B directory before you compile.

[bunnytrain]

True, there's also a problem of Mod B not being able to use Mod A's code because the user never installed Mod A. But the way I see it, this is something NMM is good at solving even if Steam Workshop isn't, so let's solve one problem at a time.

 

I'll keep digging at this, but having an answer to this question seems pretty essential in the long term for this mod community to solve its own mod compatibility problems.

[kosmo111]

http://forums.nexusmods.com/index.php?/topic/3834670-cross-mod-function-calls/page-2 is the post davidlallen mentioned.

 

Essentially you guys already touched on most of the related issues-- however towards the end of the thread tracktwo goes into slightly more detail on how to do it should you still be interested.

 

One thing I am doing to hopefully help this issue in my mod is to keep a version number around. Essentially, for my own purposes or for others, I can check what version of the mod the user is currently using (based on objects saved in the GameState) that way the mod can be gracefully updated. If the mods you are trying to work with have this, you could always make sure that the version is one that you support before doing any cross mod function calls.

[davidlallen]

Related:

http://forums.nexusmods.com/index.php?/topic/3834670-cross-mod-function-calls/

http://forums.nexusmods.com/index.php?/topic/3839560-template-modification-without-screenlisteners/

http://forums.nexusmods.com/index.php?/topic/3840485-mod-load-order-with-nmm/

[bunnytrain]

Thanks for the links! I read through and the idea of stubbing out the files sounds promising.

 

In case anyone was wondering, the thing I'm actually working on is a central "Mod Settings" UI for mods to optionally hook into. I've figured out most of the details to making this happen, except this issue of calling into another mod's classes. But if stubbing in the classes works, then that's a not-ideal but workable solution. Will try this tonight when I get home.

[bunnytrain]

Just reporting in: solved the problem by adapting some of the techniques here: http://forums.nexusmods.com/index.php?/topic/3834670-cross-mod-function-calls/page-2

 

I'll write it up after I've tested a few more things that might make the process less brittle.

[TeamDragonpunk]

Just reporting in: solved the problem by adapting some of the techniques here: http://forums.nexusmods.com/index.php?/topic/3834670-cross-mod-function-calls/page-2

 

I'll write it up after I've tested a few more things that might make the process less brittle.

Is there a definitive thread for this now. I'm curious if it's worth my time to develop an "Enterprise Service Bus" to handle this, or if we're just all going to conform to a standard of UIListener and AmbientNarrativeCritiera Template extending.

 

I need to check into this further to see if it works as an ESB:

https://docs.unrealengine.com/latest/INT/API/Runtime/Messaging/IMessageBus/index.html

 

Of course that link is for Unreal Engine 4, will check for 3...

 

Speaking with Firaxis right now, curious if I/we could extend the X2EventManager to act as an ESB... Will take a look tonight.

 

For those who aren't familiar with an ESB, think of a UIListener that would broadcast the event to each mod listening, instead of placing individual hooks to call.

 

https://en.wikipedia.org/wiki/Enterprise_service_bus

Edited March 7, 2016 by TeamDragonpunk