I never thought even I could make some music, but I don't know if mine would be too unpleasant to hear, so it takes me some courage to share them here 
DoubleX - Everyone Turning Against You
DoubleX - Everyone Turning Against You
Show posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
RMMZ Script Database / [MZ][MV] DoubleX Event Text Extractor
April 16, 2022, 10:12:16 pmDoubleX_RMMV_RMMZ_Event_Text_Extractor
Authors: DoubleX
Version: v1.00a
Type: Event Text Add-on
Key Term: Game Utility
Authors: DoubleX
Version: v1.00a
Type: Event Text Add-on
Key Term: Game Utility
Note
This plugin works for both RMMV and RMMZ
Purpose
Lets you extract texts in events/common events/battle events to txt file
Video
Games using this plugin
None so far
Download Link
Demo Link
3
Tutorials / Basic knowledge to the default RMMZ TPBS battle flow implementations
March 05, 2022, 02:00:31 am
This topic aims to share the basic knowledge on what the default RMMZ TPBS battle flow implementations do in general, but you're still assumed to have at least:
1. Some plugin development proficiency(having written several easy, simple and small battle-related plugins up to 1k LoC scale)
2. Basic knowledge on what the default RMMZ turn based battle flow implementations do in general
3. Basic knowledge on what the default RMMZ TPBS battle flow does in general on the user level(At least you need to know what's going on on the surface when playing it as a player)
Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience
That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ TPBS battle flow implementations, feel free to correct me if there's anything wrong
For those wanting to have a solid understanding to the default RMMZ TPBS battle flow implementations, I might open a more advanced topic for that later
1. Some plugin development proficiency(having written several easy, simple and small battle-related plugins up to 1k LoC scale)
2. Basic knowledge on what the default RMMZ turn based battle flow implementations do in general
3. Basic knowledge on what the default RMMZ TPBS battle flow does in general on the user level(At least you need to know what's going on on the surface when playing it as a player)
Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience
That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ TPBS battle flow implementations, feel free to correct me if there's anything wrong
For those wanting to have a solid understanding to the default RMMZ TPBS battle flow implementations, I might open a more advanced topic for that later
4
Tutorials / [MZ]Basic knowledge to the default RMMZ turn based battle flow implementations
February 28, 2022, 11:16:35 pm
This topic aims to share the basic knowledge on what the default RMMZ turn based battle flow implementations do in general, but you're still assumed to have at least:
1. Little javascript coding proficiency(barely okay with writing rudimentary Javascript codes up to 300 LoC scale)
2. Basic knowledge on what the default RMMZ turn based battle flow does on the user level(At least you need to know what's going on on the surface when playing it as a player)
Simplified Flowchart
Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience
Start Battle
This is the phase handling the start of the battle(with the empty phase only being run once), until BattleManager.startInput will be called to change the phase to "input".
To keep things simple here, only the parts that are common to all the 3 different ways(battle tests, normal encounters and event encounters) of starting battles will be covered.
The common parts start from BattleManager.setup, which initializes the battle phase as empty in BattleManager.initMembers:
Then, regardless of how the battles are started, either of the following will be called to start the battle scene:
At the beginning of the scene life cycle(too advanced to be covered here), Scene_Battle.prototype.create will be called to call Scene_Battle.prototype.createDisplayObjects as well, which calls Scene_Battle.prototype.createAllWindows:
Here, Scene_Battle.prototype.createPartyCommandWindow and Scene_Battle.prototype.createActorCommandWindow are methods creating the party and actor command windows respectively, and these 2 are the windows that are parts of the battle flow.
As the scene life cycle reaches Scene_Battle.prototype.start, BattleManager.startBattle will be called to change the phase to "start":
When the events that are supposed to be run upon battle start are finished(how this is exactly done is too advanced to be covered here), Scene_Battle.prototype.update will call Scene_Battle.prototype.updateBattleProcess, which will call BattleManager.update, causing BattleManager.updatePhase to be called as well(frame updates in battle flow are too advanced to be covered here), and so BattleManager.updateStart will be called to call BattleManager.startInput, in order to change the phase to "input", meaning that the battle is finally fully started:
Input Actions
This phase starts from BattleManager.startInput and ends with BattleManager.startTurn, and it's the phase where players can either try to escape the battle, or input all actions for all inputable party members, until BattleManager.startTurn is called to change the phase to "turn", or BattleManager.processAbort is called to abort the battle.
First, Game_Unit.prototype.makeActions will be called, causing Game_Battler.prototype.makeActions to be called to make all battlers have their respective number of action slots determined by their respective Action Times+ at that moment:
Note that Auto Battle and/or confused actors will automatically input all their action slots without player inputs because of Game_Actor.prototype.makeActions:
Whereas all enemies will always automatically input all their action slots:
As for inputability, an actor's inputable if he/she/it's alive, in battle and has no Restrictions enforced by states and no special flag Auto Battle.
As long as the party can input actions in the current turn(determined by whether it's the 1st turn with a surprise battle start and whether any party member can input actions), this phase will proceed as follows:
1. Scene_Battle.prototype.changeInputWindow will call Scene_Battle.prototype.startPartyCommandSelection(its reasons are too advanced to be covered here), which setups the party command window:
2a. If those players choose to escape, then Scene_Battle.prototype.commandEscape as the corresponding handler of the party command window(handlers are too advanced to be covered here) will be called to call BattleManager.processEscape.
The escape attempt will always succeed upon the 1st turn if the battle starts with preemptive, otherwise its probability of success is determined by the escape ratio at that moment, which is initially set as 0.5 * the average of agi of all party members in battle / the average of agi of all enemies in battle, and will increase by 0.1 per failed attempt.
2a(i). If the escape attempt succeeded, then BattleManager.onEscapeSucces will be called to call BattleManager.processAbort, which calls BattleManager.endBattle which the result argument as 1 to abort the battle(how battles are ended are too advanced to be covered here):
2a(ii). If the escape attempt failed, then BattleManager.onEscapeFailure will be called to call BattleManager.startTurn, which starts the current turn and will be covered in the later parts of this post:
Note that Game_Party.prototype.onEscapeFailure will call Game_Actor.prototype.onEscapeFailure for all party members, and so Game_Actor.prototype.clearActions will be called to void all action slots:
2b. If those players choose to fight, then Scene_Battle.prototype.commandFight use select next command(covered in the later parts of this post) to let those players input all actions of all inputable party members sequentially.
3. Those players will first input the 1st action slot of the 1st inputable party member, then the 2nd, 3rd, and finally the last action slot of that member, and those players will proceed with the same sequence for the 2nd inputable party member, finally those players will repeat this sequence until the last action slot of the last inputable party member is inputted, with the restriction that those players can never break nor escape this sequence without inputting all action slots of all inputable party members.
4. When inputting actions for inputable party members, players can use the ok command to proceed to the next action slot of the current member, or from the last action slot of that member to the 1st action slot of the next member(or start the current turn upon finish inputting the last action slot of the last member).
The ok command is handled by the actor command window(how it's setup is too advanced to be covered here) using the handler Scene_Battle.prototype.selectNextCommand, which calls BattleManager.selectNextCommand to call Game_Actor.prototype.selectNextCommand:
5. Similarly, players can use the cancel command to proceed to the previous action slot of the current member, or from the 1st action slot of that member to the last action slot of the previous member(or setup the party command window upon cancelling the input of the 1st action slot of the 1st member).
The cancel command is handled by the actor command window using the handler Scene_Battle.prototype.selectPreviousCommand, which calls BattleManager.selectPreviousCommand to call Game_Actor.prototype.selectPreviousCommand:
6. While the exact traversals of this doubly linked list are too advanced to be covered here, the party command window(head sentinel node) and the turn start(tail sentinel node) are the start and end of this sequence respectively, while the ok and cancel commands are single steps for moving forward(next pointer) and backward(previous pointer) respectively.
Process Turns
To be precise, there are 2 phases in this part, which are "turn" and "turnEnd".
The "turn" phase starts from having BattleManager.startTurn called upon inputting the last action slot of the last inputable party member, and ends with calling BattleManager.startAction to change the phase to "action", or BattleManager.endTurn to change the phase to "turnEnd":
This changes the phase to "turn" and increases the battle turn count by 1.
Then, by calling BattleManager.makeActionOrders, the action order queue descendingly sorted by the speed of all battlers(the faster the battlers are the more up front they're on this queue) at this moment will have all the inputted actions of all those battlers, with the ordering of all actions among the same battler unchanged from his/her/its action slot input sequence:
Note that the speed of a battler is determined by the fastest action slot inputted by that battler(the skill/item with the lowest Speed).
After that, all battle events which should be run upon turn start will be run(how this is exactly done is too advanced to be covered here), and then BattleManager.updatePhase will call BattleManager.updateTurn:
If there's no action execution subject, BattleManager.getNextSubject will be used as a try to find the most up front alive battler in the action order queue at that moment, with all the dead ones removed from the queue before an alive one is found, and having found such a battler means that battler will be removed from the queue as well:
If no such battler's found, then the phase will change to "turnEnd" by calling BattleManager.endTurn(which will be covered in the later parts of this post).
If such a battler's found, he/she/it'll be the new action subject, and BattleManager.processTurn will be called to try to execute inputted actions of that battler:
An action is said to be valid upon execution if it's forced or its user meets all the conditions of the corresponding skill/item upon execution.
If the action execution subject has no valid actions to execute, then BattleManager.endAction will be called(this will be covered in the later parts of this post), which will cause BattleManager.updateTurn to be called again later, meaning that another action execution subject has to be found, or the turn will just end.
If the action execution subject has valid actions to execute, then all the invalid ones will be discarded and the valid ones will be executed sequentially, by calling BattleManager.startAction, which makes the target queue of the current action to be executed and changes the phase to "action":
The "turnEnd" phase starts from having BattleManager.endTurn called upon having no more action execution subject to be found nor execute valid actions not yet executed, and ends with later calling BattleManager.updatePhase, which calls BattleManager.updateTurnEnd to change the phase to "start":
Execute Actions
It basically starts from BattleManager.startAction and ends with BattleManager.endAction to change the phase to "turn".
It's the phase where the current action execution subject will, after discarding all the invalid actions, execute all the valid ones sequentially, which the ordering unchanged from the action slot input sequence of that subject.
As far as only the current action execution subject is concerned, this phase will proceed as follows:
1. The 1st valid action that aren't executed yet will be executed after showing its start using the battle log window(how Window_BattleLog works is too advanced to be covered here).
2. Upon the start of the execution, BattleManager.updatePhase will call BattleManager.updateAction, which tries to find the 1st target in the target queue of the action to be executed:
If such target's found, that target will be removed from the queue and BattleManager.invokeAction will be called:
For now, you just need to know that Window_BattleLog is way more than just a battle log window, as it actually coordinates all the visual display sequences in the battle flow(also too advanced to be covered here).
If no such target's found, then BattleManager.endAction will be called to change the phase to "turn":
Summary
The battle first starts with the empty phase.
The empty phase will always change to "start" after finished preparing to start the battle.
The "start" phase will always change to "input" after finished starting the battle to try to let players input actions for all inputable party members.
All battlers will use their respective Action Times+ at that moment to determine their respectively number of action slots they can have in the current turn.
If there's no such member or the battle starts with surprise, the battle phase will immediately change to "turn".
Otherwise players will either try to escape the battle, or sequentially input from the 1st action slot of the 1st inputable party member to the last one of the last such member.
A sucess escape attempt will abort the battle while a failed one will change the phase to "turn" without inputting any action slot of any inputable party member.
The battle phase will change to "turn" when all actions slots of all inputable party members are inputted.
The "turn" phase will try to sequentially execute actions from the 1st inputted valid ones of the fastest alive battler at that moment to the last inputted valid ones of the slowest alive battler at that moment.
Whenever the 1st inputted valid action not executed yet by the current action execution subject is to be executed now, the phase will change to "action".
When there are no more alive battlers left to execute valid actions that aren't executed yet, the phase will change to "turnEnd", which will soon change to "start".
The "action" phase will try to sequentially invoke the currently valid action to be executed into each of its targets and remove that target from the action target queue.
When that action target queue has no more targets, the phase will change to "turn".
That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ turn based battle flow implementations, feel free to correct me if there's anything wrong
For those wanting to have a solid understanding to the default RMMZ turn based battle flow implementations, I might open a more advanced topic for that later
1. Little javascript coding proficiency(barely okay with writing rudimentary Javascript codes up to 300 LoC scale)
2. Basic knowledge on what the default RMMZ turn based battle flow does on the user level(At least you need to know what's going on on the surface when playing it as a player)
Simplified Flowchart
Please note that this flowchart only includes the most important elements of the battle flow, to avoid making it too complicated and convoluted for the intended targeting audience
Start Battle
This is the phase handling the start of the battle(with the empty phase only being run once), until BattleManager.startInput will be called to change the phase to "input".
To keep things simple here, only the parts that are common to all the 3 different ways(battle tests, normal encounters and event encounters) of starting battles will be covered.
The common parts start from BattleManager.setup, which initializes the battle phase as empty in BattleManager.initMembers:
BattleManager.initMembers = function() {
this._phase = "";
this._inputting = false;
this._canEscape = false;
this._canLose = false;
this._battleTest = false;
this._eventCallback = null;
this._preemptive = false;
this._surprise = false;
this._currentActor = null;
this._actionForcedBattler = null;
this._mapBgm = null;
this._mapBgs = null;
this._actionBattlers = [];
this._subject = null;
this._action = null;
this._targets = [];
this._logWindow = null;
this._spriteset = null;
this._escapeRatio = 0;
this._escaped = false;
this._rewards = {};
this._tpbNeedsPartyCommand = true;
};
SceneManager.goto(Scene_Battle);SceneManager.push(Scene_Battle);Scene_Battle.prototype.createAllWindows = function() {
this.createLogWindow();
this.createStatusWindow();
this.createPartyCommandWindow();
this.createActorCommandWindow();
this.createHelpWindow();
this.createSkillWindow();
this.createItemWindow();
this.createActorWindow();
this.createEnemyWindow();
Scene_Message.prototype.createAllWindows.call(this);
};
As the scene life cycle reaches Scene_Battle.prototype.start, BattleManager.startBattle will be called to change the phase to "start":
BattleManager.startBattle = function() {
this._phase = "start";
$gameSystem.onBattleStart();
$gameParty.onBattleStart(this._preemptive);
$gameTroop.onBattleStart(this._surprise);
this.displayStartMessages();
};
BattleManager.startInput = function() {
this._phase = "input";
this._inputting = true;
$gameParty.makeActions();
$gameTroop.makeActions();
this._currentActor = null;
if (this._surprise || !$gameParty.canInput()) {
this.startTurn();
}
};
Input Actions
This phase starts from BattleManager.startInput and ends with BattleManager.startTurn, and it's the phase where players can either try to escape the battle, or input all actions for all inputable party members, until BattleManager.startTurn is called to change the phase to "turn", or BattleManager.processAbort is called to abort the battle.
First, Game_Unit.prototype.makeActions will be called, causing Game_Battler.prototype.makeActions to be called to make all battlers have their respective number of action slots determined by their respective Action Times+ at that moment:
Game_Battler.prototype.makeActions = function() {
this.clearActions();
if (this.canMove()) {
const actionTimes = this.makeActionTimes();
this._actions = [];
for (let i = 0; i < actionTimes; i++) {
this._actions.push(new Game_Action(this));
}
}
};
Game_Actor.prototype.makeActions = function() {
Game_Battler.prototype.makeActions.call(this);
if (this.numActions() > 0) {
this.setActionState("undecided");
} else {
this.setActionState("waiting");
}
if (this.isAutoBattle()) {
this.makeAutoBattleActions();
} else if (this.isConfused()) {
this.makeConfusionActions();
}
};
Game_Enemy.prototype.makeActions = function() {
Game_Battler.prototype.makeActions.call(this);
if (this.numActions() > 0) {
const actionList = this.enemy().actions.filter(a =>
this.isActionValid(a)
);
if (actionList.length > 0) {
this.selectAllActions(actionList);
}
}
this.setActionState("waiting");
};
As long as the party can input actions in the current turn(determined by whether it's the 1st turn with a surprise battle start and whether any party member can input actions), this phase will proceed as follows:
1. Scene_Battle.prototype.changeInputWindow will call Scene_Battle.prototype.startPartyCommandSelection(its reasons are too advanced to be covered here), which setups the party command window:
Scene_Battle.prototype.changeInputWindow = function() {
this.hideSubInputWindows();
if (BattleManager.isInputting()) {
if (BattleManager.actor()) {
this.startActorCommandSelection();
} else {
this.startPartyCommandSelection();
}
} else {
this.endCommandSelection();
}
};
Scene_Battle.prototype.startPartyCommandSelection = function() {
this._statusWindow.deselect();
this._statusWindow.show();
this._statusWindow.open();
this._actorCommandWindow.setup(null);
this._actorCommandWindow.close();
this._partyCommandWindow.setup();
};
The escape attempt will always succeed upon the 1st turn if the battle starts with preemptive, otherwise its probability of success is determined by the escape ratio at that moment, which is initially set as 0.5 * the average of agi of all party members in battle / the average of agi of all enemies in battle, and will increase by 0.1 per failed attempt.
2a(i). If the escape attempt succeeded, then BattleManager.onEscapeSucces will be called to call BattleManager.processAbort, which calls BattleManager.endBattle which the result argument as 1 to abort the battle(how battles are ended are too advanced to be covered here):
BattleManager.processAbort = function() {
$gameParty.removeBattleStates();
this._logWindow.clear();
this.replayBgmAndBgs();
this.endBattle(1);
};
BattleManager.onEscapeFailure = function() {
$gameParty.onEscapeFailure();
this.displayEscapeFailureMessage();
this._escapeRatio += 0.1;
if (!this.isTpb()) {
this.startTurn();
}
};
Game_Actor.prototype.onEscapeFailure = function() {
if (BattleManager.isTpb()) {
this.applyTpbPenalty();
}
this.clearActions();
this.requestMotionRefresh();
};
Game_Actor.prototype.clearActions = function() {
Game_Battler.prototype.clearActions.call(this);
this._actionInputIndex = 0;
};
3. Those players will first input the 1st action slot of the 1st inputable party member, then the 2nd, 3rd, and finally the last action slot of that member, and those players will proceed with the same sequence for the 2nd inputable party member, finally those players will repeat this sequence until the last action slot of the last inputable party member is inputted, with the restriction that those players can never break nor escape this sequence without inputting all action slots of all inputable party members.
4. When inputting actions for inputable party members, players can use the ok command to proceed to the next action slot of the current member, or from the last action slot of that member to the 1st action slot of the next member(or start the current turn upon finish inputting the last action slot of the last member).
The ok command is handled by the actor command window(how it's setup is too advanced to be covered here) using the handler Scene_Battle.prototype.selectNextCommand, which calls BattleManager.selectNextCommand to call Game_Actor.prototype.selectNextCommand:
Scene_Battle.prototype.selectNextCommand = function() {
BattleManager.selectNextCommand();
this.changeInputWindow();
};
BattleManager.selectNextCommand = function() {
if (this._currentActor) {
if (this._currentActor.selectNextCommand()) {
return;
}
this.finishActorInput();
}
this.selectNextActor();
};
Game_Actor.prototype.selectNextCommand = function() {
if (this._actionInputIndex < this.numActions() - 1) {
this._actionInputIndex++;
return true;
} else {
return false;
}
};
The cancel command is handled by the actor command window using the handler Scene_Battle.prototype.selectPreviousCommand, which calls BattleManager.selectPreviousCommand to call Game_Actor.prototype.selectPreviousCommand:
Scene_Battle.prototype.selectPreviousCommand = function() {
BattleManager.selectPreviousCommand();
this.changeInputWindow();
};
BattleManager.selectPreviousCommand = function() {
if (this._currentActor) {
if (this._currentActor.selectPreviousCommand()) {
return;
}
this.cancelActorInput();
}
this.selectPreviousActor();
};
Game_Actor.prototype.selectPreviousCommand = function() {
if (this._actionInputIndex > 0) {
this._actionInputIndex--;
return true;
} else {
return false;
}
};
Process Turns
To be precise, there are 2 phases in this part, which are "turn" and "turnEnd".
The "turn" phase starts from having BattleManager.startTurn called upon inputting the last action slot of the last inputable party member, and ends with calling BattleManager.startAction to change the phase to "action", or BattleManager.endTurn to change the phase to "turnEnd":
BattleManager.startTurn = function() {
this._phase = "turn";
$gameTroop.increaseTurn();
$gameParty.requestMotionRefresh();
if (!this.isTpb()) {
this.makeActionOrders();
this._logWindow.startTurn();
this._inputting = false;
}
};
Then, by calling BattleManager.makeActionOrders, the action order queue descendingly sorted by the speed of all battlers(the faster the battlers are the more up front they're on this queue) at this moment will have all the inputted actions of all those battlers, with the ordering of all actions among the same battler unchanged from his/her/its action slot input sequence:
BattleManager.makeActionOrders = function() {
const battlers = [];
if (!this._surprise) {
battlers.push(...$gameParty.battleMembers());
}
if (!this._preemptive) {
battlers.push(...$gameTroop.members());
}
for (const battler of battlers) {
battler.makeSpeed();
}
battlers.sort((a, b) => b.speed() - a.speed());
this._actionBattlers = battlers;
};
After that, all battle events which should be run upon turn start will be run(how this is exactly done is too advanced to be covered here), and then BattleManager.updatePhase will call BattleManager.updateTurn:
BattleManager.updateTurn = function(timeActive) {
$gameParty.requestMotionRefresh();
if (this.isTpb() && timeActive) {
this.updateTpb();
}
if (!this._subject) {
this._subject = this.getNextSubject();
}
if (this._subject) {
this.processTurn();
} else if (!this.isTpb()) {
this.endTurn();
}
};
BattleManager.getNextSubject = function() {
for (;;) {
const battler = this._actionBattlers.shift();
if (!battler) {
return null;
}
if (battler.isBattleMember() && battler.isAlive()) {
return battler;
}
}
};
If such a battler's found, he/she/it'll be the new action subject, and BattleManager.processTurn will be called to try to execute inputted actions of that battler:
BattleManager.processTurn = function() {
const subject = this._subject;
const action = subject.currentAction();
if (action) {
action.prepare();
if (action.isValid()) {
this.startAction();
}
subject.removeCurrentAction();
} else {
this.endAction();
this._subject = null;
}
};
If the action execution subject has no valid actions to execute, then BattleManager.endAction will be called(this will be covered in the later parts of this post), which will cause BattleManager.updateTurn to be called again later, meaning that another action execution subject has to be found, or the turn will just end.
If the action execution subject has valid actions to execute, then all the invalid ones will be discarded and the valid ones will be executed sequentially, by calling BattleManager.startAction, which makes the target queue of the current action to be executed and changes the phase to "action":
BattleManager.startAction = function() {
const subject = this._subject;
const action = subject.currentAction();
const targets = action.makeTargets();
this._phase = "action";
this._action = action;
this._targets = targets;
subject.cancelMotionRefresh();
subject.useItem(action.item());
this._action.applyGlobal();
this._logWindow.startAction(subject, action, targets);
};
BattleManager.endTurn = function() {
this._phase = "turnEnd";
this._preemptive = false;
this._surprise = false;
};
BattleManager.updateTurnEnd = function() {
if (this.isTpb()) {
this.startTurn();
} else {
this.endAllBattlersTurn();
this._phase = "start";
}
};
Execute Actions
It basically starts from BattleManager.startAction and ends with BattleManager.endAction to change the phase to "turn".
It's the phase where the current action execution subject will, after discarding all the invalid actions, execute all the valid ones sequentially, which the ordering unchanged from the action slot input sequence of that subject.
As far as only the current action execution subject is concerned, this phase will proceed as follows:
1. The 1st valid action that aren't executed yet will be executed after showing its start using the battle log window(how Window_BattleLog works is too advanced to be covered here).
2. Upon the start of the execution, BattleManager.updatePhase will call BattleManager.updateAction, which tries to find the 1st target in the target queue of the action to be executed:
BattleManager.updateAction = function() {
const target = this._targets.shift();
if (target) {
this.invokeAction(this._subject, target);
} else {
this.endAction();
}
};
BattleManager.invokeAction = function(subject, target) {
this._logWindow.push("pushBaseLine");
if (Math.random() < this._action.itemCnt(target)) {
this.invokeCounterAttack(subject, target);
} else if (Math.random() < this._action.itemMrf(target)) {
this.invokeMagicReflection(subject, target);
} else {
this.invokeNormalAction(subject, target);
}
subject.setLastTarget(target);
this._logWindow.push("popBaseLine");
};
If no such target's found, then BattleManager.endAction will be called to change the phase to "turn":
BattleManager.endAction = function() {
this._logWindow.endAction(this._subject);
this._phase = "turn";
if (this._subject.numActions() === 0) {
this.endBattlerActions(this._subject);
this._subject = null;
}
};
Summary
The battle first starts with the empty phase.
The empty phase will always change to "start" after finished preparing to start the battle.
The "start" phase will always change to "input" after finished starting the battle to try to let players input actions for all inputable party members.
All battlers will use their respective Action Times+ at that moment to determine their respectively number of action slots they can have in the current turn.
If there's no such member or the battle starts with surprise, the battle phase will immediately change to "turn".
Otherwise players will either try to escape the battle, or sequentially input from the 1st action slot of the 1st inputable party member to the last one of the last such member.
A sucess escape attempt will abort the battle while a failed one will change the phase to "turn" without inputting any action slot of any inputable party member.
The battle phase will change to "turn" when all actions slots of all inputable party members are inputted.
The "turn" phase will try to sequentially execute actions from the 1st inputted valid ones of the fastest alive battler at that moment to the last inputted valid ones of the slowest alive battler at that moment.
Whenever the 1st inputted valid action not executed yet by the current action execution subject is to be executed now, the phase will change to "action".
When there are no more alive battlers left to execute valid actions that aren't executed yet, the phase will change to "turnEnd", which will soon change to "start".
The "action" phase will try to sequentially invoke the currently valid action to be executed into each of its targets and remove that target from the action target queue.
When that action target queue has no more targets, the phase will change to "turn".
That's all for now. I hope this can help you grasp these basic knowledge. For those thoroughly comprehending the essence of the default RMMZ turn based battle flow implementations, feel free to correct me if there's anything wrong
For those wanting to have a solid understanding to the default RMMZ turn based battle flow implementations, I might open a more advanced topic for that later
5
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Skill Item Cooldown
February 07, 2021, 10:13:23 am
Updates
* { codebase: "1.1.1", plugin: "v1.02a" }(2021 Feb 7 GMT 1300):
* 1. Added skillItemCooldownGaugeColor1 and skillItemCooldownGaugeColor2
* to let you show the TPB battler cooldown bar inside battles with
* configurable colors
* 2. Added cancelBattlerCooldownHotkeys and
* cancelSkillItemCooldownHotkeys to let you set some hotkeys to
* cancel the battler/skill item cooldown of the corresponding actors
* respectively
* 3. Added the following parameters:
* - canCancelBattlerCooldown
* - canCancelSkillItemCooldown
* - cancelBattlerCooldownFail
* - cancelSkillItemCooldownFail
* - cancelBattlerCooldownSuc
* - cancelSkillItemCooldownSuc
* - canCancelBattlerCooldownNotetagDataTypePriorities
* - canCancelSkillItemCooldownNotetagDataTypePriorities
* - cancelBattlerCooldownFailNotetagDataTypePriorities
* - cancelSkillItemCooldownFailNotetagDataTypePriorities
* - cancelBattlerCooldownSucNotetagDataTypePriorities
* - cancelSkillItemCooldownSucNotetagDataTypePriorities
* 4. Added the following plugin commands:
* - canCancelBattlerCooldown
* - canCancelSkillItemCooldown
* - cancelBattlerCooldown
* - cancelSkillItemCooldown
* 5. Added the following notetags:
* - canCancelBattler
* - canCancelSkillItem
* - cancelBattlerFail
* - cancelSkillItemFail
* - cancelBattlerSuc
* - cancelSkillItemSuc6
Chat / Beware of scams like this...(pretending to be Paypal)
January 29, 2021, 07:41:05 am
I just received an email like this:
Title: Notification Case #(Some random numbers)
Sender: (Non-Paypal logo)service@paypal.com.(My PayPal account location) <(Non-PayPal email used by the real scammers)>
Recipients: (My email), (The email of an innocent straw man used by the real scammers)
Contents(With UI styles copying those in real PayPal emails):
Someone has logged into your account
We noticed a new login with your PayPal account associated with (The email of an innocent straw man used by the real scammers) from a device we don't recognize. Because of that we've temporarily limited your account until you renew and verify your identity.
Please click the button below to login into your account for verify your account.
(Login button copying that in real Paypal emails)
If this was you, please disregard this email.
(Footers copying those in real PayPal emails)
I admit that I'm incredibly stupid, because I almost believed that it's a real PayPal email, and I only realized that it's a scam right after I've clicked the login button, because it links to a URL that's completely different from the login page of the real PayPal(so fortunately I didn't input anything there).
While I've faced many old-schooled phishing emails and can figure them all out right from the start, I've never seen phishing emails like this, and what makes me feel even more dumb is that I already have 2FA applied to my PayPal account before receiving this scam email, meaning that my phone would've a PayPal verification SMS out of nowhere if there was really an unauthorized login to my account.
Of course, that straw man email owner is completely innocent, and I believe that owner already received the same scam email with me being the straw man, so that owner might think that I really performed unauthorized login into his/her PayPal account, if he/she didn't realize that the whole email's just a scam.
Before I realized that it's just a scam, I thought he/she really done what the email claims as well, so I just focused on logging into my PayPal accounts to assess the damages done and evaluate countermeasures to be taken, and if I didn't realize that it's just a scam, I'd already have given the password of my PayPal account to the scammers in their fake PayPal login page.
I suspect that many more PayPal users might have already received/are going to receive such scam emails, and I think this way of phishing can work for many other online payment gateways as well, so I think I can do some good by sharing my case, to hope that only I'll be this dumb(even though I didn't give the scammers my Paypal password at the end).
Title: Notification Case #(Some random numbers)
Sender: (Non-Paypal logo)service@paypal.com.(My PayPal account location) <(Non-PayPal email used by the real scammers)>
Recipients: (My email), (The email of an innocent straw man used by the real scammers)
Contents(With UI styles copying those in real PayPal emails):
Someone has logged into your account
We noticed a new login with your PayPal account associated with (The email of an innocent straw man used by the real scammers) from a device we don't recognize. Because of that we've temporarily limited your account until you renew and verify your identity.
Please click the button below to login into your account for verify your account.
(Login button copying that in real Paypal emails)
If this was you, please disregard this email.
(Footers copying those in real PayPal emails)
I admit that I'm incredibly stupid, because I almost believed that it's a real PayPal email, and I only realized that it's a scam right after I've clicked the login button, because it links to a URL that's completely different from the login page of the real PayPal(so fortunately I didn't input anything there).
While I've faced many old-schooled phishing emails and can figure them all out right from the start, I've never seen phishing emails like this, and what makes me feel even more dumb is that I already have 2FA applied to my PayPal account before receiving this scam email, meaning that my phone would've a PayPal verification SMS out of nowhere if there was really an unauthorized login to my account.
Of course, that straw man email owner is completely innocent, and I believe that owner already received the same scam email with me being the straw man, so that owner might think that I really performed unauthorized login into his/her PayPal account, if he/she didn't realize that the whole email's just a scam.
Before I realized that it's just a scam, I thought he/she really done what the email claims as well, so I just focused on logging into my PayPal accounts to assess the damages done and evaluate countermeasures to be taken, and if I didn't realize that it's just a scam, I'd already have given the password of my PayPal account to the scammers in their fake PayPal login page.
I suspect that many more PayPal users might have already received/are going to receive such scam emails, and I think this way of phishing can work for many other online payment gateways as well, so I think I can do some good by sharing my case, to hope that only I'll be this dumb(even though I didn't give the scammers my Paypal password at the end).
7
Mathematics / Using Abel-Ruffini theorem on encryptions
January 25, 2021, 07:54:12 am
The complete microsoft word file can be downloaded here(as a raw file)
Summary
The whole password setup/change process is as follows:
1. The client inputs the user ID and its password in plaintext
2. A salt for hashing the password in plaintexts will be randomly generated
3. The password will be combined with a fixed pepper in the client software source code and the aforementioned salt, to be hashed in the client terminal by SHA3-512 afterwards
4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by a randomly generated salt in the client terminal
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation, which will finally be stored there
11. The 2 aforementioned different salts will be encrypted by 2 different AES-256 keys in the client software source code, and their encrypted versions will be sent to the server to be stored there
12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time
The whole login process is as follows:
1. The client inputs the user ID and its password in plaintext
2. The client terminal will send the user ID to the server, which will send its corresponding salts for hashing the password in plaintexts and forming distinct roots respectively, already encrypted in AES-256 back to the client terminal, assuming that the user ID from the client does exist in the server(otherwise the login fails and nothing will be sent back from the server)
3. The password will be combined with a fixed pepper in the client software source code, and the aforementioned salt that is decrypted in the client terminal using the AES-256 key in the client software source code, to be hashed in the client terminal by SHA3-512 afterwards
4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by the corresponding salt sent from the server that is decrypted in the client terminal using a different AES-256 key in the client software source code
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation
11. Whether the login will succeed depends on if the literal expression of the polynomial equation from the client exactly matches the expected counterpart already stored in the server
12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time
For an attacker trying to get the raw password in plaintext:
1. If the attacker can only sniff the transmission from the client to the server to get the encoded then encrypted version(which is then encrypted by RSA-4096) of the polynomial equation, the salt of its roots, and the counterpart for the password in plaintext, the attacker first have to break RSA-4096, then the attacker has to figure out the highly secret and obfuscated algorithm to decode those numbers and number separators into the resultant polynomial equation and the way its roots are attached by existing numeric literals and named constants
2. If the attacker has the resultant polynomial equation of degree 512, its roots must be found, but there's no direct formula to do so analytically due to Abel-Ruffini theorem, and factoring such a polynomial with 156 different named constants efficiently is very, very complicated and convoluted
3. If the attacker has direct access to the server, the expected polynomial equation can be retrieved, but the attacker still has to solve that polynomial equation of degree 512 to find all its roots with the right ordering among them and all their correct literal expressions
4. If the attacker has direct access to the client software source codes, the pepper for hashing the password in plaintext, the pepper used on the polynomial equation roots, and the highly secret and obfuscated algorithm for using them with the salt counterparts can be retrieved, but it's still far from being able to find all the roots of the expected polynomial equation of degree 512
5. If the attacker has all those roots, the right ordering among them and all their correct literal expressions still have to be figured out, and the salts and peppers for those roots has to be properly removed as well
6. If the attacker has all those roots with the right ordering among them, all their correct literal expressions, and salts and peppers on them removed, the attacker has effectively recovered the hashed password, which is mixed with salts and peppers in plaintext
7. The attacker then has to figure out the password in plaintext even with the hashing function, salt, pepper, and the highly secret and obfuscated algorithm that combines them known
8. Unless there are really efficient algorithms for every step involved, the time complexity of the whole process can be as high as factorial time
9. As users are still inputting passwords in plaintexts, dictionary attacks still work to some extent, but if the users are careless with their password strengths, then no amount of cryptography will be safe enough
10. Using numerical methods to find all the roots won't work in most cases, because such methods are unlikely to find those roots analytically, let alone with the right ordering among them and all their right literal expressions, which are needed to produce the resultant polynomial equation with literal expressions exactly matching the expected one
11. Using rainbow tables won't work well either, because such table would be way too large to be used in practice, due to the number of polynomial equations with degree 512 being unlimited in theory
12. Strictly speaking, the whole password encryption scheme isn't a one-way function, but the time complexity needed for encryption compared to that for decryption is so trivial that this scheme can act like such a function
Areas demanding further researches:
1. The time complexity for factoring a polynomial of degree n with named constants into n factors analytically
2. Possibilities of collisions from the ordering among all roots and all their different literal expressions
3. Existence of efficient algorithms on finding the right ordering among all roots and all their right literal expressions
4. Strategies on setting up the fixed peppers and generating random salts to form roots with maximum encryption strength
Essentially, the whole approach on using polynomial equations for encryptions is to exploit equations that are easily formed by their analytical solution sets but very hard to solve analytically, especially when exact literal matches, rather than just mathematical identity, are needed to match the expected equations.
So it's not strictly restricted to polynomial equations with a very high degree, but maybe very high order partial differential equations with many variables, complex coefficients and functions accepting complex numbers can also work, because there are no known analytical algorithm on solving such equations yet, but analytical solutions are demanded to reproduce the same partial differential equations with exact literal matches, as long as performing partial differentiations analytically can be efficient enough.
Summary
The whole password setup/change process is as follows:
1. The client inputs the user ID and its password in plaintext
2. A salt for hashing the password in plaintexts will be randomly generated
3. The password will be combined with a fixed pepper in the client software source code and the aforementioned salt, to be hashed in the client terminal by SHA3-512 afterwards
4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by a randomly generated salt in the client terminal
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation, which will finally be stored there
11. The 2 aforementioned different salts will be encrypted by 2 different AES-256 keys in the client software source code, and their encrypted versions will be sent to the server to be stored there
12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time
The whole login process is as follows:
1. The client inputs the user ID and its password in plaintext
2. The client terminal will send the user ID to the server, which will send its corresponding salts for hashing the password in plaintexts and forming distinct roots respectively, already encrypted in AES-256 back to the client terminal, assuming that the user ID from the client does exist in the server(otherwise the login fails and nothing will be sent back from the server)
3. The password will be combined with a fixed pepper in the client software source code, and the aforementioned salt that is decrypted in the client terminal using the AES-256 key in the client software source code, to be hashed in the client terminal by SHA3-512 afterwards
4. The hashed password as a hexadecimal number with 128 digits will be converted to a base 256 number with 64 digits, which will be repeated 8 times in a special manner, and then broken down into a list of 512 literals, each being either numeric literals 1 to 100 or any of the 156 named constants
5. Each of those 512 numeric literals or named constants will be attached with existing numeric literals and named constants via different ways and combinations of additions, subtractions, multiplications and divisions, and the whole attachment process is determined by the fixed pepper in the client software source code
6. The same attachment process will be repeated, except that this time it's determined by the corresponding salt sent from the server that is decrypted in the client terminal using a different AES-256 key in the client software source code
7. That list of 512 distinct roots, with the ordering among all roots and all their literal expressions preserved, will produce the resultant polynomial equation of degree 512
8. The resultant polynomial equation will be encoded into numbers and number separators in the client terminal
9. The encoded version will be encrypted by RSA-4096 on the client terminal with a public key there before being sent to the server, which has the private key
10. The server decrypts the encrypted polynomial equation from the client with its RSA-4096 private key, then decode the decrypted version in the server to recover the original polynomial equation
11. Whether the login will succeed depends on if the literal expression of the polynomial equation from the client exactly matches the expected counterpart already stored in the server
12. The time complexity of the whole process, except the SHA3-512, RSA-4096 and AES-256, should be controlled to quadratic time
For an attacker trying to get the raw password in plaintext:
1. If the attacker can only sniff the transmission from the client to the server to get the encoded then encrypted version(which is then encrypted by RSA-4096) of the polynomial equation, the salt of its roots, and the counterpart for the password in plaintext, the attacker first have to break RSA-4096, then the attacker has to figure out the highly secret and obfuscated algorithm to decode those numbers and number separators into the resultant polynomial equation and the way its roots are attached by existing numeric literals and named constants
2. If the attacker has the resultant polynomial equation of degree 512, its roots must be found, but there's no direct formula to do so analytically due to Abel-Ruffini theorem, and factoring such a polynomial with 156 different named constants efficiently is very, very complicated and convoluted
3. If the attacker has direct access to the server, the expected polynomial equation can be retrieved, but the attacker still has to solve that polynomial equation of degree 512 to find all its roots with the right ordering among them and all their correct literal expressions
4. If the attacker has direct access to the client software source codes, the pepper for hashing the password in plaintext, the pepper used on the polynomial equation roots, and the highly secret and obfuscated algorithm for using them with the salt counterparts can be retrieved, but it's still far from being able to find all the roots of the expected polynomial equation of degree 512
5. If the attacker has all those roots, the right ordering among them and all their correct literal expressions still have to be figured out, and the salts and peppers for those roots has to be properly removed as well
6. If the attacker has all those roots with the right ordering among them, all their correct literal expressions, and salts and peppers on them removed, the attacker has effectively recovered the hashed password, which is mixed with salts and peppers in plaintext
7. The attacker then has to figure out the password in plaintext even with the hashing function, salt, pepper, and the highly secret and obfuscated algorithm that combines them known
8. Unless there are really efficient algorithms for every step involved, the time complexity of the whole process can be as high as factorial time
9. As users are still inputting passwords in plaintexts, dictionary attacks still work to some extent, but if the users are careless with their password strengths, then no amount of cryptography will be safe enough
10. Using numerical methods to find all the roots won't work in most cases, because such methods are unlikely to find those roots analytically, let alone with the right ordering among them and all their right literal expressions, which are needed to produce the resultant polynomial equation with literal expressions exactly matching the expected one
11. Using rainbow tables won't work well either, because such table would be way too large to be used in practice, due to the number of polynomial equations with degree 512 being unlimited in theory
12. Strictly speaking, the whole password encryption scheme isn't a one-way function, but the time complexity needed for encryption compared to that for decryption is so trivial that this scheme can act like such a function
Areas demanding further researches:
1. The time complexity for factoring a polynomial of degree n with named constants into n factors analytically
2. Possibilities of collisions from the ordering among all roots and all their different literal expressions
3. Existence of efficient algorithms on finding the right ordering among all roots and all their right literal expressions
4. Strategies on setting up the fixed peppers and generating random salts to form roots with maximum encryption strength
Essentially, the whole approach on using polynomial equations for encryptions is to exploit equations that are easily formed by their analytical solution sets but very hard to solve analytically, especially when exact literal matches, rather than just mathematical identity, are needed to match the expected equations.
So it's not strictly restricted to polynomial equations with a very high degree, but maybe very high order partial differential equations with many variables, complex coefficients and functions accepting complex numbers can also work, because there are no known analytical algorithm on solving such equations yet, but analytical solutions are demanded to reproduce the same partial differential equations with exact literal matches, as long as performing partial differentiations analytically can be efficient enough.
8
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Skill Item Triggers
December 26, 2020, 10:03:41 am
Updates
* { codebase: "1.1.1", plugin: "v1.01a" }(2020 Dec 26 GMT 1300):
* 1. Added the following notetag types:
* subjectMiss
* subjectEva
* subjectCnt
* subjectMrf
* subjectCri
* subjectNorm
* subjectSubstitute
* 2. Added the following parameters:
* subjectMissNotetagDataTypePriorities
* subjectEvaNotetagDataTypePriorities
* subjectCntNotetagDataTypePriorities
* subjectMrfNotetagDataTypePriorities
* subjectCriNotetagDataTypePriorities
* subjectNormNotetagDataTypePriorities
* subjectSubstituteNotetagDataTypePriorities
* 3. Fixed the eventEntry of all notetags not correctly accepting all
* intended suffixes and rejecting the unintended onesYou'll need the latest version of DoubleX RMMZ Enhanced Codebase as well
9
RMMV Script Database / Re: [MV] DoubleX RMMV Superlative ATB
December 11, 2020, 08:26:25 am
Updates
* - v0.15c(GMT 0700 11-Dec-2020):
* 1. Fixed the following wrong documentations:
* Battler manipulations -
* i. setDelaySecCounter should be setSATBDelaySecCounter
* ii. addDelaySecCounter should be addSATBDelaySecCounter
* iii. multiplyDelaySecCounter should be
* multiplySATBDelaySecCounter
* iv. delaySecCounter should be satbDelaySecCounter
* 2. Added the action sequence for the Delay Module in
* Yanfly Engine Plugins - Battle Engine Core
* 3. Lets players cancels actor cooldown by clicking the actor sprite
* 4. Lets players cancels actor charge by clicking the actor sprite
10
RMMZ Script Database / Re: [MZ] DoubleX RMMZ TPBS Countdown States
December 10, 2020, 10:36:58 pm
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 11 GMT 0400):
* 1. Adding the plugin command and query counterpart of the
* isTPBSCountdownState battler manipulation
* 2. Documented the isTPBSCountdownState battler manipulation
* 3. Fixed the bug of not removing countdown states nor triggering
* effects from plugin DoubleX RMMZ State Triggers11
RMMV Script Database / Re: [MV] DoubleX RMMV Superlative ATB
December 07, 2020, 01:58:01 am
Updates
* - v0.15b(GMT 0400 7-Dec-2020):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Superlative_ATB_Parameters_File when changing the
* parameter plugin file name
* 2. Fixed the wrong this of the following Array prototype methods:
* i. fastFilter
* ii. fastMap
* iii. filterMap
* iv. mapFilter
* v. mapReduce
* vi. mapSome
* 3. Fixed the x and y positions and opacity update bugs for discrete
* order battler sprites
* 4. Fixed wrong unit test check conditions for the x and y positions
* and opacity for discrete order battler sprites12
RMMZ Script Database / Re: [MZ] DoubleX RMMZ TPBS CTB
December 02, 2020, 05:14:48 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.TPBS_CTB.PLUGIN_NAME when changing this plugin file
* name13
RMMZ Script Database / Re: [MZ] DoubleX RMMZ TPBS Battle Turns
December 02, 2020, 04:51:05 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.TPBS_Battle_Turns.PLUGIN_NAME when changing this
* plugin file name14
RMMZ Script Database / Re: [MZ] DoubleX RMMZ TPBS Actor Hotkeys
December 02, 2020, 04:37:57 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.TPBS_Actor_Hotkeys.PLUGIN_NAME when changing this
* plugin file name15
RMMZ Script Database / Re: [MZ] DoubleX_RMMZ_Targeting_Hotkeys
December 02, 2020, 04:23:38 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0900):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Targeting_Hotkeys.PLUGIN_NAME when changing this
* plugin file name16
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Script Call Hotkeys
December 02, 2020, 02:14:50 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0800):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Script_Call_Hotkeys.PLUGIN_NAME when changing this
* plugin file name17
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Plugin Query
December 02, 2020, 02:02:13 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0700):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Plugin_Query.PLUGIN_NAME when changing this plugin
* file name18
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Custom Script Calls
December 02, 2020, 01:18:58 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0700):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Custom_Script_Calls.PLUGIN_NAME when changing this
* plugin file name19
RMMZ Script Database / Re: [MZ] DoubleX_RMMZ_Custom_Key_Maps
December 02, 2020, 01:06:44 am
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0600):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Custom_Key_Maps.PLUGIN_NAME when changing this plugin
* file name20
RMMZ Script Database / Re: [MZ] DoubleX RMMZ Auto Battle Command
December 01, 2020, 10:46:11 pm
Updates
* { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0400):
* 1. You no longer have to edit the value of
* DoubleX_RMMZ.Auto_Battle_Command.PLUGIN_NAME when changing this
* plugin file name