Search for mod json recursively

[BimNoah]

The mod json will now be searched recursively throughout the mods folder.

Why?

Tbh I was fed up with all the ppl asking why their mod they just downloaded from Thunderstore isn't loaded in game : ^)

And honestly I would love the idea of mod collections in the future

---

PS: This will 100% solve all tickets, yes yes

(b'-')b

[ASpoonPlaysGames]

works in testing, and code looks good

[ASpoonPlaysGames]

Would be cool to get this merged, as it would allow thunderstore packages to be placed directly in the mods folder, as well as making mod installs effectively idiot proof, provided something gets put in the mods folder

Behaviour with duplicate mods is a little jank, however this was already the case before this PR

[NoCatt]

This will likely keep a lot of "mod dont work" from the modding chat.
Thus I must approve

[GeckoEidechse]

Tbh I was fed up with all the ppl asking why their mod they just downloaded from Thunderstore isn't loaded in game : ^)

While I get the noble intentions of this change I don't think we should merge it. In particular:

1. We really don't want to encourage manual mod installs. Players should really just use a mod-manager, especially if they aren't even able to properly manually install a mod.
   Additionally mod-managers can handle (auto-)updating mods which given that occasionally mod authors or Northstar introduce breaking changes is a must.
2. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.
3. I don't know how this deals with Thunderstore mods containing multiple Northstar mods. Does it load them all properly? Did anyone actually test that scenario?

And yes mod collection would be nice but then it should be properly introduced. At that point we could even adjust the mod loading code to just load zip files directly, cutting out the extraction step.

But overall, I feel like this PR will just move the issue around and cause more edge cases in the future :/

[ASpoonPlaysGames]

1. We really don't want to encourage manual mod installs. Players should really just use a mod-manager, especially if they aren't even able to properly manually install a mod.
   Additionally mod-managers can handle (auto-)updating mods which given that occasionally mod authors or Northstar introduce breaking changes is a must.

This won't change our stance on manual installs over mod managers, with mod managers already being preferred. All it will change is how difficult manual installation is, meaning fewer tickets

2. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

Updating mod managers to handle this should take about 4 lines of code changed, maximum. Unupdated mod managers will also handle this fine, they just wont be able to detect mods that arent installed in the old way, which should never happen because the mod manager should be the one installing the mods if it is being actively used.

This PR also makes it easier to handle mod installation in mod managers because you can install the package directly, instead of individually installing the mods, letting you easily determine which northstar mod is from which package

3. I don't know how this deals with Thunderstore mods containing multiple Northstar mods. Does it load them all properly? Did anyone actually test that scenario?

That is exactly what the PR aims to handle, and what I tested by putting all of the base northstar mods into a separate directory (simulating a thunderstore package, albeit not perfectly)
If you want to test this yourself then feel free

[GeckoEidechse]

1. We really don't want to encourage manual mod installs. Players should really just use a mod-manager, especially if they aren't even able to properly manually install a mod.
   Additionally mod-managers can handle (auto-)updating mods which given that occasionally mod authors or Northstar introduce breaking changes is a must.

This won't change our stance on manual installs over mod managers, with mod managers already being preferred. All it will change is how difficult manual installation is, meaning fewer tickets

No, the answer to "I installed this mod but it doesn't work" should always be, "use a mod-manager", so there's no point in adding fault tolerance for manual install :P

 

2. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

Updating mod managers to handle this should take about 4 lines of code changed, maximum

No. A mod-manager does not only need to handle discovering the mod but also removing and updating it etc. This gets even worse when suddenly someone starts to through different mods into the same folder.

Unupdated mod managers will also handle this fine, they just wont be able to detect mods that arent installed in the old way, which should never happen because the mod manager should be the one installing the mods if it is being actively used.

Writing a mod-manager myself I can tell you from experience that this is not the case. A user installing a mod-manager expects the mod-manager to pick up existing mods so a mod-manager that doesn't do that is considered "broken". Further if I e.g. update FlightCore to just drop the whole folder in there and e.g. Viper hasn't updated yet, then it won't be able to pick up the installed mod. Further the mod won't even show up in Viper and if it's a broken mod, now the user doesn't even have a way of removing that mod.

Luckily r2mm has it's own mod folder cause that would mean we'd have to basically wait forever to see the change deployed.

This PR also makes it easier to handle mod installation in mod managers because you can install the package directly, instead of individually installing the mods, letting you easily determine which northstar mod is from which package

This has already been solved via 0neGal/viper#165 and is implemented by all major mod managers (minus r2mm which keeps it mods separate)

&nsbp;

To step back here for a moment, I agree that we need some update/refactor that allows us to cleanly handle Thunderstore mods. When Northstar was first release Thunderstore integration wasn't a thing yet. Now if/when we do refactor to better support Thunderstore stuff, we need a proper change, maybe even a new mods directory. Trying to shoehorn a small change in that primarily targets adding fault tolerance to manual install just doesn't feel right by me.

[ASpoonPlaysGames]

No, the answer to "I installed this mod but it doesn't work" should always be, "use a mod-manager", so there's no point in adding fault tolerance for manual install :P

Surely though simply being more tolerant to mods in the wrong folders etc. will simply reduce the need for mod managers in general? Whilst I agree that 95% of people should be using a mod manager, imo it is better to allow for either option to be as easy as possible. The people who choose to manually install over using a mod manager, but still cannot install mods properly annoy me when they ask for help installing mods, this would help alleviate my annoyance

No. A mod-manager does not only need to handle discovering the mod but also removing and updating it etc. This gets even worse when suddenly someone starts to through different mods into the same folder.

Emphasis on "should". A mod manager really should only be looking in directories for files once (or when a refresh button is pressed) and the paths to the mods should be stored, then the mod manager should just use those stored paths for everything. One mod.json = one mod, as far as launcher is concerned. Mod managers that deal in thunderstore packages should really be encouraging this change, because it makes managing these mods easier.

Writing a mod-manager myself I can tell you from experience that this is not the case. A user installing a mod-manager expects the mod-manager to pick up existing mods so a mod-manager that doesn't do that is considered "broken". Further if I e.g. update FlightCore to just drop the whole folder in there and e.g. Viper hasn't updated yet, then it won't be able to pick up the installed mod. Further the mod won't even show up in Viper and if it's a broken mod, now the user doesn't even have a way of removing that mod.

If a mod manager deals solely in thunderstore packages, then picking up existing mods and managing them is already impossible really. If the mod manager also deals in mods, then this change is only beneficial, as new mods could be dealt with as packages instead. Finally, if the mod manager only deals in mods, then they honestly need to refactor their approach, we have been using thunderstore packages for a long time now, and if a mod manager doesn't support them in a good way (just splitting them into mods and installing the mods doesn't count) then that's not really within the scope of this PR.

As for the example, if one mod manager is updated and the other is not, then that is an issue that is very much beyond the scope of this change, as well as being an issue that would affect any mod loading change, thus it is irrelevant.

This has already been solved via 0neGal/viper#165 and is implemented by all major mod managers (minus r2mm which keeps it mods separate)

I personally was never particularly happy with this solution honestly, because a single mod could be owned by multiple packages in theory.

With this solution, the txt file containing the thunderstore author would be overwritten, and the mod would be owned by a single package, then if that package is deleted/disabled you have inadvertently broken a different package. Whilst this would already happen with dependencies, the difference here is that you have no way of knowing without re-downloading all packages and checking their contents.

Using this PR, the existing txt solution becomes simpler. Since there is still no way to determine the full thunderstore dependency string from a thunderstore package, the txt file would still be generated, however it would be put alongside the manifest.json, icon.png, etc. in the package folder, not in each mod's folder.

To step back here for a moment, I agree that we need some update/refactor that allows us to cleanly handle Thunderstore mods. When Northstar was first release Thunderstore integration wasn't a thing yet. Now if/when we do refactor to better support Thunderstore stuff, we need a proper change, maybe even a new mods directory. Trying to shoehorn a small change in that primarily targets adding fault tolerance to manual install just doesn't feel right by me.

I agree that the mod format could use a bit of a refactor at this point, but I don't see how this change can be considered small?
(other than LOC)
What other sort of refactor could really be done, other than splitting the mods folder into a mods and a packages folder? (which for the record, I think is a bad idea)

[GeckoEidechse]

Surely though simply being more tolerant to mods in the wrong folders etc. will simply reduce the need for mod managers in general?

No cause manual install tends to be a "set and forget". Meaning that mods don't get updated on new release. This results in tickets once a Northstar release breaks a the older version of a mod even though the mod author updated the mod.

Emphasis on "should". A mod manager really should only be looking in directories for files once (or when a refresh button is pressed) and the paths to the mods should be stored, then the mod manager should just use those stored paths for everything.

This falls apart the moment the user manually installs/deletes a mod or user another mod-manager to perform the same action. I specifically designed FlightCore to use the mods folder as the source of truth for this reason as it allows for full compatibility with manually managing mods.

If the mod manager also deals in mods, then this change is only beneficial, as new mods could be dealt with as packages instead.

That's what all major Northstar mod-managers (minus r2mm) do at the moment and all of them will have to be updated to handle the change of this PR.

With this solution, the txt file containing the thunderstore author would be overwritten, and the mod would be owned by a single package, then if that package is deleted/disabled you have inadvertently broken a different package.

Only if the dependency is packaged as a Northstar mod in a single Thunderstore mod. If it's properly listed as a Thunderstore dependency, then the thunderstore_author.txt and manifest.json is attributed correctly.

I haven't seen anyone package a dependency Northstar mod into a Thunderstore mod and if it does occur then it would also be wrongly attributed when using the whole Thunderstore mod as a "package". In fact in that specific (unrealistic) edge case, the proposed solution with "packages" would make things worse you could now have duplicate Northstar mods in two different Thunderstore packages.

[ASpoonPlaysGames]

This falls apart the moment the user manually installs/deletes a mod or user another mod-manager to perform the same action. I specifically designed FlightCore to use the mods folder as the source of truth for this reason as it allows for full compatibility with manually managing mods.

This is not what I meant. I should've been more clear probably but yeah the mods folder being the source of truth, but only scanned for mods once on launch, and those paths are then stored (in memory), the actual directories would never be scanned again until either a refresh button is pressed, or the program is closed and reopened

Only if the dependency is packaged as a Northstar mod in a single Thunderstore mod. If it's properly listed as a Thunderstore dependency, then the thunderstore_author.txt and manifest.json is attributed correctly.

I haven't seen anyone package a dependency Northstar mod into a Thunderstore mod and if it does occur then it would also be wrongly attributed when using the whole Thunderstore mod as a "package". In fact in that specific (unrealistic) edge case, the proposed solution with "packages" would make things worse you could now have duplicate Northstar mods in two different Thunderstore packages.

I'm not talking about dependencies here. A single mod (name) may be in multiple thunderstore packages, this is normal, expected behaviour that is guaranteed to happen eventually. For example: if S2 was to release a second glitch overhaul package, that looks visually different, they might re-use some of the mods from the original package, instead of refactoring out the duplicate mod as a dependency. Since neither thunderstore nor northstar enforce this in any way, the issue with thunderstore_author.txt arises, but is solved with this PR

As for making things worse with duplicate northstar mods in two different packages, I mentioned that originally. We already have this problem when someone installs two different mods with the same dependency in different ways. You end up with two differently named folders with the same mod.json, a duplicate mod. Launcher handles this kinda fine as far as I can tell, and we would not be introducing any new issues here, since it already exists and happens.

[BimNoah]

Late response cus my PC crashed near the end of writing this comment and it didn't save, man I should rly buy new ram that isn't broken. (I hate my life, it happened 2 times now)

1. We really don't want to encourage manual mod installs. Players should really just use a mod-manager, especially if they aren't even able to properly manually install a mod.
   Additionally mod-managers can handle (auto-)updating mods which given that occasionally mod authors or Northstar introduce breaking changes is a must.

I see your point, but honestly I would want to make the mod installation process idiot proof, rather than recommend a mod manager every single time. To me, this, more or less, just says: "Everybody should use a mod manager", which I don't think is the most user friendly way. . .
Tho, if I'm honest, I'm just not the biggest fan of mod managers, thus this opinion may be influenced by that.

Just throwing this in here cus I think it explains the state of mod installation atm

2. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

It won't tho. . .

Viper manages that already

https://github.com/0neGal/viper/blob/72c3c54dbf24819072fc38eaf552b5870d6bbe57/src/modules/mods.js#L305-L323

VTOL also checks for weird formatting

https://github.com/R2NorthstarTools/VTOL/blob/d50333b9eef4c15f94904f9c9b29cf7a4e8043d5/VTOL_2.0.0/Pages/Page_Thunderstore.xaml.cs#L3052-L3071

FlightCore doesn't do that, therefore it's Cringe, yes yes

https://forge.greenboi.me/emerald/thermite/src/commit/78bf7ca4c26817a54049a6f59fef8162f28fd691/src/core/manage.rs#L204-L224

So as it seems, somehow it doesn't break "All" the mod managers, but only FlightCore. . .

Alle Angaben ohne Gewähr

3. I don't know how this deals with Thunderstore mods containing multiple Northstar mods. Does it load them all properly? Did anyone actually test that scenario?

I'm really unsure of what you mean by that, but Spoon tested that if I'm understanding your question right. Anyway, the screenshots below should hopefully clarify the whole situation.

idk if that is what you wanted to be tested, but here you go. I hope that clears things up. If you were asking about multiple mod.json in one dir, than no, that won't work.

I'm gonna be honest, I've saw like 4 users in the span of like five hours asking why their mod doesn't work, therefore I made this PR. . .

---

1. We really don't want to encourage manual mod installs. Players should really just use a mod-manager, especially if they aren't even able to properly manually install a mod.
   Additionally mod-managers can handle (auto-)updating mods which given that occasionally mod authors or Northstar introduce breaking changes is a must.

This won't change our stance on manual installs over mod managers, with mod managers already being preferred. All it will change is how difficult manual installation is, meaning fewer tickets

No, the answer to "I installed this mod but it doesn't work" should always be, "use a mod-manager", so there's no point in adding fault tolerance for manual install :P

Plz tell me this is meant as a joke, plz.

Anyway, I have once issue with this PR. If we were to merge it we wouldn't really endorse the "right" mod structure anymore, which in return would really trigger my OCD.

(b'-')b

[GeckoEidechse]

Since neither thunderstore nor northstar enforce this in any way, the issue with thunderstore_author.txt arises, but is solved with this PR

You would still have a duplicate Northstar mods and honestly, I have no idea how the game handles loading the same mod multiple times, especially on different versions.

In particular, I'm talking about a scenario like this @BimNoah

mods
├───S2.Glitch/
│   ├───EladNLG.Modsettings.v1/
│   └───S3.GlitchTree/
└───S2.Wargames/
    ├───EladNLG.Modsettings.v2/
    └───S3.WargamesWall/

 

3. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

It won't tho. . .
Viper manages that already
https://github.com/0neGal/viper/blob/72c3c54dbf24819072fc38eaf552b5870d6bbe57/src/modules/mods.js#L305-L323

VTOL also checks for weird formatting
https://github.com/R2NorthstarTools/VTOL/blob/d50333b9eef4c15f94904f9c9b29cf7a4e8043d5/VTOL_2.0.0/Pages/Page_Thunderstore.xaml.cs#L3052-L3071

No, the sections you linked to are for installing non-wellformatted mods such that they are wellformatted. They do not handle mods once installed in non-wellformatted way.

(and FlightCore doesn't support installing non-wellformatted mods by design to pressure mod authors to format their mods properly)

 

No, the answer to "I installed this mod but it doesn't work" should always be, "use a mod-manager", so there's no point in adding fault tolerance for manual install :P

Plz tell me this is meant as a joke, plz.

No I am serious.

To me, this, more or less, just says: "Everybody should use a mod manager" [...]

Again, yes, that's exactly what I mean ^^

[...] which I don't think is the most user friendly way. .

agree to disagree :P

[BimNoah]

3. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

It won't tho. . .
Viper manages that already
https://github.com/0neGal/viper/blob/72c3c54dbf24819072fc38eaf552b5870d6bbe57/src/modules/mods.js#L305-L323
VTOL also checks for weird formatting
https://github.com/R2NorthstarTools/VTOL/blob/d50333b9eef4c15f94904f9c9b29cf7a4e8043d5/VTOL_2.0.0/Pages/Page_Thunderstore.xaml.cs#L3052-L3071

No, the sections you linked to are for installing non-wellformatted mods such that they are wellformatted. They do not handle mods once installed in non-wellformatted way.

Ah okay, I just understood you wrong, my bad.

[...] which I don't think is the most user friendly way. .

agree to disagree :P

Opinions vary

[BimNoah]

In particular, I'm talking about a scenario like this @BimNoah

mods
├───S2.Glitch/
│   ├───EladNLG.Modsettings.v1/
│   └───S3.GlitchTree/
└───S2.Wargames/
    ├───EladNLG.Modsettings.v2/
    └───S3.WargamesWall/

This works as expected.

If that still isn't what your looking for, refer to what Spoon said:

If you want to test this yourself then feel free

[GeckoEidechse]

In particular, I'm talking about a scenario like this @BimNoah

mods
├───S2.Glitch/
│   ├───EladNLG.Modsettings.v1/
│   └───S3.GlitchTree/
└───S2.Wargames/
    ├───EladNLG.Modsettings.v2/
    └───S3.WargamesWall/

This works as expected.

If that still isn't what your looking for, refer to what Spoon said:

If you want to test this yourself then feel free

That's not the example I mentioned. The one I mentioned is

mods
├───Northstar.Client
├───Northstar.Custom
├───Northstar.CustomServers
├───S2-Glitch
│   ├───EladNLG-ModSettings-2.0.2
│   │   └───mods
│   │       └───EladNLG.ModSettings
│   │           └───mod
│   └───S2Mods-GlitchOverhaul-1.2.7
│       └───mods
│           ├───S2.GlitchAutoLighting
│           │   └───mod
│           ...
└───S2-WarGames
    ├───EladNLG-ModSettings-2.0.2
    │   └───mods
    │       └───EladNLG.ModSettings
    │           └───mod
    ├───S2Mods-ClientKillCallback-1.0.0
    │   └───mods
    │       └───S2.ClientKillCallback
    │           └───mod
    └───S2Mods-WargamesOverhaul-1.0.2
        └───mods
            └───S2.WargamesOverhaul
                └───mod

which does not work due to duplicate file loading

[ASpoonPlaysGames]

That's not the example I mentioned. The one I mentioned is

mods
├───Northstar.Client
├───Northstar.Custom
├───Northstar.CustomServers
├───S2-Glitch
│   ├───EladNLG-ModSettings-2.0.2
│   │   └───mods
│   │       └───EladNLG.ModSettings
│   │           └───mod
│   └───S2Mods-GlitchOverhaul-1.2.7
│       └───mods
│           ├───S2.GlitchAutoLighting
│           │   └───mod
│           ...
└───S2-WarGames
    ├───EladNLG-ModSettings-2.0.2
    │   └───mods
    │       └───EladNLG.ModSettings
    │           └───mod
    ├───S2Mods-ClientKillCallback-1.0.0
    │   └───mods
    │       └───S2.ClientKillCallback
    │           └───mod
    └───S2Mods-WargamesOverhaul-1.0.2
        └───mods
            └───S2.WargamesOverhaul
                └───mod

which does not work due to duplicate file loading

This is expected behaviour, though that file structure is kinda weird and not what I would expect

[ASpoonPlaysGames]

A valid point that gecko brought up in discord is that VTOL currently "disables" mods by placing them in subdirectories, this PR would break that atm.

[GeckoEidechse]

This is expected behaviour, though that file structure is kinda weird and not what I would expect

Yes and my point is that it's a lot harder to troubleshoot then requiring mod.json to be in root dir of each nsmod.

A valid point that gecko brought up in discord is that VTOL currently "disables" mods by placing them in subdirectories, this PR would break that atm.

To give more context, VTOL is around 1/4 to 1/3 of all Northstar users.

Given that this change could impact mod-managers, it might be fair to have @0neGal, @BigSpice, and @AnActualEmerald give their opinion on this as well.

[0neGal]

Given that this change could impact mod-managers, it might be fair to have 0neGal, BigSpice, and AnActualEmerald give their opinion on this as well.

I think that if this were to be merged, it should be held back until at the very least Viper, FlightCore and (especially) VTOL supports it, as to not break anything.

I'd also point out that this is not very good for backwards compatibility, most clients won't fetch the mods right at all, and like with VTOL currently, Viper used to move disabled mods into a separate folder. While that's overall a minor issue, currently if I launched the first public release of Viper right now, it'd actually work just fine, again minor, but something to keep in mind.

Overall, I'm not against this change from the perspective of the user, but having a (mostly) standard mod folder structure, and then more or less saying "oh but you can ignore most of it, and put anything anywhere you want", will inevitably cause breakages and a lot of mod creators and users will be creating all sorts of weird folder structures.

3. This will "break" all mod managers in the sense that they do not expect the mod.json in a subdirectory and as such will create more edge case installations that need to be handle.

Updating mod managers to handle this should take about 4 lines of code changed, maximum

No. A mod-manager does not only need to handle discovering the mod but also removing and updating it etc. This gets even worse when suddenly someone starts to through different mods into the same folder.

I would also like to ditto what Gecko is saying here, it is not just 4 lines of code... While yes, it won't take too many to get it "working", one thing to consider here is how we handle deleting and updating, that, will really take a lot more. Take the following folder structure:

mods
└── packages-of-mod
    ├── mod_subfolder
    │   └── mod.json
    └── mod_subfolder2
        └── mod.json

How should a mod manager realistically and properly delete the packages-of-mod folder? Realistically, we can't, not without guessing and hoping we get it right, and this only gets more complicated the more recursive you go:

mods
└── packages
    ├── mod_subfolder
    │   └── mod.json
    ├── mod_subfolder2
    │   └── mod.json
    └── packages2
        └── packages
            ├── mod_subfolder
            │   └── mod.json
            └── mod_subfolder2
                └── mod.json

Or even just:

mods
└── folder
    └── packages
        ├── mod_subfolder
        │   └── mod.json
        └── mod_subfolder2
            └── mod.json

Do we delete just packages? And or also folder? And should all these subfolders be counted as one mod, and how would that be determined, and if not, deleting one of them shouldn't delete the parent folders, but should deleting the second one afterwards then remove the parent folders?

And this is just removing mods, another problem entirely is updating mods, which would also have to account for these changes.

And so, I'm not entirely certain that going away from a (mostly) strict folder structure is a good idea, with all this in mind, at least not from a mod manager perspective.

There's obviously some solution to all these problems, but I highly doubt every mod manager will support it, especially to the same degree, which makes interoperability very hard. Feel free to let me know if I'm missing something here however.

[BobTheBob9]

this feels weird, making your actual mod be buried a few layers into a mod folder feels like it could needlessly complicate things to me, and mod collections could be done with a more purpose-built feature than this

[BobTheBob9]

a solution to this could just be to have more obvious errors/warns for issues like this (e.g. automatically detecting folder has no mod json and logging something for that), maybe something that shows ingame perhaps?

[F1F7Y]

We could add a warnings tab to the mod menu which could show stuff like "Folder missing mod.json", "mod.json detected in incorrect folder", "This mod is fucked", etc...

Would be pretty easy

[ASpoonPlaysGames]

We could add a warnings tab to the mod menu which could show stuff like "Folder missing mod.json", "mod.json detected in incorrect folder", "This mod is fucked", etc...

Would be pretty easy

Sure, but I would vote against it being in the mod menu, as most players don't even look at it. It should be a dialog or something that the user cannot miss as easily

[GeckoEidechse]

We could add a warnings tab to the mod menu which could show stuff like "Folder missing mod.json" [...]

Be careful with that one. Cannot speak for other contributors but personally I have my mods folder as a git repo, i.e. if I want my core mods to be on git main branch I can just do a git pull. So checking for "missing mod.json" means that you'll get a warning each run cause it cannot find mod.json in .git and .github folder.

My Titanfall2\R2Northstar\mods

Similarly disabled folder from VTOL will cause the same error message to pop up.

Recursive mod.json search and corresponding warning should be feasible though.

[Alystrasz]

Be careful with that one. Cannot speak for other contributors but personally I have my mods folder as a git repo, i.e. if I want my core mods to be on git main branch I can just do a git pull. So checking for "missing mod.json" means that you'll get a warning each run cause it cannot find mod.json in .git and .github folder.

(A good way to avoid this is cloning your NorthstarMods fork somewhere outside of your game directory, and then creating a symlink replacing mod folder with your working mod.)

[BobTheBob9]

We could add a warnings tab to the mod menu which could show stuff like "Folder missing mod.json" [...]

Be careful with that one. Cannot speak for other contributors but personally I have my mods folder as a git repo, i.e. if I want my core mods to be on git main branch I can just do a git pull. So checking for "missing mod.json" means that you'll get a warning each run cause it cannot find mod.json in .git and .github folder.

My Titanfall2\R2Northstar\mods

Similarly disabled folder from VTOL will cause the same error message to pop up.

Recursive mod.json search and corresponding warning should be feasible though.

having a warning here wouldn't really be a massive deal imo given it wouldn't be fatal at all? but also wouldn't be hard to just not warn for any that start with a .

[BimNoah]

Okay, I'll look into a proper way of doing mod-collections and maybe also the warnings, don't hold me to the last one tho. The next PR could take a bit cus school moment, but ehhh, I'll fit it somewhere.

Closing this

(b'-')b

[uniboi]

I have my mods folder as a git repo

Me when I accidentally discard 637 untracked files

[Alystrasz]

and maybe also the warnings

If you don't have time for this, I can add it to the mods system rework tracking and do it myself. :)

[BimNoah]

and maybe also the warnings

If you don't have time for this, I can add it to the mods system rework tracking and do it myself. :)

@Alystrasz that would be great, since for the last couple of days I've rarely been infront of the PC and I don't think this will change in the next couple of days and maybe weeks. . .
(Also, I rly don't know C++, but that wouldn't be as hard to solve as my school issues rn)
thx

(b'-')b

[Alystrasz]

If you don't have time for this, I can add it to the #396 and do it myself. :)

@Alystrasz that would be great, since for the last couple of days I've rarely been infront of the PC and I don't think this will change in the next couple of days and maybe weeks. . .

I addressed this in #415 :)