#Mod Manager Discussion
1 messages ยท Page 2 of 1
just make the manager subscription based
tbh the feature creep isnt to bad yet
yeah I can open a patreon, screw all of you over and run with the money 
not Yet
๐
i think we have a solid foundation though
I'm gonna collect all the relevant knowledge into a pinned OP as well
yeah, just need to give this a week or few to settle, get mods on it and a useable frontend(s)
usually i use PoC as an entirely different acronym
PoS can also mean different things and lead to really bad misunderstandings 
"the PoS system is not working again"

that has a lot more overlap to my knowledge
wouldnt you say my frontend is usable yet?
tru
that is correct its certainly not
its functional
usable == functional?
i fixed the bad no-autopilot-mod in master manifest
btw is it possible to make it a portable program? that might be simpler for users
yes
i can even do both i need to check again but the settings should be saved independently from the .exe location theoretically
I'm talking private in a "not on the public masterlist" sense. Though it also means people can migrate to another masterlist if ever necessary.
I want to eventually provide a class library that can function as a "core"
for any frontend or cli app initiative
elaborate
well for any c# implementations anyways right?
could also try to do provide bindings or smth so multiple languages could use it
or slop port it to other languages ๐
I don't aim to enforce rules on using it or anything, but I think its nice to provide example implementations
to give idea about expected usage patterns
you better not i would die
we should and need to provide a lot of documentation for standards and everything
yes that's why I made the schema document
well yes i know i mean we definitely can improve it
absolutely
but again, aiming for version 1.0 at the start is false hope, it's better to start with the pieces you need to build a house, before trying to build an entire house
true but then we need to do it in the right order you cant build a roof without having anything to build it on after all
๐ true
Finally wrangled dotnet publish and got it working.
Also fixed the patcher so it correctky steals BepInEx's eyes when disabling mods
@autumn hamlet what Java runtime do i need
java 21 i can probably make the requirement like java 8 so more systems are directly compatible
do I need to hide from Larry if I download 21 ?
?
uh what
fun fact i (re-)learned how to code by writing a java uninstaller ๐ญ
when I was still a desktop techie
we had to roll a bunch of machines back to like java 7.40 because business reasons XD
the jvm though very good for what it is
๐
Larry Ellison
Oracle CEO
if you end up working for a place that is an oracle customer, you will understand what I meant
i better never find out then
they probably make more money extorting companies on license audit findings than on actual products and services 
manager works pretty good, pulls the dependency chain for NOTT, disables/enables stuff as expected so pretty cool ๐ป
just lacks feedback on progress
well yes
but im updating the entire ui again
will push as soon as ive looked over all the code again
also I would probably model the UI so that these two buttons are the same
yeah that got changed completly in style both
they are diffrent but they have the same vibe
but ya all the foundations are there so pretty good mate ๐ป
just one is a bigger design
gonna go full ape on a new project tonight, lmk if anything comes up but I might not read chats for a while 
i like the ui colors/pallette it kinda reminds me of the android "material you"
it literally is compose multiplatform with material library that is also used on most android apps
and you can configure it
i remembered I haven't had dinner yet so full ape mode is postponed 
ok except for installing bepinex which is like 50% done everything is done even pack exporting importing and whatever there probably are things that wnat improvement in the future but most things are done
installing + initialising bepinex would be pretty nice to do smoothly
tbh we could just have a pre-initialised bepinex package that would likely work on all systems
do you think its a good idea to just make a precofnigured bepinex.cfg file and save that
(meaing, run the game once with a clean install of bepinex, then grab all its files)
it will regenerate anything missing anyway
ik but i dont want it to be 2 steps
1 button
1 step
oh right
run game button
duh
and it won't Sh*t itself if you run the game first time with a clean fresh bepinex install with pre-existing plugins and configs
that's how I build my server image
and
it
just
works
it will just regenerate whatever's missing
that we don't have to ask people to run the game once
after the manager installs bepinex
so it can be 1 step
well yes but uh HideManagerGameObject = true how do that
I'm pretty sure if you leave a bepinex.cfg file that only has that and nothing else, it will regenerate the rest of the standard default values while keepint that as it was
i can try it just now, actually
as the cfg doesnt exist yet i cant edit it before launching it once my idea was to just have a preconfigured .cfg file in the manager that gets saved
pls do
wow thats actually way smarter then my idea of just placing it there with all things in there why didnt i think about just having that field in it
you proabbly need to define
[Chainloader]
HideManagerGameObject = true
before
well it needs to be true duh
ah ffs I didn't change it
๐
I currently have it off because i fixed my mods 
isnt the fix the mods turning it on themselfs
instead of me trying to autocinfigure that in my manager
better to have fail safe
anyway
test 2
what can i say

is always right
when the
when the config parser parses the config 
i was about to say why wouldnt the parser work if it didnt have all the fields that would have been a stupid ahh parser
well testing doesnt hurt
I like bepinex
it doesn't cause much drama
and it loads my mods
hope y'alls' mods didn't break with patch
i think mine are working
well i have like 1 mod i barely maintain every few big updates atm
Siick. Btw are addons all gonna be in a folder called pluginfolder/Addons exactly? So i know how to update my mods
that would be a good standard
well thats another thing they would be inside the addons folder in the structure extendedmod/addons/addon1/extractedzipname/extractedzipcontent
so uh if thats a problem i can change it to be the content directly in the addon1 folder
but
idk
same for mods
the zip gets extracted itself into the mod folder with modid as name not its content
if thats a problem i can change that but i believe its fine
well its not that its just imagine you have
mod.zip with id mod1
then it would look
mod1
-meta.json
-addons
-mod
--modcontent
and since everything is versioned
extendedmod/addons/id/extractedzipcontent
should be enough, no ?
i should probabbly change to this right
only thing is we need a marker inside the folder that marks what version is installed
but ya we could just put a meta json in there
when the install happens
well the meta.json contains modid the artifact object of the version and i believe a cached version of the extension for future offline modpage lookup
by i believe i mean i know i made it after all lol
it might make sense to leave a separate meta json inside addons/id/
for the particular addon
or do like unity editor, id.meta
well addons are handled just like mods just that if they are enabled they get moved in the addon folder so they too have meta.jsons
i believe with the current structure addons could even have addons themselfs
probably cleaner to have the meta inside the addon folder tbh
(ignore me again)
for offline lookup I would just save the entire manifest
that's why i have a version.json in here:
https://github.com/KopterBuzz/NOModManifestTesting/tree/main/manifest
get the version.json first,
the manifest exists locally and the version hasn't changed, use the local copy of manifest.json, otherwise download the remote one
but it might make sense to leave metadata inside the mod and addon directories
to record what version they are etc
that way
even if people can't figure out how to package and version things correctly on their release pages
yeah i will probably make it one big cached file of the manifest
not now
we could do something to keep it working
btw uhh mod exporting importing its just a lot of refrences with ids and versions it will first look locally to enable them if not found search and try to download and then enables them and disables all other mods
also this way we have at least one stable fingerprint that should tell if the install was managed or not
i dont think you understoof addons are just mods they too have meta.jsons they are handled the exact same way
cool
and when disabled they just get moved into the disabledPlugins folder with no structure
I'll get myself to bed before I start understanding even less 
what i mean by that in the disabledPluginsfolder they are independent from any mods addons folder
i shall not go to bed till ive completed some more things and made a release for some people to be able to test
i will continue to fix yappinator and then add features until its broken again
https://github.com/JUSTJ7780/Weapon-utility-mod/releases/tag/flaremanager is this ok for mod manager?
it will work but its better if you tag the releases with a version number ideally
got it
if anyone wants to try the mod manager and give feedback that be cool
https://github.com/Combat787/NuclearOptionModManager/releases/tag/1.0
if you are on linux or macos you need to build it yourself though only provided window .msi and .exe
Can you please make it portable? I hate installing software.....
@final wren
{
"id": "NOLiveryPlus",
"displayName": "Livery Plus",
"description": "A BepInEx mod and unity editor tool combo for making Nuclear option Liveries with full control over the material.",
"tags": [
"mod",
"QoL"
],
"infoUrl": "https://github.com/nikkorap/NOLiveryPlus",
"authors": [
"nikkorap"
],
"artifacts": [
{
"fileName": "LiveryPlusBepInEx.zip",
"version": "1.2.0",
"category": "release",
"type": "plugin",
"gameVersion": "0.32",
"downloadUrl": "https://github.com/nikkorap/NOLiveryPlus/releases/download/BepinexMod/LiveryPlusBepInEx.zip",
"hash": "sha256:8fc8c1676aeb314adcdaa2b4c1eb2c4245bbfc030de0e046f00afd7b23921940"
}
]
},
To:
{
"id": "NOLiveryPlus",
"displayName": "Livery Plus",
"description": "A BepInEx mod and unity editor tool combo for making Nuclear option Liveries with full control over the material.",
"tags": [
"mod",
"QoL"
],
"infoUrl": "https://github.com/nikkorap/NOLiveryPlus",
"authors": [
"nikkorap"
],
"artifacts": [
{
"fileName": "LiveryPlusBepInEx.zip",
"version": "1.2.0",
"category": "release",
"type": "plugin",
"gameVersion": "0.32",
"downloadUrl": "https://github.com/nikkorap/NOLiveryPlus/releases/download/BepinexMod/LiveryPlusBepInEx.zip",
"hash": "sha256:8ec3f19aeeda9e622dbf115e36067a337c99e091019bf0649aeb0f3c705c9acd"
}
]
},
TLDR; hash is incorrect.
New version for anyone who is interested.
Added Bep5 support
Where
Originally focused on Bep6 which is what I had installed while I designed it
thanks, though ignore hash checks for now, its also incorrect for all the voice packs
I've skipped it for voice packs.
It's only for plugins mostly.
I'll fix the liveryplus hash after โ
nikko is working on new release structure for yappinator so currently available voice packs will have viability for hash checks too, soon
should be fixed, static page is redeploying now
thank you for the report 
I think mine are okay ? Can't check before tomorrow, I'm away for the weekend
uh it is? i provided a exe except you mean it isnt portable cause it saves 1 small config file
added bepinex configuration manager to the mod list
so it can be added as dependency for other mods
added it to noblackbox and nott
add rue
what's rue
runtime unity editor
oooo
good shout mate I didn't know this existed
i might have some good use for this today actually ๐ป
gonna go for a walk now then will add it when I'm back
๐ฅฆ
or
NO
MM
totally original idea
bruh
RUE added
one sec
I randomly had an idea
very generic kinda
but still
sure looks better then mine lol
i like it but the coloring is a bit simple but if you are gonna improve them a bit more id be happy to use them you just need to send it to me as a 256x256 png that should be fine
Yellow might pop a bit and still fit with the nuclear theme
@pliant pine the manager doesnt really have one theme color as you can change it so dont base the color on the images of the manager i send before
@autumn hamlet
cool thanks will credit you in the readme
it currently looks a bit weird when its small in the taskbar can you maybe like make the detail bigger and the spaces between the things bigger else they visually merge when to small
how about this
@pliant pine can you remove the outline and reduce the teeth count on the gear to like 8 and make the space between the gear and the outer things bigger
sure
oh, check dms btw
It looks really good !!!
looks really good
what about somthing like this?
could we have multiple options like he colours?
It's more the idea of the MM (ModManager) letters, i made the mockup in paint lol
I personally prefer it without the letters tbh
do we want/need scrollbars in a mod manager
depends on the practicallity
well would anyone use it without a scroll wheel?
i doubt it unless laptop users?
i would add a scroll bar + page up/down
what is worth it more having a custom integrated window decoration or being able to snap the window on windows
window on windows tbf
i think so too window decorations are a real pain
You always want a scroll bar, yeah.
scrollbar it is
It's a standard visual cue that you can scroll, and you always want to ensure you follow UX/UI standards (both for accessibility reasons, as well as compatibility with more esoteric input methods)
Also just a nice indicator of "how large is this list"
so true
ok i hate launch options
it somehow caches them at multiple places and its not really a guarantee it works im just gonna show a popup telling the user to put in the options themselves when on linux
i love doing annoying plumbing work like this so i can try to help you improve setting the launch option at some point
but i think asking to set a launch option should be reasonable, its not too difficult to do, steam makes it fairly easy for the user
exactly
"To make BepInEx work on Linux you need to add the following to the Steam Launch Options for Nuclear Option.
WINEDLLOVERRIDES="winhttp=n,b" %command%"
this a good popup message?
i think it wouldnt be to hard to just kill steam for this and then set the file but i need to look into it a bit more and im not gonna do it rn im doing more essential things first
i think thats good
What issues are you having with it?
automating setting teams launch options for the game
because on proton/linux bepinex needs the winhttp.dll added to its wine config
setting them correctly in the vdf but steam just rolls it back or something no clue tbh
its fine though if you use linux you probably are competent enough to set a launch option yourself
soz i did my typical half context brain dump without thinking
Probably just want to make it a popup, yeah
tags good like this or any suggestions?
pretty good
yappinator should receive additional tag imo
especially if we will get more voice mods
like ones replacing Jennifer warnings
Yeah, that looks nice
May want to normalize tags btw, in case of multiple mods defining tags with different capitalization
we should but thats just limiting what tags someone can give a mod the tags are just a list of strings on each mod
is it possible to make some kind of filter underneath the search bar
Normalizing just means make it all lowercase, strip spaces at the ends, etc...
That way, you don't run into the problem that mod A with tag "QoL" has a different tag from mod B with tag "qol".
i thought you meant more like standardizing but yeah same thing
here
Semantics are important in programming :P
Ideally, it'd have some kind of smart search/multi-filter tbh.
it definitely is the thing is am i willing enough to do that rn
yeah i was already planning integrating it into the search
anyone want to test?
one sec will send link soon
@pliant pine
cancel the release i havent yet added scrollbars
๐ด
@final wren should i already make a dedicated mod manager thread in the mod forum or should we wait till the manifest is a bit more complete
if you think its mature enough i have no issue with it
i will do it tomorrow (today) and we need to get more mods into the manifest asap
ok
tested themes
i figured
though simple "everything works" would be sufficient
if you want you can uninstall bepinex and try the bepinex installer i just remmebered i havent yet added the loading to bepinex install button but it still installs probably
havent tested that once yet tbh
it works
epic
it
just
works 
@autumn hamlet cookin crazy
ok 2 more things i believe are missing scrollbars and bepinex install button status as well as safety for not being able to click it multiple times
actually i will do those real quick
and then i think
i can basically release it for real
just got done with all those changes
I'll give it a try and send you my feedback if any.
very epic
Is this normal?
I have already installed mods, it just doesn't like them very much.
hmmm
idk
not sure
try disabling the empty one and look in the disabledPlugins folder next to the plugins folder
most of them got detected no?
Yes, just the Json being messed up is the issue, thanks to our lazy dev ofc.
I liked that it detected the empty one, it has been bugging my game for 2 weeks now.
lol
I can finally nuke some people.
do u mean the json manifest? any error pls throw them at me with extreme prejudice
It just doesn't have all the mods, neither does it have the ones I have installed lmao, that's why.
I have resorted to more extreme measures.
i have to get some IRL shit done today and then continue working on release scraping
Same as Nikko, if you discover the secret to how to extend a single days duration to 90 hours, i am interested 
and for the time being y'all are welcome to add more items via PR
https://github.com/KopterBuzz/NOModManifestTesting/blob/main/SCHEMA.md
https://github.com/KopterBuzz/NOModManifestTesting/blob/main/SCHEMA.md#how-to-contribute-mod-manifests
Mine: https://gist.github.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsPrimary
Yours but with my touch: https://gist.github.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsSecondary
Mine but with your touch: https://gist.githubusercontent.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsTesting
Yours: https://kopterbuzz.github.io/NOModManifestTesting/manifest/manifest.json
@final wren
public Dictionary<string, string> ManifestSources { get; } = new()
{
{ "Primary Source", "https://gist.githubusercontent.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsPrimary" },
{ "Secondary Source", "https://gist.githubusercontent.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsSecondary" },
{ "Development Source (UNSTABLE)", "https://gist.githubusercontent.com/NaghDiefallah/82544b5e011d78924b0ff7678e4180aa/raw/NOModsTesting" },
{ "Community Source", "https://kopterbuzz.github.io/NOModManifestTesting/manifest/manifest.json" }
};
I hate to say this
but thats not a pull request
otherwise, if this is about implementing multiple manifest sources, that's handy
is there rate limit consideration for gists ?
Yeah, it's not about PR lmao ๐
It's just my app using different sources in case 1 breaks.
yaya sorry
Nope, haven't hit it for more than a week now.
nice
i guess we will see if it scales
its up to the front-end to implement source handling tbh but thats a good pattern
Yeah I have it handle all these sources at the moment, yours is working perfectly, mine is broken af.
I'm gonna work a bit on auto-updating and auto-publishing master manifest
but i need to get some paperwork done
applying for masters and its opening today
Damn, good luck with that.
Don't worry about auto-updating it's simple.
When will we be able to use the mod manager? ๐
now https://discord.com/channels/909034158205059082/1467341462227124305 the manifest just doesnt have a lot of mods yet
will the mod manager update mods that are on the manifest if if they were manually installed?
maybe? but just uninstall it and install it from the manifest again
i need to finish the manifest automation ๐ญ
yes you do
why do i pay for this ๐ญ
real
its working now
so what exactly do you want to do for manifest automation
I will extend the schema with non-required properties for github repo owner and repo name
then parse the 3 latest release and generate artifacts for them in the meta manifest, for any mods where those properties are available
why not check which of the releases doesnt haave a artifact yet and and those to the artifacts
i guess that wasn't obvious but that would also be covered
im sure you know what your doing
the only problem I foresee is when people put multiple release packages into one release and there is no obvious way to tell which one is the actual mod artifact...
V E R B O T E N
E
R
B
O
T
E
N
or you need to predefine what the name of the mod file is
wait a minute
is that why you wanted to add that
that was before the previous brainwave
since then I realised that I can do loads of github api calls
but yeah ideally people will be nice and keep their addonpacks in separate releases, so our job will be easier
question, how hard it would be to make images/previews for mods in NOMM?
how would you know what release is what mod
it seems like a good next move
they would have to be stored somewhere
I don't want us to make a system with running costs that goes beyond the 5 quid I pay monthly for github premium
this
ideally we have a system anyone could continue after us through forking it
i believe you can post images to the github and maybe the mod manager would show that plus description?
anonymous direct access to repos is rate limited to 60 per hour what do you think will happen when more people start to use the manager
maybe we can do it with free cloudflare but that needs to be explored and confirmed
honestly i have no idea in this field i just remember icarus mod manager having the feature lol
well 60 per person per hour but same thing if we have 60 mods that hit the limit and that doesnt take into account reloading
i guess you could cache images locally but the rate limit still stands
that would need to be done but we would need to then get some sort of hash for the image in the manifest and so on
and still 60 images per hour so in the first hour you can only see the first 60 images
i cant remember how icarus mm did it but youd "populate it"? it would essentially freeze for a second and download the images / descriptions
maybe we could gather a icon from every repo when doing the manifest automation and then store it in a single zip on the manifest repo
I also don't want to make it too difficult for modders, but ya maybe we could ask them to put small image in the repo with a specific name, and we could every now and then scrape repos we don't have an image from yet and maintain an icon pack release that can be downloaded by the front-end app
IMO I have a lot of other more important things to finish before I want to think about this more deeply but I think that is a viable method that's not too difficult
need some collective ๐ง
how would you keep dependency chains safe with automated artifact updates
Just an optional icon.png, or a relative path in the manifest
I'm writing a workflow to pull releases automatically via github api for the mods where its viable, and automatically update the manifest artifacts for those
not all releases, n, n-1, n-2 would be enough i think
Wait, what exactly?
Why would you do that?
what are your concerns
It seems like an overcomplication at best, and a way to accidentally get stale data in the manifest at worst.
Why do anything more than just:
- keep a list of repo URLs
- have the client iterate over those to read (and potentially cache clientside) their manifests?
the client won't be doing this
the manifests are stored at a central location and published on a static page
Wait, what?
there will be an entire chain of guardrails to stop crap from getting into it
I'm basically writing a back-end using github actions ๐
I was under the impression each mod could just have a manifest in their repo, and a mod manager could read those
yeah and that way we have 1000 people making 100000 typos in their json
I don't want that
Yeah:
- Mod manager has a masterlist of repos
- Repos contain their own manifest, and hence are in control of their releases
That's their problem / you filter those out
Not a fan at all of a cached manifest list tbh. I want to be in control of what releases I serve / which ones I pull from rotation for whatever reason / etc...
(Heck, you could even make a GitHub action that opens an issue on their repo if it detects an invalid manifest, if you really wanted to)
I don't think we fully understand each other, but we will still be very much in control of what gets served
nothing will be allowed to be merged automatically
From what I understand, you seem to imply your repository will update its own master manifest with manifest entries of mods?
Generated based on their releases?
after it gets checked and approved
That seems like an unnecessary step over just having a masterlist of repo urls and letting the clients fetch & cache them
And again; chance for stale data, reliance on an approval flow & github actions, lack of control on mod authors' end if they want to change things / remove a release / etc...
โจ```
"githubOwner" : {"type": "string"},
"githubRepoName" : {"type": "string"},
"autoUpdateArtifacts" : {"type": "boolean"},
if these are not present in the mod manifest it won't be auto-updated
do you know what the rate limit considerations are for having the manifests in each individual repository and fetching from there?
anonymous requests have been neutered quite a lot last year iirc
Hm, do they have docs on it? Not sure if there's a per-repo rate limit or a global one (or both)
If you have direct links to manifests, at least you're doing relatively few calls
so if you have more than 60 mods in the list you are cooked
unless you can change your public ip very quickly 
Hm
the main advantage of my design is you can just serve a json blob from a static page that will have either non-existent or very robust rate limit
so it can take a lot of users
what you mean
just either take the dependencies from the last artifact or require ther eto be a meta.json with dependencies in the release if they want to change it
Then you're still iterating through all of those releases though
Unless you cache that too, I guess
(this isn't done on the client)
no im talking about the automation this would be the caching process
we are talking about the automatic manfest generation on the repo
I keep coming back to the issue of stale data & ownership / release flow control, though. Not sure what an ideal fix is.
all the stuff we are currently discussing is in my local dev branch and not visible yet
?
elaborate
I explained it a bit higher.
well we basically need to have a central manifest there is no real way around that without hitting the api limit
and it is a proven system its basically what ckan does
(and its already hard enough to get everyone to create a proper release package without fairytale tagnames)
etc
TL;DR:
Not a fan of a repo caching data that might be changed / removed. Can lead to stale data, and takes away control from modders in case they need to e.g. pull a version that has issues, or want to remove specific versions for whatever reason without it still showing up in the manifest (unless a PR is made to remove it, but that relies upon the maintainer to remain active). It also adds a lot of moving parts.
Doesn't CKAN pull from Spacedock?
well no it has a master manifest that autmatically searches for new releases on github and spacedock and another platform
like if someone deletes their github and the automation can't find any releases, what do you think should obviously happen
we can add that during the automatic manifest generation when we cache releases we can check if any releases disappeared and remove those
Are you handling all edge cases?
- Version removal
- Version re-release with different manifest data
- Changing old release manifest info in a new version
- etc...?
not currently as everything is still in development but I am capable
what you mean changing old release manifests info into a new version?
bro is capable indeed
I will be thinking until someone has to put me in a coffin
and nothing will happen
i think we had a similar discussion previously
if you have any better suggestions you are welcome to give them
my first idea also was diffrent from what we are doing now
but I do appreciate any tips and guidance
its a community project for the community
after all ๐ป
rereleases with diffrent manifest data ?
if you mean diffrent dependencies thats just bad practice imo
if someone flags that they moved from core.xy dependency to core.yz dependency that's gotta be handled somehow
what the best way for that is, idk, but it will take 2 minutes to open a PR by someone to change it
sure but by releasing a new version
or to let someone know that it has changed
true but we want most to be automated maybe we should just recavhe every release every time if that is possible
that's also something we can probably make an issue template for or something
and tie an action to it that takes care of it
Yeah, I'm reading into how CKAN handles it a bit more. I feel a bit iffy about it, but I do understand the API rate limit challenge, and if we intend on sticking with GitHub releases this might be the only realistic way.
Apologies if I came across strongly.
why though
no worries at all, I appreciate being challenged because it DOES stop me from doing stupid shit every now and then
all good you should always say if you think something is wrong we do the same
extend != dependencies
Again, above reasons. It doesn't feel clean / has a lot of edge cases to take into account. A mod distribution platform with strong mod author ownership/control and an API is better in practically every way imo; performance, artifact scanning, author control, presentation, etc... But it's not the standard in the community. Taking into account rate limit issues, this approach might be the most realistic.
the main reason I would like to stick with github releases is because it allows the entire system to basically run for free
because there are no storage costs
etc
I mean, if we opted for something like Thunderstore / another platform with an API, it would solve a lot of issues. I've used GitHub Actions to automate my releases to Thunderstore with great success in the past, for example.
But if we stick with GitHub, then I can agree this automated manifest seems like the best approach.
Thunderstore has tags iirc
yeah but
installation
yeah the wholenreason for us doing it like we are is so we can have more no specific features
not everything can work just by vomiting it into the plugins folder
I'd have to ask a friend who's better versed, but I think you can ask them to define installation methods for different types of packages iirc.
?
At least they were pretty approachable back when I last needed something
Like, custom directories / unpacking for specific types of mods
maybe
I haven't installed voice packs yet though
But in the interest of not killing your work, and not shaking up the community. Perhaps we should just stick with the current concept.
I'd feel kinda bad if we moved to Thunderstore after y'all made managers & manifest automations
well what community would be shaken up by killing this
I mean the modding community
well no one uses this really yet
Like, changing their release flow / making them get used to something new if the current system would work fine
It's cool stuff y'all made
im honeatly ok with anything thats better than nexusmods ๐ญ
obviously im all for for keeping this in use but if something else would prove better for the community i would be willing to sacrofice this
not that complicated
also mods for servers
The client peeps recommend for Thunderstore is R2ModMan. Though we could build our own client / repurpose the existing ones.
what edge cases and how would performance be affected by this compared to something else
The stuff I mentioned earlier about manifest changes / peeps pulling mods / it needing to be kept up-to-date with that / etc...
Just any abnormal editing of one's releases or manifests that the flow wouldn't pick up
It adds a buffer between the actual truth, and the source of information, and the consumer of the information
And that feels iffy to me from a software engineering pov
(Hence why I was more in favor of directly referring to a repo's manifest file URL in a masterlist - no way to have incorrect information. But obviously rate limit issues there)
But if the automated system is designed properly. It might not be an issue
i mean, imo most of these could be said about any package management system, they act as a buffer
the whole reason for the master list is to not require the client to do hundredss of requests the content of it would ideally still be controled by the modders just updated periodically
from my pov there is no difference between an out of date manifest and someone forgetting to push a release to thunderstore
Generally those have cached releases though, afaik. So they become a source of truth.
Rather than proxying a state of the truth that might not be truthful
If I change my release on the Thunderstore, that'd be equal to me changing my manifest, since they're the source of truth.
The release on Thunderstore is the actual release, not a proxy to elsewhere
you are required to upload the release to thunderstore, so it would be cached and remain accessible there, and since our system relies on github releases, imo its the same. or will thunderstore not let you delete your data if you no longer want it there?
that is true but realisticly what would that affect the user
well not exactly the same because you can go in and edit a github release and mess things up
What I mean is that you cache information, but not a full release. So if you e.g. cache that release A has no incompatibilities, but I later update the manifest to reflect that A has incompatibility B (without drafting a new release), you wouldn't have that information unless you're listening to every single repo update somehow.
Whereas if I edit it on e.g. Thunderstore, that's both the release and source of information as a single entity
(Same as querying the manifest on the repo itself, rather than a cached version)
that could be solved by recaching old releases in the automation which i believe would be fine
If it can recache things on any repo update, that would probably solve those edge cases
that's why this exists
Might be a potentially large amount of recaches though
update to the master manifest will change the version
the client should first check if the version changed
and refresh the locally cached manifest
while true that would be done in the automation so not a client problem
Does the manifest repo automation re-read my manifest on any push to my master branch?
Or only when I make a new release?
the automation will run on a schedule, not every time something changed
the client always just regets the manifests its not really limited by any api limits
5k right?
And on that schedule you're re-checking all know repos & recalculating the manifest (if it is different)?
well we could inteligwntly do the automations partially each time and just get as much as possible for the first hour and so on
yes
I guess you'd be fine then. Trying to think of other edge cases.
and if it all for some reason scales to such a magnitude that this would exhaust the rate limit, we can store the state and continue later
Could just put it on an hourly schedule tbh
ye
how many api request do we expect per mod
Limit to e.g. 4.5k per hour, store state each time.
I'm a microsoft graph api veteran and I have some skills 
That way you already build a continuation system into it
And refresh relatively often
Hm, if you refresh all repo's on an e.g. hourly basis, it might be fine yeah.
May want to think of an easy way to opt-out / remove yourself from the list.
another pr
i might spin some of the automation off into a containerised service later, probably won't take too much compute and I do have a big server with some idle cores...
But yeah, if you refresh often enough, that does temper my worries about stale states. Especially if you just do a full "rebuild" rather than only look at e.g. new releases.
yes but we should setup a github automation for just having it
so it could run itself
for now I want to keep it all as action workflows
and even if i did this, I would publish the image & resources used for it in case I have to hand it off for someone else to run
@junior geode did you already see the mod manager client i made you can give feedback on that too if you like :)
I've been busy with a job change (started today at the new employer), whilst juggling a major Nuclei rework ๐
Haven't even had time to fly and drop nukes all weekend
all good
congrats mate
Thanks! Very happy about the change. The new team is pretty awesome too.
Defo remind me though. I'll have to poke around and maybe refer to some UX guidelines I have saved somewhere. Got a friend who works in frontend, too; could ask him for feedback.
its the first real anything ui i made
Great learning experience
And UI is hard. We can hide crappy / inefficient code in the back, but any UI imperfections are immediately apparent once encountered.
I definitely respect good UI devs tbh.
its keept very simple imo
I'm not going to be derailed
I'm not going to be derailed
I'm not going to be derailed
TIL GitHub API doesn't provide the hash of the release assets ๐ญ
i guess now I understand why packer plugins' release structure for example, mandates uploading hashes as separate release assets ๐ญ
@jaunty surge @autumn hamlet we may have to abandon the hash checks until further notice because of the abovbe 
didnt implement it yet
:)
All good, I just have it not check it if it's null in the manifest lmao.
bigbrain move
I don't have braincells to finish this tonight but I have a plan
the principle will work
keep up the work lads ๐ซก
{
"authors": [
"qwerty1423"
],
"description": "Advanced flight control systems with a full-featured autopilot.",
"displayName": "Autopilot Mod",
"downloadUrl": "https://github.com/qwerty1423/no-autopilot-mod/releases/download/v4.13.11/com.qwerty1423.NOAutopilot-4.13.11.zip",
"hash": "sha256:871080eae9abd291287228701ce517ce8423228583f9cb1e19e75775f196d096",
"id": "no-autopilot-mod",
"infoUrl": "https://github.com/qwerty1423/no-autopilot-mod",
"tags": [
"Mod",
"QoL"
],
"type": "Plugin",
"version": "4.13.11"
},
I'm using this for now, it currently supports all released mods for NO, 59 in total, with all the voice packs.
Will convert it into the way your JSON works once I get enough energy.
59 already OMG
haha we just had a conversation about how a different architecture would be challenging earlier, due to the 60 request per hour limit on anonymous github requests! ๐
whith what I am working on right now, it will be enough to have the repo URLs and I can take it from there ๐
but actually the rest contains important metadata that I couldn't recover from that alone so maybe its a good idea 
who will we allow to make the last mod
port patator's hud mod to bepinex
as last mod
totally won't break the current build of the game! 
Well, one of the voice packs is missing, so that's 60. ๐
YC already does that, it's just some mods aren't even on github let alone are a release/pre.
@autumn hamlet I stole the drawer design from your app btw.
๐
remember the "The Absolute State of Mod Discovery: An Appeal to Modders" reddit post?
I'll happily take the $75 a year donation to make that happen
?
$10/yr for a .com domain, $65 for the various costs of Cloudflare Workers
I may be underestimating but I'm also excluding everything but static file storage and service
no i mean what we already basically have it all worked out on github alone with no costs?
ye
what we may still need though
is an actual domain so we can cache the master manifest on cloudflare
I mean I do own Kopter.buzz but I might want to use that for actual personal stuff...
you shall be owned by the NO community from now on your property is public property from now on
the way I understand, what we need for the current infrastructure is just caching of a static page, which is available on free tier Cloudflare
it won't do it automatically, but it can be enabled
but then again the static page rate limit of github pages is quite generous, so for the time being I do not foresee any issues
what is it
a lot of plain text fits in 100GB
btw just an anecdote about package managers and stale data/discrepancy between source of truth & actual truth
the powerbi desktop app is always out of date in the main winget repository because MS can't get their sh*t together
and because of how powerbi works, if you have a slightly out of date desktop client, everything is broken ๐ซ
and they update the app at least once a month, the download on the main website is always up to date, but the winget manifest for the app is not ๐ซ
despite the fact they are both microsoft managed products/services
at least it used to be that way, I haven't had to deal with it in a while so unsure of current state
so this is a real world challenge that can plague any package manager
hm it appears they slightly improved it, now its only 1 day difference between the release and the manifest update XD
Hell yeah
added buttons to open game related folders
I can update releases automatically now
and then after that a second pass updates the dependencies for any newly found versions
action workflow isn't done yet but I'm getting close with the puzzle pieces
any cool features one could have in the manager?
else i will release the update in a sec
https://raw.githubusercontent.com/KopterBuzz/NOModManifestTesting/refs/heads/dev/manifest/test.json
any chance you could check the client with this and see if anything breaks
easy enough as i can just change the link in the client :D
i think only "breaking change" is that hash will be null for any auto-discovered artifacts because something something github api
๐ซ
probably just gonna ditch that for now
Oh I also added downloadcounts
:/
yeah i see
will do
also
"githubOwner": "downloadpizza",
"githubRepoName": "LaserRocketFix",
"autoUpdateArtifacts": "True",
these 3 are new also
need it for the autoupdate api calls
they are non-required so can be null
in some cases
would you say thats relevant information for the client?
the first artifact of nott doesnt contain type
thats a requireed one for me rn
even though its unsused
i can make it not required on the client
ok got it to work now
my problem with type is that it comes from "nowhere" so if I just add a new mod and let the automation pull the first release for it
so I added something for that case to type it as "unknown"
and then I hand-fixed them
but the new nott artifact was probably generated before I did that
should i still show hashes or what was up with that i forgot
pushed a commit to dev so test.json should have types now
na automatic hash checks are not possible purely via github api sadly, the modder would have to upload a separate hash file aslongside the actual release ๐ญ
because the api doesnt' serve the hash you can see on the page
epic

i will still keep it in case anyone wants to add it ig
i made it non-required in my validation for now
where do i add downloadcount
if I knew I would have been able to pass the UX exam even if it wasn't open book 
maybe somewhere close to the download button ?
nah all the information is on the left you cant just put the downloadcount somewhere else
and yea ofc can't provide downloadcount for anything that doesn't have releases!
or if the release tagnames are so fffffd up that they are impossible to parse
I already have a regex snake growing to parse version numbers from tags ๐ญ
we will force anyone that wants to use this to have it on github releases :)
:
you
will
comply
im planning to combine all my weapon mods into 1 file is that better or seperate releases for the manager?
what do you mean combine them into one file? zip all your dlls up or have only 1 dll
1 dll
id imagine its fine
how does the download counter work? is it tracked by the manager or github?
@candid aspen
MY RIVAL ๐
we grab metadata from github releases
its not realtime
but will update automatically multiple times a day
I'm humbled ๐
Looking great, I find everything excellent so far, it just works

ahhhh ok
did some last minute fixes will release now
I'll push that dev branch manifest to main so the static page refreshes
should be up soon
its live
its live
hmmmmmmmmmmm
i just noticed something
what's up
dependencies get reinstalled when installing a mod
whaatever
all good
we will survive
we need to advertise the manifest and the manager among users and modders
soon
ah whatever i will fix it
Either would be fine. As a user, I personally prefer individual packages unless they're part of a cohesive bundle, I will say.
Do y'all support server mods for the dedicated server, too? 
Though I figure most people will deploy Nuclei with a Docker image anyway
elaborate
it's in library btw
how does your plugins folder look like
?
just delete it its when you install a fake manifest i should probably add a a safety
2500 empty folders.
jesus christ
hey now your not gonna run out of folders!
yeah, nothing broke when I deleted it, still kinda scary to find them like that
did you install a fake mod?
probably
you mean lorem ipsum stuff?
yes
no, I think
learning moment: if you change a release package on github, you will lose the download count for that asset ๐ซ
how do you even change a release package
click edit
delete zip file
upload new zip file
i couldn't be arsed to make a new release to fix the folder structure for noblackbox and nocursoroverride
so I just re-zipped and reuploaded to the same release
noblackbox downloadcount down to below 1400 ๐ซ
that makes sense though imagine changing your totally safe calculator.exe to notavirus.exe and it keeps it 1000m download count
me no brain
and because its count is per file not per release
btw you currently count total downloads per mod right?
ya it crawls thru all releases
maybe we can add a per veesion download count as well
and grabs the download count for release.assets[0]
ideally there is always only one asset per release

ideallly
its not yet automated right but it does work in generating the manifest?
how many api requests does it do
not counting it yet but it can page 1000 releases per call so probably in the low double digits
we should be fine for like the first thousand mods right?
the actual paging I need to double check in the api docs because
the boilerplate was made by claude ๐ซ
no the first thousand releases per mod
which is a big number
as long as you know what to ask for its actually a great tool
so unless there is literally thousands of releases per mod
unlikely
it should be one one call per mod
btw im still a bit confused on versions
i dont really know how to interpret the version in depends extends and incompats
also they are given in the order of latest first so eventualyl we can probably start ignoring ancient stuff...
but that would result in losing download count
we will burn that bridge while we have to cross it 
yes
this
well I'm assuming
if a mod comes out with a new release
and it has a dependency
if the modder was able to make a new version
it must still be working with the dependency versions
that the previous version worked with
so like is the version a minimum version or what
but then again after the artifacts meta manifests are updated with new releases
there is a second script that also checks if there are any new versions for dependencies
what about the one on incompats
and updates the dependency chains of each mod's latest artifacts
incompats I'm just copying the latest known information atm
but what does it meam to have a incompat with mod a version 2.0
incompatibilities can be higly esoteric mix of unknown unkowns
so I don't think that can be automatically updated, oustide of the domain of taking issue templates that trigger an automated version change in the incompatibility
can you have multiple incompats with the same mod
what does the manager do with that
I don't know, you should probably display a warning
obviously it can but would it
currently i just force disable other incompat mods but idk what to do with the version on the incompat does it mean that all version from that one up are incompat or all before that or only that one
this is where it comes to esoteric mix of unknown unkowns
if you have 5 mods patching getspeedofsound()
who is gonna win 
me
im gonna win
something something we will burn that bridge once we cross it something
I would just warn the user that there is a potential problem with the compatibilities and let them disable stuff as they see fit
imo that's a etter experience, instead of force disabling
sure i can do that
what if i add a option to force enable when like shift clicking the enable bypassing any checks
whatever i will add warnings
as long as your chosen method is clearly telegraphed I guess is fine
some warnings would be nice to have
will do
easy enough
maybe we add a fix incompat between property on a artifact
nah
we will do it some other day
what would that do
no clue disable the warning when 2 incompat mods are enabled
you could store that in the local meta manifest in the mod folder
I don't think I would want to add that to master manifest
btw incompats can if you havent already add them too both mods
that property isn't actually filled for anything yet
hmm
but ya that is how it should be done
well i can also do it client side
but if its done in the manofest directly it would be more practical
icon looking good btw
it serves its purpose good
btw will the manifest stay on NOmodmanifesttesting forever?
no
good to know
I don't want to just randomly rename the repo etc and since things are still getting fleshed out I dont want to touch it yet
oh btw
we have currently only the info url right what if we like add more urls one can add to their modpage
while true that would be 2 clicks and we know what happens when some users need to click multiple times
^
what I want to do: finish the automation
what I'm doing: trying to explain a developer that he needs to change the app name in the manifest so I can upload the dev version as a separate artifact to m365 integrated apps ๐ญ
at least by now they learned that the version inside the manifest needs to be incremented for m365 to validate the manifest ๐
we are going towards the right direction
one step every 6 months
see I deal with manifests all day
I should rename to Johnny Manifesthand or smth
the manifester
๐ต DOWNLOAD AND LISTEN: https://thechalkeate.rs/itjustworks
โก Follow us on Spotify: https://thechalkeate.rs/spotify
Every Bethesda's E3 showcase in one meme song. Thank you, Todd Howard, for
Fallout 76 Nuclear Winter and Elder Scrolls Blades, you are the inspiration.
๐ Love the song? SUBSCRIBE for more gaming meme music stuff and LIKE t...
For whoever's interested in Yellowcake, I'm going on vacation today, I'll try as much as I can to push the new version today, of course I don't believe in tests, we write perfect code as usual.
enjoy your vacation mate!
Thank you.
it depends on how they respond to color setting change
but i prefer the first one with the green theme
I'm being summoned to play AoE4 with my friends tonight so won't work on the back-end until tomorrow
I'll let you know before infourl changes to string array type in live manifest anyway
I'm not planning to introduce any other breaking changes
the one with the outline?
this
#1464652513704808657 message
the brown looks neat with the green
i agree but i use that color as the color for what is currently navigated
this also isnt perfect cause its just the primary color which should be used for important actions not tags
it works for me
i mean this
that's even better
perfect i just used onsurfacevariant and then used surfacevariant as text again
basically a cutout
who needs dinner stuff anyways lol
I'm not fully converted to plane yet
still need biomass
ooops
i really need to add a safeguard for when clicking download on a fake mod
The specific version that is depended upon
/incompat/etc...
We may want to do some kind of format tbh
propose one
It should flag it if 2 incompatible mods are enabled, and probably recommend mods somewhere that extend installed mods. And automatically install dependencies