Jump to content

XML talk:TRAM: Difference between revisions

Why don't we have a list of anim types bound to user input?
(ITO: "primary" interpolation length seems hardcoded but you can overwrite it via a Shortcut after all)
(Why don't we have a list of anim types bound to user input?)
Line 1: Line 1:
==What we know and not know==
Animations never stop, they flow from one to another.
The default case is a character getting spawned and then just standing there, he idles.
This brings us to the core attributes of an animation: '''type, state, variant'''. (In XML it is varient. [sic])
:Theoretically you could recycle all attribute and build your own animation system, but that would not be of much practical use.
:The prone mode mod is an exception, in the context of the existing system it can be considered a logical expansion where BSL handles the transition.
Now then, the idle animation does not link to a specific followup animation - or for short "anim" - it rather links to a state being followed.
: Ironically all anims have a <FromState> and a <ToState>, but no obvious <CurrentState> which can cause confusion on what the current anim actually is.
: This gives us two options of how to think of the situation: either consider <FromState> being usually the <CurrentState>, or states exist only between anims and serve as transition rules.
Linking to a followup '''state allows for multiple choices''' of what specific animation comes next. For example there's a rare chance that Mai will sneeze if she idles for a long time.
An anim is picked up randomly from a pool of valid animations. Their '''probability or <Weight> is determined by TRAC''' - the anim collection.
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMKONOKOidle1</Animation>
            </TRACAnimation>
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMKONOKOidle2</Animation>
            </TRACAnimation>
Here's the sneeze animation with Weight 100, but the real chance of getting picked up is still low. Why?
Welcome to the world of Oni <s>bugs</s> mysteries.
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMKONOKOidle_spec3</Animation>
            </TRACAnimation>
A working example of <Weight> is the Ninja Moonwalk named taunt2.
            <TRACAnimation>
                <Weight>100</Weight>
                <Animation>TRAMNINCOMtaunt1</Animation>
            </TRACAnimation>
            <TRACAnimation>
                <Weight>5</Weight>
                <Animation>TRAMNINCOMtaunt2</Animation>
            </TRACAnimation>
To let an character flow from one anim state to another the <ToState> is used.
Let's say a SBG grenade hit Konoko and she falls down, TRAMKONOKOblownup1 is played.
She is now in state FallenBack and the engine picks up next animation with <FromState>FallenBack.
KONCOMfallen_back puts the character into combat mode by using <Varient>Combat.
But if the player gives no input Mai will remain on the ground as <ToState>FallenBack creates a loop.
Question: Why is KONCOMgetup_lt not played automatically since it also has <FromState>FallenBack and <Varient>Combat?
It differs in its <Type>. Obviously some [[anim types are bound to user input]] and therefor are excluded from the automatically created pool of valid anims to follow.
A left mouse turn tells the engine to use an anim of type StandingTurnLeft.
This is true for KONOKOcomb_turnlt and KONCOMgetup_lt but only the latter matches the current <FromState> condition.
: KONOKOcomb_turnlt has in fact <Varient>Combat, comb stands here for combat, not combo. Following Oni's naming convention, the file should have been named KONCOMturn_lt.
Knowing this behavior we can deduce that anims types registered to user input will make the engine ignore all the automatic anims inside the pool, therefor breaking the loop of KONCOMfallen_back.
Since KONCOMgetup_lt has <ToState>Standing and <Varient>Combat the following idle animation must also have <Varient>Combat.
So, next anim played will be KONCOMidle1 or KONCOMidle2.
[...]
==ITO Round 2==
==ITO Round 2==
The ITO bug seems to be caused by our limited knownledge of the animation system.
The ITO bug seems to be caused by our limited knownledge of the animation system.
8,471

edits