Ease the migration of NPSBD users to CPS

[Iridar]

Let's officially name this project Community Promotion Screen -> CPS.

NPSBD is currently used by nearly 300k users, so we ought to make the process of them migrating to this mod as painless as possible.

Since NPSBD still uses a UISL to inject its screens, we can "kill" it easily enough through OPTC by setting its ScreenClass to some dummy screen. However, NPSBD also MCO's UIArmory_PromotionHero, which may or may not be a problem, and needs to be investigated.

The overall goal is to make CPS able to coexist with NPSBD, harmlessly replacing it. We'll make a note in CPS mod description that running both is unnecessary, but there will be plenty of people who will not read that, and in this case I don't want to use the CHL incompatible mods feature to create a warning popup to avoid scaring people.

[Iridar]

Should probably take some measures to not override RPGO's NPSBD, so CPS doesn't break RPGO at least.

[Iridar]

Another issue is that both CPS and NPSBD use the same mod ID and script package name, so they would show up as duplicates in AML, and only one of the mods, and only of the script packages, would be loaded.

[Iridar]

But we need the original script package name so that CPS can work out of the box with configuration that was meant for NPSBD. The solution here might be to move the CPS script into a second script package, and keep the original NPSBD script package so we can get config from it.

[pledbrook]

The solution here might be to move the CPS script into a second script package, and keep the original NPSBD script package so we can get config from it

That was my initial thought. I don't really know what the implications are of "hijacking" another mod's packages. I'm assuming that since it's a straight replacement mod, it's not an issue (running both mods together would be a problem regardless).

Since NPSBD still uses a UISL to inject its screens, we can "kill" it easily enough through OPTC by setting its ScreenClass to some dummy screen. However, NPSBD also MCO's UIArmory_PromotionHero, which may or may not be a problem, and needs to be investigated.

This sounds like you're considering the case where both mods are installed together. That doesn't sound like a great idea to me. A painless migration for me would be disabling/uninstalling NPSBD and installing && enabling CPS. Trying to make them coexist while making migration smooth sounds like it could be an intractable problem.

[Iridar]

Making the migration smooth is the process of making them able to coexist together! Yeah it's ideal if people replace NPSBD with CPS, but if we purposefully mark them as incompatible, we will drown in "hey that soldier class mod requires NPSBD, which is incompatible with your mod, what do". I guarantee it. RPGO had thousands of these, until Musashi had enough and set up RPGO's NPSBD able to coexist with workshop NPSBD.

So if there's a way to make them able to coexist, even if we have to jump through a few hoops, IMO we should pursue it.

[Iridar]

This is a question of how much legacy support we are willing to extend to mod users who use NPSBD, and mod makers that made mods that depend on NPSBD, and we seem to have a conflict of "in principle" versus "in practice".

In principle, an update to NPSBD could ruin any kind of legacy support we're trying to build.

In practice, NPSBD update is unlikely in general (otherwise there would be no need for CPS in the first place), particularly of the kind that would break our legacy support, since it would mean the NPSBD update itself is not backwards compatible.

In principle, we can't know how much legacy support we are required to do, since a mod that depends on NPSBD could be doing absolutely anything to it, including even building against it and accessing its class methods.

In practice, mods that depend on NPSBD are soldier class mods that just need a way to display more than 2 perk rows at the same time. They could potentially be shipping its own config for ability rows / ability costs. LW2 Classes and Perks, for example, ships config for ability rows, though it's technically unnecessary in that case.

If somebody will have to choose between CPS and NPSBD, or even think that they have to choose between CPS and NPSBD, they will choose NPSBD every time. We have to make CPS backwards compatible with NPSBD, or this project will never lift off from the ground.

To be backwards compatible, we have to be able to read config that was made for NPSBD, and to be able to do that, we have to include NPSBD script package.

In theory, we could build CPS against NPSBD, and access its config arrays under a "is mod present" check, without directly including NPSBD script package, but then CPS would require NPSBD to be present. That could be our way out, potentially. It would mean our project shifts in tone from "NPSBD replacement mod" to "NPSBD improvement plugin".

[Iridar]

By the way, has anybody reached out to NPSBD's author? If they're willing to implement our changes and publish an update that would make this much easier.

[Iridar]

So far our options seem to be:

1. Completely abandon any kind of support for NPSBD and release CPS as a new standalone mod.
2. Make CPS backwards compatible with NPSBD, but having both of them active at the same time will not be possible.
3. Make CPS backwards compatible with NPSBD, and it's possible to have them active at the same time, but not required.
4. Make CPS a plugin for NPSBD that imbues it with new functionality, but CPS will be unable to function without NPSBD present.

In my opinion Option 3 is the best one. But to accomplish it, we need to ship NPSBD's script package with CPS so that we can access NPSBD's config arrays. According to Xymanek, this may cause issues on the end of CPS users if NPSBD is ever updated.

If we want to avoid that possibility, we should reach out to NPSBD mod author and reach some sort of agreement regarding it, so they don't do any updates without syncing with us first.

If we don't want to do that, or we're not willing to risk that possibility at all, then our second best solution is Option 4. Then we will have to build CPS against NPSBD to access its config arrays, making NPSBD a hard requirement for CPS. We could guard array access behind "NPSBD is present" checks, which will at least avoid crashing the game if the game is launched with CPS but without NPSBD, but then we will have no way to access any config shipped by soldier class mods for NPSBD, so NPSBD is going to be required for the mod to fully function anyway.

I realize this is a difficult subject, and none of these solutions are ideal, so there could be some reluctance in committing to either option, but we really do have to decide this before the project can move forward.

[robojumper]

I was asked for input on this. I had skimmed over this previously but didn't realize the config issue.

Getting our changes uploaded to the original workshop page with the help of the original author would be best. In case that is not possible, I don't see the value in any setup that supports or requires having NPSBD enabled in addition to CPS, for a number of reasons:

1. It'd make it difficult to discern which mod is actually doing things, leading to confused users and bug reports.
2. It's possible we want to add a feature later that clashes with NPSBD in some way, and dropping support for or requirement of an enabled NPSBD down the road is going to be more difficult.
3. It could be extra work both for us and for mods that would like to un-integrate NPSBD (lwotc and potentially RPGO)? Not so sure about this one.

I would argue that CPS should include a script package with the required name and classes to access mods' config for NPSBD, but not include anything else in that package. I realize that requiring users to switch off of NPSBD can be difficult, but:

1. People are kind of used to this already with NPSBD specifically because RPGO already tells users to disable NPSBD.
2. We have a Highlander feature to point out incompatible mods specifically for drastic cases like this.

[Iridar]

Thank you. To address some of your concerns:

1. It'd make it difficult to discern which mod is actually doing things, leading to confused users and bug reports.

We should be able to reliably disable NPSBD by killing its UISL, so assuming its MCO to UIPromotion_Hero is not a problem, we should be always able to conclude the issue is with CPS.

2. It's possible we want to add a feature later that clashes with NPSBD in some way, and dropping support for or requirement of an enabled NPSBD down the road is going to be more difficult.

Unlikely, NPSBD essentially becomes glorified config holder.

3. It could be extra work both for us and for mods that would like to un-integrate NPSBD (lwotc and potentially RPGO)? Not so sure about this one.

I'm not sure what to do with RPGO at this point, it's unlikely we'll be able to support it in any way without Musashi updating it.
As for LWOTC, Peter said he'll move LWOTC to CPS if it supports all of the features he needs, so there should be no need for it to ship its own NPSBD at all.

I would argue that CPS should include a script package with the required name and classes to access mods' config for NPSBD, but not include anything else in that package. I realize that requiring users to switch off of NPSBD can be difficult, but:

1. People are kind of used to this already with NPSBD specifically because RPGO already tells users to disable NPSBD.
2. We have a Highlander feature to point out incompatible mods specifically for drastic cases like this.

Do we still need to tell people to switch off NPSBD if we ship its partial package? What happens if both NPSBD and CPS are active at the same time?

I'm wary of using CHL warning screen for a mod used by 300k people. There will be a lot mod users who will not read the description, will not read the warning screen, they'll just see a scary red popup and assume they can't use CPS. I know it will happen because I've seen it happen. Personally I'm not mentally prepared to deal with something like that.