RMEBuilder, the first package Manager for RPGMaker VXAce !

[Der Botaniker]

Hello, we (RMEx crew) are happy to introduce the first Package Manager for
RPG Maker VXAce.
This project is inspired by the package manager of Linux (like Aptitude or Yaourt) and provide a fresh environnement for script installation (and update).
Every scripters could submit their scripts on the application and provide a continous feedback ! Please use it

Official web page : http://rmex.github.io/RMEBuilder/uk.html

RMEBuilder is a tool for installing scripts in RPGMaker VXAce. It makes dependency management easier. On top of the comfort it provides, RMEBuilder is free software, licensed under LGPL.
RMEBuilder synchronizes via internet with the latest versions of scripts in order to guarantee that they are always up-to-date (and cover all known bugs)!

Overview

The idea behind RMEBuilder is to allow script users to easily and quickly install scripts. Indeed, RMEBuilder is a tiny executable that permits the adding of scripts to one or several projects. Here is an example of a typical method of using RMEBuilder.

• Select a project
• Add (with commands) the script list for the project
• Start the project building routine
• Start working!

It's also possible to update scripts and, obviously, any script writer can add to the database of available scripts (we hope they do)!

Downloading

RMEBuilder can be obtained really easily, just go to the Releases page and download the file RMEBuilder.zip.

Installing

In order for RMEBuilder to work perfectly, configuring your antivirus/firewall is sometimes necessary so that it lets RMEBuilder download files.

Installing RMEBuilder is very straightforward, just unzip RMEBuilder.zip in the chosen folder (not necessarily inside an RPGMaker project folder, you can use RMEBuilder to build several projects at once).

Normal use

First launch

To launch RMEBuilder, you simply need to click on RMEBuilder.bat (which is a shortcut to launch the application). Upon starting for the first time, the application will ask you to choose the target project. Choosing a valid RPGMaker VXAce project is mandatory.
Once the application knows the target project, a command line device can be accessed. With it, you can enter commands relating to project building.

You can change your target project at any time by entering the target command, which, on top of giving you the current target project path, allows you to change it.

Here is an example of RMEBuilder's first launch.

Composition of a schema

After a project has been chosen in the application, you can now add to it any scripts you want. To do so, you can use the show command which displays the list of available packages on the internet.
The about package-name returns information (description, authors, etc.) about a package.

In order to add packages to a project, simply use the add package-name command. This command's effect is to add a package to the list of packages to be added to the project.
The schema command displays the list of packages to be installed.

It is obvious that if RMEBuilder is closed, all scripts in the schema will be saved and will still be there when you reopen it!

Modifying the schema

By default, during the compilation step (which we will see later), scripts are installed in the order in which they were added. Obviously, you can change the order:

• remove package-name: removes the package from the list
• move package-name up: moves the package up one place
• move package-name down: moves the package down one place

Haha I made a typo in the gif (mouwe instead of mouse, aha) sorry!

Compiling the project

Once your schema is complete, you can compile your project. Compiling in RMEBuilder consists in downloading the scripts currently in the schema and assembling them in the Scripts.rvdata2 file.

Be aware that, before compiling your project, it is mandatory that you close it in RPGMaker. You will be able to open it back later, once the compilation is done.

When the build command is used, the application will download all unknown scripts, and will then make a Scripts.rvdata2 file, which it will merge with the other scripts. This means your project can have pre-installed scripts without problem.
Each time the build command is called, elements built by RMEBuilder are purged. Thus, if you decide to remove an element from your schema after compiling (with the remove command), then it will be taken into account upon recompiling (build).

Managing assets

When compiling your project, RMEBuilder sometimes will ask you if you want to merge assets. It happens when packages contain external files (images or DLLs for example). Upon first compiling the project with a script that requires assets, it is recommended to answer Yes (Y). However, after the script has been added once, you do not need to merge its assets again. If you edit the images, merging the assets again will override all your edits, it would be bad!

At any time, you can fetch a package's assets with the get assets of package-name command.

Updating packages

Upon launch, RMEBuilder will check if updates for your installed scripts exist. It's very useful for keeping up-to-date with script versions and edits:

You can also use the check updates command, which will check if packages are up-to-date.

Once a package is updated, running the build command (after closing the RPGMaker project) is mandatory in order to take the update into account!

Dependency management

If a package depends on another package, it's not necessary to reference the latter in the schema. When building the project (with the use of the build or build dev commands), the application will download and install all dependencies. If a package with dependencies is removed from the schema, the dependencies will be removed as well (unless they were explicitly added (with add) to the schema).

Temporary compilation

The problem with RMEBuilder is that you have to close it after every edit. In order to address this, it is possible to compile temporarily. Using the build dev command will make a temporary file that, when the project is launched, will read the scripts from where they were downloaded. This allows you to only use build dev (and so, close the RPGMaker project) when adding or removing a file in the schema. Package updates don't force a project rebuild. It's very convenient for oft-updated scripts.
However, before distributing your project, executing a build is mandatory so that your project does not rely on temporary files anymore!

Updating RMEBuilder

When an update for RMEBuilder is available, the application will warn you. You simply need to confirm it and it will update itself.

Before publishing your project

Once your project is complete, you can remove the build_schema.rb file from the project folder (don't forget to build, in order to make sure all your scripts are installed). Now all that's left is to encrypt (or not) your project and diffuse it!

For script writers

RMEBuilder is obviously not destined to be used to publish and store only our scripts. We hope that it will be used by a lot of people to easily share scripts throughout the world! (starry eyes)

Make a script available in RMEBuilder

Publishing medium

In order for a script to be available in RMEBuilder, it is important to understand that it must be available on the internet. For that, we personally use Github, which allows us to manage versions of our scripts. You can also use Dropbox, but Github is really suited for the job!

Packages

In order for a script to be fully compatible with RMEBuilder, its structure must be described in a file that will always be named package.rb.

Example with a simple package

The package used in this example is nuki-break-scene, which allows users to easily create pause systems. Its Github folder can be found here.
The package's structure is simple enough: script.rb is the script (elementary!) and package.rb describes the package:

# Package description Package.new( name: 'nuki-break-scene', version: vsn(1, 0, 0), authors: {'Nuki' => 'xaviervdw@gmail.com'}, components: ['script.rb'], description: 'Provide a little customizable scene for InGame\'s pause', )As you can see, you simply need to instantiate a Package object. This is the minimum required for a package.

• name: name of the package
• version: version number (updates can work thanks to this argument)
• authors: a hash with the authors as keys and their email addresses as values
• components: an ordered list of the script files. Their path is relative to the package.rb file
• description: a little description for the package

Example with several files

This time we are going to use the RME package as an example. As you can see, there is not a lot of changes, except that there are several authors and several files:

# Package descriptionPackage.new( name: 'RME', version: vsn(0, 0, 5), authors: { 'Nuki' => 'xaviervdw@gmail.com', 'Grim' => 'grimfw@gmail.com', 'Raho' => '', 'Joke' => 'joke@biloucorp.com', 'Mspawn' => '' }, components: [ 'SDK.rb', 'SDK.Gui.rb', 'Database.rb', 'Internal.rb', 'EvEx.rb', 'Commands.rb', 'Incubator.rb', 'EE4Cmds.rb', 'Tools.rb', 'DocGenerator.rb', 'Doc.rb' ], description: 'RME is a powerful tool to improve your RPGMaker VXAce experience!')Example with dependencies

The DisplayText script (which can be found here) requires installing the StandardizeRGSS script beforehand. You simply need to specify it in a dependancies argument, which takes a list of scripts on which the current script depends:

# Package descriptionPackage.new( name: 'display-text', version: vsn(1, 0, 0), authors: {'Nuki' => 'xaviervdw@gmail.com'}, components: ['script.rb'], description: 'Provide a full customisable text engine', dependancies: ["standardize-rgss"])That's it, you know enough to start correctly packaging your scripts!

Example with assets

It may be that a script contains additional files: assets. For example, a DLL or images. To include them you simply need to add an assets parameter, which is a Hash whose keys are resource URLs (relative or not) and values are their positions in the project. For example, here is the "raho-useless" package file which doesn't have any use except demonstrating how assets work:

# Package descriptionPackage.new( name: 'raho-useless', version: vsn(1, 0, 0), authors: {'Hyperaho' => ''}, components: ['script.rb'], assets: { 'assets/raho1.png' => 'Graphics/Pictures/raho1.png', 'http://full.ouplo.com/f/12/AgkA.png' => 'Graphics/Pictures/raho2.png' }, description: 'Epic script for Epic projects')This package uses two images: one with a relative paht and the other with an absolute path.

Beware! Don't forget that RMEBuilder's goal is to be used by lots of people, so consider prefixing your assets in order to avoid collisions! For example, if I publish a menu that uses an image, I should name the image nuki-menu-my-image.png in order to guarantee that it does not override (and that it is not overriden by) any other image.

Submit a package as an RMEBuilder patch

The package list is a Github respository. To contribute, you simply need to "fork" this project. To add a package, just edit the list of available packages in the packages.rb file, and add a relation as such: "package name" => "URL of the corresponding package.rb".

Be careful that the URL must point to a raw file, not to an HTML page. For Github you have to use the raw link so that only the file contents are exported, and not the entire HTML page.

About package naming semantics

There aren't any formally stated semantics. However, in order to avoid package collisions, we suggest that you prefix your package names with the author's nickname. If the package is major and/or renowned, it is possible not to prefix it. However, we reserve the right to reject a package list edit if a package would override another.

The customPackages folder

In the RMEBuilder/customPackages folder, you can add your in-progress scripts. It allows for reading packages without them being hosted. This means you can make folders for your WIPs in there and work on them as if they were already published. This prevents you from having to publish an unfinished script.
Moreover, thanks to the build dev compilation command, you can also edit your code from your favorite editor (like emacs), without having to constantly copy-paste after every minor edit.

Cloning existing packages

For whatever reason, you might want to edit a package already published by someone else. In RMEBuilder you can use the clone package-name command and the package will be copied into your RMEBuilder/customPackages folder. A package in RMEBuilder/customPackages will always be added at the expense of an external package in the building step, so if you want to revert to the original package, you will have to remove it from RMEBuilder/customPackages or use the reclone package-name command to override the local copy with the latest published version.

Conclusion

That's it with the RMEBuilder, presentation tour, we hope that it will be really useful and that it will change (and simplify) users' ways of installing scripts. We also hope that script writers won't hesitate in publishing their scripts! The more the merrier

Please contribute. In our opinion, RMEBUilder is a very convinient approach for script diffusion ! 

GOODBYE.

Powered by : 

• Joke
• Grim
• Raho
• Nuki
• Mspawn
• Hiino

This is free ! 

 

[Joke]

I love it. <3

RMEBuilder is very usefull to make big scripts divided into many files.

I use it to do my own custom packages, building dynamic links between RPG Maker and my scripts, so I can test my game while I write the script directly into my text editor. 

Above all, it's a very new way to get, install and share scripts around the world. I hope it will be used like this! 

 

[Tsukihime]

This is cool.

So if I understand this correctly, I just need to

1. Clone this: https://github.com/nukiFW/RPGMaker (I see a lot of repos, but nothing with a list of packages)

2. Create a folder for my files (eg: TH_Test)

3. Put my files in there (eg: test_script.rb)

4. Create a package.rb file. Eg:

# Package descriptionPackage.new( name: 'th-test', version: vsn(1, 0, 0), authors: {'Hime' => 'himeworkschannel@gmail.com'}, components: ['test_script.rb'], description: 'Just testing',)5. Push the changesAnd then it is ready to go?

I'm not sure about where you are referring to here

The package list is a Github respository. To contribute, you simply need to "fork" this project. To add a package, just edit the list of available packages in the packages.rb file, and add a relation as such: "package name" => "URL of the corresponding package.rb".

 

[Der Botaniker]

Nop, you have to clone this project : https://github.com/RMEx/RMEPackages

The file "packages.rb" refer all packages, you just have to make a link between this file and your project. 

With only a project for link reference, you preserve the control of your scripts

When the packages.rb (in RMEPackages) is updated, you just have to make a pullrequest on the original project. I valid and after validation, your script is on RMEBuilder. 

If you made an update (and change the "package version"), the users of your script will be notified when they open RMEBuilder.

Edit : In fact, I don't have mentionned RMEPackages in the topic, its corrected thanks ! 

 

[Tsukihime]

Let's say I have ten unrelated scripts. Would I have to create 10 packages?

 

[Der Botaniker]

Yes.

The independancy of package preserve an updating per script.

But a package it's not very long. No?

 

[Engr. Adiktuzmiko]

Tried to use GitHub and made a package for testing.


Though, what happens if my script needs users to configure some parts of it, then I update it and the users get that update? Does that mean the changes they made in the config part will be reset? In that case, then it would be troublesome to use for non plug-and-play scripts which is most of the scripts.

 

[Der Botaniker]

Your pull request was refused beacause you have erased all other package. You just have to add yours not erase the others.

Actually, the Builder don't handle configuration systems. A good approach is to use two package, Once for the configuration and once for the core script. With this method, makers could profite of update and just change the "configuration script".

 

[Engr. Adiktuzmiko]

Ahhhh.. I see.

But what if I modify the configuration script, like add a new config option there.

EX:

Original config:

module ADIK ACTIVE = trueendSo let's say the user changes it to FALSE, thenUpdated config

module ADIK ACTIVE = true NUMBER = 1endImagine if that's a LONG LONG LONG list, it will be troublesome if it would just reset back to the default.Also since most scripts here have a config of sorts within the script itself, then all scripters who wants to add to the builder will then have to separate the config from the actual script. Which will also make the script list in the editor longer.

 

[Der Botaniker]

I see the problem... We have reasoned about RMEPlaceholder, for embed custom configuration file, but actually it is not a priority.

In my opinion, if configuration file change, user must reason about this changement and could rewrite the configuration file...

When configuration's file change, we have a "major update"... (and the user is not obliged to update).

 

[Sixth]

I personally doesn't see this any easier or better than the default way. At least not in it's current state.


With this DOS interface and these command lines, it just makes it more confusing.


If you would make a human-readable, easy to understand GUI for it, than yes, it would be an improvement, but until then, it's just an extra step you need to do to upload/use the scripts, and I am not very fond of these extra steps.


Adik's concern about the config parts of the scripts is something you absolutely must consider to work on, because 99% of the scripts got some settings. That should be high priority on your list, or else not many people would choose to use it, I guess.


I don't want to kill the mood or anything, this is just my honest opinion.

 

[Engr. Adiktuzmiko]

Yeah, as it is right now, I find it more troublesome to use both as a scripter and as a user.

 

[Der Botaniker]

I personally doesn't see this any easier or better than the default way.

With single script, I agree. But RMEBuilder was builded because we working on a very large script (https://github.com/RMEx/RME/tree/master/src) and RMEBuilder offer a simple way to download/install/update the script. We don't have to C/P every components and push it in the good order. 

Another point is the dependancies management. You don't have to be carrefull about the dependancies (for example, Victor XXX who need Victor core Engine). 

The last point is the update. Wih RMEBuilder, you don't have to be careful of the update of a script, you just have to run the software. 

(And the assets could be correctly downloaded, images, dll).

For the configuration script, i'm not agree with your point of view. You are totally in the right when you say that a lot of script use a configuration module. But when you have to change this configuration module, you made a major update. And the user MUST rethinking is script configuration. 

For the scripters, you don't have to say how to install the script. And you can write your script outside RPGMaker, using a nice editor (like Emacs ). 

I have made a little video (apologizes for my Ugly English) who describe the way to publish your work on RMEBuilder : (its actally in uploading, i will edit this message when it is done).

 

[Engr. Adiktuzmiko]

Thing is this is only mostly for installation, which isn't really done a lot of times. Mostly, it's just done one time and a few updates only until the end. This is especially true when the scripts you are using are those already in "final" builds. And once somebody manages to use a certain set of scripts once, he'd probably have no trouble installing it in another project either. They could also just build a "sample project" with the scripts already there so they could just copy paste that next time.


This is more useful when the scripts are still continuously updated/patched, as the update check would be really useful in that case.

We don't have to C/P every components and push it in the good order.

Maybe for your scripts or those with dependencies, but what about required order for scripts that are entirely independent of each other but causes problems when placed in a certain order? There are also cases of those, and is actually a pretty normal cause of problems. Does the builder also know how to handle those?

 

[Der Botaniker]

Here is the video 

 

[Sixth]

... RMEBuilder offer a simple way to download/install/update the script.

If you call that DOS interface simple, our opinion on what is simple differs. It may look simple for you, because you created it, but I assure you, a complete tech-newbie will get lost within seconds or will find too bothersome to learn how to operate it.
You need to visualize the tool, otherwise it can not be called simple, at least I can't call it that way.

For the scripters, you don't have to say how to install the script.

That has to be done either way.
Even if a scripter decides to use this tool to publish his/her work, he/she would still release scripts the regular way too for people who don't use this tool to install scripts.


At least most would, if not for something else, just to avoid forcing the script users to use an external tool for installing the scripts (and let's be honest, most people don't like any external tools for anything).


Adik brought up another good point.


What about seemingly irrelevant scripts which overwrites/alias the same methods? Placing them in a specific order might just work, but other orders might kill off some functions from either scripts or even make your game crash. You can't really foresee these issues, but they will happen, and rather often if someone uses scripts from different authors.

 

[Der Botaniker]

Adik brought up another good point.What about seemingly irrelevant scripts which overwrites/alias the same methods? Placing them in a specific order might just work, but other orders might kill off some functions from either scripts or even make your game crash. You can't really foresee these issues, but they will happen, and rather often if someone uses scripts from different authors.

Yes, we should implement a special command "magic coersion", who's resolve every user-failure. We can use magic for resolve this problems  

(You can manage your schema with RMEBuilder, it is notified in de documentation...)

 

[al'Яογ]

I think that we are missing the essentials here.

RMEBuilder has been designed as a package manager for RPGMaker's additional scripts, then it:

1. provides a formalized way to describe scripts through packages and list them: one place, a ton of scripts !
2. handles scripts' dependencies (dependency which can be assets or other scripts); (avoiding downloading and copy/paste-ing each file into your RPGMaker directory)
3. alerts you of scripts' updates

(And... the most important I guess , this is still a work in progress)

1 - RMEBuilder provides a formalized way to describe scripts through packages, and list available scripts

As you implied, Sixth, (most) RPGMaker's users are tech-newbies who are too dumb to adapt themselves to the interface which is the most widely used in computer sciences: the console.

Well... Even though RMEBuilder's console is actually the one provided by RPGMaker (RGSS Player) and the fact that I feel quite hurt by what you said: interfaces such as console are not simple (think about linux users who use consoles everyday to do the most basic action they have to do); I bet that RPGMaker's users will be grateful to have a tool which lists all available scripts, on which they can perform researches based on specific criteria. Shutting down the era of "I want this kind of script" where you had to search scripts over several forums which had not the same way of archiving scripts.  

Anyway, you are right: having a graphical user interface (GUI) would be better !

2 - RMEBuilder handles scripts' dependencies

Through the package description, you are able to enumerate your package's:

• components (i.e: scripts);
• assets (files such as pictures, music or .dll) to download and where each one has to be saved inside the project's directory;
• packages that are mandatory in order for this package to work (a.k.a: dependencies).

Both components and dependencies are given as arrays and thus define in which order each components (or dependencies) will be added to the RPGMaker project.

Quite the same way as what we are doing nowadays but without having to download and copy/paste each file in the given order ! What is currently taking you long minutes can be easily (and automatically) done in few seconds .

Concerning the following point: 

Adik brought up another good point.
What about seemingly irrelevant scripts which overwrites/alias the same methods? Placing them in a specific order might just work, but other orders might kill off some functions from either scripts or even make your game crash. You can't really foresee these issues, but they will happen, and rather often if someone uses scripts from different authors.

Actually, that's something which happens even if we are not using RMEBuilder =/. Even though I do personally think that they are no "bad scripts", but only misguided users; I still consider that we can't objectively determine which scripts have to be put above and which ones have to be put under if scripters keep doing this abusive way of overwriting methods.

However, I do think that what Nuki/Der Botaniker suggests - that is to say having someone above us revising and (probably) accepting our scripts - is a fairly good alternative in order to build a library of consistent and well-made scripts that will no longer be selves destructive.

3 - RMEBuilder alerts you of scripts' updates (when you launch it)

As scripters we should always be searching how to improve our scripts in terms of performance or configuration, as well as fixing them. These are some reasons why scripts can change over time. This tool provides a way to alert users who have already "installed" your script, that a new version has came out and that they can install it if they want.

About the "what if I modify the configuration script, like add a new config option there". Well... You have to deal with how the scripters has define its configuration whether you use RMEBuilder or you do it manually. As far as there is no formalized way to write an additional script, we can't infer on which part of the scripts has to remain unchanged and which has to be updated.

Here is a suggestion (obviously it can be wrong as well, but I have not think about any disadvantages for the moment), in order to have an independant configuration:

What about relocating it instead of specifying it into the "core script" via namespacing your scripts ? First, it will help to avoid overwritten methods, then uncouple the what-so-many-call "model" part of your system (the core of your system that can be put unchanged from one project to another) from the configuration (which is specific to the user's project); and finally, will prevent configuration made by the user from any updates . Plus, it will make you focus on writing the configuration related documentation rather than some speech which is less important for the user !

For instance, in RME, configuration can be made through .CSV files.

Here is an example of how to add a quest: https://github.com/RMEx/RME-uk/wiki/Extendable-database#example-of-tables-and-fields-creation-in-pictures

 

[Engr. Adiktuzmiko]

Thing here is that when you offer users a tool that is supposed to make their lives easier, they tend to completely depend on it and forget other things they need to do...


Like for the arrangement problem for non-related scripts, with this tool I could foresee people having problems and not realizing it could be because of script order simply because "I used the builder ,it's supposed to fix orders right?".


I'm also curious about one other thing, if I modify the order in the script editor then rebuild the scripts using the builder, will the order get reset again? Because then that would also present a problem.

What about relocating it instead of specifying it into the "core script" via namespacing your scripts ? First, it will help to avoid overwritten methods, then uncouple the what-so-many-call "model" part of your system (the core of your system that can be put unchanged from one project to another) from the configuration (which is specific to the user's project); and finally, will prevent configuration made by the user from any updates

Then you missed my reply, what if THE CONFIG WAS CHANGED BY THE SCRIPT AUTHOR. Like what if I add a new line to my configuration file? That would entail an update.


If I distribute it (the config) without using the builder so users won't "accidentally" update the config without backing up their config, then I do think it defeats the purpose of having this RM builder.


IDK how long you've known other users of RM, but from my experience here a lot of script users are let's just say, "simple minded individuals". Those who would have more experience won't be using this that much, why? Because most of them use specialized, non-public scripts for their projects anyway. So your market here are those using public scripts, most of which use public scripts that aren't even being updated anymore. The best example here would be Yanfly's scripts, A LOT of people use those and those scripts are well last updated YEARS ago.


Of course it's good if scripters always find a way to improve something, but sometimes it's just not worth the trouble anymore. Imagine if you have a 5-day, full time job, and 100 scripts in your library, and also develops your own game, will you spend every free time to check and improve any of those 100 scripts? I'm just being realistic here guys, talking about what's actually happening instead of what you think should happen.


The tool is really awesome, in an ideal situation where all of us here are full time devs with full time scripters releasing and updating publicly usable scripts on a normal basis. Sadly, an ideal situation doesn't exist. Most of us aren't full time devs, and most scripters here aren't full time too.

 

[Joke]

Hi!

Thank you all for your comments, we can think together about pros and cons, it's nice!

With or without RMEBuilder, if you release a new version of your script... users already have to rewrite his config the both way... nope?

It's true, that may be a problem, but how did you do before?

If I distribute it (the config) without using the builder so users won't "accidentally" update the config without backing up their config, then I do think it defeats the purpose of having this RM builder.

We can't "accidentally" update a script, the user is just informed that there is an update, and the order it should use to update.

Can be added to the alert an indication that if the script is configurable, they can lose their initial configuration.

I guess the console interface works on users since they know how to type 'help' and read on it... that's all! 

Ergonomics has always been my priority, seeking for the best "user-friendly" way. I personally think that a GUI can not simplify more than it already is. The GUI can just " do less fear," I totally agree.

I'm helping newbies since 2003, I know so far how they are thinking, they can be disturbed... I'm always trying to work with it. 

It's really fast, try it if you have not yet done!