RPG Maker MV / MZ Script Call List

@werzque - Andar is correct: command wait time only applies between commands.

Consider using multiple Script elements in your move route, e.g.

---

if (Math.random() < 0.8) { $gameTemp.requestBalloon(this,5); this._waitCount = 59; this._jumpOnNextMoveCommand = true; }

---

if (this._jumpOnNextMoveCommand) { delete this._jumpOnNextMoveCommand; this.jump(1, 2); this.setMoveSpeed(4); }

---

This allows the wait to process and tracks whether or not to jump afterwards by defining a temporary value on the character.

@Bex - that is for use in a stand-alone Script command, not in a move route Script. It is context-dependent because it uses the this keyword. It might be suitable...depends exactly what they're trying to achieve.

Just for the sake of clarity, the code is typed in here on a single line. In the "normal" scripting space, "this" wouldn't work at all. Could that be the issue?

Thanks for the detailed explanation, it makes sense that it doesn't. I'll try to split the scripting up in two parts as caethyril suggests.

Will try this, many many thanks!

EDIT: works like a charm! Woohoo! Thanks so much!

I noticed that the map name display calls are listed as
$gameMap.enableMapNameDisplay(); and $gameMap.disableMapNameDisplay();

Meanwhile in MV (can't speak for MZ) the "Map" part isn't there in rpg_objects.js:
Game_Map.prototype.disableNameDisplay = function() { this._nameDisplay = false; }; Game_Map.prototype.enableNameDisplay = function() { this._nameDisplay = true; };
So it should instead be
$gameMap.enableNameDisplay(); and $gameMap.disableNameDisplay();

This is also incorrect for MZ.

Thanks for pointing that out! Should be fixed now~ :kaohi:

Does anyone know a scriptcall to Seal an EquipSlot during runtime ?
I skimmed the forum and googled .. but found anything for this.

Funnily enough, yes I do know a script call that can achieve the effect of doing that.
You can't actually seal a slot during runtime, you have to use a workaround.
Basically, set the slot to be sealed in the Class trait settings. Then, at the very start of the game, use the script call to un-seal it. And when you want to seal it again, use the other script call to seal it again.
It's what led me to make my first plugin, in my signature.
As for the script call, it's:
to unlock the sealed slot (where X is the class ID and y is the index of the Class's trait - starts from 0 at the top of the list)
and:
to lock it again
So, to use an example from a project of mine:

Nice I will try it ..

The problem with what @Sleepy Kitten Games suggests is that making changes to the database (e.g. $dataClasses) is not saved.

So as soon as the executable is closed and the user starts the game again, it will reload the values from the database. The script calls provided above will not go into the save game. What you're looking for requires a dynamic traits plugin to do correctly.

That's odd, because when I tested it the value gets saved just fine. That was the first thing I checked once I figured it out.

Thank you both.
And you @ATT_Turan for mention it.
But this would not be an issue, because
I can do a checking of the value .. and block the slot again.

Are you using VZ? I’ve had the same with traits seemingly being saved as long as the VZ plug-in is turned on. However, at one point it suddenly resets. It really isn’t stable…

If by VZ you mean VS, ie VisuStella, then yeah. Though I could swear even in the demo project, the trait values get saved.

You're both right.

The $data ... sections are never saved, and as such any changes to the classes or enemies or so will be lots when the game is quit - with one single exception.

The ACTORs are saved into the savegames to keep their data and actually need the reset from the change membership command to be reloaded from $dataActors.

So changes to the actor traits get saved, but nothing else.

@Nafraju - as others have mentioned, traits are stored on database records, not on saved data. More technically: only $gameActors etc are saved, $dataActors etc are not. The former constitute subsets of data that are expected to change during a playthrough: current HP, MP, TP, states, param bonuses, class ID, etc. Traits are not part of this.

Ways to add/remove traits mid-game without plugins include:

• Add/remove state - ideal except that by default death removes all states.
• Change class - mostly the same, just with different trait sets.
• Extra, locked equip slots - (un)equip these via event commands.

These may not be suitable, depending on your game's design. Failing any of these, I'd suggest a plugin for "persistent states", "passive states", or as already suggested, "dynamic traits". :kaohi:

Database records should not be modified during play unless you reset them in a controlled manner, e.g. change value, perform operation, reset value. Changes not made in such a manner may persist for the rest of the session: they won't reset on starting a new game or loading a save, which can easily cause bugs. In short: I don't recommend it. :kaoswt2:

I agree with @werzque: VisuStella seems to implement some kind of cache of trait objects on battlers that persists through save/load. My guess is that it resets when the battler is refreshed...if so, the problem will only become apparent after certain actions, e.g. changing equipment, taking damage, using a healing potion, etc. (This thread is not for plugin support, though.)

First
- thank you ALL.

Second
- I really think it all belongs here in this thread, because maybe in future there will be a scriptcall for this.

Third
- I used another way in my project where I didn't need to Seal an EquipSlot

Fourth
- just responding to the save issue ...
in general I solve those that way:


#1902 is example here


Sure Plugins are a nice thing .. but
in scriptcalls, it is faster to change or adapt something.

That doesn't make a lot of sense - there is approximately a 0% chance that Gotcha Gotcha is going to entirely rewrite an entire section of the game engine (which has functioned identically for decades, as far as I know). :wink:

The trick there is that now you're taking up a variable and a switch and a common event, just to manipulate this one trait. And that parallel event is going to be running the whole time for no further reason. It's absolutely a way to implement what you want, but it seems to be going through a lot of hoops just to avoid installing a plugin to streamline it.

If you say so? I don't see how locating an event inside of RPG Maker and editing the code there is any faster than opening a .js file and editing the same code.

Anyway, good luck with your project.

I am try to do a scrip command for if a certain party member is the leader, their image would pull their picture? Any help would be appreciated

@whiteswords12 - you've used that script call incorrectly: $gameParty.leader() (nothing in the brackets) returns an actor reference, not a number. Then you'd probably want to get their actor ID and check if that's equal to 17 (?) for the branch, e.g. $gameParty.leader()?.actorId() === 17.

However, I think you can just use event commands here...easier to read, lower chance of mistakes, shows up via Event Searcher, and might even be more efficient. You can store the leader's actor ID in a variable and then check the value of that variable:

• Control Variables -> Game Data -> Party -> Member #1 (Actor ID)
• Conditional Branch -> Variable

E.g.

---

◆Control Variables：#0001 = Actor ID of party member #1 ◆Text：None, None, Window, Bottom ： ：\n[\v[1]] is leading the group! ◆If：#0001 = 17 ◆Show Picture：#1, People4_7, Upper Left (192,104), (100%,100%), 255, Normal ◆ ：End

---