|
|
| Line 13: |
Line 13: |
| : ... following things are done: | | : ... following things are done: |
| * <strike>motion blur (mini tutorial?)</strike> | | * <strike>motion blur (mini tutorial?)</strike> |
| * impact effects (mini tutorial?) | | * <strike>impact effects (mini tutorial?)</strike> |
| * TRAM picking mechanism: it gets easier to this mechanism if we differentiate between pool construction and pool usage | | * <strike>TRAM picking mechanism: it gets easier to this mechanism if we differentiate between pool construction and pool usage</strike> |
| * throw pair animation table | | * <strike>throw pair animation table</strike> |
| * a simple tutorial to let a modder warm up with animations in Blender (it's okay if it rather resembles "round trip") since this page is about the file type itself (therefore: import and export) | | * a simple tutorial to let a modder warm up with animations in Blender (it's okay if it rather resembles "round trip") since this page is about the file type itself (therefore: import and export) |
| --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:53, 15 March 2023 (CET) | | --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 16:53, 15 March 2023 (CET) |
|
| |
| ==Variants==
| |
| Further research needed.
| |
| * The existence of STRCOMrun_thw_fw_p(_tgt) and STRCOMrun_thw_fw_pl(_t) means that we need extra research to understand the full extent of the throw system.
| |
| * The variant (varient [sic]) pickup system is not clear yet: is a RIFCOM idle and a RIFNAT idle both possible?
| |
| ** Or do rightpistole, leftpistol, rightrifle and leftrifle variants count as subsets of combat?
| |
|
| |
| ==TRAM picking mechanism==
| |
| : Older brain dump.
| |
|
| |
| Animations never stop, they flow from one to another. (See also: concept of state machines in gaming.)
| |
|
| |
| 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 much practical.
| |
|
| |
| :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 anim comes next. An anim is picked up randomly from a '''pool of valid anims'''. Their '''probability or <Weight> is determined by TRAC''' - the anim collection.
| |
|
| |
| The Ninja's Moonwalk anim (taunt2) has only a 5/(100+5)*100 = 4,76 % chance of getting picked.
| |
|
| |
| <TRACAnimation>
| |
| <Weight>100</Weight>
| |
| <Animation>TRAMNINCOMtaunt1</Animation>
| |
| </TRACAnimation>
| |
| <TRACAnimation>
| |
| <Weight>5</Weight>
| |
| <Animation>TRAMNINCOMtaunt2</Animation>
| |
| </TRACAnimation>
| |
|
| |
| There's also a rare chance that Mai will sneeze if she stands for a long time.
| |
|
| |
| Here's the sneeze anim with Weight 100, but the real chance of getting picked is still low. Why?
| |
|
| |
| <TRACAnimation>
| |
| <Weight>100</Weight>
| |
| <Animation>TRAMKONOKOidle_spec3</Animation>
| |
| </TRACAnimation>
| |
|
| |
| That's because all '''idle anims''' are in fact of '''type Stand''' while Konoko's '''idle_spec3''' is of '''type Idle'''.
| |
|
| |
| The chance of idle type anims to be picked up is determined by ONCC values in <IdleAnimation1Timer> and <IdleAnimation2Timer>.
| |
|
| |
| Anyway, to let an character flow from one anim state to another the <ToState> is used.
| |
|
| |
| Let's say a SBG grenade hits Konoko. The particle's '''damage type''' is '''blownup''', this and the direction of damage force an anim of type '''Blownup''' or '''BlownupBehind''' to play like TRAMKONOKOblownup1.
| |
|
| |
| This all simply means she falls to her back, going into the FallenBack state. The engine picks up next anim with <FromState>FallenBack.
| |
|
| |
| Also, '''receiving damage''' puts the character into '''Combat mode''' so further anims will be of variant 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 most [[XML_talk:StNA|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 Konoko is still in Combat mode the following idle anim must also have <Varient>Combat.
| |
|
| |
| So, next anim played will be KON'''COM'''idle1 or KON'''COM'''idle2.
| |
|
| |
| Konoko will eventually calm down when her ONCC<FightModeTimer> run down and then KON'''OKO'''idle1 or KON'''OKO'''idle2 will be played.
| |
|
| |
| Actually the COMidle will continue until an non-combat anim will break that loop.
| |
|
| |
| That is the fallback behavior of anims getting picked: if the engine cannot find an anim for an active variant (or "mode") it will choose the normal (non-variant) version.
| |
|
| |
| Anims can be in the following variants: Combat, LeftPistol, LeftRifle, Panic, RightPistol, RightRifle and Sprint.
| |
|
| |
| As for combinations of variants, it's possible, yes, but rarely and only Sprint and one weapon variant at a time.
| |
|
| |
| [...]
| |
|
| |
|
| ==Problem with exporting a textured character with non-native TRAC animation== | | ==Problem with exporting a textured character with non-native TRAC animation== |
| Line 147: |
Line 59: |
|
| |
|
| "dae to xml(41).bat" will generate files with '''E'''Keys. | | "dae to xml(41).bat" will generate files with '''E'''Keys. |
|
| |
|
| |
|
| ====... using the Windows address bar==== | | ====... using the Windows address bar==== |
| Line 154: |
Line 65: |
|
| |
|
| We want to type as less as necessary, don't we? =) | | We want to type as less as necessary, don't we? =) |
|
| |
|
| |
|
| ====... using onisplit GUI==== | | ====... using onisplit GUI==== |
| Keep in mind that the GUI is only a mask for onisplit. New onisplit versions - v0.52.9.0 or newer don't have the command -create:tram. | | Keep in mind that the GUI is only a mask for onisplit. New onisplit versions - v0.52.9.0 or newer don't have the command -create:tram. |
|
| |
|
| |
|
| ====normal animations==== | | ====normal animations==== |
| Line 193: |
Line 102: |
|
| |
|
| Don't forget to add types, variants, particle etc. to your xml file before you convert it to the oni format. | | Don't forget to add types, variants, particle etc. to your xml file before you convert it to the oni format. |
|
| |
|
| |
|
| ====testing the created files==== | | ====testing the created files==== |