[B18][Mod Updater] ModSync Ninja

[Jaxxa]

Neat, looks like I better start putting my mods up.

[frenchiveruti]

Neat, looks like I better start putting my mods up.

Yaaay! I was just about to suggest you doing so

[Nightinggale]

I released a new version of ModCheck, which can read ModSync version numbers for conditional patching and load error messages.

[Kiame]

Oh BTW guys,

If I can be of any help, I'd be happy to help. I'm a webdev amateur and I'm French (for any translation works).

Keep up the good work ;-)

Thanks kaptain_kavern!

We need to figure out how to get translations submitted. There is already a languages directory in the mod if you want to take a look. I'm working on a few things that'll add a few more fields.

[kaptain_kavern]

Already sent in the other thread, in Mods » Tools section. 

[UnlimitedHugs]

Hello!
Nice work on the mod and the website. The addition of the GitHub update pulling feature is especially appreciated.
The only thing that irks me is the lack of a public source code base. Once that is sorted, I will gladly participate and enlist my mods.

Some minor feedback:
- More specific information about the ModSync.xml file would be nice. What are the fields that one would need to keep updated? How are the change notes for each version provided?
- The text on the website is not very readable. Browser zoom does not seem to help either, and breaks the layout. A bolder typeface might improve things.

[Kiame]

We're discussing making the client side available. There's concern with security with the backend side. Due to hosting restrictions the db password and other secure values are in the actual code.

historic_os can correct me if i'm misspeaking.

As far as what needs to be updated in the ModSync.xml is the <version> attribute. The format of the version is up to you. I'm personally using a format of <rw major version>.<rw minor version>.<mod major>.<mod minor>

You can see other mods here: http://modsync.ninja/mods

[historic_os]

quick note on top of what Kiame wrote:
theres also the <SaveBreaking> tag. if any version between player's version and latest version is tagged as save breaking - true. the user is notified that updating will require a new save.

other than that, there are no more tags or attributes to the modsync file yet, we are looking to possibly add patch notes \ feature codes (for example, showing at the client that the version includes bug fixes, features or translations). but still considering the best approach that will require less amount of work from the modder.


as for source code, like Kiame said, this is mostly for security purposes. we received multiple questions about the source code. i'll open it up in private explaining the issues in details with those who asked.

[UnlimitedHugs]

Thank you for the info.
I would be quite satisfied with the client-side source code, since that is what players would be running.
Server-side source availability would promote the long-term survival of the project, but the security concerns are understandable.

[Nightinggale]

As far as what needs to be updated in the ModSync.xml is the <version> attribute. The format of the version is up to you. I'm personally using a format of <rw major version>.<rw minor version>.<mod major>.<mod minor>

ModCheck has further restrictions on <version>. In order to figure out if one version is higher than the other, I need to convert it into ints somehow. I decided on using System.Version. This mean it supports the following formats:
x.x
x.x.x
x.x.x.x
Each x has to be a number without characters, meaning RC1 or similar is not supported.

ModSync seems to support anything because apparently it just compares the strings to see if they are identical. When making version 1.5 before publishing it, ModSync told me it was outdated because 1.4 was released. If ModCheck is told the version should be at least 1.4, it would accept both 1.4 and 1.5.

[Kiame]

I made a method which will convert a period-delimited version number into an int. It also supports numbers and [A-Za-z] - it can support any character from 0-999 (assuming unicode) but i'd probably keep that fact unmentioned. It'll probably get trashed as it probably isn't needed with a design change.

warning: i have done limited testing so i'd verify this is working prior to deploying it =P

Code Select Expand


/// <summary>
/// Converts the given version string into an int.
/// Examples:
/// 0.18.1 will return 181
/// 0.1.8.B will return 1801
/// 0.1.8b will return 1801 as well
/// For the last two [A-Z] and [a-z] are converted to 00-26
/// In all cases periods are ignored
/// </summary>
/// <param name="version">The version string to convert into a number</param>
/// <returns>A number representing the given version</returns>
private static int GetVersionAsNumber(string version)
{
    int i = 0;
    foreach (Char c in version.ToUpper().ToCharArray())
    {
        // for each iteration increase the magnitude by 10
        i *= 10;
        if (c >= 48 && c <= 57)
        {
            // 0 - 9
            i += (c - 48);
        }
        else if (c != '.')
        {
            // This is a case where it's a special character (not a number or period)
            if (c >= 65 && c <= 90)
            {
                // A - Z
                // In this case the numbers count for two digits. Increase i's magnitude by 10 again
                // and add the letter's value. A will be 0. Z will be 26
                // Thus 0.18M would become 1811 (M being 11)
                i *= 10;
                i += (c - 48);
            }
            else
            {
                // This is a really unsupported character.
                // I doubt this will ever happen. I'm just going to increase the magnitude of i by 100 and hope for the best
                i *= 100;
                i += c;
            }
        }
        // else Skip '.'
    }
    return i;
}


Since versions increase in value it should be as simple as using >, ==, < for comparing versions

[Nightinggale]

The ModCheck code. It takes the two version strings ModVersion and version and convert them into Version types. Once converted, all the magic happens here:

Code Select Expand

return current.CompareTo(min) > -1;
1 = current is newest
0 = the same
-1 = min is newest

The question is which approach is the best? I mean which is the newest of 1.71 or 14.1? Your code will say 171 while mine will go for 14 > 1 

Code Select Expand

        protected override bool isTestPassed()
        {
            int index = getModLoadIndex(modName);
            if (index != -1)
            {
                ModMetaData MetaData = ModsConfig.ActiveModsInLoadOrder.ElementAt(index);
                string ModVersion = RimWorld_ModSyncNinja.FileUtil.GetModSyncVersionForMod(MetaData.RootDir);

                Version current;
                try
                {
                    current = new Version(ModVersion);
                }
                catch
                {
                    throw new ArgumentException("CurrentVersionUnreadable");
                }

                Version min;
                try
                {
                    min = new Version(version);
                }
                catch
                {
                    throw new ArgumentException("MinVersionUnreadable");
                }

                return current.CompareTo(min) > -1;
            }

            return true;
        }

[Kiame]

AHAHAHA
Yeah I assume a static world where modders don't change their version formats mid-stream. Your approach is probably better in the long run due to that. I was trying to be more inclusive and support as many strange version formats as possible.

To get around that I could make a new class with a list of numbers. Each index is the set of numbers between each period. To compare it starts at the beginning of the list and compared each index. If at any point a number is greater for the new mod it is the higher number. If everything is equal then the new or old version has an additional index it wins

[dburgdorf]

Yeah I assume a static world where modders don't change their version formats mid-stream....

I didn't actually think about this yesterday, but the problem might not even be limited to format changes.

Since I never bothered with version numbers before, when I added my mods to ModSync the other day, I just went with a simple "<Date>.<Release#ForThisDate>" format.  All of my initial ModSync updates were 171204.1, since for each mod, the update was the first on December 4.  I noticed when I updated a couple of mods yesterday, that before I updated the ModSync version, ModSync was suggesting that I "update" from 171205.1 to 171204.1.  I thought it was odd that the system didn't recognize that the higher number would be the newer version, but I just assumed that it suggested updates any time the numbers didn't match. Which actually *does* make sense, since it's probably safe to assume that a user, unlike the modder him or herself, is never going to have a "newer than current" update.

EDIT: OK, I didn't read the prior messages closely enough. I thought ModSync was already checking for "most recent," and so wanted to point out that the check didn't seem to be working. But if all it's actually doing is comparing the strings, well, yeah, my "bug" isn't a bug at all, and it's working exactly as it's supposed to.

[historic_os]

at the moment, actual version comparison is simply not worth it. the whole versioning convention in rw mods is a mess/not exists.
its unlikely that the end user will have a version greater than the developer. the only possible reasoning for that is that the user is testing a version for another version of RW for example B19. for that, we have game version added to the mods soon.

yes, it would be nice to know what's the newer version but for the example of mod sync its irrelevant. regardless, having modders use a version numbering convention would be ideal in the long run