Print

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

[Ryu116]

Hello everyone,

There is one thing that made me think of this after seeing how people like me usually enjoy having lot different mods combined together to enjoy much larger diversity of experiences in Starsector game.


There is one thing that I think would be great assist to both an author of Starsector and modders, theoretically:

Mod loading Order

It allows for any specific mods to be loaded from top (first) to bottom (last), where the data get loaded in order.  With that, any specific features in certain mods can laod over other for sake of stablization without causing lot of data being conflicted when all mods is loaded at the same time.


Another feature that I also think would help with modders:

Mods conflict detection

(Note: Please let me know if this feature is already implemented in Starsector.  I recently started playing starsector last month and I am loving every moment of it.)

There could be an additional feature in program that detects the conflicting codes that changes the same thing from two or more different mods.  For example, mod #1 changes the campaign, then mod #2 change the same thing.  That is when they could create an additional log file that shows the conflicting between two or more mods.  The goal of ths is to locate the exact conflicting codes that can be easily changed, to allow multi-mods to work together in more stablized ways.


What do any of you think about this features?

I believe that with game being already flexible, any additional features that allow author of starsector and modders to be able to handle the data and mods in more stablized, efficient, and effective ways will allow starsector to expand even more.

[Tartiflette]

Mod Order: Yes but not for the players, I'm pretty sure that would cause more troubles because they didn't read the instructions and messed up the list. But some way via the API to specify when a mod is loaded could be useful (it is already somewhat possible but imply giving your mod a weird name).

Mod Conflict: An autodetection script seems like either a time consuming task for Alex and your CPU (check the content of a mod even before it's loaded) or on the modders (making a list of all files modified). A mod list of conflict could be a simpler solution: SS+ could warn against loading Targeting Pip, or Upgraded Rotary Weapons for example, TC could prevent any non-utility mods to load...

But what I would far prefer to see is a Dependency Check: Most mods require at least LazyLib, a large amount ShaderLib, and a handful TwigLib. A lot of reports we get concerns people either not having those, or using an outdated version. If when ticking a mod the launcher would check a list of dependencies and their version, then automatically tick them too or warn the player, that would help a lot!

[Zaphide]

Mod Order: Yes but not for the players, I'm pretty sure that would cause more troubles because they didn't read the instructions and messed up the list. But some way via the API to specify when a mod is loaded could be useful (it is already somewhat possible but imply giving your mod a weird name).

Mod Conflict: An autodetection script seems like either a time consuming task for Alex and your CPU (check the content of a mod even before it's loaded) or on the modders (making a list of all files modified). A mod list of conflict could be a simpler solution: SS+ could warn against loading Targeting Pip, or Upgraded Rotary Weapons for example, TC could prevent any non-utility mods to load...

But what I would far prefer to see is a Dependency Check: Most mods require at least LazyLib, a large amount ShaderLib, and a handful TwigLib. A lot of reports we get concerns people either not having those, or using an outdated version. If when ticking a mod the launcher would check a list of dependencies and their version, then automatically tick them too or warn the player, that would help a lot!

Yeah great suggestions (I actually thought the TC prevention stuff was already in there?)

The 'known conflicts' should be version-aware too (e.g. so ModA would have a known conflict with ModB(v1) but not with ModB(v2)).

Likewise with dependency (e.g. ModA requires ModB(v1) or above). Might be a problem with breaking changes in a dependency but then the original mod would need to be updated anyway.

[xenoargh]

The TC-prevention stuff is there, and mods can be marked "utility" if they aren't likely to cause major conflicts, but there are definitely issues in terms of order-of-operations stuff, where two mods change the same variables and can freely overwrite one another.  It's hard to resolve that one easily without allowing the end-user to specify the order manually, though, like mods for BethSoft's engine are handled.