Examples of Scripting Use that won't be stored in a saved game?

[ZombieKidzRule]

Hello, everyone. I put this in MZ Support because I wasn't sure if this might be engine specific. I don't think it is, but I wasn't positive since I don't know much about Java Script, Scripting, or how the different engines work.

In a variety of threads, I have seen passing references to instances where how you do something with Scripts in Events might not be saved in a Save Game file. But I haven't completely understood how to know when that might be an issue.

I could be completely wrong, but I think I understood that depending on how you make a Variable with a Script will depend on whether that is a "temporary" variable (sorry, don't remember the proper term) that will only last while that script is running or a more "permanent" variable (global?).

I also got the impression that the same might be true with creating arrays and objects.

So, my fear is that I will use a Script to achieve what I want for what I am currently testing, without realizing that if I tested the same Event in an actual game that needs to be saved, it might not do what it does in the simple Play Test of that singular Event.

I also get the impression, perhaps completely incorrectly, that sometimes when suggestions are offered to help, they might not automatically differentiate whether the variable/array/object that is being created needs to be kept for future reference and reuse or it is an Event/script only need.

I know that I never think to clarify that when I am asking questions...mostly because I didn't even know it was an issue until I saw it mentioned somewhere.

I think I have seen things mentioning "let" and "const" as examples. From a quick search, it seemed like both of those are "temporary" and not "global", but I could be wrong.

I'm not sure if I am explaining this correctly.

Am I completely confused about this?

If not, are there any simple rules I can try to remember about using scripts to work with Variables, Arrays, Objects, Switches, or anything else to tell whether those will be stored in a way that is accessible later and will be saved in a Saved Game?

I apologize if this is an ignorant question...meaning uninformed and lacking general awareness...but in many regards...I am very much uninformed about how things work with Java Script and MZ!

Thanks for any help you can provide to assist me in hopefully understanding this better (correctly) and saving it for repeated reference.

 

[caethyril]

This method creates the save data from values in memory (rmmz_managers.js):

DataManager.makeSaveContents = function() {
    // A save data does not contain $gameTemp, $gameMessage, and $gameTroop.
    const contents = {};
    contents.system = $gameSystem;
    contents.screen = $gameScreen;
    contents.timer = $gameTimer;
    contents.switches = $gameSwitches;
    contents.variables = $gameVariables;
    contents.selfSwitches = $gameSelfSwitches;
    contents.actors = $gameActors;
    contents.party = $gameParty;
    contents.map = $gameMap;
    contents.player = $gamePlayer;
    return contents;
};

So something on $gameTemp or window will not be saved, but something on $gameSystem will be saved.

var, let and const are local variable declarations. They are not used for defining properties on objects. Furthermore, MZ's script calls are effectively sandboxed: any local declarations in those will not persist after the script call ends.

---

Technically it is possible to write a plugin to include a local variable value in the save data, so long as the local variable is appropriately scoped, i.e. it can be "seen" from the plugin's makeSaveContents and extractSaveContents method patches.

 

[ZombieKidzRule]

Ah, that is very helpful, thanks!

So it looks like if I use any of the examples above from the create save method ($gameVariables, $gameActors, etc.) in a script, whatever values I use/change will persist outside the script call and will be saved. Unless I misunderstand how those things are affected by the script sandboxing.

Thanks again for taking the time to explain that!

 

[coyotecraft]

In my mind there's 2 types of objects in the game. The $dataWhatsits and the $gameWhatsits.

The $dataWhatsits is all the data in the database. Like Actors, Classes, and the Map data. This stuff is generally read-only*. In contrast to $gameWhatsits that is anything that might change during gameplay and needs to be recorded to a save file.
Like you'll find the player's custom named character in $gameActors. The character's default name is in $dataActors

*Technically you can edit $dataWhatits while the game is running, but it's just a temporary copy. It's not going to rewrite the game's .json files (unless you tell it to). You can make changes to the map tiles in-game for example. The actual map tiles; not event graphics. But those changes aren't going to appear in the editor and they won't be saved to a savefile (unless you tell it to).

 

[ZombieKidzRule]

Thanks for that additional information! I hadn't thought to much about it, but I see the difference between trying to change the $gameActors (for that specific game) versus the $dataActors (for the actual database.

I hadn't really made the connection about the difference before.

Thanks!

 

[Andar]

And there is one other point that needs to be mentioned:

If new data is saved into the savefile, that will automatically make all previous savefiles (which do not containt that data) incompatible to the current game and requires you to start new games.

That is why it is said that in case of adding or removing plugins, most of them require starting a new game after the change.
And it is the reason of the type mismatch errors that happen randomly after loading an incompatible savefile (because it is not random, but as soon as the changed data is accessed)

 

[ZombieKidzRule]

Thank you for mentioning that! It isn’t anything I would have thought of on my own.

 

[caethyril]

If new data is saved into the savefile, that will automatically make all previous savefiles (which do not containt that data) incompatible to the current game and requires you to start new games.

This is not necessarily true. It will cause an error if the plugin assumes that data exists in the save file. It is perfectly possible to skip extraction of undefined values, or simply check them mid-game, to avoid errors. Example code from one of my plugins (Cae_ChoiceShuffle):

Spoiler: example

$.extractSave = function(contents) {
    const v = contents[$.SAVE_PROP];
    if (v === undefined) $.initShuffle();
    else $.setShuffle(!!v);
};

// Alias! Extract plugin data from save contents.
void (alias => {
    DataManager.extractSaveContents = function(contents) {
        alias.apply(this, arguments);
        $.extractSave(contents);
    };
})($.alias.DataManager_extractSaveContents = DataManager.extractSaveContents);

extractSave here explicitly checks if the value read from file is undefined, and if so it initialises it to the "new game" value instead.

*Technically you can edit $dataWhatits while the game is running, but [...] those changes aren't going to appear in the editor and they won't be saved to a savefile (unless you tell it to).

Also, by default the database is only loaded on game boot, so any such changes will persist for the rest of the play session, i.e. they will not be reverted when you start a new game or load a save file. To be safe you'd want to apply then revert those edits before the player can perform new/load game.

For things like map tile swaps I would suggest a plugin instead, but you might be safe there because the map reloads each time, unlike the database.

 

[ZombieKidzRule]

Awesome, again, thanks! I will try to experiment with these concepts to try to make sure I don't mistakenly build something that isn't going to work outside of the quick Play Test option.

 

[Arthran]

I just want to stress that you're kinda asking two separate questions here. Usage of let, const, and var aren't directly related to whether or not something makes it into the save file.

Say you put this in a script call:

let Butts = 'stinky';
const Buttz = 'ztinky';
var Butt5 = '5tinky';

Of those 3 variables, none of them are going to be stored in the save file, and none of them are going to still exist after the script call ends. Those keywords dictate the scope of the variables. As caethyril mentioned, the scope is basically the context from which a variable is accessible.

For example, var has a function scope, meaning that a variable that is declared with that keyword can be referenced from anywhere within the same function. However, let and const are block scoped, meaning that the variable can only be referenced from within the same block of code that it is declared in. For the sake of simplicity, you can consider a block of code to be any code that falls between one { and a corresponding }.

Spoiler: Examples of Scope

So for example, look at this function:

function buttFunc() {
    if (true) {
        let Butts = 'stinky';
        const Buttz = 'ztinky';
        var Butt5 = '5tinky';
    }
    console.log(Butts); // Uncaught ReferenceError: Butts is not defined
    console.log(Buttz); // Uncaught ReferenceError: Buttz is not defined
    console.log(Butt5); // 5tinky
};

buttFunc();

This will result in an error, because neither Butts nor Buttz are allowed to be accessed from outside the if statement that they were created in, due to them being declared with let and const. Once a variable's scope has ended, it no longer exists. On the other hand, accessing Butt5 from outside the if statement does not result in an error, since it was declared with var.

On the other hand, any of the variables can be accessed from within the if statement:

function buttFunc() {
    if (true) {
        let Butts = 'stinky';
        const Buttz = 'ztinky';
        var Butt5 = '5tinky';

        console.log(Butts); // stinky
        console.log(Buttz); // ztinky
        console.log(Butt5); // 5tinky
    }
};

And a code block within a code block does count as part of the parent block. So this won't throw any errors:

function buttFunc() {
    if (true) {
        let Butts = 'stinky';
        const Buttz = 'ztinky';
        var Butt5 = '5tinky';

        for (let i = 0; i < 1; i++) {
            console.log(Butts); // stinky
            console.log(Buttz); // ztinky
            console.log(Butt5); // 5tinky
        }
    }
};

buttFunc();

And none of the variables will be accessible from outside the function they're declared in:

function buttFunc() {
    if (true) {
        let Butts = 'stinky';
        const Buttz = 'ztinky';
        var Butt5 = '5tinky';
    }
};

buttFunc();

console.log(Butts); // Uncaught ReferenceError: Butts is not defined
console.log(Buttz); // Uncaught ReferenceError: Buttz is not defined
console.log(Butt5); // Uncaught ReferenceError: Butt5 is not defined

If you declare the variables outside of any functions or code blocks, then they're globally scoped, and you can access them from pretty much anywhere:

let Butts = 'stinky';
const Buttz = 'ztinky';
var Butt5 = '5tinky';

function buttFunc() {
    if (true) {
        console.log(Butts); // stinky
        console.log(Buttz); // ztinky
        console.log(Butt5); // 5tinky
    }
    console.log(Butts); // stinky
    console.log(Buttz); // ztinky
    console.log(Butt5); // 5tinky
};

buttFunc();

console.log(Butts); // stinky
console.log(Buttz); // ztinky
console.log(Butt5); // 5tinky

Note that the code within an event's script command is technically being executed within a function, since there is a function within the game engine that parses that code an executes it. So even if you aren't explicitly declaring any functions inside your script call, the variables you declare there still aren't considered global variables.

Spoiler: let vs const

The difference between let and const is that the value of a variable declared with const cannot be changed after it is initially assigned. The way to remember that is that "const" stands for "constant":

const Butt = "one butt";
Butt = "moar butts"; // Uncaught TypeError: Assignment to constant variable.

let Butts = "some butts";
Butts = "all the butts"; // acceptable operation

There is one caveat that I should mention, even though it might make things more confusing. If a constant variable contains an object or an array, you can still change properties of the object or elements of the array. For example, this code will execute fine:

const Butts = [1, 3, 3, 4];
console.log(Butts); // [1, 3, 3, 4]
Butts[3] = 7;
console.log(Butts); // [1, 3, 3, 7]

The reason why that works is because, technically speaking, Butts doesn't actually contain the array--it contains a reference to the array. For visualization purposes, you can think of it as if the value that Butts contains is actually the address of where the array is stored in your computer's memory. You can modify the data that is at that location in memory, and it doesn't technically break the const rule, because the address itself isn't changing.

If you're wondering why you would ever want to bother using const over let, there are a few reasons. Firstly, it conveys the programmer's intent to other programmers, and lets them know that the variable can't/won't be changed. It also tells the compiler to protect against this happening, in case somebody messed up and accidentally tried to change a variable that isn't supposed to change. But the most common reason is that it can potentially allow the compiler to make certain performance optimizations, on account of the fact that it knows ahead of time that the variable will never change.

As a general rule of thumb, if you know that the value of a variable will not need to be changed, then use const. Otherwise, use let. Generally speaking, you should probably avoid using var. In most programming languages, variables are block scoped (i.e. they behave like let), so getting too used to using var can create bad habits that might bite you if you ever try programming in another language. The reason you might see var being used in examples around here is because, in the early days of MV, let and const didn't exist, so those examples might be from before MV got updated to allow for newer JavaScript features--either that or people just never got the memo.

I was going to touch on the matter regarding getting variables to save in the save file, but this post has already become way longer than I intended, and caethyril already gave a pretty good explanation, so I'll just leave a quick example.

Suppose that this is being executed from a script call in an event:

/* Globally accessible (can be accessed from other script calls)
will not be saved in the save file */
$gameTemp.enemiesKilled = 7;

/* Globally accessible (can be accessed from other script calls)
will be saved in the save file */
$gameParty.enemiesKilled = 22;

/* Local to the script call (cannot be accessed from other script calls)
will not be saved in the save file */
let enemiesKilled = 4;

 

[ZombieKidzRule]

@Arthran Thank you very much! This is exceptionally helpful and has given me a much better understanding!

This is definitely something that a new user, who is trying to learn Java Script and experimenting with Scripts, needs to know, but I haven't really seen this explained anywhere. Perhaps I just haven't been looking in the right places.

This tells me I am going to need to be much more careful when trying to use Scripts in my experiments.

I recently posted somewhere about having just enough knowledge to be dangerous. I think this is an excellent example of that concept.

Thanks again to everyone who has taken the time to try to make this more clear.

 

[ATT_Turan]

This is definitely something that a new user, who is trying to learn Java Script and experimenting with Scripts, needs to know, but I haven't really seen this explained anywhere. Perhaps I just haven't been looking in the right places.

I don't know what you're using to teach yourself, but if I like the w3schools tutorial. If you start with the Statements lesson (as the first few deal with using JavaScript for Web sites), lesson 5 for Let introduces the concept of scope, which you can then refer to in its own section further down.

JavaScript Let

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

 

[ZombieKidzRule]

Thanks, @ATT_Turan ! I have been reading through the book, Javascript for Kids, since that seemed like it should be very basic.

Then, whenever I have a specific question, I will search the topic and look at the results. I have definitely read parts of the W3Schools’ course.

I still need to take a step back and go through a course like that, start to finish.

I wish someone taught a JS course with examples of how it is implemented in MZ!

Thanks again!

 

[ATT_Turan]

I wish someone taught a JS course with examples of how it is implemented in MZ!

You can look at Trihan's Jump Into JavaScript - that doesn't really teach JavaScript, but it does go through the files and explain the flow of the code if you have an understanding of the language generally.

The trick with your idea is that it's kind of ultimately...I'm trying to think of a nicer-sounding word than "pointless"

Everything in RPG Maker's code is done at a professional, fluent level. So there isn't any part of it that you can look at and say "This is a basic such and such." You could pick out a specific, single line and say "this is declaring a variable," but then there's really no point to referencing RPG Maker at all...declaring a variable is declaring a variable.

The thing about learning to code is that it's about concepts, not implementations. That is, if you understand how to declare and manipulate variables, and how to call functions, manipulate arrays, etc., that's it.

There isn't anything RPG Maker does that is somehow unique to itself. If you understand the above things, then you can just open up one of the source code files and read it and understand what it's doing. I didn't "know JavaScript" when I started modifying RPG Maker code - I had taken classes in C++ and worked in C, and JS is fundamentally the same. I was able to read RPG Maker's code.

If you don't understand the above concepts on their own, then trying to teach someone what this specific RPG Maker function does isn't useful, because they won't have a way to extrapolate that knowledge.

It's like people learning to play a single piece of music on the piano by watching a YouTube video and emulating the hand motions. They might, after enough grinding effort, be able to duplicate that music. But they don't know anything significant about how to play the piano.

 

[ZombieKidzRule]

Thanks and I can’t disagree. Going back and methodically going through a course will be much more beneficial.

 

[Arthran]

I don't know what you're using to teach yourself, but if I like the w3schools tutorial.

w3schools is pretty good, but I feel that they have an alarmingly low number of butt-themed code examples. Was it Confucius who once said: "more butts, more better?"

Thanks, @ATT_Turan ! I have been reading through the book, Javascript for Kids, since that seemed like it should be very basic.

I probably shouldn't speak ill of the book without having read it, but I would personally be a bit wary of "for kids" programming books.

I think that there is a good chance that books like that will leave out a lot of concepts and explanations that the author feels would be too difficult for children to wrap their heads around. I'd be worried that things are getting "dumbed down" to the point that the knowledge isn't useful enough to actually put to use in a real life scenario. You'd probably wind up learning things only halfway, without being able to develop a proper understanding of them.

Since you probably have greater comprehensive abilities and self discipline than the average child, and your goal is to understand JavaScript well enough to use it in real scenarios, I think you might be better off with a more comprehensive book. There should be plenty of non-kid books that start off with the assumption that you have zero programming experience.

Of course, your book could be perfectly fine. I'm just making assumptions without having actually seen it.

I wish someone taught a JS course with examples of how it is implemented in MZ!

MZ uses regular JavaScript. It's unlikely that anything you learn in a book or tutorial won't be valid in MZ.

 

[ATT_Turan]

w3schools is pretty good, but I feel that they have an alarmingly low number of butt-related code examples. Was it Confucius who once said: "more butts, more better?"

There are certainly fewer than in RPG Maker's included ass-ets.

I probably shouldn't speak ill of the book without having read it, but I would personally be a bit wary of "for kids" programming books.

I didn't think to say so, but I absolutely agree. I find it very unlikely that a book aimed at kids would get into more advanced/elegant boolean expressions or JavaScript's array methods, both of which are very useful for RPG Maker code. Just to produce some likely examples.

Unless it's at least a high school-level textbook, I wouldn't want to use it for an adult learning tool or reference. I'm pretty sure I still have, someplace, my copy of "C++ For Me++"

 

[ZombieKidzRule]

You are both right. I bought it on a whim because it seemed less daunting. Although it does teach about arrays and objects…but probably not as comprehensive as it should. But it does have a cute cat on the front So that is a bonus.