Actor Controller - an advanced character controller

That's because there's an "ActorDriverEditor.cs" file that is the inspector. When a Monobehaviour has an inspector, the default rendering of all properties is overridden by the the inspector.

@Shawn67 brings up a good point as well. Fortunately, you can kill two birds with one stone...

If you create your own class and inherit from ActorDriver, your properties will show up since you don't have an inspector for it. That also protects you from updates to the asset as Unity will overwrite ActorDriver, but it won't touch your file.

 

This is great stuff! How is mobile performance?
And from what I understand, it's possible to have the character interact with regular Unity physics objects?

 

I can confirm with you. AC performance is really good, 10 times better than Unity Character Controller. AC can interact with Physics objects out-of-box. But, if you need more Physics interactions, you can add Rigidbody (Kinematic for me) & Collider. The real trick is how to set the settings right, to get the most performance and stable movements. Compare to a normal Physics Controller, the good thing about AC is that you don't need to add Rigidbody and Collider to any movable thing, only add them if needed. A Physic Controller requires these 2 components to be able to work. So at the end, I think AC is cheaper in that aspect. Anyway, Tim supports are really good btw.

 

Thanks @ikemen_blueD . Great answers.

For mobile, I've been running a character on my Galaxy S4 with no issues. I haven't tried pushing it to see how many I can run.

For the physics, ikemen is on the money. The AC will collide with unity colliders as you'd expect. However, by default, the AC doesn't have any rigid body or collider on it. So, you need to add them for external raycasts or triggers as needed. Just add them like you would any other Unity objects.

 

ok cool
Thanks ikemen and Tim!

 

it's Look Very fun too use

 

I cannot get my ActorController to ride my physics-based ship. He slides off the stern as it moves forward.

I think the issue is that he is not following the angular motions of the deck. e.g., if he stands at the bow as the ship rises up at the head upon meeting a big wave, he sinks into the deck rather than following it upward. The issue MIGHT be that you are not considering the local velocity of the portion of the platform he is standing upon -- the ship's position may not be changing, but the angular motion is certainly causings its bow to move upward.

Does this make sense? Have you tested the controller on (say) a see-saw?

 

Yeah, I've tested it on moving platforms and moving/rotating sloped platforms as well.

One of the testers did report an issue that if their ship was moving really fast and tilting up (like they are launching), there was an issue... but I couldn't reproduce it. Then, they discovered if they moved when the ship animation out of Maya and into Unity, the issue went away. (I think that was the right details).

I know I do all of the position updating in LateUpdate()... if that helps.

Is there a small scene you could send me that reproduces this? That may be the best way for me to help.

Send it to tim@ootii.com. Thanks!

 

I had trouble with this when using pre-built animations to drive my ship. The character and ship were not always in sync. I eventually tossed out the imported animation, and used a waypoint driven animation instead. This seems to work better, but there are still limits. I always feel like one misstep will send me flying. I'm not sure how to get physics based motions to sync, other than to try using FixedUpdate() or LateUpdate() for them though. Even then, fast movements can be tricky.

BTW, I ran into the "sinking into the deck" problem on dry land later on, and @Tryz suggested setting the "Step Up Speed" in Actor Controller to "0", and reducing the "Max Angle" setting to "3". This helped in that case, so may be worth trying here as well.

 

I'm setting up MC2 in a scene of mine in a game running Ork Framework. So far I'm not having integration issues, but I think I may be having Actor Controller issues. When I run my character across the Unity terrain, he sometime begins to sink into the ground. If I stop moving, the character will slowly rise back up. If I keep running I fall through the ground, sometimes resting on the water plane, sometimes falling forever. I have used this terrain a lot, with other controllers, and never saw this happen, so I do not think it is a terrain issue..

Also, I am unable to run through a sphere checked as trigger, anymore. Always worked before.

And my final question: Would you comment on the integration with Node Canvas. I see you are using it yourself. How do you like it? As only a novice programmer do you think it would be a good tool for me? There are several graphical interfaces on the store now, any of your thoughts would be greatly appreciated.

 

Hey @wood333 ,

You're running into two common questions I get. So, I may have to rethink how I did these.

Sinking into the ground
I have a feature called "smooth stepping". The idea is that instead of popping-up steps, I smoothly rise you up. It's great for things like foot IK (if you have an IK package). However on slopes, it can cause what you're seeing.

If you go into the advanced settings, you'll see a "Step Up Speed" and "Max Angle". To totally shut this off, set "Step Up Speed" to 0. However, I've found pretty good success by just limiting the Max Angle to something like 3. This will keep you from smooth stepping up any slope greater than 3 degrees. Increasing the Step Up Speed may also help if you want to keep it enabled.

Trigger Colliders
I actually talk about this in the MC documentation (I added it yesterday ).
http://www.ootii.com/Unity/MotionController/MC2Guide.pdf (page 6)

The MC (and AC) uses Unity raycasts to manage collisions. However, Unity’s raycasts actually collide with trigger
volumes. That means your character will collide with colliders even if the colliders have “Is Trigger” checked.
To prevent your character from colliding with trigger volumes, simply set their layer to Unity’s “Ignore Raycast” layer.

Node Canvas
I've used several of the SM/BT solutions and I like Node Canvas the best. I find that the approach he takes follows more in line with how I think. It's pretty rich out-of-the-box. So, you really don't need to do any coding for it. I have been adding custom conditions and tasks to work with MC/AC and my other assets. I'm happy to share them once I'm sure they are working as expected.

My biggest problem is trying to think in "flows" vs. coding... I've been coding for 20+ years. But, that's my issue. I say it is well worth the money.

Hope that helps!

 

@Tryz - I'm not super sure you need to re-think things, but maybe just leave some breadcrumbs in the docs to help with problem solving.

Like, maybe as an example have trigger volumes (on ignore raycast) set to change the step up speed and max angle for characters as they move from urban to natural environments, or something like that. If that makes sense.

 

Has anyone tried combining this with RTP3? More specifically with terrain holes? Every thing I've tried so far results in full unity lockup.

 

I haven't tried that but for my portal system to work, I had to add a rigid body and capsule collider to the character prefab. In order to get Actor Controller to be able to do all of the things it does, I think Tim uses something special to detect collisions. He explained it to me at the time but I can't really remember. But once I added the rigid body and capsule collider, my portals worked fine. I haven't used RTPs holes but Terrain Hole System would have required me to do the same thing based on testing I did with it about a year ago. Prior to using AC but I remember it's scripts using similar methods to what I used in my portal system to detect the player colliding with the "hole" area.

 

Are things locking up when you hit the hole specifically or as soon as the character hits anywhere on the terrain (like when the game first starts and the character stands in a field)?

What Shawn is talking about is the character triggering trigger colliders. I discuss it here on page 6, but I'm wondering if you've got something else going on.
http://www.ootii.com/Unity/MotionController/MC2Guide.pdf

(I probably need to add this page in the AC guide as well. )

 

So what it's doing is using Physics.IgnoreCollision(collider, terrain,true) while inside the trigger. I'm assuming that due to the different methods for collision detection that Physics.ignoreCollision does not work and is causing the crashing.

 

Its only crashing when I enter the trigger that is meant to remove the collision between the character's collider and the terrain. Is there a way for me to turn off your collision to the terrain instead?

edit: I should point out that this is not RTP specific, as RTP only allows the transparent painting of the hole. I'm certain it's the Physics.ignoreCollison that is causing it.

 

Yeah, I figured it was just a normal terrain using RTP.

Physics.ignoreCollision shouldn't be an issue. It just doesn't seem like that would cause an endless loop somewhere. I'm actually using Unity's physics system under the hood (Physx). I'm just doing raycasts, spherecasts, etc.

I know when one of the testers used a water volume, we just put that on a separate layer. So, we could do the same thing here. If the terrain is on a "Terrain" layer, you could tell the character to ignore the terrain layer while in the trigger volume.

I'm testing out the Physics.ignoreCollision now.

 

So I created a new area complete with terrain blending, trigger, etc and no crash. Nothing happened. I'm not sure why the original locations are crashing, but I'll keep testing until I figure it out.

 

I'm building it out here too.

Thanks for being so patient!

 

I don't know the why yet, but it's the imported mesh that causes the crash when I come into contact with it.

 

ahhh. That's why I was asking if it crashed when you came in contact with the terrain mesh anywhere or just the hole. I thought you were using a standard terrain.

Check out page 8 of the guide:
http://www.ootii.com/Unity/ActorController/ACGuide.pdf

It talks a bit about the "Mesh Partitioner".

How big of a mesh is it and does it have a lower resolution mesh collider? I parse the mesh (or preferably lower resolution mesh collider) to determine exactly where collisions are taking place. I've tested meshes with 20-40k vertices and it parses instantly. I'm wondering if your terrain has a lot more.

Can you send me the terrain mesh? tim@ootii.com

 

Well I am using standard terrain for the main land, the mesh that crashes it is the cave entrance. This particular mesh has 5k verts, I just threw it together w/o a retopo and inside I have a separate piece with 2k verts that works just fine. I'm going to cut a new hole, make a different mesh cave and see if I have the same issue.

 

5k seems small... meaning I shouldn't have any issue processing that.

I did find an issue where I collide with triggers instead of automatically ignoring them and I'm trying to get the "hole through terrain" working. So, I'll let you know what I find... but it's midnight here.

 

Sounds great. So I've tried duplicating the issue from start to finish and just can't do it. I'm going to chock it up to an anomaly for now and re-create that entrance (was planning on it anyway). If there are any more issue with crashes then I'll revisit it. Otherwise all I need is to be able to fall through terrain on trigger and I'm set thanks a ton for all your help.

 

If you do find it comes back, feel free to send me the mesh and I'll dig into it.

I've tested this code for creating a "door" that will let you go through the terrain. I've included comments that detail the steps. Hopefully this all makes sense.

I'll check in tomorrow morning.

Code (CSharp):

1.  
2. using UnityEngine;
3. using com.ootii.Actors;
4.  
5. namespace com.ootii.Demos
6. {
7.     /// <summary>
8.     /// Script used to allow the actor to go through terrain (or any mesh)
9.     ///
10.     /// 1. Add terrain to your scene and put it on a "Terrain" layer. This can be
11.     ///    any Unity Layer. Just add per normal Unity layers.
12.     ///
13.     /// 2. Add a game object with a collider that will act like a door. Using a
14.     ///    cube works fine. Check "Is Trigger" on the collider.
15.     ///
16.     /// 3. Change the layer of the "door" to "Ignore Raycast". This step will go away soon.
17.     ///
18.     /// 4. Add this component to the "door". Set your terrain on the Terrain property.
19.     ///
20.     /// 5. Add a Rigid Body to the "door". Uncheck "Use Gravity" and check "Is Kinematic".
21.     ///
22.     /// 6. Add a plane or other mesh under the door and cave. This way when we disable collisions
23.     ///    on the terrain, your character won't fall through empty space.
24.     ///
25.     /// 7. On your Actor Controller, ensure your character's Collision Layers and
26.     ///    Grounding Layers include your new Terrain Layer from step #1.
27.     ///
28.     /// 8. Ensure you Actor Controller has "Use Grounding Layers" checked.
29.     ///
30.     /// 9. Add a Capsule Collider to your Actor Controller and adjust as needed.
31.     ///
32.     /// </summary>
33.     public class TerrainHoleActivator : MonoBehaviour
34.     {
35.         /// <summary>
36.         /// Terrain collider who is on a different layer
37.         /// </summary>
38.         public TerrainCollider Terrain = null;
39.  
40.         /// <summary>
41.         /// Tracks the layer the terrain is on
42.         /// </summary>
43.         private int mTerrainLayer = 0;
44.  
45.         /// <summary>
46.         /// Used for initialization
47.         /// </summary>
48.         void Start()
49.         {
50.             mTerrainLayer = Terrain.gameObject.layer;
51.         }
52.  
53.         /// <summary>
54.         /// Deactivate the collisions
55.         /// </summary>
56.         void OnTriggerEnter(Collider rCollider)
57.         {
58.             if (Terrain == null) { return; }
59.             if (mTerrainLayer == 0) { return; }
60.             if (rCollider.gameObject == null) { return; }
61.  
62.             ActorController lController = rCollider.gameObject.GetComponent<ActorController>();
63.             if (lController == null) { return; }
64.  
65.             int lInvertedMasks = ~lController.CollisionLayers;
66.             lController.CollisionLayers = ~(lInvertedMasks | (1 << mTerrainLayer));
67.  
68.             lInvertedMasks = ~lController.GroundingLayers;
69.             lController.GroundingLayers = ~(lInvertedMasks | (1 << mTerrainLayer));
70.         }
71.  
72.         /// <summary>
73.         /// Reactivate the collisions
74.         /// </summary>
75.         void OnTriggerExit(Collider rCollider)
76.         {
77.             if (Terrain == null) { return; }
78.             if (mTerrainLayer == 0) { return; }
79.             if (rCollider.gameObject == null) { return; }
80.  
81.             ActorController lController = rCollider.gameObject.GetComponent<ActorController>();
82.             if (lController == null) { return; }
83.  
84.             lController.CollisionLayers |= (1 << mTerrainLayer);
85.             lController.GroundingLayers |= (1 << mTerrainLayer);
86.         }
87.     }
88. }
89.  
90.  

 

Sinking into the ground
Limiting the advanced setting Soft Step Max Angle to 3. fixed it.

Trigger Colliders
Set their layer to Unity’s “Ignore Raycast” layer. fixed it.

(new) MC2 in Ork Framework

I have added MC2 to a scene within the Ork Framework, and without much difficulty, I enabled movement with sprint and jumping, and more importantly, successfully passed through Ork scene changers retaining MC2 character control. Cool!

 

As someone else who had this issue, my final solution was to set the Max Angle to 5, and the Step Up/Down speeds to 5 as well. Setting these speeds to 0 caused other weird problems (freezing/hesitation) when walking on irregular mesh surfaces, but setting them higher, combined with reducing the angle worked great. As for the original purpose of this feature, to smooth motion on steps, higher speeds can make this look a bit jerky, but simply adding ramp colliders to all stair objects solves this (plus makes the collider physics solution simpler).

Might explain how I missed it.

This is actually a common issue in Unity, and not just with Ootii products. I've gotten into the habit of setting all trigger colliders to the “Ignore Raycast” layer when I create them. It just saves me the trouble of doing it later, when problems like this crop up in gameplay.

I used to use something similar back in Unity 4, along with a terrain render mask that created visible holes in the terrain. Unfortunately, the masking solution stopped working in Unity 5, and I don't have RTP, so I switched to just lowering the terrain under areas where I want tunnels, and covering them with a mesh. This isn't an entirely ideal solution either though, so I'll hold onto this script in case I find a way to do terrain holes again. Thanks.

As I may have mentioned before though, you should create a script section in the Vault for goodies like this. Not everyone needs them, but for those that do, it can save a lot of hair pulling to have a ready made tested solution available.

 

Tim the script worked great, but I noticed something else I'm not sure if you've seen it or not. I have a 12m tall T-Rex and whenever he comes into contact with a rock and the upper body piece touches it, and is over it, the FPS drops dramatically. Down to 6 fps at one point. If I place the rocks in a different layer, any layer other than default, it doesn't happen. Either that or replace the mesh collider with a box or sphere and it wont either.

This isn't a huge concern at the moment as I can just place them in their own layer, but I thought I'd bring it up. Also, as the characters get bigger, this issues is more noticeable. I can make a video if you'd like.

 

The video really won't help much.

Can you send me a small scene with the T-Rex and rock that is causing the issue? If I can make it happen here, I can see what's going on.

Please send to tim@ootii.com

 

I use an editor add on, QHierarchy, which displays the layer for each item in the hierarchy window. You can see at a glance if your collider is in Ignore Raycast. It's one of my favorite editor expansions.

https://www.assetstore.unity3d.com/en/#!/content/28577

 

Orient to ground is an awesome feature, especially for a side scroller, but I'm wondering if there's a way to smooth it out a bit for very uneven terrains. I'm using Gaia to generate and there are a lot of changes in direction. If the character moves too fast he's super jittery changing orientation constantly.

 

You can slow down the orientation. In the advanced tab, there's a property called "Time" in the "Orient To Ground" section. This is the # of seconds to orient 180-degrees. I had to find a balance between slight variations in the terrain and jumping off the ceiling to the floor.

 

Is interaction with 2d colliders possible? I've been working with 3d colliders to get things to work and figured I should at least ask

 

I'm not sure. Most of the time, I'm using Unity's standard raycast and sphere-overlap functions. I'm not sure if they cross 2D vs. 3D.

To be honest, I didn't know there was such a thing as a 2D collider...

 

Yep and the only reason I would like it is the polygon collider. It allows for some unique shapes. Otherwise they can be used with 3d colliders just fine.

 

Hi Tim, I'm having a few problems:

1. I have a basic setup with a sphere object, but when I try to make it walk over a fairly shallow slope, it keeps either teleporting back away from the slope, getting stuck on the edge, or sometimes embedding itself inside of it. Here's a gif of the problem:
   
   http://imgur.com/MeCVLt6
   
   I've been tinkering with it for about an hour, and can't make sense of it, so am I missing something obvious in the settings that will solve this?
   
   
2. When I use AddImpulse() for motion, I'd like it to be able to stop all velocity/acceleration in the given direction if it collides with a surface, and possibly even rebound off of it. At the moment, if its stopped by an object, and you try to apply Impulse in the opposite direction, you have to overcome the current acceleration before it'll begin to move in the direction you want it to travel.
   
   Plus, if it hits an object, it technically stops, but the velocity is still being applied, so if the character moves around the object, it suddenly moves with full velocity. Here's a gif of that one:
   
   http://imgur.com/Ybt0Vvk
   
   What/where would I need to make changes to do this?
   
   
3. I've attached a Non-Kinematic Rigidbody to the child object with the Collider, with a script that notifies me if it collides with another object (I eventually want it to do things like push objects, but not at full speed like a Kinematic object would), and there seems to be a few frames of delay between when it appears to collide, and when the message comes through.
   
   Is that an unfortunate biproduct of how its collision system is designed, or something that can be overcome (within reason e.g. a little extra performance cost)?

Thanks.

 

Hey @Bibdy ,

I'm attaching a video here of a sphere I setup. The real purpose is to show you the settings that I'm using so you can compare:

I'm using the "Sphere Driver" that's included in the AC package.

Based on the questions and what you're seeing, I'm wondering if you're trying to "drive" the ball using AddImpulse(). You really don't want to do that.

The thing to remember is that the AC is an input-based character controller, not a physics or rigid-body controller. What I mean is that it's meant for precise control based on input, not reaction-based control from physics (forces, collisions, slopes, etc.) So, AddImpulse() does give you some capabilities to add things like a bounce up, but it isn't meant to control the character.

To address your issues specifically:

1. I've not the seen the teleport before and I haven't been able to duplicate it. Can you send your project to tim@ootii.com? Internally, I do track how the character is moved (using Move, RelativeMove, Rotate, SetPosition, etc.). If you try to move the object without using those functions, it will be ignored... but the teleport is odd.

2. This really goes to my earlier comments. You won't get the "physics deflection" and movement unless you create a driver that does that for you. It just wasn't built for that.

As for the velocity not being removed... that's working as designed, but maybe I need to rethink the design. For example, when you use AddImpulse() to add a push up (for a jump), gravity will compensate and remove the force over time. For a horizontal impulse, I figured that would be managed by the driver the user created (as needed).

3. I think I follow you. You're using Unity's rigid-body and collider to tap into the OnCollision events. That's totally fine and I do that for triggers. Unfortunately, I don't have a lot of insight into when they trigger the events as that is handled totally by the Unity engine. The AC really isn't involved at that point.

I haven't had to be as precise as I think you're needing. So, I don't know if having it a couple frames off is normal or not.


The AC definitely isn't meant to be a rigid-body controller. Those controllers work well for hard-body simulations (think pool table physics), but they tend not to be as responsive to user input as they rely on physics forces for control. For my work and assets, I focus on input-based controllers.

I hope that makes sense. Feel free to email tim@ootii.com and we can discuss more as needed. If I can get the project for #1, that would help a lot.

 

Hey Tryz,
This plugin looks promising, I do have a couple questions though:
1. How would you go about creating complex colliders for characters?
I would like to use box colliders for example. But since I can't use a rigidbody without interfering with the Actor Controllers functionality, I'm realy not sure how to go about it.
2. Do you have an API? Would it be possible to change options on the controller through code at runtime? because using the inspector raises errors...

Cheers

 

Also, I have a bug to report.
You can encounter it in your AC_Demo1 scene:
Using the robot, if you jump onto a steep slope, like that metal plate on the left side of the closest building, and keep pressing in the direction of the slope the robot will stay lodged and will not slide as long as you press.
Press long enough and when you release the robot will fall to the ground at a much faster pace than it usually would, which looks unrealistic.

 

One last thing,
I'm experiencing fps drops (to 15 fps) due to garbage collections.
those occur frequently when stress testing using 100 spider bots e.g, but also occur seldom playing the Demo1 as it is.

 

In the User's Guide (page 7), I talk about Body Shapes. That should explain everything.

You can use a rigid body on the character, but I prefer not to. If you do you a rigid body, you'll have to make sure "Is Kinematic" is checked and "Use Gravity" is not.

Yes. Just use your IDE's Object Browser and you can see all the functions that are exposed.

I haven't seen any errors in the inspector and no one has reported any. Can you email me the error tim@ootii.com and what you where doing?

Pressing forward will keep the character up similar to if you continue to press a ball against the wall and the ball doesn't fall... the forward force is counteracting the gravitational force. I'll look into the rapid drop.

The capabilities of your system will come into play when dealing with 100 active characters. For example, my frame rate never went below 100 FPS.


Unfortunately, Unity's physics calls do create some garbage. It's a known issue that may be helped with the 5.3 release.

In the case of 100 active characters, I'm getting 21.4KB of garbage from the physics calls. Certainly not perfect, but not horrible either. What platform are you running?


Here's a deep profile (that runs slower):


Apparently 5.3 has some new physics calls that may help with the allocations. I'll check them out. I also see some allocations when I resize my object pool. I'll look at that too.

 

Thank you for your prompt and extensive response!
I appreciate you taking the time.

Doesn't explain how box colliders could be used to account for sharp corners (let's say a box shaped character).
While using a kinematic rigid body is a good solution for triggers, it would still result in the character's colliders getting pushed through a wall.

Great, thanks.

To be clear - the inspector works perfectly in edit mode.
But if you try to tweak it in play mode you get:
"InvalidOperationException: This cannot be used during play mode.
UnityEditor.SceneManagement.EditorSceneManager.MarkSceneDirty (Scene scene) (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorSceneManagerBindings.gen.cs:148)"
I'll send a pic to your mail.

Yeah it makes sense from a programming point of view, but results in unrealistic physical behavior for our purposes. If you could find a solution, maybe forcing the sliding effect, it would be great! (our team wasn't able so far).

Im currently running Unity 5.3.2f1 on Windows 8.1.
You can see the drops I was referring to in your own profiler pictures. for example - that CPU peak in the first pic.


I just wanna mention, for anybody who might be reading this, this plugin is great!
Apart of the few esoteric issues that I've mentioned, It works very well, performance is well optimized, and it presents a large variety of elegant solutions to problems we've encountered working with Unity's character controller.

Thanks for the great work.
Thumbs up.

 

Unfortunately, the AC doesn't support box-shaped colliders. You could extend it by inheriting from BodyShape. That's how I created BodyCapsule and BodySphere. I'll add BodyBox to my list, but you're the first one to ask for it... so, it's low on the list.

Thanks for that. I just hit it myself. It seems to be a new "feature" of 5.3. So, I'm working through it now.

If you were to customize an Actor Driver, you could do something like stop the forward input if you sense a wall in the direction you're trying to move. I'm a bit hesitant to change the default behavior because there are other cases where I wouldn't want to automatically remove the forward force. Think anything with a constant force (ie engine or motor) or even a slope. You're the first one to request it and I don't want to change behavior on everyone else.

Agree on that spike. I'll see if the changes I'm making help, but I think it's going to be a bigger job to integrate the new Unity 5.3 physics call. I'll work on them, but I doubt it will be done this week.

Thanks.

 

Great thanks.

Specifically about the BodyShapes - I'm sure the Unity community could benefit from having additional shapes like a BodyBox and a BodyCylinder.
It would seem like adding those would be a natural course of progression since you already went to the lengths of developing the BodyShape abstract class

 

The problem with sharp edges is that they typically don't work well for character controllers. That's why you'll find nearly all character controllers are built as capsules or spheres.

Here's an example:




With a box collider (on the left), the character will actually stop because the final collision normal of the box collider and wall totally counteracts the movement. On the right, a capsule (remember we're looking from top down) creates a collision normal that will cause the character to move around the wall in a much better way.

You can certainly create special code that handles the example on the left, but I feel that's pretty game-specific. The plumbing exists to help you do that, but I feel that it's really up to the game developer to implement how they see fit.

If I get lots of requests for this, I may tackle it. But, having a character that is physically represented by a box seems pretty unique right now.

 

Are there any patch notes somewhere for the latest build of AC?

 

Yeah, on the product page. Click the version number.

 

Fair enough

 

So I've recently been converting my Character Driver over from using Unity's builtin CharacterController, to the ActorController, and I've come across something that I'm not 100% sure how to convert -- My character has a "jump landing" animation where she kinda bends her knees to soften the impact of landing from a jump. As a result, her mesh is significantly shorter during a portion of this animation than her default "idle" standing height. With just an Animator that triggers this animation, she properly keeps her feet planted on the ground at all times.

In my old implementation, using the CharacterController would cause it's CapsuleCollider to act as the "bottom" edge of the character, so I had to dynamically resize the CapsuleCollider so that it matched the animations' height, in order to keep my character's feet on the ground. Not doing this would cause her to remain centered in the CapsuleCollider, resulting in her feet floating off the ground during the animation, during which she would slowly put them back down, as she blended into her idle animation.

However, with the ActorController, I no longer have just a simple CapsuleCollider to work with anymore, and I'm struggling a bit to figure out exactly what I should be dynamically resizing in order to keep her feet on the ground like I was achieving before. I'm seeing BodyShapes (a body capsule and a foot sphere) that as far as I can see, are both treated differently from each other internally, and a collision sphere around the character. I've tried temporarily changing some of the values around these things and have yet to discover what combination of things I should be adjusting in order to achieve my desired result: Keeping her feet planted on the ground during the whole animation.

I'm assuming I need to once again be dynamically resizing _something_ during the course of my animations, I'm just trying to figure out _what_.