Motion Controller

Well, we knew it wouldn't be perfect...

After some more testing, I found that Unity 5 seems to "loose" Animator connections after updating from the Asset Store. If this happens to you, you'll see your character freeze while climbing or running.

Fortunately, the fix is pretty easy. Just close Unity 5 and restart it. Then, everything seems to be fine.



Sorry for the inconvenience, but this one is out of my control.

 

I don't know if the new character controller can handle it, but maybe a common generic motion would be to climb / descend stairs regardless of step size. I imagine this would also be applicable to hiking in rugged terrain.

 

That's probably a good motion for me to do in concert with the Bone Controller too. I wanted to start getting some motions out the leveraged the BC, so I'll start there.

The "Actor Controller" itself is actually going pretty well right now. Collision responses are fast. Still a little ways to go, but I'm liking it more and more.

Just in case I haven't said it directly, this Actor Controller would be the basis for the Motion Controller (instead of the Unity Character Controller). Therefore it will be free to all Motion Controller owners. You could use it with or without the Motion Controller.

 

If you stick with the term "character controller" we can continue using abbreviations for your stuff, like BC (Bone Controller), MC (Motion Controller), AC (Adventure Camera), and MP (Mount Points). Actor Controller would conflict with Adventure Camera, but "CC" (character controller) is currently unused.

 

Augh... you're right!

I'm wondering if I could get away with "Character Controller". Unity might squish that since it's a generic term... but if they didn't... hahaha

 

Oh, is Character Controller going to be a separate asset? Well, if they don't like "Character Controller" straight up, you can always modify it as "Advanced Character Controller." Then we call it ACC, and harmony in the kingdom is preserved.

 

haha! ACC works.

Yeah, I'm thinking it will be separate so people can use it without the MC. However, the MC would inherit from it and take advantage of the performance improvements and non-UCC features. Hence MC users would get it for free.

I still need to see if it all comes together like I plan, but that's...the...well...plan.

 

What? You want to walk on walls? Yeah, me too...

While we wait for the Bone Controller, I thought I'd show you some progress on the ACC... hmmm we need a better name.

 

I like having the ability to walk walls (and ceilings) when needed, but with this setup, I wonder how it knows if a slope is too steep to traverse, or if it has followed a curved surface upward so far that now it should fall ...?

 

These are all settings. So, you can disable the wall walking, set the max slope, etc.

What's good from my perspective is that the math and physics are the same regardless if you're upside down or not. So, these features become a design decision and not a technical limitation.

 

Looking forward to seeing the motions with the new ... ACC.

 

It occurs to me that an environmental factor that might be fun to demonstrate using the ACC and MC/BC is moving on ice and snow. Can the character slide across smooth and bumpy surfaces with realistic body movement and momentum? If they are going fast enough downhill, can they slide off ski jumps and even go full circle on a looped ramp?

That's not a 100% necessary thing to work out, but I was thinking that it might make for a cool demo to help advertise the usefulness of the kit. Put a knitted cap on the mecanim dude and get him in a ski pose (no skis) and send him downhill. His legs should independently move in relation to ground curves, and bend and unbend and bend again as he goes off a ramp and lands.

 

Definitely doable. I'd put that in a motion where the normal root-motion is augmented for the sliding.

Because I track the movement frame to frame, we could access that information to keep momentum going. Augh... not enough hours in the day... haha.

 

Hi, I purchased the Motion Controller recently and I managed to get it up and running no problem following along with the documentation. But I did end up with a question and I apologize in advance if it's been discussed already. One of my main interests in using Mecanim is the ability to blend animations together. In your Adventure Camera demo, for example, when you let go of the run button the character will play a stopping animation instead of just coming to a dead halt. This looks really natural. How would I use the motion controller to accomplish something like this? Do I have to code a new motion in order to get an effect like this?

Thanks for your time!

 

Hi LNMRae,

Welcome!

The Motion Controller will support blending of animation since it uses Mecanim under the hood. However, you have to be careful when you use blending; stopping is a great example...

Originally, I did use the Adventure Camera's stopping for the Motion Controller. However, the more I tried to platform with the character, the more I realized I didn't have complete control over my character.

I couldn't make him stop exactly where I wanted because the blending would continue. This was horrible for jumping across ledges or keeping from running off cliffs. When I'd jump or move, the blending looked great but kept me from actually maneuvering the level. After doing some research and play testing other games (Tomb Raider, Batman, etc), I realized they took a "control over beauty" approach. So, I ended up going that route myself.

One other note: Blend Trees. I also don't use blend-trees much. The reason is that blend trees don't go from "run to stop" nicely. Meaning they don't allow you to stop quickly. Instead, they slowing you down and cause you to go from "run to jog to walk to stop" instead of "run to stop". That's not good if you're trying to keep from running off a ledge.

So, I took the approach that I thought would help most people. That said, your game may require a "beauty over control" approach and you would have to create a new motion. It's totally doable and I'd be happy to help you through it. I just wanted to explain why I took the approach I did.

Whew, sorry for all that. But, I hope it's helpful. Please email me at tim@ ootii.com if you do need help. I think you'll find making this motion from the AC would be pretty easy.

 

That makes sense, I completely understand. Yes, in my case I am going for the 'beauty over control' look. Thanks for the prompt and in-depth reply. I'll take another look at the MotionBuilder documentation and likely shoot you an e-mail at some point. I'm an awful programmer, ahaha.

 

Do you know if animfollow works with your Controllers?

 

Hey Blueivy,

I looked at the page and checked out the demo, but I'm not sure.

The MC uses Mecanim to run all the animations. I'm not doing anything like taking control of the bones directly. So, if AnimFollow works with Mecanim you should be fine. The only thing I think would be an issue is if AnimFollow interrupts Mecanim transitions. If it does, some MC motions might not recognize that they completed.

Unfortunately, that's just a bit of a guess on my part.

 

Hmm, how have I not found this before. I'm looking for a third person controller, that looks good client-side, but also can run simplified with just the collider(s) server-side for authoritative server controlled movement, and server-side AI control for NPCs.

 

Hey Whippets,

I haven't done any work to support authoritative movement. I'm only vaguely familiar on the subject, but from what I understand it requires the client to be able to play-back previous movement requests from a specific point in time.

Unfortunately, that doesn't exist and you'd have to implement it if it was required.

Sorry

 

That's no problem. It's more a case of getting the motor to control a capsule colider on the server via script rather than from Input. I saw in one of the demos that there was an NPC running, turning, and jumping - so I presume some of that exists already. I'm certainly willing to give it a try

 

Hi! I've bought the latest version, and I'm trying to make simple AI character to walk over the cube.


mController.SetTargetPosition(currentPath.transform.position, 1f) - is working fine, if the character is on the straight line with the cube. Else, character runs in slightly wrong direction, never reaching the cube.

Ok, so I thought, maybe I can just rotate him firstly?

So I do this:

Quaternion lLookAt = Quaternion.LookRotation(currentPath.transform.position - mController.transform.position, Vector3.up);
mController.SetTargetRotation(lLookAt);

but, character starts running into totally different direction. I was expecting him to rotate, but not run? Why does this happen? I'm using example AI character from the demo. Somehow I can't get all this simple stuff working, probably I am missing something.


EDIT:
I think I've tried all the different combinations, but I can't find any way to make it work with those functons:

MotionController.SetTargetPosition()
MotionController.SetTargetVelocity()
MotionController.SetTargetRotation()

For example, I want AI chat run next to some point. When he is near the point, I want him to stop. Any of those 3 functions will either make him stop immediately (not naturally animated, when we run fast and suddenly stop), or simply just run forward forever, even thought I can set velocity like forward * 2f or forward *4f.

 

Hey @RyuMaster

I just got home and I have to run out again real quick, but I wanted to let you know that I got this.

Are you running the latest version of the Motion Controller?

I did some work to clean all this up. The functions you listed are exactly right, but I leave most of the "arrival" slowing to the developer as a lot of AI solutions actually calculate those speeds themselves.

That said, I know I had a sample that goes between 3 different way points. When I get home, I'll crack it open again to make sure everything is as I expect and I'll send you some sample code for getting the player to arrive gracefully.

I'll have an update later tonight (Florida time).

 

Hey @RyuMaster

Sorry this took longer than expected to get to it.

I couldn't find the script. So, I recreated it to show how to have an AI character arrive. You could certainly do more smoothing than what I did, but this is a start.

Download this monobehavior and use it on the AI character in the demo scenes (instead of SimpleAI). Then assign some targets in the inspector.

You'll see that I'm just using SetTargetPosition() and SetTargetRotation() to control the AI character.

 

Is there a reason this doesn't just use Animator.Crossfade or Triggers? Relying on an int means you have to very carefully track the Animator state and make sure to set the int back to 0 after the transition which seems like you could avoid by just using the more recent OOTB Animator features.

There are also costs associated with Any State transitions that could be avoided by switching to Crossfade or whatever so you could even more thoroughly encapsulate each motion within a state that doesn't need to know anything about any other state.

 

The int worked/works well for managing the state between motions that we didn't know would exist. There's code in there that will reset the value to 0, so that wasn't ever an issue.

Whether you use Crossfade or the int, you still have to manage the state of some motions; the climb and physics jump are perfect examples.

The Any State does have a cost, but so does the Crossfade. I didn't see much of a difference in my performance tests (about a year ago). Unity 5 is moving more towards "Entry" and "Exit" which helps the encapsulation I've wanted. That along with the release of the Animator API will help the Motion Controller quite a bit. Unfortunately, these will leave Unity 4 users behind... which may be ok.

I noticed that Shader Forge dropped Unity 4 all together. Maybe that's what I need to do.


So, short answer. The int worked well for Unity 4 and hasn't created confusion or a performance hit so far. However, there's lots we can take advantage of in Unity 5.

 

Last thing worth mentioning...

As I get back to the Actor Controller, I do plan on a pretty big change to the Motion Controller. Motion Controller v2 will use the Actor Controller as it's base character controller and leverage the new animator features Unity 5.

 

I've been experimenting with the Enter / Exit nodes but unfortunately Unity doesn't have a way to jump to a sub-state directly. I guess the workaround would be an empty start node on the base layer that could be jumped to and then you would let it exit with no time to the state which could branch off it's Enter node but that's not much different than Unity 4 using the same method.

A good Unity 5 feature though are the StateMachineBehaviour scripts. So an issue I've seen in MC are all those hardcoded strings for transition names and states. That's has a code debt for when you start changing around states that you have to make sure everything is still synced and doesn't seem like the best way to track which sub-state is currently playing.

Seemingly you can replace all that AnimatorStateInfo checking and hashing strings with a simple script that indicates OnStateEnter which state it is in and OnStateExit clears it out. If you need to track which particular clip is playing it's a lot easier with an Animator Tag to determine IsPivot or whatever than the strings.

Any vague idea of a timeline on those changes?

 

Good info. I need to dig into U5 Animator more.

I'm hoping before the end of the summer. First the Actor Controller, then work on my game, and then MC v2.

 

I wish I could do a poll here...

You've seen me talk about the Actor Controller and how it will replace the Unity Character Controller within the Motion Controller. After noodling on it for a couple of days, I've decided:

The Actor Controller and Motion Controller v2 will require Unity 5.

At some point, I have to advance in order to take advantage of new features.

Thoughts? Silence is acceptance.

 

This is a general shift of many of the assets now. The changes are so huge between versions. And the code #IF namespace noodle that is supporting sub 5_0 installs is enough to make some authors crumble all on it's own.

Frankly U5 hangs for me if I leave it unattended for more than 10 minutes at the moment - which is a problem - by June I hope they have fixed that.

So, Yes from us, on the understanding that the IDE version is actually stable enough to use professionally by that time.
In terms of the "people left behind" we have been thinking about senarios where 4.x is > than 5_0 and currently that would seems to revolve mainly around 2D games, which is outside the scope of this question.

Total size in PBR might be a problem for academic or educational writers (10MB limit on the initial d/l for example) however time will come up with solutions to this, and my early tests managed to get a "game" working - procedurally - in something like 3mb in 4.x. and something like 10mb in 5_0. So again this is not really a "problem" just will require some thought and - really again - is outside the scope of this question.

Sound like a "fair enough" and "considering everyone" answer?

PM'd you

 

Exactly!

I haven't had a problem with U5. It's been smooth for me and I'm using it more and more.

Good stuff to think on.

 

I get that hanging too. I've gotten in the habit of just closing Unity when I leave my desk but you'd think if it was that common Unity shouldn't have problems tracking it down.

Since the Asset Store allows you to keep a version for 4.x available that seems fair enough if forward development requires the newest version.

With all the fixes and UI dev going to 5.0 only even people uninterested in PBR and what have you have a good reason to move on from 4. With the more generous Free/Pro split I can't imagine many are sticking with 4.x. The most persuasive reason would be if someone on the last leg towards release and they wouldn't be updating their Assets either.

Unrelated, what is the best way to have an on demand only motion? Set a really low priority on it and use ActivateMotion?

In your rewrite I think the input system should be completely decoupled from the MC. There's not much reason to have code threaded through it about input if you expect to use it for AI. It's movement Vector2's/floats/etc should be set externally as well as triggering motions so then supporting any input system is a lot more trivial and doesn't require modifying anything on updates.

 

That's really what's threw me over the fence. The "ops" guy in me wouldn't ever want to abandon anyone, but since U5 is better, I think it's a good call.

Exactly.

I would like to, but I don't think we can. With something like jump or climb, the motions need to respond to input. That's why I use the input stub. You can create motions that use input, but don't care how that input was implemented. I think it has worked well. However, I'm always open to suggestions.

 

With the more generous Free/Pro split I can't imagine many are sticking with 4.x
^This

Also a lesson in how not to have to support your old products for too long
(or at least not for many)

With regards to decoupling I too would rhetorically say that, in principle, it is an excellent device to engender re-use and implemented correctly this might increase the future solution space of the product. If Fuzzy_Slippers has spotted something helpful in current code-set and provides a demonstrative, more de-coupled diff that would certainly be great to look at, for future rumination.

 

Our first shared motion! whoo hoo!

Thanks to @twobob we have our first shared motions and it's a.... swim!

The animation was kindly donated by Tanuki Digital.

This isn't a complex motion... which makes it a great one to start with. The goal all along would be that people could share motions and plug them in with minimal effort. I think @twobob did that perfectly.

You can pick it up from the ootii website.

 

Excellent. Huge respect to The suimono project for kindly donating the core movements (which I simply, converted, coded, packaged and shipped). Details in the README.

This is a genuinely helpful process for EVERYONE so I am very proud to push it forwards.
Yay!

 

OFFTOPIC: http://www.hallowsdeep.com/forums/topic/features-intended-ones-suggestion/
my 2nd ooti first for the day. Looking forward to seeing that surface one day.
Have a great day

 

I posted a question, but figured I'd ask here. @twobob You'll appreciate this...

For the upcoming Actor Controller, I've got GC allocation down to 48B. It seems this 48B is coming from Physics.OverlapSphere().

How bad is that? Will that cause a problem for mobile users?


(ignore PlatformMover.Update()... that's only for testing)

 

Always glad to see people keeping an eye on GC.

 

Well. I found it did stutter some really tragic android devices I have but only in conjunction with other stuff and only time-to-time. Can anyone tell me if UT actually did go to a newer version of the GC yet? I suppose that has a bearing, I may have "old" results, Long story short not too bad. Proper pain that Physics Sphere ey?

Need to retest - with an otherwise (GC) clean project -to give you any kind of meaningful feedback.

AND REMEMBER PEOPLE: SUPPORT: http://feedback.unity3d.com/suggestions/garbage-free-physics

 

Hi Tim

I am all for the Unity 5 only as well. Those that were in the v4.X should have no reason not to upgrade/convert.

Thank you twobob for the addition. I have had suimono from the early days and it has always been excellent in all flavors.

 

Hi Tim,

Firstly, I would like to say well done. This works really well and is very Emote and Animation Key friendly. I have completely switched over now to Motion Controller in lieu of my own. Again your tools shine.


There are only a couple of issues and ideas. Once these are solved I will update my smooth camera zoom (middle mouse axis) to work with your camera rig. This will be free for you to add and distribute if you like.

The following I am using the Independent Adventure Camera Rig and Motion Controller. I also did this with my own character model. The animations synced up nicely as well as substituting my Mixamo Animations into this. For the issues below I reverted to the Raw Mocap Anims provided for consistency.

1) Animation Rotation in place. When I press Q & E (my Horizontal Axis lateral motion) blends into the forward motion. If the character is standing in place the character should just pivot left (Q) and right (E). When moving forward the rotation blend is working properly.

2) Camera Controls. This one is slightly complicated to explain so I will try my best. I am in play mode while writing this to be the most accurate.

- Left Click Camera Viewing....none here or I have not found the connection. This is usually used to simply move the camera around without steering the character. Handy for swinging around to have a look while leaving the character do its thing. You have this with the Right Click and hold but only with no momentum. This could used for Pivoting as well (explained below).

- Right Click Steering. This is 'sort of' there but 'feels' disconnected from the animation. Casual Idle....Rotate with View....now right click and rotate. They are out of sync. It appears there is a swing angle and then tugging once the angle is met to rotate the model....I may be wrong here....just appears that way. I can completely go with => as long as Right Click is held down the camera and the character model simply rotate together as a locked pair.

- When the character faces the camera (within an angle range) the backward animation plays but does not move. The W (forward key) should actually continue forward momentum toward the camera as any rotation.

- The camera is very jittery at around 90 degrees (sides of character).

3) Adventure Forward. As I am using the Motion Controller for all my needs I see that the AI Model is using the Adventure Animation set which includes the pivots which I really like. With the camera issues above I love the pivot with Right Click and Hold camera swing but the disconnect is again feeling wrong.


The above do not seem heavy issues to resolve since everything looks like it is there to accept this. Any help would be very much appreciated.

Cheers

 

For your work on the raycast based controller you might be interested in checking out this guy's work on his "super character controller" : https://roystanross.wordpress.com/

I haven't had time to dig into it but the results are definitely impressive and it seems along the same lines as you are pursuing.

Naw you just need some kind of event system to trigger things externally and have them respond to input vectors whether those come from a player, from a pathfinder, or whatever. I've extended motion controller and the motion controller motions to integrate with my character and event system and I've got my jumping and climbing motions working for AI and the player using the same motions through events.

As an example here's my dodge motion : http://pastebin.com/zp0KS5yu which is triggered the same on both AI and players using it.

 

Hey Olander, I'm having a hard time visualizing some of what you're writing. Any chance you can get a video or even an image that you mock up?

That said, a couple of things stuck out...

If you're using the Motion Controller, you should use the "Adventure Camera Rig". Not the independent one. The independent one is for non-ootii controllers. I probably need to be more clear about that.

When you do that, make sure "Is Late Update Enabled" is not checked. If it is, that can cause some jittery behavior since the camera processes its update twice. It can also cause issues because the camera could process before the Motion Controller.

With the Casual Idle motion, you also want to make sure "Rotate With View" is not checked when you're using the Adventure Camera Rig. This will prevent the character from rotating as you have the camera orbit around. Is that what you're talking about? Sometimes it's just hard to visualize the behavior when it's written.

See if those help and we can go from there.

For your #1, I don't have a "step off with rotation"... I think that's what you're talking about. I actually did in the beginning, but it did't blend well and you'd get a "blip" in the animation as it went from the idle-to-run animation to the actual run. This is especially true if you started stepping off with a slower walk vs. a run. Once I get some time, I'll go back and see if there are some better animations that may help this. However, if I remember correctly, this was more an issue of transitions.

I hope this help.

 

Hey Fuzzy, thanks for this. I poked around the site a bit and it looks interesting. I avoid downloading code like this because I don't ever want to be accused of stealing someone's stuff. But, based on what I see in his blog, we definitely hit some of the same issues and it looks like our goals are similar.

Just as a side note, the Actor Controller is going well. This week was spring break with the kids, but I did get some work in. Going up and down stairs is now very fluid, most of the edge cases (ie overlapping objects) are handled, and I've got dynamic spheres and capsules working so you can define your character's shape if you have an odd character... say a horse or monster. Performance took a hit because of the dynamic character shapes, but I'm still 30% faster than the Unity CC. I've also got some ideas for caching obstacle data to help performance.

First... love the "dodge" script! You rock!

I see what you're saying about the events with "OnDodge" and "CanDodge". I had thought about events in the beginning (that's one of the reasons the Event Dispatcher exists). However, I had a couple of worries:

1. Not everyone would be using the same event system and I need to be flexible.

2. I was worried I would need to poll for current values in the motions. A lot of times, I'm not just responding to an event, but querying information (ie current stick value) and rotating based on that. That didn't feel "event-like"... but maybe I'm over thinking it. Have you had to deal with this kind of data yet?

I need to think more about this. Maybe there's some hybrid. I do agree about decoupling.

 

1: I'm allergic to strings so I use an event system that's pretty inflexible, but I think there would be room for something more generic within the MC. You can currently query the motions and get a motion and activate it manually, but that ignores priority and its conditional entry.

I think it might be a good idea to add something like a CanStart(string motionName) to the MC which would look for that motion and check its TestActivate (and a TryStart for simplicity perhaps). Maybe by default it would look for an active higher priority motion and return false if anything higher priority is active (which is what I do in mine currently).

Then add a property like CanAutoStart and only motions true on that would be part of the current update check for auto activation based upon priority. GetButton input code doesn't need to be part of the TestActivate of any motions that way.

So Jump is non-auto started event driven motion but Fall would be part of the update check. My EdgeGrab auto starts but waits on character input to complete the motion.

2: In my ICharacter setup every unit has a Move and Look Vector2 that's updated by whatever drives it (input or AI). With the events like Movement or Climbing and such it checks that to decide what kinda of movement is desired. The input system updates the Player Character's ICharacter implementation with the stick values while the pathfinder keeps the AI characters updated.

So Move and Look updates aren't considered events in of themselves but events use those values. ICharacters all have their own event system so character components are checking the local ICharacter rather than anything global. Your MC integrated with my setup pretty well in that regard since the MC naturally lends to a bundle of components checking local status.

 

Adventure Rig placed and the camera is working much better. No jitters at 90 degrees. So must be something with the Independent version. FYI....in Motion Controller PDF is says to use either.

This was always unchecked. I checked it with the Independent and it did not make a difference.

Not even close to what I asked. A pic is useless here.
Press Q - Rotate Left with No Forward Movement (Does not work)
Press W - Forward Movement (Already Works)
Press E - Rotate Right with No Forward Movement (Does not work)
Animations play zero part in the Rotation since the model simple rotates at a configured speed. I have Mixamo Animations that I played with the Rotation Speed because most 'Pivot/Stand In Place Turning' animations have static roots.

How Motion Controller is working is it 'Blends' turning with Forward to get moving. When pressing Q or E the Feedback Text at the top is also stating Forward as well (depending which Forward Layer is set). Try it.
**Some people will prefer A & D as their rotating keys. Strafing is something completely different....that would require an animation layer.

As for the Left and Right Mouse.
Click and Hold Left Mouse - Camera is Free to have a look around at the Player's Liberty....momentum or not.
**With no Momentum you Right Click and hold does exactly this. When Moving you should Also be able to do the same thing.
Right Click - Align Character to Camera Angle (you do this already with the Middle Mouse Click...only this includes the Shoulder Zoom feature....which is very very nice)
Right Click and Hold - Aligns Character to Camera Angle and then steers the Character as long as it is held down. Currently (see Pics) those are the angles the camera starts to 'Tug' on the character to get it turning. The Character is very difficult to steer with the mouse currently.

Added this eve (Adventure Camera is allowing testing of this feature):
Reverse Turning - When swinging the camera around quickly in Forward Momentum this causes a Reverse Turn. Great Feature....love it. However, it is Reverse Turning 45 Degrees off. This is consistent whether swinging from the left or right. I think the code should be looking at -180 from the current vector instead of some camera trigger angle to start the animation.
*Note: the AI running between targets IS actually using a 180 turn so this issue must have something to do with the camera angle triggering the animation. Just a thought here.

Hope that help explain things.

Cheers
O

 

I'd classify some of the things as "not working by design" since they aren't part of the current feature list or instructions I provide.

They may be good for a wish list, but I just wanted to be clear (for others) that when you write "does not work"... that's a bit like saying "My car isn't flying. So, flying 'does not work'." You're not wrong, but...

By design. There is no implementation for Q.

By design. There is no implementation for E.

With these, it seems clear that they are features you'd like to see. They all make sense to me.

I've got a lerp with the turn so that it feels a little more natural. I can see where that is making it less responsive and having some options for you to disable it would help.

I believe I know exactly what you're talking about. It has to do with the transitions of the 180-pivot. In order to have the pivot blend into the run, the transition creates an overlap. During that overlap, some of the rotation is actually lost. I ended up making the decision... bad blending or partial rotations. I felt the later was minimal and acceptable, but you're right...180 is not 180.

All good stuff and things for me to add to my list. In some cases, I just want to make sure I'm clear about what's a non-working feature and what's a feature request.

 

Thank you for the reply.

Q & E....we can agree to disagree here. Who makes a Character Controller with no Rotate? Without it turning on a platform or dangerous ridge just makes for an auto suicide. I shall have to add it then. Fair enough.

The question remains....if there is no implementation of Q & E....then How is the Horizontal Axis (my Q & E) tied to the Forward (W) and the animation does actually turn to get started. When I code in a Standing Rotation....what am I fighting against in code?

This was not a feature request...I just want to learn where to turn this 'feature' off.