This feature is intended as replacement of the old addon model feature.
A series of new bones with specific names are introduced, each bind with a unique animator to perform a specific 
skinned or unskinned animation.
Most of the animation bones described here only applies to player's own tank for both performance and gameplay reasons.
It's not necessary to setup ownModel.xml profile. As long as mod_ownModel.pyc is installed and working, these base
layer support features will be active. 



------------------------------------------------------------------------------------------------------------
[Which file should I edit for the animation]
These bones are available in all tank parts, unlike in previous implementation where they can only be used in 
gun visual.

There are two things to consider before planning your project:
1) Should I place my animation in gun visual or their corresponding tank part visual(hull, turret)?
    So long as the bones controlling your geometry reside solely within the same tank part, you can place the animations
  in their respective tank part visual. You can do cupola animation in turret visual, and artillery spade in hull visual.
  The benefit of doing so, aside from ease of set up, is that now these parts can inherit camouflage tiling parameters
  from the correct part instead of using gun camo tiling.
    Only when you need bones from different parts that nesting animation in gun visual is a must, because with the help of 
  <static_joint_hull>, the node hierarchy of the entire tank can be structured, albeit in a backward fashion. For example, 
  to model mantlet canvas for casemate tank destroyer, you'll need bones from both turret and hull.

2 How to place animation in static parts (hull and turret)?
    Actually they do accept animated or skinned primitives, as long as the shader version is correct. 
    1. When doing the export, export option 'visual type' must be "animated, skinned (Bones, rigged)"
       Even if you are not planning to use skin animation but merely 'attach to node'
    2. If a certain mesh object should be static, do not skin it.
       If a certain mesh object should be animated but only under the influence of a single node, you can choose NOT
       to skin it, but link it below the intended animator node.
       If the mesh object needs multiple bones (antenna for example), or you just prefer skinned, use skin modifier normally
       as if you are doing a gun visual.
    3. When manually editing visual file during the final step (filling out primitiveGroup section), use non-skinned 
       shader for non-skinned renderGroup, for example, pbs_tank.fx, glass.fx, glow.fx
       use skinned shader for skinned renderGroup, for example, pbs_tank_skinned.fx, glass_skinned.fx



------------------------------------------------------------------------------------------------------------
List of new animation bones for gun geometry (as of UML ver1.56)
'static_joint_hull',
	A node bound to hull. Needed to skin canvas for casemate TD
	Also serves as parent node for other bones that is supposed to be attached to hull, not gun or turret. 
	Should be placed right under top-level node 'nodes_01' 

'actuator'+anything except '_'
	Reserved for animations triggered by user input. Check 'instruction_on_triggered_animations.txt'

'swingH' + anything except '_'
'swingT' + anything except '_'
'swingG' + anything except '_'
	Reserved for swing animation. 
	swingH* is for hull nodes ,swingT* for turret node, swingG* for gun node.
	for example, 'swingHBucket'  'swingTAntenna1'
	Apparently, for swingH* to function properly it must be either inside hull visual, or attached under <static_joint_hull>

'autorotor_joint_0',
'autorotor_joint_1',
'autorotor_joint_2',
'autorotor_joint_3',
'autorotor_joint_4',
'autorotor_joint_5',
'autorotor_joint_6',
'autorotor_joint_7',
	These nodes will rotate without player input. It can auto-rotate like a fan, or search rotate like a 
	commander looking at random directions in search of something.
	Can be placed anywhere depending on modder's need.

'miniturret_joint_H*',
'miniturret_joint_T*',
'miniturret_gun_joint_H*',
'miniturret_gun_joint_T*'
        '*' being a number, for example 'miniturret_joint_H1', 'miniturret_gun_joint_T12'
	These nodes will respond to player input, follow player viewpoint considering turret arc limit.
	So they are typically used to drive mini-turrets in multi-turret tank like soviet T-28.
	'miniturret_gun_joint_*' will only elevate, not rotate, so should be linked under corresponding 'miniturret_joint_' node to form a full turret controller set.
	Nodes with '_H' before the tailing number is intended for animators attached to hull, so should always be a child of 'static_joint_hull', directly or indirectly.
	Nodes with '_T' before the tailing number is intended for animators attached to turret, so should never be a child of 'static_joint_hull', neither directly nor indirectly.
	Any nodes that are not recognized by game mechanism or ownModelLoader will be treated as attached to turret, unless they are child of another node that is driven by something else.

'loading_joint_*'
	'*' being a positive integer, or 'static'
	for example, <loading_joint_10>, <loading_joint_static>
	These nodes are for Loading Lock mechanism. After firing a shot, these node will traverse then locked into certain 'reloading position'
	They will revert back to player's cursor position after reloading.
	In essence it assume 'Gun' node's function as elevation controller, but driven by UML manipulation instead of direct user mouse input.
	[#] if * is a number the node will operate in 'fixed loading position' mode with the number being loading position elevation.
	    loading_joint_10 means loading lock position is 10 degrees up. Mostly found on tank with autoloader but also leopard2
	[#] if * is 'static' the node operates in 'decoupler' mode, meaning the barrel elevation motor is decoupled from gunner control after a shot,
	    remain whatever elevation it's in at the time of firing, and will only return to player control after reloading of the next round.
	    loading_joint_static is one such node. this type of loading lock can be found on some tanks like Abrams M1
	[#] It has a default delay of 0.8sec after loading process starts to allow recoil animation to finish before elevating.
	    To change this value, use '_delayXXX' option

------------------------------------------------------------------------------------------------------------
[how to use]
1.  Rebuild a gun/hull/turret model normally in 3dsmax as if you are exporting a standard gun remodel for WoT.
    That means aligning your gun geometry properly, insert all the essential nodes for the host part, like [Gun, G, 
    HP_gunFire] for gun visual, [HP_turretJoint, HP_Track_Exhaus_1, HP_Track_Exhaus_2, etc...] for hull visual.
    add a 'skin' modifier to your geometry and assign binding weights accordingly.
    or simply link the geometry under the animation node, as stated in previous section.
2.  add new dummy helpers "loading_joint_*", for example "loading_joint_10". It should be located at scene root or under <nodes_01> parallel to <Gun> node.
    Then bind elevating part of tank gun to this <loading_joint_*> instead of the original <gun> node.
3.  Because this node functionally replaced the original <Gun> node, all other features that's related to <Gun> should be redirected to Loading_joint.
    Foe example coaxl MG or spotlights that's linked to <Gun> via <drivenJoints> mechanism should now be a slave of our <loading_joint_*> instead of <Gun>
4.  export normally. Export option 'visual type' must be "animated, skinned (Bones, rigged)" even for hull and turret. 
    Replace primitiveGroup definition in visual file with WoT standard shaders as your normally would for normal wot 
    remodel.







============================================================================================================
[Detailed description for each animationBone]
------------------------------------------------------------------------------------------------------------
'static_joint_hull'
Static node bound to hull geometry. In truth it's a node centered around turret ring but rotate in opposite 
direction of the turret animator. Also serves as parent node for other bones that is supposed to be attached 
to hull, not gun or turret. 
[#] Must be placed exactly where HP_turretJoint would be if 3dsmax scene is centerd on HP_gunJoint
[#] Should be one of the topmost nodes in the scene , or a direct child of 'nodes_01' which is the standard root node
    in recent Wargaming practice.
[#] But it is not necessary and not recommended to link 'Gun' to 'static_joint_hull' as its child node.
    In most cases 'Gun' should be parallel to 'static_joint_hull' to serve togerther as topmost nodes, or both linked
    as direct child to 'nodes_01'
[#] Because it also serves as root node for other animationBones that are supposed to be attached to hull, 
    'static_joint_hull' become mandatory in such scenarios. In other cases this node is optional.


------------------------------------------------------------------------------------------------------------
autorotor_joint_0 to autorotor_joint_7
8 optional nodes that will rotate around center pivot at given axis without user input.
With this modder can use auto-rotation mode or a random rotation mode.
It uses the following format as <transform> matrix to pass parameters to game.
V1	0	INTERVAL
0	V2	0
0	0	V3
P1	P2	P3

[#] Coordinate (P1,P2,P3) defines the location of the hardpoint as well as pivot of the rotation
[#] If 'INTERVAL'=0 then this node use auto-rotation:
	Vector (V1,V2,V3) defines rotation axis and speed. 
	For example (V1=2,V2=0,V3=0) will rotate horizontally with a speed of 2 seconds per circle
[#] If 'INTERVAL'>0 then this node use random search rotation:
	'INTERVAL' defines how long until the next search animation starts
	Once the animation is triggered, it will take 'INTERVAL/2' seconds to turn to a random direction, 
	then stay idle until the next animation is triggered.
	Vector (V1,V2,V3) is not used in this case. RandomSearch always use horizontal plane for the rotation. 
	It's hardcoded because I can't think of a reason why anyone would want a random rotation animation on 
	a different plane. But for the sake of future compatibility it's advised to set it to (1,0,0)
[#] because a non-standard transform matrix is used to pass paramters, all rotate and scaling info that originally 
    carried in the matrix will be lost(replaced by identity matrix after parameters are loaded). Can be easily 
    fixed by attaching this node to another parent node which carries rotation/scaling info.


------------------------------------------------------------------------------------------------------------
miniturret_joint_H*
'*' being a number, for example 'miniturret_joint_H1'
multiple mini-turret nodes attached to hull that will rotate around center pivot to follow user viewport.
Miniturrets are generally controled by player cursor (during live game session) but will be overwritten by main
turret aiming direction during game replay.
It uses the following format as <transform> matrix to pass parameters to game.
1	leftBound	rightBound
0	1		rotationSpeed
0	0		1
P1	P2		P3

[#] Coordinate (P1,P2,P3) defines the location of the hardpoint as well as pivot of the rotation.
[#] [leftBound, rightBound] defines boundary for valid yaw range. Forward is 0. Angle to the left is negative value 
    measured in degrees. Angle to the right is positive value.
[#] Rotation speed is accepted only when row2column2 is 1 (to differ from orientation matrix that are not aligned to default)
    Rotation speed is measured in degrees per second. If set to 0, miniturret will use the same speed as main turret.

    For example a left-front turret has firing arc from left 50 to right 10 degrees, and the same speed as main turret:
1	-50	10
0	1	0
0	0	1
P1	P2	P3
[#] because a non-standard transform matrix is used to pass paramters, all rotate and scaling info that originally 
    carried in the matrix will be lost(replaced by identity matrix after parameters are loaded). Can be easily 
    fixed by attaching this node to another parent node which carries rotation/scaling info.
[#] must be child of 'static_joint_hull' either directly of indirectly. Because these are supposed to be attached to hull
[#] in order to support arbitrary initial facing, arc yaw limit and speed can optionally be registered inside node identifier.
    append _speedXXX to the end of original identifier. XXX being angular speed in degrees/sec
    append _limitYawXXX,YYY to the end of original identifier. XXX being left bound and YYY the right bound.
    for example, 'miniturret_joint_T0_limitYaw-150,-90_speed30' is the identifier for an turret MG port facing rear-left.


------------------------------------------------------------------------------------------------------------
miniturret_joint_T*
'*' being a number, for example 'miniturret_joint_T2'
Multiple mini-turret nodes attached to turret that will rotate around center pivot to follow user viewport.
Requirements and setup is the same as hull mini-turret except:
[#] Must NEVER be child of 'static_joint_hull' either directly of indirectly. Because these are supposed to be attached to turret



------------------------------------------------------------------------------------------------------------
miniturret_gun_joint_H*
miniturret_gun_joint_T*
'*' being a number, for example 'miniturret_gun_joint_T3'
Mini-turret gun elevators for hull and turret respectively.
It will copy maingun elevation thus no speed nor elevation limit parameters are required.
It will use the standard <transform> node as it's intended to. Place it at elevation pivot.
[#] Should be child of corresponding 'miniturret_joint_**' node to form a complete mini-turret controller set.



------------------------------------------------------------------------------------------------------------
swingH**		swinging animator for hull
swingT**		swinging animator for turret
swingG**		swinging animator for gun
	'**' can be any string that does NOT contain _
	_ is used to separate optional parameters from bone name and from each other. 
	In its current implementation, swing node will respond to velocity vector change, shooting and being shot.
	Will not respond to angular acceleration caused by turret/hull rotation or break, etc. 
[IMPORTANT ]
	Initial facing of this animation bone also represents the neutral attitude that it will attempt to bounce back to.
	So you can't start the animator in one attitude and converges on another. It ends where it starts.
	The 'UP' of this bone should align with center of mass, so in case of upright antenna the default 'UP' is correctly facing upward.
	To model a lateral swing like a ship rudder, 'UP' should be horizontal pointing toward rudder mesh center.
[#] It has two motion modes. The default swing mode uses (_mass*) and (_stiffness*) to model the behaviour.
    In gravity mode enabled by (_gravityArm*) it uses (_mass*) and (_gravityArm*) to model the behaviour.
    At the moment, even gravity mode does not check where the gravty vector currently is, but use a different formula 
    to calculate centering force targeted at neutral attitude. This is due to performance concern.
[#] In case of shooting or being shot, this animator will receive an impulse from muzzle/impact point toward this node, 
    to simulate object being pushed by the blast. 
[#] In case of own tank velocity vector change, this animator will receive an impulse opposite to the velocity change, 
    to simulate inertia of the small object.
[#] In its current implementation, does NOT respond to attitude change, including hull and turret rotation or the hull 
    swinging caused by brake. It will still respond to velocity changed caused by brake. 
[#] It can pitch and roll from impulse received. It can not translate nor yaw.
    It can be set to only pitch or only roll by using optional parameters
[#] It does not have collision detection. Movement boundary can be pre-defined using optional parameters. 
[#] It can be used without settings. Default behaviour is modeled for long flexible antenna that evenly respond to 
impulse event from all direction.


	Following OPTIONAL parameters can be used by appending them after node name(recommend doing it in visual file, not in 3dsmax project file)
	Preview of swinging dynamics is possible by pressing 'INSERT'(default forward animation key) and 'DELETE'(default backward animation key), 
so one can change parameters in visual, change to another tank in hangar then change back, observe the effect, adjust parameters again.
	INSERT will introduce impulse from north with shock strength of firing 37mm_KwK_L46
	Delete will introduce impulse from southwest with shock strength of firing _150mm_Pak_L63
	* preview impulse strength will be overwritten by _shotForce parameter if present.
	* to achieve arbitrary direction, use 'hangman' mod to rotate tank in hangar.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
_dangle
	<affect any impulse input>
	<affect any motion mode>
	Invert torque from impulse. Without this parameter, default behaviour represents antenna that has center of gravity above pivot.
	So to correctly model dangling itemw with center of gravity below pivot, this parameter is essential.


_mass*
	<affect any impulse input>
	<affect any motion mode>
	'*' being a positive float number.	
	multiplier to modify object mass
	increased mass reduces pitch/roll speed gained from impulse. Also makes the swinging slower for having greater inertia.  
	reduced mass makes the swinging more violent and may potentially push it off the boundary, causing strange twitching motion.



_stiffness*
	<affect any impulse input>
	<affect swing mode animator>
	'*' being a positive float number.	
	multiplier to modify stiffness.
	for example, swingT2_stiffness2.0
	value above 1 makes it less responsive to impulse while dampens faster.



_gravityArm*
	<having this parameter puts the animator into 'gravity' mode>
	<affect any impulse input>
	<affect gravity mode animator>
	'*' being a positive float number. It represents distance from center of gravity to rotation pivot in meter.
	for example, "swingHBucket_mass0.6_gravityArm0.25" models a 0.6kg hanging bucket with center of mass 0.25 meter from hanging point.


_pitchOnly
_rollOnly
	<affect any impulse input>
	<affect any motion mode>
	enforce pitch only or roll only mode. used for axis constrained swinging, like buckets, plates installed 
	on hinge, etc.



_pitchParamsXXX,YYY,ZZZ
_rollParamsXXX,YYY,ZZZ
	<affect any impulse input>
	<affect any motion mode>
	[#] used to define rotation boundary and rebound behaviour
	[#] XXX being a positive float smaller than 1. Rebound factor. When animator hits a boundary, angular speed will be reversed after applying this multiplier.
	[#] YYY being maximum deflection measured in degree.
	[#] ZZZ being minimum deflection measured in degree.
	for example:  'swingHbucket_pitchOnly_pitchParams0.3,45,-5' simulates a bucket with a slopped armor plate nearby.



_shotForce*
	<affect shot impulse>
	<affect any motion mode>
	'*' being a positive float number.	
	multiplier to override impulse strength from firing the main gun.
	[#] not using this parameter will allow game to continue using impulse strength of the actual gun.
	    This means if abrams remodel is applied to both pz38(t) and Tiger, antenna swing from firing the tiger gun 
	    will be stronger than when firing the pz38(t) gun. This may not be desirable, because both tank shares the same abrams
	    appearance now, so logically the muzzle blast should behave the same.
	[#] value '1' will override actual in-game gun muzzle blast strength with an UML default, making the remodel's swinging 
	    behaviour consistent across any recipients. 
	[#] any other positive value means multiplying the UML default by this value when doing the overriding. 



_threshold*
	<affect motion impulse>
	<affect any motion mode>
	'*' being a positive float number.	
	for example, swingT2_threshold4.5
	sets the minimum velocity change required to begin nudging the animator, measured in m/s²
	used to reduce swing event spamming by velocity change
	if this field is not used, default threshold is 6m/s²



_factor*
	<affect motion impulse>
	<affect any motion mode>
	'*' being a float number
	for example, swingT2_factor0.25
	adjust curve slope at the lower end. smaller value flatterns the curve while larger value bends it into log shape.
	Larger factor will also increase resulting impulse which can be scaled back down using _multiplier*



_multiplier*
	<affect motion impulse>
	<affect any motion mode>
	'*' being a float number
	for example, swingT2_multiplier2.0
	This parameter is used to scale the simulated force from velocity change.
	The curve from threshold upward is log shaped. Current formula is:
		impulseForce = log( (max[deltaVelocity.length,threshold] - threshold) *factor +1 )*0.02 * multiplier




------------------------------------------------------------------------------------------------------------
loading_joint_*
	'*' being a positive integer, or 'static', as mentioned in the overview above.
	In essence it assume 'Gun' node's function as elevation controller, but driven by UML manipulation instead of direct user mouse input.

<IMPORTANT>
Be careful when using this with <drivenJoints> feature. Because loading_joint_* now assumes the duty of 'Gun', master node of <drivenJoints> should be
edited to reflect this change, or risk the potential of CTD without producing a python.log report. This is especially true when you are constantly 
changing node name to try out animator parameters.

<Hierarchy requirement>      1)must be on the same level of 'Gun' node, child to 'nodes_01' if applicable
                            2)must be parent of 'G' node for apparent reason
                            for example:
                            \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                            nodes_01
                            |      \
                            Gun    loading_joint_10 
                                    |    \
                                    G    HP_UMLGunFire1_[shot_auto]_burst6,0.06    
                                    |
                                   HP_gunFire   
                            ////////////////////////////////////////////////////////////////////////////////////


<parameters>
	Following OPTIONAL parameters can be used by appending them after node name(recommend doing it in visual file, not in 3dsmax project file)


_speed*
	* is a positive integer, donates maximum pitch speed in degrees per second. If this parameter is not provided, UML default is 18 degrees/s
	for example:
		loading_joint_10_speed22
_delayXXX
	XXX is time measured in millisecond. Barrel elevation Loading Lock mechanism will initiate XXX millisecond after firing.
	This is used to delay elevation motor action to wait for recoil animator.
	If this parameter is not provided, UML default is 0.8 sec, which is about 80% of main/large recoil
	for example:
		loading_joint_static_delay1000