How to add custom second wave options

[SpazmoJones]

I'd like to update some of my mods to make them custom second wave options. How do I define new ones and how do I check if they are enabled or not? I presume there's a standard way to do this now? Thanks!

[LiQuiD911]

Querying SW in tactical is done this way:

 

if(XComGameReplicationInfo(class'Engine'.static.GetCurrentWorldInfo().GRI).m_kGameCore.IsOptionEnabled(OptionIndex))

 

and in strategic it's IsOptionEnabled()

 

but I think it will be problematic to integrate different SW mods because they'll have conflicting SW slots

[johnnylump]

We're using up to #29 in the base version, so 30 through 35 are available. Not planning to add any more.

[tracktwo]

Yeah I decided against making the permanent motion tracker mod a SW option because of the conflict possibility with other mods as well as because they become a little less self contained. For LW with a fancy installer its OK, but people are used to installing mods by loading the patch file in patchergui and clicking the go button. A SW option also requires changes to the .int file for the text, which is a separate step.

[tracktwo]

Resurrecting this old thread - I've been doing some more thinking about how to make this work a little better. I can see a couple of problems with making use of the new available SW slots LW gave us but didn't use:

 

1. There are only a few, so we have the potential for mods to use the same ones and conflict with each other.

2. Even if we somehow came up with some agreement of which mods would use which values, that's bad for everyone because there are so few slots and most people are not going to have every single mod installed, so we'd quickly have more mods than slots but many available spots would be wasted in any given person's install.

3. Installation is a problem since it involves making changes to several files, including the localization files and .ini files.

 

Some of these problems could be solved with a meta-mod to manage second wave options. Basically, a mutator. This is fairly convoluted so maybe not worth actually doing unless several mods would make use of it, but here's the idea:

 

Mods would register themselves with the SW helper by adding to a .ini file specific to that mod. They could register using a string identifying the mod, which should be unique enough to avoid mods from stomping over each other. The job of the mod helper is to inject itself into the SW options UI and add an entry for each of the mods listed in its INI file. It is responsible for organizing which mod goes in which SW slot. The last slot is reserved and cannot be assigned to any mods. The particular ordering of SW options will depend on what mods are installed on the system.

 

Since the mods themselves that use this wouldn't know what SW option they were actually assigned, they can't just directly query the option to see if its set. And since mutators can't return values AFAIK this would be a two step process: first call a helper mutator with the string identifying your mod to let it know you'll be asking for a particular option (e.g. Mutate("SecondWaveHelper:MyFancyMod")), and the helper will set or reset a fixed option number (e.g. the last one). After the mutator returns, the mod can query the last SW option and get the value. This would be less convoluted if we can find a function to steal, especially one that takes a string and returns an int or bool, or if mutators could return values, cause then it'd be only one step.

 

For localization, mods could also register their localization string(s) in the helper .ini and (hopefully) the helper mod can finagle them into the SW UI. Again since the mods don't know what SW option they're assigned they can't directly modify the .int files and have to rely on the helper to do it for them.

 

This helps with 1 and 2, but 3 is still an issue. I don't know how to solve that other than writing a custom installer, or at least an extension to a standard installer like WIX or whatever to handle modifying .ini files. Unreal .ini files are tricky because the same key can occur multiple times in a section, that's how dynamic arrays are created. So it isn't enough to simply check if a given key exists in the .ini file, you need to check if the particular value is also there, and I don't know if any of the standard installers can handle multiple copies of a key in a file.

 

Thoughts? There seems to be quite a bit of mod activity right now that might benefit from this, but I also don't really want to do too much infrastructure work with xcom2 so close, and who knows what, if any, mod loading helpers they'll have integrated. Possibly none, in which case a lot of this stuff might be useful down the road anyway.

[Dethraker]

I was wondering about the available SW slots as well, I fully intend to insert my "Alternate Tech Tree" mod as a SW option(currently have it placed in slot 30), but if others also place theirs in slot 30 then it will definitely cause problems. While the mutator idea is genious, would it be easier to just expand the available spots for SW options, maybe upping the number to 45 or 50?

 

Not sure how this impacts the rest of the modders on the other sites that are modding XCom...wait I think it's basically exclusive to Nexus lol. Anyway, joking aside, it has been danced around for awhile, we don't really need to make an official LW++ team, we're basically that team already. We all have our own things going on, but most modding XCom are regulars on these forums, I'm fine with being assigned a slot, and we can put out a patch that simply increases the number of SW slots. Like you said, XCom2 is right around the corner, though several of us are considering continuing LW modding, once XCom2 hits we might get drawn in to the shiny newness lol.

 

Whichever road we take I'm all aboard, if help is needed with creating a mutator to accomplish this I'm all for doing what I can to help. I guess in the long run(especially if modding continues after XCom2 launches) the mutator would be the better option.