[Starsector Mods][0.95.1a] Concord 3.5.2g

Also, I could see how modders would want both unidirectional (non-mutual) and bidirectional (mutual) exclusions. Both for automatic via tag, and via custom methods.

So perhaps:

vEx_safetyoverrides < this hullmod will be incompatible only with safety overrides but not other incompatible hullmods
vExMutual_safetyoverrides < this hullmod plus all hullmods that are incompatible with safety overrides

With:

public Set getCustomExclusiveTags();/* just the hullmod with these tags */
public Set getCustomMutualExclusiveTags();/* hullmod with these tags and other hullmods that are blocked by these tags */

Github link with no sources. Boo. Show us the code, so we can see a bit more

Also, I could see how modders would want both unidirectional (non-mutual) and bidirectional (mutual) exclusions. Both for automatic via tag, and via custom methods.

So perhaps:

vEx_safetyoverrides < this hullmod will be incompatible only with safety overrides but not other incompatible hullmods
vExMutual_safetyoverrides < this hullmod plus all hullmods that are incompatible with safety overrides

With:

Code

public Set getCustomExclusiveTags();/* just the hullmod with these tags */
public Set getCustomMutualExclusiveTags();/* hullmod with these tags and other hullmods that are blocked by these tags */

I wrapped the source in the jar but I agree that'll be easier to track, updated github with src

I can't really wrap my head around wanting to be incompatible with safety override but not other mods with such incompatibility, since that's the very purpose of this mod.
It can easily be other hullmods, for example, a modified version of ITU. In such case, you don't want other mods providing their targeting unit to be compatible with yours otherwise it can immediately create some 200% range abomination. Most mods try to avoid this by restricting such hullmods to their own faction of ships which I find uninteresting; If such hullmod is public it deters new implementations of hullmods in same fields due to them easily stack and become OP.

Hello, I have download the mod but it does not appear among the mod list to enable it.

It's current name in mod list is Mod Concord.

I've updated the name to be consistent with post title and, should now be easier to find.

At a first glance this looks like a clean implementation (tag based systems are great), but if I may ask is there a reason to use this instead of MagicLib's hullmod incompatibility features?

I think Sutopia answers it here:

However, there is currently no cross-mod compatibility check available, allowing for insane hullmod stackings.

So for example, if mod A has some variant of SO, call it SO_A, that's incompatible with SO, and mod B has a different variant of SO, say SO_B, that's also incompatible with SO, it's unlikely that SO_A and SO_B will be incompatible with each other unless the mod authors of A and B explicitly communicate and add specific exceptions to their respective hull mods' applicability code.

• When adding an incompatible vanilla hull mod, Concord doesn't let me know what hull mod(s) it's incompatible with before turning it red.
• Similarly, if all of the conflicting hull mods are removed, the red vanilla "incompatible" hull mod should go away.
• IMO the biggest issue is that the replace-vanilla-hullmod-with-incompatible-marker behavior is happening inside the isApplicableToShip method. I don't think this is the right place to do this, for two reasons. The first is that isApplicableToShip should not have side effects as it's just a boolean "checker" method. The second is that there's no guarantee that isApplicableToShip will be called after the hull mod has already been installed. In the particular case of adding a hull mod in the refit screen, this behavior works because the base game has to call isApplicableToShip on every hull mod in order to update the GUI button (turn the text orange if it's not applicable). In the general case (i.e. if a mod has its own way to add hull mods, or adds a vanilla hull mod to a ship outside of the refit screen), the sequence is check if applicable -> apply if not unapplicable, which your mod won't catch if the hull mod in question is a vanilla hull mod. MagicLib does the incompatibility check in applyEffectsAfterShipCreation, which I think is a good candidate.

I think the best solution would be for the base game to implement a similar functionality to what you've done: have a set of exclusive tags such that a ship can only have one hull mod from each exclusive tag. Modders could make their custom hull mods incompatible with vanilla hull mods by adding custom exclusive tags to vanilla hull mods on application launch. In fact, I think most of this functionality is already there (see: shipHasOtherModInCategory).

When adding an incompatible vanilla hull mod, Concord doesn't let me know what hull mod(s) it's incompatible with before turning it red.

Update coming soon (TM)
Updated

Similarly, if all of the conflicting hull mods are removed, the red vanilla "incompatible" hull mod should go away.

Not possible due to S-modding exist, so it should be up to users removing the incompatible hullmod.
I've been bugged by vanilla doing this:

• I add a mod hullmod that is an ITU equivalent
• ITU seems perfectly fine so I put ITU in
• ITU is in but bumps out the now isApplicable false mod hullmod

Update: I kinda see what you mean. It now adds back the conflicted vanilla hullmod should mod hullmod get removed.

Put logic in applyEffectAfterShipCreation

Can do that
Done

About base game

Since fitting already is checking isApplicable, it shouldn't be expensive to do a round of temporary "Add hullmod" variants, populate and examine if the tentative add hullmod operation putting any hullmod isApplicable into false state, and thus is able to detect reverse incompatibility. Tag based is much easier to do but it would be nice to have a fail safe fallback.

Magiclib requires O(n^2) work for all the cross-incompatibilities while CONCORD only requires O(n) and much less likely to miss the function calls.

Not that it matters for most existing mods to switch over since most of them already extra guard their creations not applicable to not-same-mod ships;
The mod is mainly providing a breeding ground for future mods to not need to hold back their creations from having unnecessary restrictions in fear of "breaking the game".

Known issue: The first mod that removes the vanilla hullmod registers as the incompatible and doesn't actually populate the full list for hullmod placeholder
WIP to solve: multi incompatibility registration and logistic-like modification limit

I downloaded and enabled this mod and for some reason I'm seeing 2 of every hullmod

For missions you need to strip the ship for it to work. The underlying code relies on a hidden hullmod to dynamically change which one you see. Regardless of which one you’re using it’s the same one on the ship.

Actually, let me fix that as well (variant update). Updated

I downloaded and enabled this mod and for some reason I'm seeing 2 of every hullmod

For missions you need to strip the ship for it to work. The underlying code relies on a hidden hullmod to dynamically change which one you see. Regardless of which one you’re using it’s the same one on the ship.

Actually, let me fix that as well (variant update). Updated

Thanks.
It seems to let me install 2 of each hullmod as a result, though some will be labeled as (S) while others won't be.  The green markers also do not appear unless the ship is selected in the refit section.