Author Topic: [Cross-platform] FS2 GOG/Mod installer  (Read 72274 times)

0 Members and 1 Guest are viewing this topic.

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
I haven't started to work on it on my side, so feel free to implement it. At first, I was aiming for a simple text input, but if we can parse "flags.lch", that's great. An improvement on what wxLauncher currently does would be sliders for lighting settings.

I'm currently checking which settings fs2_open supports on each platform, so we can avoid showing settings that will not be used by the engine (I'm thinking about antialiasing on Win*). It will only be a set of minor changes.

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
I've added a settings window to edit the flags. (You can reach it by clicking "Settings" in a Mod Info window or by clicking "FS2 Settings" > "Default command line flags".) Since FS2 generates the flag list itself, it should only show relevant options.
I also added you to the copyright statement, is that alright? (I should have thought of that earlier...)

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
Yes, that's fine !
(I checked the current branches, and develop is missing some of the ui files.)

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
Which ones? I'm seeing none missing...  :confused:
(master doesn't have all of them, of course, but that's because master is still the old version I first released. I'll update master as soon as develop is stable and the new package management is merged.)

BTW, would be nice if this becomes a standard (option in mod.ini ?). I guess that's what your comment in the settings window code was about, wasn't it?

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
Sorry, I was wrong, I inadvertently put the content of the master branch into the develop directory.

And yes, my comment was about this specific issue. (the settings window currently only reads available builds and lists them, but it doesn't use the user input)
« Last Edit: March 08, 2014, 06:53:56 am by Hellzed »

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
Sorry for the long slience...  :nervous:

AFAIK the current TODO list would be:
  • Update the parser for Goober's text files
  • Finish the improved mod repo logic
  • Add an auto-update feature
  • Track mod versions (and updates)
  • Check and improve OS X support

Did I miss anything?

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
No worries !

That's pretty much everything for the core features.
I'll also need to write a real working fs2_open version selector (the one I made is only a stub) since a unified build working with all mods isn't out yet. And I'll have to get ready for fs2_open Windows builds switching to .cfg files (but i'll keep the registry settings for retail compatibility). Ubuntu/Unity integration may have to be refreshed for newer distros.

Now, I have thoughts about the UI, assuming the existing UI is considered the "advanced UI". All I need will be a Qt/WebKit view, a way to parse very simple HTML templates, and use callbacks similar to the fso handler actions (play/install/uninstall mod).

I guess some files in my dropbox mod repository are outdated, i'll updated them next week.

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
@ngld : I see you have made some changes to fs2mod-py-packager in the last few days, to support Goober's installer new text files... Does it mean you're not using a json mirror any more (last time I checked, http://dev.tproxy.de/fs2/all.json was down) ?

By the way, now I see 4 big shortcomings with the text files :

- some mods are considered "parts" of other mods. Depending on the UI, for example, end users would have to know Silent Threat Reborn or Awakenings are parts of fsport to find them. To me, it's only relevant to the installer, not the user. To the user, all mods should be equal and sorted by relevant criteria (universe, before FS2 or after FS2 main story, author...)
Currently it's hard to tell if something is an optional vp or a mod of its own.

- the update mechanism is not that efficient. Look at the last version of fsport checking for ALL the old versions to get rid of their files : http://fsport.hard-light.net/installer/fsport.txt
I prefer the idea of having an "image" of a working mod directory with all checksums, and a script to keep/add/update/delete what should be in order for the mod to reach a playable state.

- overrides (an optional part of the mod changing one of the files, like fsport-mediavps changing fsport mod.ini to enable hd graphics) are currently possible with the RENAME token, but not automatically reverted when you disable the optional part of said mod.

- a mod cannot be associated with a specific build of fs2_open by default. Even if many mods use the default builds in a near future, I think it's still a useful feature.

Finally, it also misses a lot of "semantic" tokens like "AUTHORS", "MIN SPECS" etc... that are not used by the installer, but would help create better mod pages.
(adding this here : for optional files, we should also have a "recommended" flag)

Any thoughts ?

With that in mind, I'm writing a Symfony bundle that would handle storage of mod informations into a database, with user friendly forms.
My first goal is to replicate Goober's installer text files as a demo. Once it's working, I'll add parsing options (maybe text files with a few more/different tokens, or json).
« Last Edit: August 25, 2014, 11:08:13 am by Hellzed »

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
I'm rewriting the repo backend (which was the point of the packager branch). I deleted the all.json file along with some others because it was outdated.
I've written a schema for my new json format. The "requirements" will be a list of tokens (i.e. "os=windows" for the FSO Windows builds or "fso>=3.6.*" for a mod which requires FSO to be 3.6.x or newer.) Let me know if you have any ideas to improve it.

Right now you can run "python converter.py import repo.json" to convert Goober's installer text files to my json format (this example is updated every hour).
"python converter.py checksums repo.json repo.gen.json" creates checksums for all mod archives and their contents (pretty much like the "image" you described).
A big improvement over the old converter is that it only downloads changed archives which saves a lot of bandwith.

fs2mod-py is supposed to be the script you mentioned. :) The biggest problem are user changes. fs2mod-py will effectively undo all changes made by the user whenever he/she updates a mod. I guess I'll create a "user-changes" subfolder which will be ignored by fs2mod-py and passed to FSO using the -mod flag. If you want to add a new file or change an exisiting file, you'll just put the changed / new file in the "user-changes" folder.

A mod isn't supposed to change another mod's files. "Overrides" (the way you described them) aren't possible right now. After installing fsport-mediavps, you have to select it as the active mod instead of fsport to get HD graphics. FSPort's mod.ini isn't changed in any way.

Now that I've rewritten the server-side backend, I just need to finish implementing the new format in fs2mod-py. I'll make a new release once it actually works again.
If it helps your fsmoddb project, I can implement a "python converter.py export repo.json repo.txt" command which generates Goober's text files from my json schema...

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
Quote
fs2mod-py is supposed to be the script you mentioned. :) The biggest problem are user changes. fs2mod-py will effectively undo all changes made by the user whenever he/she updates a mod. I guess I'll create a "user-changes" subfolder which will be ignored by fs2mod-py and passed to FSO using the -mod flag. If you want to add a new file or change an exisiting file, you'll just put the changed / new file in the "user-changes" folder.
The good old bash script used to do this exactly, with a clear warning that all user made changes would be deleted during mod "cleaning". Steam does the same, without the warning !
The logic was in the bash script was:
- download the files list and checksums,
- if the file doesn't match or is missing, check the cached archive,
- if the archive doesn't match or is missing, download the new one from repository.
- Then warn the user that the mod will be cleaned, and if the user confirms, every file in the mod folder that's not on the new list is deleted.
It saves a lot of bandwidth indeed...

Quote
A mod isn't supposed to change another mod's files. "Overrides" (the way you described them) aren't possible right now. After installing fsport-mediavps, you have to select it as the active mod instead of fsport to get HD graphics. FSPort's mod.ini isn't changed in any way.
Sorry I explained poorly, and current fsport was a bad example, but i'm absolutely sure i have seen these kind of hacks in the past, when a mod ships with 2 versions of the same file, and a script to rename/activate the right one.
I thought about overrides because an optional file for a mod should be able to specify it own "requirements" tokens. Imagine a mod that runs on default builds, with optional extras that need an experimental build (and of course one of the requirements token should be "branch").

And I think the new json format is a very good start :)
(I may send you a proposal tomorrow about a small change, but I'm still thinking about.)

 

Offline m!m

  • 211
Re: [Cross-platform] FS2 GOG/Mod installer
@ngld: The JSON format you propose looks very promising but I noticed some things that might be worth changing:
  • Listing mod IDs as keys in the JSON object. Why don't you use an array and specify the ID in the mod object?
  • It would probably be easier if the "files" array would contain an array of objects specifying the files, example below.
  • Instead of having a "delete" array it would be nice to have a generic "actions" array that could be extended with other actions in the future (see below for an example).
  • The elements "requirements" and "dependencies" somehow sound like they are doing the same thing. I understand why you need "requirements" so that could be renamed to something more obvious like "environment"?
  • Specifying only the ID for a dependency doesn't have enough options, instead you could use an object array that can contain more data (see below for an example)

Code: (files example) [Select]
{
  "files": [
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/fs2_open_3.7.2_RC3.zip",
        "http://scp.fsmods.net/builds/WIN/fs2_open_3.7.2_RC3.zip",
        "http://scp.indiegames.us/builds/WIN/fs2_open_3.7.2_RC3.zip"
      ]
    }
  ]
}

Code: (actions example) [Select]
{
  "actions": [
    {
      "type": "delete",
      "files": [
        "test.vp",
        "foo.vp"
      ]
    }
  ]
}

Code: (dependencies example) [Select]
{
  "dependencies": [
    {
      "id": "<ID>",
      "version": "1.2.*"
    },
    {
      "id": "<ID>",
      "version": ">=1.0"
    }
  ]
}

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
@ngld :
I think I found something, and I don't know how to understand it :
 
Code: [Select]
"FSOI#FreeSpace Port.Command Briefing Animations.1024x768 Command Briefing Animations": {
     "files": [
            [
                [
                    "http://fsport.freespacemods.net/releases/"
                ],
                {
                    "tango_hi4_fs1.zip": {
                        "dest": "fsport",
                        "is_archive": true
                    },
                    "tango_hi5_fs1.zip": {
                        "dest": "fsport",
                        "is_archive": true
                    },
                    "tango_hi2_fs1.zip": {
                        "dest": "fsport",
                        "is_archive": true
                    },
                    "tango_hi3_fs1.zip": {
                        "dest": "fsport",
                        "is_archive": true
                    },
                    "tango_hi1_fs1.zip": {
                        "dest": "fsport",
                        "is_archive": true
                    }
                }
            ]
        ],
        "description": "",
        "dependencies": [],
        "logo": null,
        "submods": [],
        "requirements": [],
        "title": "1024x768 Command Briefing Animations",
        "notes": "",
        "source": "#FSOI",
        "version": "Version 1.2",
        "delete": []
    }

This submod of "FSOI#FreeSpace Port.Command Briefing Animations.1024x768 Command Briefing Animations" doesn't list any dependencies, so how does fs2mod-py know that it has to install parents mods first ? Does it read the mod <ID> and use the points "." as separators to build the dependency tree ?

In the end (if the answer to the previous question is yes), what is the difference between setting the "dependencies" and "submods" values in parent/children mod objects, and mapping dependencies from mod IDs ? (I must be missing something because it looks a bit redundant to me)

Also, how do you plan to differentiate "user facing" submods (the ones that are presented directly to moddb users) like Silent Threat: Reborn and Cardinal Spear from "technical" submods like MV_Advanced ? I don't think Goober's installer text files provide this piece of data, but the new json format should provide it.


Here's something I dashed, for native mods, but I don't think it would play well enough with Goober's text files logic to be a solution :
(and with this syntax, a "package" cannot have dependencies like other "packages" in the same mod or a "package" inside another mod, this could be an issue.
This syntax would also help me to create a user friendly "mod builder" in Symfony.)
Code: [Select]
/* Repo configuration */
// Most of this is similar to Goober's text files (http://www.hard-light.net/wiki/index.php/FSO_Installer_Text_Files)

{
    "<ID>": {
        "title": "...",
        "version": "...",
        "description": "...",
        "features": ["<FEATURE1>", "..."], //Technical details (added functionnality, models, ships) that don't fit in the description
        "author": "...",
        "tags": ["<TAG1>", "..."], //Tags allow to quickly search for a mod in the moddb
        "logo": "<will be extracted from the archives if null>",
        "notes": "...",
        "submods": ["<ID1>", "..."],
        "dependencies": ["<ID1>", "<ID2>", "..."],
        "source": "<only when imported otherwise null>",
        /* Packages would replace "technical" submods that should not appear on their own in the moddb.*/
        "packages": [
            {
                "name": "...",
                "notes": "...",
                /*A package can be :
                - "required" (always installed with the mod, in fact these are the base files of the mod),
                - "recommended" (automatically selected for installation, but the user can skip them),
                - "optional" (not automatically selected, but user can add them during the install process) */
                "status": "<required|recommended|optional>",
                "requirements": ["<req>"] //A package should be able to set different requirements that override the mod requirements (example : a high res/shader package that requires an experimental build
                "files": [
                    [
                        [
                            "<link1>",
                            "..."
                        ],
                        {
                            "<filename>": {
                                "is_archive": true,
                                "dest": "<destination path>"
                            }
                        }
                    ]
                ]
            }
        ],
        "delete": ["<file1>", "..."]
        "requirements": ["<req>"] // TODO
    },
    "#include": [
        "<repo file 1>",
        "..."
    ]
}

There is a more conservative version of this, and it may play better with the text files conversion :
(this version is more limited in terms of things we can recommend on install)
Code: [Select]
/* Repo configuration */
// Most of this is similar to Goober's text files (http://www.hard-light.net/wiki/index.php/FSO_Installer_Text_Files)

{
    "<ID>": {
        "type": "..." //Something like "MOD" for user facing mods, "ADVANCED" for technical packages, "BUILD" for fs2_open builds.
        "title": "...",
        "version": "...",
        "description": "...",
        "features": ["<FEATURE1>", "..."], //Technical details (added functionnality, models, ships) that don't fit in the description
        "author": "...",
        "tags": ["<TAG1>", "..."], //Tags allow to quickly search for a mod in the moddb
        "logo": "<will be extracted from the archives if null>",
        "notes": "...",
        "submods": ["<ID1>", "..."],
        "dependencies": ["<ID1>", "<ID2>", "..."],
        "source": "<only when imported otherwise null>",
        "files": [
            [
                [
                    "<link1>",
                    "..."
                ],
                {
                    "<filename>": {
                        "is_archive": true,
                        "dest": "<destination path>"
                    }
                }
            ]
        ],
        "delete": ["<file1>", "..."]
        "requirements": ["<req>"] // TODO
    },
    "#include": [
        "<repo file 1>",
        "..."
    ]
}

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
@m!m:
About using an array as an external wrapper for mods :  I don't know what ngld's original reason was, but in my php framework documentation they recommend using objects instead of arrays as external wrapper for a json response, in order to avoid some possible XSSI cases.
« Last Edit: August 26, 2014, 08:57:20 am by Hellzed »

 

Offline m!m

  • 211
Re: [Cross-platform] FS2 GOG/Mod installer
I didn't mean the external wrapper but the definition of the mods. I would propose something like the following:
Code: (mod definition) [Select]
{
  "mods": [
      {
        "id": "foo",
        ...
      }
    }
  ],
  "#include": [
    "<repo file 1>",
    "..."
  ]
}

  

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
@m!m
  • I'm using mod IDs as keys since it's more convienient (I can simply look them up and don't have to search a list). I could transform a list of mods into an object and get the same result. You're right, it's more consistent if the mod ID is an attribute (just like the title, description, etc.).
  • My files list is supposed to save some typing.
    If you have 5 files on 3 mirrors, using your syntax I'd have to write:
Code: [Select]
{
  "files": [
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/a.zip",
        "http://scp.fsmods.net/builds/WIN/a.zip",
        "http://scp.indiegames.us/builds/WIN/a.zip"
      ]
    },
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/b.zip",
        "http://scp.fsmods.net/builds/WIN/b.zip",
        "http://scp.indiegames.us/builds/WIN/b.zip"
      ]
    },
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/c.zip",
        "http://scp.fsmods.net/builds/WIN/c.zip",
        "http://scp.indiegames.us/builds/WIN/c.zip"
      ]
    },
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/d.zip",
        "http://scp.fsmods.net/builds/WIN/d.zip",
        "http://scp.indiegames.us/builds/WIN/d.zip"
      ]
    },
    {
      "isArchive": true,
      "destination": "/",
      "urls": [
        "http://swc.fs2downloads.com/builds/WIN/e.zip",
        "http://scp.fsmods.net/builds/WIN/e.zip",
        "http://scp.indiegames.us/builds/WIN/e.zip"
      ]
    }
  ]
}
Using my syntax I'd have to write:
Code: [Select]
{
  "files": [
    [
      [
        "http://swc.fs2downloads.com/builds/WIN/",
        "http://scp.fsmods.net/builds/WIN/",
        "http://scp.indiegames.us/builds/WIN/"
      ],
      {
        "a.zip": {
          "is_archive": true,
          "destination": "/"
        },
        "b.zip": {
          "is_archive": true,
          "destination": "/"
        },
        "c.zip": {
          "is_archive": true,
          "destination": "/"
        },
        "d.zip": {
          "is_archive": true,
          "destination": "/"
        },
        "e.zip": {
          "is_archive": true,
          "destination": "/"
        }
      }
    ]
  ]
}

It's also easier to add mirrors since you only have to add 1 line.

  • The "actions" array sounds like a great idea. Any suggestions on additional actions?
  • I'm not sure if "environment" is a fitting name for this field. It's supposed to specify all requirements (OS, FSO version, maybe CPU features, ...) that don't fit in dependencies.
I'd like to shorten your "dependencies" syntax to this:
Code: [Select]
{
  "dependencies": ["<ID>=1.2.*", "<ID>>=1.0"]
}

I don't see the point of the version requirement. Can't we just assume that a mod needs the most recent version of its dependencies?


@Hellzed
Yeah, you found a bug in the converter. I didn't test it, yet. Apparently I have to add the mod's parents to its dependencies.
The "." seperators aren't parsed in any way. It's how Goober's installer tracks dependencies. It was the easiest way to generate unique IDs for the converted mods and keep the dependency references intact. You can use pretty much anything as the mod's ID as long as it's unique.

I'm not differentiating between real submods and features. It's a nice idea but I'm not sure if it's worth the trouble. The converter would have to guess if a submod is an actual mod or a feature. How would you display the difference to the user? However, if we're going to add this, I'd pick the first example since the hierachy of mods / features is much clearer.

The XSSI concerns don't really apply here since we aren't processing user input (which could contain malicious code).

 

Offline m!m

  • 211
Re: [Cross-platform] FS2 GOG/Mod installer
Most of the JSON files will be generated automatically anyway so limiting the capabilities (every file has to have the same name on every mirror) in favor of saving some typing doesn't seem like a good idea. Instead the format should aim to reduce programming overhead.

I'm not sure if "environment" is a fitting name for this field. It's supposed to specify all requirements (OS, FSO version, maybe CPU features, ...) that don't fit in dependencies.
Well, the things you have listed describe the environment the mod will run in so the naming makes sense to me. I would also advise to have the FSO requirements specified in the dependency field. That would allow to handle executables just like a mod without much special handling.

The "actions" array sounds like a great idea. Any suggestions on additional actions?
I can't think of any actions right now but with the actions array adding a new action type should be easy to do when needed.

I'd like to shorten your "dependencies" syntax to this:
Code: [Select]
{
  "dependencies": ["<ID>=1.2.*", "<ID>>=1.0"]
}

I don't see the point of the version requirement. Can't we just assume that a mod needs the most recent version of its dependencies?
That version syntax is much harder to process and can be ambiguous which means specifying the version requirement and the id separately solves not only that problem but will also allow future expansions without breaking older mod definitions.

Specifying version requirements is needed to make sure a mod runs with the correct version of the MediaVPs. Assuming that a mod will work with the latest version of a dependency will only cause problems.

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
Most of the JSON files will be generated automatically anyway so limiting the capabilities (every file has to have the same name on every mirror) in favor of saving some typing doesn't seem like a good idea. Instead the format should aim to reduce programming overhead.
I could transform my files syntax into your syntax in the same step where the checksums are added. What do you think about that?

Specifying version requirements is needed to make sure a mod runs with the correct version of the MediaVPs. Assuming that a mod will work with the latest version of a dependency will only cause problems.

Well, here we have a problem. As long as we generate these files from Goober's text files we can only install the most recent version of each mod. If a mod depends on the 2014 MediaVPs, it has to put "FSOI#2014 FSU MediaVPs" in its dependencies. If it depends on the 3.6.12 MediaVPs, it has to put "FSOI#FSU MediaVPs, version 3.6.12" in its dependencies. Those two versions are two seperate mods in Goober's files.

I would also advise to have the FSO requirements specified in the dependency field. That would allow to handle executables just like a mod without much special handling.

Uh, what special handling are you saving here? Actually, this would require more special handling since we don't have one "FSO" package a mod could depend on. We have one for every OS and several for Windows.

The cleanest solution would be to write the JSON files from scratch but then you have to maintain them and update them whenever Goober changes his files. That's the only way we could get proper version handling.

 

Offline Hellzed

  • 28
Re: [Cross-platform] FS2 GOG/Mod installer
@ngld : I currently have a group of php/symfony related entities mapping exacly your json format. Now, I'm playing with the "form builder" to create a dynamic form with jquery, based on the entities. (click "create mod", then fill in basic fields, then click "add  file" for each file. Auto completion for dependencies would be a cool feature too)
Once it's done, rendering a json file or a txt file, depending on the request, shouldn't be too hard.

 

Offline m!m

  • 211
Re: [Cross-platform] FS2 GOG/Mod installer
I could transform my files syntax into your syntax in the same step where the checksums are added. What do you think about that?
Sounds good. I would also advise to move the checksums to the file objects as those things belong together.

Well, here we have a problem. As long as we generate these files from Goober's text files we can only install the most recent version of each mod. If a mod depends on the 2014 MediaVPs, it has to put "FSOI#2014 FSU MediaVPs" in its dependencies. If it depends on the 3.6.12 MediaVPs, it has to put "FSOI#FSU MediaVPs, version 3.6.12" in its dependencies. Those two versions are two seperate mods in Goober's files.

[...]

The cleanest solution would be to write the JSON files from scratch but then you have to maintain them and update them whenever Goober changes his files. That's the only way we could get proper version handling.
This new format should replace the old format used by the installer so the old format should only be used to get an initial version of the JSON files which are then adapted to the new format which includes merging different versions of the same mod.

Uh, what special handling are you saving here? Actually, this would require more special handling since we don't have one "FSO" package a mod could depend on. We have one for every OS and several for Windows.
The special handling would be that the launcher has to know that the "FSO" package contains the actual executables for the game. Everything other than that can be handled by using the "environment"/"requirements" option for the executable to determine which executable should be used. That would also resolve the "What is SSE/AVX?" questions as the launcher can determine if the CPU supports that instruction and use the correct executable.
Having the executables as standard packages would need support by the nightly/release build script to publish every new build to the repository but that is nice to have and no requirement.

@ngld : I currently have a group of php/symfony related entities mapping exacly your json format. Now, I'm playing with the "form builder" to create a dynamic form with jquery, based on the entities. (click "create mod", then fill in basic fields, then click "add  file" for each file. Auto completion for dependencies would be a cool feature too)
Once it's done, rendering a json file or a txt file, depending on the request, shouldn't be too hard.
That would be great! A mod author could just create the mod and the information would automatically be propagated to the users.

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: [Cross-platform] FS2 GOG/Mod installer
I've updated the schema.
@Hellzed: I didn't add your "required" packages and kept the "files" list instead. I also renamed your "packages" into "features". What do you think?

Since we aren't restricted by Goober's files anymore, I made semantic versioning a requirement for the "version" field. I suggest we use composer's syntax for versioned dependencies.

I've added an example for the "environment" option. It's a bit long but should be more flexible this way.