Table Of Contents

Skills

Skills are where the majority of the battle magic occurs, and are very versatile. This is where the Notes coding is at it's most complex, so be prepared for that.

General Settings

Damage Formulas

And now for the Formulas. RPG Maker uses a very specific system for writing out formulas that must be followed correctly.

The first part of the system is how the user and target of a skill are referred. They are known as a and b respectively. In addition if an extra party member's stats are needed, they can be called by $gameActors.actor(#), with # being their ID (1 for Omori, 2 for Aubrey, 3 for Kel, and 4 for Hero.).

The next part is the stats being factored in. If we want to use the stat of a battler, we must put their name(a for the user, b for the target, and $gameActors.actor(#) for extra party members) with a period, and then the abbreviation for the stat. In practice this looks like "a.atk" for the user's attack stat.

After that we have the operations that can be used. These include Addition, Subtraction, and Multiplication(Division can be done by multiplying by decimals), all of which use the standard keyboard symbols for them. Parenthesis can be used to create Order of Operations equations.

This is all you need for basic formulas that don't have any variables other than character stats. So for example an attack that adds the attack of the user and Hero's luck, multiplies the sum by 2, and then subracts that by the targets defense would look like: "(a.luk + $gameActors.actor(4).luk) * 2 - b.def"

The last part of these damage formulas are what I will call "State Checks" which use JavaScript if then statements to determine what formula to use.

(a.isStateAffected(6) || a.isStateAffected(10) || a.isStateAffected(14)) ? a.atk * 4 - b.def : (a.isStateAffected(7) || a.isStateAffected(11) || a.isStateAffected(15)) ? a.atk * 5 - b.def : (a.isStateAffected(8) || a.isStateAffected(12) || a.isStateAffected(16)) ? a.atk * 6 - b.def : a.atk * 3 - b.def;

This is the most extreme example of this is OMORI, being the skill Final Strike, which deals more damage the higher Omori's emotion is. Let's take it one step at a time.

"(a.isStateAffected(6) || a.isStateAffected(10) || a.isStateAffected(14)) ?" This code checks if the user (Omori) is affected by state 6, 10, or 14, which are Happy, Sad, and Angry respectively. The || acts as a shorthand for "or." And the "?" as a shorthand for "then." So this code would read to a normal person as "If the user is affected by state 6, or state 10, or state 14, then [proceeds to the rest of the action.]"

"a.atk * 4 - b.def" This code will activate if the previous conditions were met, which is thanks to the ? before this code. This is the actual damage calculation for if Omori is at a stage 1 emotion. It's the user(Omori)'s attack times 4 minus the foe's defense.

": (a.isStateAffected(7) || a.isStateAffected(11) || a.isStateAffected(15)) ?" This code will activate if the previous conditions were not met, which is thanks to the ":" at the front of this section, which acts as a shorthand for "else." This code does the same check as before, but now for the stage 2 emotions. So this will be the condition to be met.

"a.atk * 5 - b.def" This code will activate if the newly defined conditions of being at a stage 2 emotion. The code reads the same as the previous formula, but now the user's attack is multiplied by 5.

": (a.isStateAffected(8) || a.isStateAffected(12) || a.isStateAffected(16)) ?" This code is the exact same as the check for stage 2 emotions, but now for stage 3.

"a.atk * 6 - b.def" This code is the exact same as the stage 2 formula, but now the user's attack is multiplied by six.

": a.atk * 3 - b.def;" This code is activated if all the above conditions are failed, meaning Omori has no emotions. The damage formula itself is once again the same but the user's attack is multiplied by only three. And lastly any state checking formulas like this must have the final formula end with a semicolon (";")

This was a really complex example, which I chose for demonstration purposes, but you can make much simpler ones with only one state check, or go even further and add more checks and variables. Since this simply checks if you are affected by a specific state, you aren't limited to just emotions. Buffs, Debuffs, and other states can also be checked, and for anyone, not just the user. For example you could have "$gameActor.actor(4).isStateAffected(1)" Which will check if Hero is dead. This system is very versitile.

Notes Coding

Now for the most complex section of making skills. The Notes tab. Normally in RPG Maker this is simply an area to add, well, notes. But since OMORI is a respectable RPG Maker game, it uses Yanfly's scripting plugins, allowing the Notes Section to become a bit of a JavaScript host. Here I will be showing the general and common uses of the Notes tab, as it would be impossible to show everything.

General Parameter Notetags

These notetags can be added to skills to make small functional or aesthetic changes. These can be placed anywhere in the Notes tab, but are usually placed at the top for organization.

<BattleLogType: string> This notetag determines what text to display from a js file called Custom Battle Action Text. Personally I prefer using a different of displaying text, but this can be used for basic attacks where you just want "User attacks Target!" In this case just add "<BattleLogType: ATTACK>"

<AntiFail> Some skills do things other than heal or harm a friend or foe, but RPG Maker might show still show a "It had no effect" message. This disables that.

<HideInMenu> Self-Explanatory. Hides it from the skill equip menu. Use this for your basic attacks and follow-ups.

<Enemy or Actor Select> The emotion skills, Sad Poem, Pep Talk, Annoy, and Massage, can be used on both friends and foes. This is achieved with this notetag.

Timing Notetags

These notetags can be added to skills to determine the order of certain actions in the Notes Coding. All of these must be placed before and after their contained code, with the closing version having a / infront of the name like this </Target Action>

<Setup Action> The earliest of the 4. This happens before any juice is consumed, so things like User animations and other "setup actions" will usually occur here.

<Whole Action> This occurs right before the main action, and applies its effects to all targets simultaneously. However, it does this in a bit of an odd way. It calculates the action for one target, and then dupes the results onto everyone else. This can cause some issues for effects that are based on target-by-target variables like their level of buff or debuff.

<Target Action> In my opinion, the better Whole Action. Occurs exactly as the main action effect will occur, and works its effects on each target individually. So things like attack animations and state changes should occur here. Make sure that if you use Target Action, you must define when the skill's main action occurs. This is done with the line "action effect," which can be placed multiple times if you want the move to activate multiple times, like Red Hands.

<Post-Damage Eval> A rarely used aftermath section. This is used for times where a closing action needs to occur that isn't part of the target action. I've also seen <After Eval> used in these types of situations, but I couldn't tell you the difference.

Text Notetag

The "eval:" notetags can be added to skills to excute JavaScript, but it is mainly used in OMORI to display text. Like this:

eval: BattleManager._logWindow.push("addText", `${user.name()} hypes up ${target.name()}!`)

This is a line from a mod I'm working on, but that's not important. What is important is that this is all you need to display detailed text in OMORI's battle box. The cyan text is what's actually shown in game, with the user and target name's being self-explanatory. Since it's part of the Notes coding, you can determine when in the skill it plays, and have if and then statements change the line used. It's rather versatile and simple.

Emotion & Stat Changing Notetags

These are just really formulaic if then statements with their ids swapped out for the correct state. However, OMORI handles its buffs and debuffs in a rather janky way. Buffs and Debuffs don't combine with each other, and instead are just both active states at the same time. So getting a -1 Attack Debuff while at a +3 Buff doesn't lower you to +2 Attack, but rather +3 Attack and -1 Attack, which is just dumb. Luckily a wonderful person named Nru made statements that do correctly combine the buffs and debuffs. I've also referenced their skills section in the OMORI Modding Mastersheet for a lot of this page, so thank you.

Other Common Notetags

animation x: y Plays the animation with x ID. y is where the animation will play. It can be user, target, actors(all actors), character #(# being their actor id), and screen.

wait for animation Waits for all animations to end before proceeding. Can sometimes be a bit finicky.

wait: # Waits the set number of frames before continuing. RPG Maker runs in 60fps, so wait: 60 will wait for one second.

<Custom Requirement> This is setup the same as a timing notetag, but is for setting extra requirements for a skill be usable. This is done by a JavaScript if then, where "value" is the boolean that determines if a skill can be performed or not. This is mainly used for Follow-Ups.

Follow-Ups

Follow-Ups, as to be expected, work quite differently from all the other skills in OMORI. This will explain how to set them up.

All Tiers Of The Follow-Up

In OMORI, your follow-ups get stronger after hitting specific story beats. These upgrades to your follow-ups are separate skills in the Database, and as you need to have a "Pre-Skill" that checks what skill should be used, and then activates that skill. In OMORI, these are called Checks.

Before the Checks actually determine what skill to use, they have a <Custom Requirement> notetag that checks to see if the party members involved in the follow-up are dead. This will lock the skill if they are dead. You can just copy paste that requirement from a preexisting check.

Now for the actual Check. This is done by activating a Common Event. This Common Event will then go through an if then chain to see if the player has met the story beat needed for a specific tier, if they have, it uses the Force Action event on the Party Member to use the actual Follow-Up on the Last Target. It roughly looks like, 

If : StoryBeat2 is on

Force Action : Basil, Vent 3, Last Target

jump to label: end

     end

If : StoryBeat1 is on

Force Action : Basil, Vent 2, Last Target

jump to label: end

     end

Force Action : Basil, Vent 2, Last Target

label : end

Attaching The Follow-Ups To Your Attacks

Now we're done the annoying a tedious part. The rest is easy.

To attach your follow-ups, you have to add this Notetag to your basic attack for all 3 follow-ups it has.

<ChainSkill: #, direction> The # gets replaced with the ID of the Check, not any of the actual Follow-Ups. The Direction is what arrowkey has to be pressed to activate the Follow-up. up, down, left, and right.

Follow-Up Notetags

<ChainSkillIcon: #> This determines what image to use for the Follow-Up bubble. You can see them in img/system/ACS_Bubble.png. If you're adding new Follow-Ups, refer to the Sprites & Art page for adding new Follow-Up bubbles. What I didn't mention there is how they are indexed. It's the same as most images in OMORI, starting at 0, left-to-right, top-to-bottom.

<ChainSkill[Name of a followup]> I don't know what exactly these do, but I recommend just setting them to the Follow-Up that uses that slot normally. So for example, Basil's comfort follow-up is his down follow-up, and he takes Kel's place in the battle menu, so I'd set Comfort to <ChainSkillPassToOmori>

<EnergyCost: #> Self Explanatory. All but Release Energy cost 3 energy, with Release energy costing 10, but you can set them all to whatever you like(Within reason. I don't know what would happen if you set one to 0 or anything above 10, probably works fine, but just be ready if something goes wrong).

<HideInMenu> Not Follow-Up specific but make sure they don't show in the skill menu.

Items

Luckily for us, Items for the most part are simply one time use skills, so most of the skill code carries over to here, and therefore I will only go over the differences.