Toolbox technical questions here, please

[Amineri]

So I have just one place to check, I'm going to ask that people ask technical questions about Toolbox in this thread.

 

There's not a whole ton of code in there, but there are few bits of tricky business involved.

 

1) Multiple script files in a single mod.

 

This is done via the XComEngine.ini lines :

[UnrealEd.EditorEngine]
+ModEditPackages=LW_XCGS_ModOptions
+ModEditPackages=LW_Tuple
+ModEditPackages=LW_XCGS_ToolboxOptions

Each ModEditPackage defines an additional package that should be created during the make commandlet.

 

For Toolbox, we used this to break out separate API chunks -- lightweight interface-like classes that provide a mechanism for mods to share code. There are three of them in Toolbox :

 

• LW_XCGS_ModOptions
• LW_Tuple
• LW_XCGS_ToolboxOptions

The ModOptions API package is the interface another mod uses to interface with the Options Menu code. You basically copy the ModOptions Src folder into your project, and it gets built and added to the other mod. Multiple mods may have this, but since it's a fixed interface, it doesn't matter which one gets loaded (so load order doesn't matter). Just doing go changing it! :smile: We are already using ModOptions in the current PerkPack to enable in-game options specific to that mod.

 

LW_Tuple is a basic Tuple class that was built to allow inter-mod communication via the X2EventManager. If you look at the most recent version of LeaderPack, you'll see that we had added this in advance, and registered listeners to receive events that would be created by Toolbox.

 

Toolbox Options API package is a separate bit that provides access to Toolbox specific things such as RedFog settings and SquadSize, so that other mods can directly make changes to those settings via code, without requiring users to change config, or requiring a particular load order. This is an alternative method of inter-mod communication, which has some pros and cons versus using the X2EventManager.

 

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

 

2) Inter-Mod communication

 

As mentioned before, Toolbox implements two different mechanisms to allow inter-mod communication.

 

A) X2EventManager -- This is the most general method, which utilizes the LW_Tuple class to pass data bi-directionally between multiple mods. One mod has the TriggerEvent, and other mods (or it) can set up RegisterForEvent methods to listen for the event.

 

I used this to pass data between OfficerPack and Toolbox, so that OfficerPack makes use of the more-refined UISquadSelect built in Toolbox

 

B) ModEditPackage -- This (I feel) is a more targeted method, but is useful for other things besides just inter-mod communication. It basically allows building of multiple script packages within a single mod. Using small, simple API packages allows for mods to share code-sets, which allows a richer amount of interoperability.

 

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

 

I'll add more to the post as I think of things, and as questions arise! ^_^

[davidlallen]

Thanks for setting up this thread. I am curious about this particular feature:

 

ALLOW COMBAT AUTO-RESOLVE [...]

 

Can I reach this easily from my mod, without having to install yours? This would indeed be very helpful in testing my upcoming storyline mod.

 

If the mission has some victory conditions, do they automatically get satisfied?

 

Can this be used from the main game, or is it only available in TQL?

Edited April 29, 2016 by davidlallen

[Deleted32045420User]

if i want for example access your variables that govern what stuff is active in the game how could i send values to be applied there through intermod communication?(I'll be working on a game launch options screen for your toolbox- it saddens me that you dont have one)

Edited April 29, 2016 by Guest

[Amineri]

if i want for example access your variables that govern what stuff is active in the game how could i send values to be applied there through intermod communication?(I'll be working on a game launch options screen for your toolbox- it saddens me that you dont have one)

 

Yes, fairly late in the process it was suggested that we add Shell-level access for Toolbox, and allow it to change the default config settings, but at that point the mod had been tested to be pretty stable, so we wanted to release rather than add another feature. It is a great idea, and I wish I'd thought of it sooner.

 

The reason there's no access in the Shell is because I decided to store the mod option setting in a gamestate, attached to the CampaignSettings gamestate. The advantage here is that such settings are stored separately per campaign, making it possible to have multiple campaigns with different settings. Handy especially if two people share the same computer, for example.

 

The downside, of course, is that the settings have to be set for each campaign.

[Amineri]

Thanks for setting up this thread. I am curious about this particular feature:

 

ALLOW COMBAT AUTO-RESOLVE [...]

 

Can I reach this easily from my mod, without having to install yours? This would indeed be very helpful in testing my upcoming storyline mod.

 

If the mission has some victory conditions, do they automatically get satisfied?

 

Can this be used from the main game, or is it only available in TQL?

 

Shoot, I didn't add an access method to allow other mods to change that. I'll take note of QoL features that people want -- we have to update anyhow for future DLC, so I'll see what I can get added and stable. That one should be pretty simple.

[Deleted32045420User]

 

if i want for example access your variables that govern what stuff is active in the game how could i send values to be applied there through intermod communication?(I'll be working on a game launch options screen for your toolbox- it saddens me that you dont have one)

 

Yes, fairly late in the process it was suggested that we add Shell-level access for Toolbox, and allow it to change the default config settings, but at that point the mod had been tested to be pretty stable, so we wanted to release rather than add another feature. It is a great idea, and I wish I'd thought of it sooner.

 

The reason there's no access in the Shell is because I decided to store the mod option setting in a gamestate, attached to the CampaignSettings gamestate. The advantage here is that such settings are stored separately per campaign, making it possible to have multiple campaigns with different settings. Handy especially if two people share the same computer, for example.

 

The downside, of course, is that the settings have to be set for each campaign.

 

My system works the same way (though it saves it to a regular gamestate not as a subcomponent)and I have been able to get data to get through the Shell passage using a UIDataStore object(Edited-Yup that's it), what I'm planning to do is basically copying the code but what I'll need is to get a way to pass the variables to the Toolbox code to use when starting a new campaign.

Edited April 29, 2016 by Guest

[TeamDragonpunk]

This is in response to @davidlallen post here: https://forums.nexusmods.com/index.php?/topic/3882135-x2eventmanager-as-an-enterprise-service-bus/?p=37291930

 

David, if we can reverse engineer the Toolbox easily enough, then agreed, it becomes a non-issue. I was under the impression there may be some PERL scripts or other files that we can't get directly from the Workshop, given that the solutions file for the directory structure isn't downloaded.

 

I certainly share your concern that direct access via Github could result in different flavors/distros, but I just don't see that actually happening with this community. I can't envision a use case for any mod in which that would be necessary (other than someone just trying to be a troll).

[johnnylump]

We didn't use anything like PERL scripts or other tricks outside the mod toolkit.

 

I've uploaded an optional file on the Nexus Toolbox page which is just a zip of the solution from our development directory. The only thing I removed was the Workshop ID file, so you should find the solution files, internal directory structure, loose icons, and the source for Tuple, Mod Options and the Toolbox files themselves. Let us know if that satisfies (although I'm not sure what else there would be to provide).

[TeamDragonpunk]

We didn't use anything like PERL scripts or other tricks outside the mod toolkit.

 

I've uploaded an optional file on the Nexus Toolbox page which is just a zip of the solution from our development directory. The only thing I removed was the Workshop ID file, so you should find the solution files, internal directory structure, loose icons, and the source for Tuple, Mod Options and the Toolbox files themselves. Let us know if that satisfies (although I'm not sure what else there would be to provide).

 

Hey, thank you! I haven't seen a link for the Nexus Toolbox page, so I didn't see that. I'm sold now. Just always weary of increased dependencies especially when things like this happen: http://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

[davidlallen]

Can the LWS team offer any insight into what may be changed, from the modding perspective in the patch coming tomorrow? Having to rummage around and test all aspects of all my mods against random changes is not a pleasant idea.

 

Also, PSA, everybody should make a local zipfile of the existing OrigSrc, since it will be silently updated, and it will be helpful to diff against the previous code.