Scene template for MV 1.6.0+ (ES6 syntax)

[trapless]

For MV 1.6.0+

class Scene_Es6_Template extends Scene_Base {
  //constructor is the new initialize
  constructor() {
    super(...arguments);
  }

  initialize() {
    super.initialize();
  }

  create() {
    super.create();
  }

  start() {
    super.start();
  }

  update() {
    super.update();
  }

  isReady() {
    return super.isReady();
  }

  isBusy() {
    super.isBusy();
  }

  prepare(arg) {
 
  }

  terminate() {
    super.terminate();
  }

}

[EDIT] Poryg is right, constructor is constructor. MV scenes call initialize in their constructor and so I have edited the template to follow suit since this is for MV after all. MV also passes arguments to initialize so I have made that change too, though no Scenes in MV pass arguments to initialize...

 

[Poryg]

No, constructor is not the new initialize. Constructor is always constructor, even in MV. MV's class constructor calls the initialize function.
Anyway, there's no point in substituting the current prototype system by ES6 syntax. MV relies on 3rd party plugins. For this the 3rd parties will need to add prototypes anyway if they want to extend an already existing class. And using ES5 syntax on one side and ES6 one on the other side just looks plain weird to me. Sure, it's simpler, but multiple writing styles create an ugly code.

 

[Jonforum]

No, constructor is not the new initialize. Constructor is always constructor, even in MV. MV's class constructor calls the initialize function.
Anyway, there's no point in substituting the current prototype system by ES6 syntax. MV relies on 3rd party plugins. For this the 3rd parties will need to add prototypes anyway if they want to extend an already existing class. And using ES5 syntax on one side and ES6 one on the other side just looks plain weird to me. Sure, it's simpler, but multiple writing styles create an ugly code.

you need translated by yourself the core rmmv in es6

 

[Poryg]

@Jonforum That was not the point. The point was that when I need to add a Scene_Map method in a plugin, I need to use prototypes anyway. And having both classes and prototypes just looks so ugly to me.

 

[LTN Games]

The ES6 template should not need that getter function for the name, why is this there?

There are plenty of reasons to get away from the constructor pattern completely, it's the worst pattern in JavaScript and while sometimes it has it's uses, outside of RM you will never see me use class or prototype.
As for substituting for ES6 syntax, there is no substituting, ES6 is JavaScript and I would highly recommend everyone avoid the old ES5 ways entirely, if they plan on doing things outside MV. 90% of new JavaScript tutorials are written in ES6, sooner or later you're going have to learn it.
Yes, when monkey-patching MV you need to use prototype, nothing wrong with that, in fact It makes it easier to see what the author has overwritten and what is newly written in the plugin.

 

[Jonforum]

The ES6 template should not need that getter function for the name, why is this there?

There are plenty of reasons to get away from the constructor pattern completely, it's the worst pattern in JavaScript and while sometimes it has it's uses, outside of RM you will never see me use class or prototype.
As for substituting for ES6 syntax, there is no substituting, ES6 is JavaScript and I would highly recommend everyone avoid the old ES5 ways entirely, if they plan on doing things outside MV. 90% of new JavaScript tutorials are written in ES6, sooner or later you're going have to learn it.
Yes, when monkey-patching MV you need to use prototype, nothing wrong with that, in fact It makes it easier to see what the author has overwritten and what is newly written in the plugin.

i just starting learn es6, and i falling on this lol https://node.university/blog/498412/es7-es8
But it does not concern anyone in particular.

 

[Poryg]

@LTN Games I am not denying the importance of knowledge of ES6 syntax. I wouldn't use ES5 syntax outside of mv either (although you will never make me type arrow functions, I hate these, even though they are useful for one liners, since they automatically return in this case), but in mv I use protototypes and will use them, since I'd have to use them anyway.

 

[peq42_]

Does ES7 work on MV 1.6? It was made in 2017 if Im not wrong, so....

 

[Poryg]

You aren't wrong, but this isn't about when MV or certain ecmascript version was created, but whether the version of nw.js supports ecmascript 7. Which it doesn't. Even the most up to date version of nw.js still doesn't support ecmascript 7 as far as I know, so we'll be waiting for that for a while.

 

[LTN Games]

Have a look here, 1.6 uses nwjs 0.24(pretty sure) and 0.24 uses node 8.21.
It supports a whole lot of everything.
http://node.green

For browser compatibility a minimum version of Babel to transform the code for modern browsers and you'll be good to go.

Most modern browsers support a whole lot already.

https://kangax.github.io/compat-table/es6/

Edit: I added wrong link for browsers, but may as well include both.

https://kangax.github.io/compat-table/es2016plus/

 

[Jonforum]

i use class when i can, its sugar for eyes.

var Imported = Imported || {};
Imported['JSONlibraryLoader'] = {version:1.0};
// ┌------------------------------------------------------------------------------┐
// GLOBAL $SLL CLASS: _SLL for SPRITE LIBRARY LOADER
//└------------------------------------------------------------------------------┘
class _SLL{
    constructor() {
        this.libsLoaded = false;
        this.libraryPath = '/SSA'; // FOLDER PATH WHERE STORED JSON LIBRARY
        this.libraryCategory = ['Characteres','Rocks','Trees','Buildings','Grass','FurnitureINT','FurnitureEXT','Cliffs','Objets','Divers']; //TODO: removeMe
        this.JsonPathLibs = {}; // result from nwJS libs folders scanner
        this.resource = {};
    };
    setLoaded() {this.libsLoaded = true};
    get isLoaded() { return this.libsLoaded }; // getter
  };

// ┌------------------------------------------------------------------------------┐
// DataManager , wait loading
//└------------------------------------------------------------------------------┘
  DataManager.isDatabaseLoaded = function() { // hack, wait loading dataManager
    this.checkError();
    for (let [i,len] = [0,this._databaseFiles.length]; i < len; i++) {
        if (!window[this._databaseFiles[i].name]) { return false };
    };
    return $SLL.isLoaded; // false||true
};
// ┌------------------------------------------------------------------------------┐
// END START INITIALISE PLUGIN METHOD
//└------------------------------------------------------------------------------┘
const $SLL = new _SLL(); //global
$SLL.load_nwJSFolderLibs();
console.log1('$SLL: ', $SLL);

 

[Poryg]

@LTN Games MV 1.6 uses nw.js 0.25.4 and node 8.6.0. It supports a whole lot of everything, you are right. Even a lot from ES 2017.

 

[trapless]

No, constructor is not the new initialize. Constructor is always constructor, even in MV. MV's class constructor calls the initialize function.
Anyway, there's no point in substituting the current prototype system by ES6 syntax. MV relies on 3rd party plugins. For this the 3rd parties will need to add prototypes anyway if they want to extend an already existing class. And using ES5 syntax on one side and ES6 one on the other side just looks plain weird to me. Sure, it's simpler, but multiple writing styles create an ugly code.

I've been busy, please excuse me.
When super is called from constructor it calls Scene_Base because Template extends Scene_Base which in turns calls Scene_base.initialize and niether they or Stage take arguments. the constructor is the es6(new) initialize.

The getter for constructor is there because

SceneManager.changeScene = function () {
  if (this.isSceneChanging() && !this.isCurrentSceneBusy()) {
    if (this._scene) {
      this._scene.terminate();
      this._scene.detachReservation();
      this._previousClass = this._scene.constructor;  <-----------!

was written by people who were not yet able see the flaws of it.

Perhapse someday we will be able to reference the scene by its name instead of a word that means builder from SceneManager.
If code is not maintained to be applicable for current times it will become obsolete. Computers are a tool, upgrade the parts when you can I figure.. If you still carried a stone sword, it would be in your grave. Im already disgusted about people wanting MV to live in the past because they want to use a plugin that isn't maintained by its developer. HTML5 and javascript are going to be around for a long time. MV will most likely be 'THE' RPG Maker until RPG Maker VR. If it's maintained, it could live on for many years after VR's realease as a power tool. I created this topic to share knowledge, not offend people. Also, if anyone reading can do anything about it.. Game.rpgproject can have a variable letting the editor know what version created it? I'd download 500mb(unpacked) extra to get a legacy nwjs option. you know.. because jumping from chome 61 back down to 41 for a new project is kinda 'eww...'

Let me know if I havn't explained the template well enough folks.

 

[Poryg]

The getter for constructor is there because

SceneManager.changeScene = function () {
if (this.isSceneChanging() && !this.isCurrentSceneBusy()) {
if (this._scene) {
this._scene.terminate();
this._scene.detachReservation();
this._previousClass = this._scene.constructor; <-----------!

was written by people who were not yet able see the flaws of it.

Could you elaborate?

Perhapse someday we will be able to reference the scene by its name instead of a word that means builder from SceneManager.

Every major object-oriented language will teach you that the class name function is also its constructor, so getting a class name through referencing current scene's constructor doesn't look weird to me at all. Btw. In fact even the es6 syntax you're presenting here comes mostly from object-oriented languages, including super (hello, c++). The only thing we're missing now are natively supported destructors.

If code is not maintained to be applicable for current times it will become obsolete. Computers are a tool, upgrade the parts when you can I figure..

Once again I'll say that if you want to enhance a class in 3rd party plugins, you have to use prototypes anyway. Prototypes are not obsolete. And I like them more than the es6 class system. Not to mention, you're talking to someone who used a Pentium III computer for 12 years.
Anyway, if you want to use es6 syntax for your plugins, be my guest. They won't be compatible with sub 1.6.0 mv, but well, that is evolution and nothing can be done about it. But since it's only syntactic sugar, I don't really see a reason to enforce it, if I say it like that, because prototypes are going to stay and because I find it ugly to use two syntaxes at once.

Game.rpgproject can have a variable letting the editor know what version created it? I'd download 500mb(unpacked) extra to get a legacy nwjs option. you know.. because jumping from chome 61 back down to 41 for a new project is kinda 'eww...'

No need to, MV 1.6.0 forces engine upgrade, so once it becomes the main version, we won't have to deal with it at all.

I created this topic to share knowledge, not offend people.

Just like I said what I had to say

 

[trapless]

Could you elaborate?

It's a mistake. I left it there when pasting the code from a project that loaded scenes dynamically from strings without using eval();
sorry for the confusion. I'll remove it from OP.