rmex / forge Goto Github PK

Dans le package, il faudrait pouvoir indiquer le lien vers un changelog pour informer l'utilisateur des changements entre version. : )

Actually, the "game thumbnail" works only with PNG's file.

• Support all image format
• Display the title of the game on the thumbnail

Use (forge-repository)[https://github.com/RMEx/forge-repository] to describe the package manager structure (with RME for example)

This issue offers a discussion of how to describe the different Forge meta-data.
The "RMEPackage" directory will be changed to "forge-repository" (available here).

General architecture of forge-repository

• mirror : a folder to store all "snapshots"
• packages.json : The list of all available packages
• README.md : How to and instruction

Describe a package (from forge perspective)

{
   "name": "package-name",
   "tags": ["battle-system", "event-making"],
   "changelog": "https://www.mychangelog.com",
   "remote": {
         "stable": "url of stable-version", 
         "develop": "url of developement version"
     },
    "snapshot": ["1.1.0" , "1.1.1", "1.1.2"]
}

The remote-field allow to have multiple version of a package (in the case of RME, for example : master is stable and dev is the developement version. The name of the remote-keys is free. The snapshot field lists all of the snapshots (mirror/package-name/1.1.x). Storing the snapshot allow to manage conflict in the dependancy graph.

Describe a package (as a remote/snapshot)

{
  "name": "package-name",
  "description": "A small description of the package",
  "version": "1.1.0",
  "license": "MIT",
  "authors": {
    "author1": "[email protected]",
    "author2": "[email protected]"
  },
  "components": ["file1.rb", "file2.rb", "file3.rb"],
  "assets": {
    "file1": "target1",
    "file2": "target2"
  },
  "deps": {
    "RME": ["~> 1.1.0"],
    "OtherScript": [">= 1.2 and < 2"]
  }, 
  "export": [
      ["variable_name", "variable_desc", "default_value"]
  ]
}

ref : https://hexdocs.pm/elixir/Version.html

Feel free to give a feed back about that :)

:aha:

Forge invokes Ruby scripts, so it is necessary to trace the states of script execution (via stdout or via a file) from NodeJS (which invokes the script) to send them in Elm.

Quick access to the last projects opened maybe. : )

• Save each openend project
• Fetch the list of last openend project
• Filter the list if a project does not exists (deleted for example)

Actually, when you select a "not rpg maker project", the software keep on "loading" state. We should fix it.

We must have the ability to read data from an RPGMaker project:

• Game path
• Game title
• Game version
• Scripts

Let's start with Webpack !
So let's write a simple windows without anything !

Add a widget to display some informations about the current project

Add CircleCI and some tests for the buisness logic (maybe Ruby and Elm)

• Prepare some scripts into forge-repository
• Fetch the list of available packages
• Add an "update" button"

Use #15 as a reference