Moveset Editing via wp .fsm - AniBullet/MonsterHunterWorldModding GitHub Wiki

Written by Velindian

mIds

There are 2 lists of mIds.

The first are the ones with a “,” after the number.

mIds Listed here are the actions the character can do. Actions in this list include attacks, states of movement, environmental interactions, & transitional animations.

In the second list there is no “,” after the mId itself.

Conditions are what is listed from here on down. Conditions can include button inputs (both compound and singular), weapon specific mechanics, environmental factors, when an attack hits, and states of animation. Actions each have their own set of conditions you can use for links, but any condition can be used multiple times. There’s a lot of repetitive conditions in the second mId list. So you can reuse many of them, and free up other mIds for custom conditions.

Most of the names for actions and conditions will be in Japanese, but not always one type of japanese writing (i.e. there is a mix of lone words, kanji, etc.). Some may also be acronyms or include english letters or words. I used Google Translate to “decode” some of the names and for the most part it makes sense. It will probably be way quicker at first if you already understand it though. Especially since some words like “Slaga” & “Pickpocketing” come out instead of “Sliding” or “???” through Google Translate sometimes.

LinkLists

Under each action in the first mId list is a linklist that determines what actions can be done from that action, and what conditions are required to do them. Actions at the top of the list are prioritized over ones  on the bottom. So if you have links with conditions that use the same input at some point, you’ll need to order them so the compound one is first (i.e. if one link’s condition is “R + O”, you’ll need to put it above all links with conditions that use “R” and “O”). Otherwise, it will read the single input before the compound one (i.e. if you pressed “R + O” and the link that is higher on the list has a condition with just “O”, the action tied to that link will occur instead of the one tied to “R + O”). This logic also applies to other conditions outside of inputs. To include: environmental interaction, phases of animation, & having a certain weapon specific mechanic active (like red extract, Shield Strengthening, demonization, etc.).

The links in the linklists follow a simple structure

Above is an open bracket.

If the link is the only one in the list, this will be right after the “mpLinkList”.

“mDestinationNodeId” is the action the link goes to.

“mExistCondition”: is always “1,” so it’s irrelevant.

“mConditionId” is the condition(s) required to activate the link.

Below is a close bracket.

The close bracket will have a “,” after it if the link is not the last in the list

The structure of the linklist changes depending on if the move has no listed links, only one listed link, or multiple listed links. This is important to keep in mind as the script that recompiles the .JSON into an .FSM will not be able to do so unless the syntax is correct. Below are picture showing the structures below with their differences highlighted.

No Links

A single link

Multiple links

Note the brackets below/next to the ”mpLinkList”, above/next to “mpProcessList”, & between the links themselves. These need to be typed in specific ways depending on the total amount of links.

Functionally some Actions will still have links, even if they aren’t displayed. These will be overwritten by the fsm. One example being the coating application on Bow. If you place a "△" link anywhere coating could be applied as a link, you will do the action tied to that instead.

Conditions

Condition mIds also have a different structure depending on how many individual conditions there are. Below are examples of them with differences from the previous highlighted.

Single Condition

Double Condition

Triple & Above Condition

Custom Conditions

As mentioned before, moves have limitations on what conditions apply to them. However there are normally unused conditions that can apply. Sometimes these conditions don’t exist in the vanilla .fsm, but can be copy/pasted from other weapon .fsms. The “property names” under the condition mIds are the conditions themselves. Some conditions will not work for certain actions, and will be ignored. However, all conditions under the condition mId that can apply to the action will still apply. Unless the individual condition is a compound input like “R + O”, then if the action accepts the conditions “R” or “O” but not “R + O” it will ignore it. If the condition mId has a “R” or “O” condition listed in it, it will use those. Much like the linklists, the higher conditions are prioritized. However, in some cases it doesn’t matter. Typically when the individual conditions include states like “Demonization”, “Red Extract”, etc.

In order for any of the conditions to work, they must be in their original form. Otherwise they won’t be recognized by the game. Whether that’s in symbols, kanji, or whatever else.

Generally the exact structure from conditions, to move names, to inputs is inconsistent.

For example, SnS, DB, CB, LS, and many more have different names for the conditions applying to “L”. Sometimes the input applied to the roll button will be listed as “X” or “Avoidance” (Though the “Avoidance” condition specifically can only be used when a roll or jump is available from whatever action you are doing).

I’m currently working on compiling a list of every condition and what they mean to the best of my ability.

Enum Value Editing

Some actions will not be mapped out in the fsm. Normally you can change the “EnumValue” underneath the action, and it will tie all the links that can be applied to the action associated with the Enum Value. In my WIP insect Glaive mod I use this too create links for actions that normally wouldn’t. The vanilla IG fsm doesn’t have a “Back Avoidance” action tied to an mId in the fsm. So I replaced the Enum Value of an mId with the one for the back roll (which i guessed from the trend in the enum values of the rolling actions), and was able to place links after it.

You can also make new actions as long as you get the syntax right, but I haven’t needed to do so yet. Theoretically this can be useful for attaching links to actions not in the fsm by default.

Jank Link Techniques

Phase 0 Cancelling

Using “phase 0” conditions to lead into other actions will cause the action to be skipped, but all mechanics like stamina drain, gauge usage, etc. will still apply. This can also fix some glitches like Helmbreaker’s shell collisions not appearing unless you initiate a Spirit Thrust beforehand.

In some cases you can also use this to convert certain actions into others. Like turning the backwards roll into SnS backstep.

Avoidance Hopping

Actions that cause basic rolling will cause a short hop if in the air.

End Of Action Cancelling

“End Of Action” conditions into idle state actions will cause some moves to cancel once they reach a certain point in their animation. These are especially early for most CB animations. Which allows you to decrease recovery at the expense of animation fluidity.

If you place the link with the “End of action” condition below any others, you will be able to halt it from occurring by holding the button used to initiate the action you just did. Sometimes this can vary depending on the action itself and the previous input. So it’s not always perfect.

By using this I was able to expand the moveset of my WIP CB mod. Mainly by allowing the use of links that could normally only be done from the mode’s idle action. Allowing for more mobility and move selection.