Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sutopia]

CONCORD download
Github repository (you can also see history releases here)

IMPORTANT Note for upgrading from prior to 3.0

Download the upgrade bridge version 2.99999
Save the game with the 2.99999 version should clean up the relic from old version.
2.99999 has the same code as 3.1.1b but will not be further updated

[close]

Purpose
Native incompatibility support

Modded hullmod can now be identified by vanilla hullmods to be listed as incompatible

Phase Lib
10 modifiers added to phase ships allowing for more dynamic phase gameplays

Various Effect Supports
Fighter Wing induced effect, Weapon induced effect and hullmod onInstall / onRemove implementations

Dynamic Ship Generation
Allows generating new ship or fighters on the fly

For players
Download the mod and enable it.
You can go to data/config/settings.json to disable cross mod checks

For modders

Native incompatibility support

NO dependency implementation

If your mod have already implemented proper incompatibility checks, you may take advantage of the tag system for vanilla hullmods to identify your hullmod as incompatible, without dependency to concord.

For example, adding tag “vEx_safetyoverrides” allows a player with concord to automatically enjoy the native incompatibility check, marking your hullmod to be incompatible with Safety Overrides, while a player without concord can still use your mod as usual.

Check "Implement compatibility check without coding" section and Codex for available tags.

[close]

NO dependency FULL implementation (new!)

Adding the tag "auto_concord" and "implicit_concord" to your hullmod will make Concord create the cross mod incompatibility shell for you automatically.
This implementation allows your mod to get full benefit of concord checks while not requiring any dependency to concord. A player can use your mod without concord just fine.

Check the following section and Codex for available tags.

[close]

Implement compatibility check without coding

This is an example line of csv

Code

,concord_targetingunit,0,,,"auto_concord, vEx_targeting_unit",,0,,TRUE,,0,0,0,0,org.sutopia.starsector.mod.concord.adv.DataEnactDomain,,,

For your hullmod that wishes to implement CONCORD, create a new line in hullmods.csv

• id is in format of "concord_{originalHullmodId}"
• it must include "auto_concord" tag
• add tags formatted in "vEx_{topic}" or "dEx_{hullmodId}" to configure incompatibility
• the script should be the same as example code

vEx: Topic leaders, all leaders in the same topic are mutual exclusive to each other
For example, if you want to make a custom targeting unit, add tag "vEx_targeting_unit"
You can use arbitrary string as topic

dEx: Followers, share the same incompatibility with the leader hullmod
For example, if you want to make a hullmod that leans toward adaptive phase coil, add tag "dEx_adaptive_coils"
Your chosen leader must be a valid hullmod ID

[close]

Implement compatibility check with coding

Hullmod that wishes to implement Concord should extend class org.sutopia.starsector.mod.concord.MutualExclusiveHullMod
If you're overriding isApplicableToShip and applyEffectsAfterShipCreation, make sure to call super first for the library to do all the heavy weight lifting.
Similarly, be careful when overriding getUnapplicableReason


Vanilla hullmod incompatibility
Add tag formatted as "vEx_{hullmodId}"
For example, if a hullmod should be incompatible with safety override, add tag "vEx_safetyoverrides"
This will automatically list other mods' hullmod with same restriction as incompatible

Current well known tags

Since 1.1.0

• percent_range_mod: incompatible with ITU, DTC and the like
• phase_mutator: incompatible with both vanilla phase hullmods because they're currently incompatible with each other

[close]

Generic hullmod incompatibility
Override method

Code: java

public Set<String> getCustomMutualExclusiveTags()

All hullmods with any tag added in the set will be mutual exclusive to each other.

[close]

[close]

PhaseLib

Available modifier dynamic IDs are listed in

Code

org.sutopia.starsector.mod.concord.phase.ConcordModStats

To modify a status, call

Code

stats.getDynamic().getMod([dynamic status ID])

These effects apply to ALL ships using vanilla phase script

Code

com.fs.starfarer.api.impl.combat.PhaseCloakStats

[close]

Other utilities

onInstall and onRemove

Use

Code: java

org.sutopia.starsector.mod.concord.api.TrackedHullmodEffect

They will be called during

Code: java

public void applyEffectsAfterShipCreation(ShipAPI ship, String id)

by ConcordCaptain

[close]

TransientHullmod

Code

org.sutopia.starsector.mod.concord.api.GlobalTransientHullmod

Code

org.sutopia.starsector.mod.concord.api.SelectiveTransientHullmod

Implementing either of the interface for your hullmod will make it globally apply BUT does not save in save files
i.e. a player can safely remove your mod from the game if your mod is only adding hullmods

[close]

Weapon and Fighter installed effects

Code

org.sutopia.starsector.mod.concord.api.WeaponInducedEffect

Code

org.sutopia.starsector.mod.concord.api.FighterInducedEffect

Implementing the interface will allow ConcordCaptain to apply the effects for you.
The ID parameter is passed in with your weapon or wing id as suffix so it's properly recognized by the game.
If you are introducing effects to something not owned by you, change the ID parameter to prevent overwriting others' effects.

[close]

fighter, ship variant and hull manipulation

ConcordDynamicInstanceAssembly provides a few methods for you to create specs on the fly to make some never-before-seen effects.

• Adding ship hull spec on the fly (.skin)
• Adding ship variant spec on the fly (.variant)
• Adding fighter spec on the flt (wing_data.csv)

[close]

[close]

Change log

3.5.2c  2022/03/13

• Added try catch for unorthodox hullmod effects
• Fixed java 8 security exception

3.5.2a  2022/03/12

• Fixed an issue with variant name accidentally adding _Hull as suffix
• Fixed transient hullmod logic, now this mod is truly removable from a save

3.5.1c  2022/03/11

• Fixed JRE8 method access issue

3.5.1a  2022/03/11

• Added Black Ops
• Added numerous APIs for spec manipulations
• Use ConcordCovert at your own risk

3.1.1a  2022/02/26

• Cleanup ConcordCaptain on player exiting market and player finishing battle to reduce memory usage

3.1.0a  2022/02/26

• Added SelectiveTransientHullmod interface
• Added WeaponInducedEffect interface
• Added FighterInducedEffect interface
• Fixed an issue with ship identification for TrackedHullmodEffect

3.0.1a  2022/02/26

• added GlobalTransientHullmod

3.0.0a  2022/02/26

• Total revamp of hullmod injection and phase injection
• Completed phase modification effect interface

2.2.2a  2022/02/22

• Fixed improper unhidden issue
• Fixed phase displaying as special system

2.2.1c  2022/02/22

• Fixed improper hidden issue

2.2.0a  2022/02/20

• Improved parsing performance for S-mod

2.1.6a  2022/02/17

• Tokenized string
• Moved two classes to separate package
• Cached blacklist
• Retired ConcordCommander, no more everyframe script

2.1.5a  2022/02/17

• Fixed my fat finger

2.1.4a  2022/02/17

• Fixed console command compatibility
• Presumably fixed progressive S-mod compatibility

2.1.0a  2022/02/17

• Fully fixed mission and campaign duplicate display
• Fully fixed S-mod display issue
• Added onInstall and onRemove interface

2.0.0a  2022/02/16

• Now supports concord implementation without library import and coding
• Now supports vanilla hullmod implicit incompatibility detection, no more placeholders
• No CSV replacement performed, compatible with [Better Deserved S-Mods]

1.4.0a  2022/02/13

• Added multi ship compatibility to prevent cheese re-add

1.3.0b  2022/02/13

• Added more informative description about the exact conflicts
• Moved the incompatible check to the applyEffectsAfterShipCreation
• Added auto re-add for vanilla incompatible injection (and theory crafting how it can break)

1.2.0  2022/02/11

• Added configuration to turn off cross mod check
• Added auto hullmod replacement with style

1.1.1  2022/02/01

• Added methods for finer getters
• More helpful default getUnapplicableReason

1.1.0  2022/01/30

• Added tag for common multi incompatibility

1.0.0  2022/01/28

• Initial release

[close]

Working in progress

None

[close]

[Jaghaimo]

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<String> getCustomExclusiveTags();/* just the hullmod with these tags */
public Set<String> getCustomMutualExclusiveTags();/* hullmod with these tags and other hullmods that are blocked by these tags */

[Sutopia]

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<String> getCustomExclusiveTags();/* just the hullmod with these tags */
public Set<String> 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.

[Zelrod92]

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

[Sutopia]

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.

[Thaago]

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?

[float]

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.

[float]

Played around with this a bit, and I think it's an interesting idea, but I don't think it can or should replace MagicLib's hull mod incompatibility stuff as there are still a few issues:

• 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).

[Sutopia]

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".

[Sutopia]

Grand update, now adds the vanilla hullmod back and show proper tooltip to let player know what's incompatible

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

[Sutopia]

2.0.0 updated, now supports concord implementation without coding and native incompatibility!

[Mephansteras]

Neat idea, I like it!

[IGdood]

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

[Sutopia]

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

[IGdood]

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.