Improved Docs, AnimationStepApplyMesh+Materials, some other minor tweaks

Docs/Animation Queues and Tangible Actors.md

@@ -30,7 +30,7 @@ This document contains several things:
 Suppose you want a character to jump up and down in-place. Typically, you would use the lua function *tangible.animate* to achieve this:
 
 ```lua
-tangible.animate(actor, nil, {action='jump', height=3.0}))"
+tangible.animate{tan=actor, anim={action='jump', height=3.0}}
 ```
 
 This function adds an *animation step* to the character's *animation queue*. An animation queue is just a sequence of animation steps. Its length is set to a fixed value, perhaps 10 steps. So if you add a step 11, then the oldest step is automatically discarded.
@@ -277,7 +277,7 @@ The routine FinishAnimation takes an *lxAnimationStep* as a parameter. This is s
 *FinishAnimation* also takes three boolean parameters: Auto Update XYZ, Auto Update Plane, and Auto Update Facing. These require some explanation. Suppose that the lua programmer pushes an animation step that looks like this:
 
 ```lua
-tangible.animate(actor, nil, {action="emote", animation="dance", xyz={1,2,3}})
+tangible.animate{tan=actor, anim={action="emote", animation="dance", xyz={1,2,3}}}
 ```
 
 Since "play an emote" isn't a travel command like "moveto" or "warpto", the lua scripter shouldn't have specified a destination XYZ, but he did so anyway, and now we have to recover from the mistake. Specifically, the tangible actor really does need to move to the new XYZ coordinate, otherwise bad things happen.
@@ -293,9 +293,9 @@ Suppose that in your game, players can teleport from one place to another by cas
 Here is the tricky scenario: player T, the teleporter, is standing in front of player V, the viewer. Player V can see player T. Then, player T casts the teleport spell, and executes this lua code:
 
 ```lua
-tangible.animate(actor, nil, {action="sparkle", particles=999})
+tangible.animate{tan=actor, anim={action="sparkle", particles=999}}
 
-tangible.animate(actor, nil, {action="warpto", xyz={1000000, 0, 0}})
+tangible.animate{tan=actor, anim={action="warpto", xyz={1000000, 0, 0}}}
 ```
 
 Luprex has no idea how long these animations take to execute. As far as Luprex is concerned, they are instantaneous. As soon as player T executes that code, Luprex thinks that player T has moved to {1000000, 0, 0}, a million miles away from player V.
@@ -313,9 +313,9 @@ In order for Unreal to actually discard a Tangible Actor, two conditions must be
 Now, let's consider a small variation of the lua commands:
 
 ```lua
-tangible.animate(actor, nil, {action="sparkle", particles=999})
+tangible.animate{tan=actor, anim={action="sparkle", particles=999}}
 
-tangible.animate(actor, nil, {action="warpto", plane="somewhere-else"})
+tangible.animate{tan=actor, anim={action="warpto", plane="somewhere-else"}}
 ```
 
 Here, instead of changing the XYZ of the player, the warpto changes the plane of the player. Unreal engine doesn't have the concept of "planes." What is the blueprint supposed to do? The answer is that we've added the concept of "plane" to Unreal at the C++ level. We have provided an API function *SetTangiblePlane*, that takes a string. When the tangible actor executes the "warpto" animation, that's all it has to do. The C++ code will make sure to only render tangibles that are on the same plane as the player.
@@ -382,17 +382,17 @@ In TangibleStaticMesh, animations are played one at a time. But you can imagine
 For example, imagine a "fireworks launcher" object that launches rockets, and which can launch many rockets simultaneously. The rockets are owned by the launcher: it's actually just one Tangible Actor, the launcher and its rockets. Now imagine that the fireworks launcher is controlled using animate commands like this:
 
 ```lua
-tangible.animate(actor, nil, {action="launch", type="burst", color="blue"})
+tangible.animate{tan=actor, anim={action="launch", type="burst", color="blue"}}
 
-tangible.animate(actor, nil, {action="launch", type="burst", color="green"})
+tangible.animate{tan=actor, anim={action="launch", type="burst", color="green"}}
 
-tangible.animate(actor, nil, {action="wait"})
+tangible.animate{tan=actor, anim={action="wait"}}
 
-tangible.animate(actor, nil, {action="launch", type="sparkle", color="blue"})
+tangible.animate{tan=actor, anim={action="launch", type="sparkle", color="blue"}}
 
-tangible.animate(actor, nil, {action="launch", type="sparkle", color="green"})
+tangible.animate{tan=actor, anim={action="launch", type="sparkle", color="green"}}
 
-tangible.animate(actor, nil, {action="wait"})
+tangible.animate{tan=actor, anim={action="wait"}}
 ```
 
 Our rocket launcher has the following unusual behavior: when it sees a sequence of animation steps with action="launch", it launches them all at the same time. So in response to the *tangible.animate* commands above, our launcher would launch two "burst" rockets simultaneously. Then, it would wait for both of those rockets to finish, however long that takes. Then, it launches two "sparkle" rockets simultaneously. Then it waits for the two sparkles to finish.