[B18][Mod Updater] ModSync Ninja

[Kiame]

The current idea i'm working on is to have a button in the Mods menu which is "Update on ModSync" just above "Update on steam"

When the modder presses the button a new dialog will pop up with the currently selected mod's version as it is in the ModSync db. A text field which has the current mod's version (as it is in the ModSync.xml file) and a second text field which is the Security Key which was used when the mod was submitted.

From here in order for the submit button to highight the version needs to change. Whether it's just different from the previous version or mandate it's higher in some way is still up in the air.

On submit I'll probably have it update the local mod's version in the ModSync file if the update is successful on the server side.

This would only be needed if the author either does not use github or has not attached ModSync to look in github for updates.

[Nightinggale]

This would only be needed if the author either does not use github or has not attached ModSync to look in github for updates.

Yeah, autoupdates from GitHub works quite well and we should encourage people to use it. It would however be a good idea to support multiple git repository hosts.

On submit I'll probably have it update the local mod's version in the ModSync file if the update is successful on the server side.

Is there a need for that? Before I release, I have to update the version for the DLL, the readme and changelog. I scripted some of that and adding ModSync.xml to the script is rather trivial.

The current idea i'm working on is to have a button in the Mods menu which is "Update on ModSync" just above "Update on steam"

If you touch that screen, make sure you stay compatible with ModSwitch 
Also if you could add the ModSync version, like just below the target version, then it would be easier to get an overview of which versions you are using.

[historic_os]

reading version from assemblies is something we've already talked about and plan to add to this magic button kiame is working on. however, there are still many mods that don't update assembly info or use pure xml modifications with no assembly at all


as for the mod page, we are not going to break it, this is exactly why the modsync page is independent to the mod one so mod managers can still work.
we will either provide a library api that lets mod managers append the button or place it somewhere else

[frenchiveruti]

This is just a suggestion on about how I did it on an old group I used to ran with publications in my school. 
We actually just told everyone that the format was <Mainmajor>.<MainMinor>.<SecondaryMajor>.<SecndaryMinor>, and enforced it (kindly!).
If I recall correctly (this was a few years ago) I introduced the idea to my group because of Fluffy's mods version scheme.
And just left it there as a sticky and anyone who came by to "innovate" at least won't be messing everybody else around with his creativity. 

Also, I don't know if there's a better method of versioning in Rimworld Mods. It's just placing it on the MainPost or the ModSync Ninja guidelines for the modder who wants to add his mod and just follow the Rimworld scheme (I think Kiame now does that of version numbers). 

Something like <RimworldMajor>.<RimworldMinor>.<ModMajor>.<ModMinor>, in a two character format <##>.<##>.<##>.<##>:

<RimworldMajor> #[Right now 18]
<RimworldMinor> #[Right now is 01 as there has not been any updates for B18]
<ModMajor>  #[Well, this is entirely up to the modder but it would be very wise to put a scheme for it, to avoid chaotic messes, like "a "modMajor" update comes when you migrate your mod from a rimworld version to another, starting from 1 from the first version you started in rimworld (if someone starts on A17 and updates to B18, his modMajor would be 2, but if he updates from A16, no updates for A17, and then back with B18, his ModMajor will be 3 even tho he never updated to A17]
<ModMinor> #[This is for the modder and his introduction on new features or content (or fixes!) but in the same Major Rimworld version, and resets if ModMajor goes up, just like the poor hospitality mod has to do right now, but better (he uses b18a, b18b, b18c, etc) as now you have 99 versions to use (if you use two digits) and only one line to edit from update to update]

So, for hospitality, his actual version number should be as easy as: v 18.01.07.04 (His changelog goes from A12, and actual version is "d" which is the 4th letter)

And then the issue is solved, you just need to compare section to section, is very probable that the user won't be able to install an A17 version on a B18 game, as rimworld already points that mistake out, so ModSync just has to compare two version numbers, heck, even one version number (the one on the <ModMinor> version) that already has 2 digits, so no weird "sort" rules to be applied.

Ninja Edit: I've checked out the modsync.xml file, wouldn't be easier to just add this tags with comments like mine next to each (I have no idea if you can "comment" in xml files) and the modder won't even have to "edit" the whole string, just each tag with the same names I gave out here. So If the modder updates to a new version in the same major he will just have to change the double digit number in that xml tag named "modMinor". (So to be clear, 4 different tags, 3 of which would rarely be touched by the modder).
NinjaEdit v00.02: Also, better do it now that there aren't many modders involved (yet...!) and not latter when it's harder to enforce.
Like:
<modMinor>01</modMinor> >> <modMinor>02</modMinor>


Let me know what you think!

[frenchiveruti]

Also another thing, and this is for some genius webmaster who knows how the GitHub API works. 
If you want to be able to "update on the fly" will a "release" format from github work? like, again comparing version numbers (in this case all the version numbers) with the releases tags. (I think combat extended does something like this: https://github.com/NoImageAvailable/CombatExtended/tags (check the "tags" names).
Like, I know some mod devs around here just post the releases on dropbox/Gdrive/Nexus and yadda yadda, but those on ModSync could be using the github API in it's benefit (without the need to know how it works) for easier downloads for the user, I don't say "auto updates" as that may conflict with the specific OS the user is running, but may be useful for mods that may not update the forum posts correctly (which involves even less lines and user mistakes for the modder to worry about!).

The thing would be something like:
Check if mod is "updated".
If the user clicks update, gets prompted if it wants "forum" or "direct download".
Direct download will download the zip file attached to the GitHub "release" that has the same tag as the one that is in the "update" in ModSync [if no attached zip file is found, downloads the source in zip format, this could have some issue as for example ClimateControlMod has a source of ~150Mb and a release zip file of ~ 500kB, but better than anything].
And place it in a "ModSync downloads" folder in the mods folder.
This of course will involve some extra work but well, it will simplify both user and modder work, the only thing that now modders will have to stick to the versioning format.

[Kiame]

If you touch that screen, make sure you stay compatible with ModSwitch 
Also if you could add the ModSync version, like just below the target version, then it would be easier to get an overview of which versions you are using.

Our current thought is to have a small dll that mods that reformat the "Mods" screen can include (like harmony0.dll) which would have a function to call to get ModSync version for Mod and "Upload/Update on ModSync"

To keep hype steady the magic Update button will probably be a work in progress which changes as time goes on =)

And place it in a "ModSync downloads" folder in the mods folder.
This of course will involve some extra work but well, it will simplify both user and modder work, the only thing that now modders will have to stick to the versioning format.

Due to concerns with malicious actors putting viruses/trackers into modsync-hosted mods we're not storing mod files and instead are redirecting users to the Ludeon forum post.
It may be something we look into in the future but for now we're playing it safe.

[frenchiveruti]

Due to concerns with malicious actors putting viruses/trackers into modsync-hosted mods we're not storing mod files and instead are redirecting users to the Ludeon forum post.
It may be something we look into in the future but for now we're playing it safe.

Yeah totally I understand that.
What about my other message?

Also, as a final suggestion, add a "report bug" button for the mods? It may be only an small square icon with the shape of a bug like this one:
That links to the "github/issues" page of the modder, if given.

[Kiame]

I've not talked version number format over with historic_os. My take is to each their own. As long as the number increases it doesn't matter.

This statement is in no way conclusive and is not the 'official' answer. Just my current opinion which could change 

[dburgdorf]

My take is to each their own.... Just my current opinion which could change.

I would strongly encourage you *not* to change your mind on that point.

Personally, I have no interest in being told that I have to start using a particular version numbering system, and I haven't even *been* using a version numbering system until now. I suspect that modders who already have a system that they've been using for a while and like would have even less interest in changing. It may seem minor, but I think it's exactly the sort of trivial-but-annoying detail that could keep modders from adopting ModSync.

[Nightinggale]

My take is to each their own.... Just my current opinion which could change.

I would strongly encourage you *not* to change your mind on that point.

Personally, I have no interest in being told that I have to start using a particular version numbering system, and I haven't even *been* using a version numbering system until now. I suspect that modders who already have a system that they've been using for a while and like would have even less interest in changing. It may seem minor, but I think it's exactly the sort of trivial-but-annoying detail that could keep modders from adopting ModSync.

I agree with that. However I would encourage using a system, which is compatible with ModCheck, that is it will be based on 2-4 numbers. Failure to do so mean other mods can't figure out if your mod is updated. This is more important for some types of mods than others, but it would be a good idea not to limit other modders. For all you know, somebody might want to patch your new furniture or something like that.

[SpaceDorf]

In my oppinion the easiest way to version mods would be by Date, which most modders allready do, independent from their own version numbers.

This is how I check for updates to mods.

Is the new Version older than 3 Days, then I propably have it allready, is it younger than 3 Days I need to have it 

[Supes]

I currently have a mod in unreleased, but would I be able to change the forum link later on if I decide to use modsync with my mod?

[historic_os]

I currently have a mod in unreleased, but would I be able to change the forum link later on if I decide to use modsync with my mod?

Yes and no, we are working on adding that ability now, so whoever finishes first

[kaptain_kavern]

I'm in the same case for some WIP mods and I choose to not add them to the service until I reached 1.0 ^^

[Supes]

I'm in the same case for some WIP mods and I choose to not add them to the service until I reached 1.0 ^^

I think I'll do the same.  but it is good to know there is something in the works for WIP mods.