[Released] Character Movement Fundamentals - A Rigidbody-based Character Controller

Thanks for the suggestion! I've already implemented a fix for this bug (which will be part of the next update), but maybe your approach is an even better solution? If that's the case, I'll definitely include it in the next update instead!

Thanks again!

 

@MrJohnWeez Great fix! Thanks for sharing!!

Thank-you, this helped a lot. I was able to write a new version with an override that allowed the new rotation to be manually set.

At the moment my game starts at 0 and I can rotate 45 degrees at a time only. My soluton at the moment is a CameraController hack which specifies a new RotateCamera, but I wasn't able to allow any sort of smooth movement, such as 'RotateTowardsVelocity'

Mostly I would love an option to have more freedom to rotate the camera and have the movement input cope with it.

Sounds great! Looking forward to it!!

 

For smooth camera rotation, the best way would probably be to rotate the camera over a short period of time using coroutines - that way, you could even use custom curves to ease in/out the rotation for a more 'organic' game feel.

If the player should only be able to rotate the camera in increments of 45° and shouldn't be able to move the camera "manually" using the mouse, a camera system like that should be very straightforward to implement.

If that's what you're after, feel free to contact me via email and I'll walk you through the specifics!

So if I understood you correctly, you would prefer a controller system that doesn't require a 'CameraController' component to work?

I'm asking because I wrote a modified controller script a few weeks ago for a different customer who needed something very similar for their project.

Essentially, instead of a 'Camera Controller' component, the modified controller only requires a reference to (any) camera in the scene and will use that camera's view axes to calculate the character's movement direction.

As a result, you're free to move and rotate the camera around as you like (it doesn't even have to be parented to the character).

If that sounds interesting to you, just contact me via email and I'll send you the script along with some instructions on how to import it into your project.

Hope that helps!

 

I was able to find a nice solution for my camera control woes. I separated the ability to Reset the camera into a public function on CameraController.cs. These were all taken from Awake()

Code (CSharp):

1.  
2.     // This resets relative controls
3.     public void ResetFromWorldPosition()
4.     {
5.         lastPosition = tr.position;
6.  
7.         //Set angle variables to current rotation angles of this transform;
8.         currentXAngle = tr.localRotation.eulerAngles.x;
9.         currentYAngle = tr.localRotation.eulerAngles.y;
10.  
11.         //Execute camera rotation code once to calculate facing and upwards direction;
12.         RotateCamera(0f, 0f);
13.     }

Meanwhile I'm using 'DoTween' for rotating the camera, on a class which inherits from CameraController. It calls ResetFromWorldPosition() while the rotation happens.

Code (CSharp):

1.  
2.     IEnumerator RotateCameraSequence(float offsetAngle)
3.     {
4.         Tween myTween = transform.DOBlendableRotateBy(new Vector3(0, offsetAngle, 0), 0.25f);
5.  
6.         while (myTween != null)
7.         {
8.             yield return null;
9.             ResetFromWorldPosition();
10.         }
11.     }
12.  

 

Hello! I'm loving the look of this package. Before I pick it up, I'd like to know a little more about how well it plays alongside Unity's own AI nav agents. Can the two co-exist in a space quite happily? What happens if the player tries to move their character through a crowd of agents, for example? Or jump on their heads?

 

Just wanted to quickly announce that version 1.2 has just been approved by Unity. Here's the changelog:

Spoiler: Version 1.2

- Fixed a bug that caused visual glitching when viewing controller prefabs in the inspector in newer versions of Unity (2018 and up).
- Added a public 'Add Momentum' function to 'BasicWalkerController', which can be used to add a force to the controller (useful for jump pads, dashing, [...]).
- Added an option for more responsive jumping: By holding the 'jump' key longer, the character will jump higher.
- Added two public functions to 'CameraController'. By calling them from an external script, the camera can be rotated either toward a direction or a specific position (see manual for more details).
- 'SideScroller' controller prefab has been streamlined (code-wise) and is now compatible with the 'GravityFlipper' prefabs.
- Various minor changes to some of the code to improve readability.

If there's any questions about some of the new features, please feel free to ask in this thread or directly by email (support@j-ott.com).

 

Hi! In allmost all situations, the controllers included in 'Character Movement Fundamentals' behave very similarly to regular rigidbodies. So when it comes to the interaction between navmesh agents and controllers, it all depends on how you've set up the agents.

For example:

• If your navmesh agents have no collider and rigidbody attached, there won't be any collision between agents and controllers (since navmesh agents by themselves are not physics objects).
• If your navmesh agents do have colliders and (kinematic) rigidbodies attached, then the controller will get pushed around by the agents.

I haven't tested this yet, but I'm fairly sure that if you attach a 'Nav Mesh Obstacle' component to a (player) controller, the agents will try to walk around it (which is probably the best solution for crowds).

I hope that helps!

 

Great, makes perfect sense. Thanks for the quick reply!

I have used NavMeshObstacles in the past and yeah that's exactly how I'd expect it to work.

I'm going to buy the plugin now

 

Thanks for the update!

Unfortunately I'm having lots of problems.
Firstly, the gravity tunnel is broken in all camera modes.

Secondly, I wasn't able to get the camera rotation controls working at all, and it's not clear what the function expects.
Could you show a working code example to press Q and E to rotate the camera in 45 degree steps around the Y axis?

Even when I got it partially working, the movement input wasn't updating for up/down controls, but the left/right controls were correctly aligned.

I was usually getting the following error when I added camera keys to the Topdown demo:

 

Hi Hayden!

I'm very sorry for the confusion, I should have explained the two new camera controller functions in more detail in the change log.

Anyway, to clear things up:
The new 'RotateTowardPosition/Direction' functions that have been added to the camera controller component are intended for making the camera look at a specific object in the scene (or in a specific direction).
They are really not suited for directly controlling the camera's angles in a precise way (which is what you need in your project).

Are you still using the 'GlobalCameraWalkerController' script I sent you? Because that script currently can't handle a rotating controller (which is what's happening in the gravity tunnel and the gravity flippers).

To make the script compatible with controller rotation, you'll need to replace the code in line 33/34:

Code (CSharp):

1. Vector3 _cameraForwardVector = Vector3.ProjectOnPlane(globalCameraTransform.forward, Vector3.up).normalized;
2. Vector3 _cameraRightVector = Vector3.ProjectOnPlane(globalCameraTransform.right, Vector3.up).normalized;

... with this code:

Code (CSharp):

1. Vector3 _cameraForwardVector = Vector3.ProjectOnPlane(globalCameraTransform.forward, tr.up).normalized;
2. Vector3 _cameraRightVector = Vector3.ProjectOnPlane(globalCameraTransform.right, tr.up).normalized;

That way, the script will take the current rotation of the controller into account when calculating the new input direction.

Sure!
Please take a look at the script I attached to this post called 'RotateAroundYAxisInIncrements'.
Try importing it into your project and attach it to the 'CameraControls' gameobject in the character's hierarchy (and make sure to delete/disable the camera controller script, if necessary).

By pressing 'Q' and 'E', this script will rotate any gameobject in adjustable increments ("Angle Increment") over time ("Rotation Duration").
You can also change the "feel" of the rotation by adjusting the "Rotation Curve" or enable "Clamp Angle" to make sure that floating point imprecision won't affect the rotation results (over time).

I hope that fixes all (or at least most) of the problems you've described. If something's still not working or if anything's unclear, please contact me via the support mail so we can continue there!

 

Thanks! I will give it a try as soon as I get back to my computer.

I was trying with an empty Unity project with just your new package. The broken gravity tunnel was in your demos, so you might want to fix that.

 

Trying it out now. I see what you mean now.
The rotate works great if I use the globalcamerarotation that you sent.

Could you show an example of the new Camera Facing Direction/target in action? It would be good to see.

 

Sure thing!
I've attached a very simple example script below. Just import it, attach it to a controller (preferably at the root) and assign any gameobject as the 'Target Object'.
As long as you hold down the left control key, the camera will turn toward the selected target object. That's really all there is to it.

A possible application might be some sort of lock-on mechanic that is often seen in third-person games featuring close combat gameplay - like Dark Souls, for example.

 

Hi Jan, I picked up CMF on sale after struggling to roll my own character controller. Exceptionally well-written documentation and beautifully organized code. I've learned a lot from it.

I've been tinkering to fit my own needs (using different cam system) and ran across something odd. My customized character kept sliding down surfaces that the prefab TopDownWalker didn't. All the settings looked the same. Turns out my character's slopeLimit in Mover.cs was set to 30 (default), where the prefab's was set to 70 - but I couldn't tell without going into debug mode, because the custom inspector for Mover hides the slopeLimit field. (There's a separate slopeLimit field in BasicWalkerController that seems to set the sliding animation, while the one in Mover determines whether the character actually slides. I think.)

Seems like Mover/slopeLimit should be exposed/documented. Or possibly I'm out of my depth and doing things wrong - that wouldn't be unusual.
Joe

 

I have a few questions before buying this asset:

1) I have a game where I can stack cubes on top of each other. These cubes are also platforms meaning that they move what's on top of them at the same speed that they're moving.

Does your system support platforms that move platforms, that move platforms...?
A picture describes the situation better:






2) Does your system allow to enter a "Push" mode where the player can move a box? I don't mean the normal Unity physics collision system. This is less important than question 1.

3) In the top down controller, is there an option that makes the character stick to the ground no matter its movement speed?
I want the character to stick as long as the distance between the ground and player is not big. The demo shows a character with low movement speed so I can't tell whether or not the player could lift off the ground when he arrives in such scenarios:

I wouldn't want the character to do what's shown in the picture below. Instead I want him to follow the ground all the way.



Thanks for the info

 

I can't thank you enough for bringing this to my attention, JoeJoe!

So, the 'Mover' component isn't actually supposed to handle slope limits at all - but it used to in an older version of the package. The 'slope-limit-handling' functionality has since been moved to the controller scripts.

However, for some reason, parts of the old code is still in the 'Mover' class. I suspect there must have been a mistake with the version control at some point (or I might have missed it, that's a possibility as well).

Anyway, I'm working on sorting this out and pushing out a new update as soon as possible (which might take a few days for Unity to approve).

In the meantime, you could just replace the check in line 235:

Code (CSharp):

1. isGrounded = (Vector3.Angle(sensor.GetNormal(), tr.up) < slopeLimit);

... with this, for the time being:

Code (CSharp):

1. isGrounded = true;

Which will bypass the unnecessary code.

I'll definitely double-check the rest of the slope-handling code as well while I'm at it, to make sure everything else is working properly.
It's unlikely, but if I do find anything else not working as intended, there might a few extra changes to the controller code as well soon.

I'm very sorry for the inconvenience! And thanks again for bringing this to my attention!

 

Hi @FeastSC2!

1) Currently, there's only a very basic moving platform script included in the project (mainly for demonstration purposes).

The platform system uses kinematic rigidbodies, which are moved around by code (not physcis) and uses trigger volumes to detect any controllers on top of the platform.

Based on your description, it sounds like you need a system that can handle dynamic rigidbodies - so I probably wouldn't recommend using the current included platform system in your case.

2) As of now, there's unfortunately no 'pushing/moving' functionality included in the package (apart from regular Unity physics, like you mentioned).

3) In general, it's really hard to keep a character grounded at all times and at any speed with rigidbody-based character controllers.
You can certainly get close (to some degree), but if the speed is high enough, any rigidbody controller will lose ground contact at some point.
I think for the effect you're after, using a raycast-based controller system or a kinematic character controller (like the built-in controller in Unity) is probably the easier way to go.

I hope that helps!

 

Alright, for the #3 I'm sure it's easy to add it on your controller with simple raycasting to the ground with a small distance. Like you said it wouldn't work with crazy high speed but that's ok.

Same goes for #2.

For #1 I haven't found a working solution with dynamic Rigidbodies actually, this is because I move each box delayed by one frame and it's really not the way to go. I think it would be easier with kinematic bodies.

Thanks for answering.

 

You're very welcome, I appreciate the swift reply. I'll make that edit.

 

@JanOtt, any chance you'll support expulsions?
Like when a player gets hit and he's pushed in a certain direction. You would have the player's input still be useful during that expulsion but it would be less effective.


This is a small detail but I see that in your scripts that you do GetComponent<Transform>(). This is not necessary: you can simply call this.gameObject.transform

 

Something similar has been added in the most recent update, namely the 'AddMomentum' function of the controller scripts.

Essentially, it allows you to directly pass a vector (like a force) to the controller, similar to how the regular 'rigidbody.AddForce()' works. If you also tweak the air and ground friction settings of the controller, you can implement a wide range of "pushing" effects.

There's also a (very) short little section in the manual (section 4.6.1, page 39), if you're interested.

Good catch, I'll look into that! Thanks!

 

Thank you so much @JanOtt for making CMF!

I'd been struggling with making another character controller networked for ages (literally months on and off) and I got yours working within 24 hours with networked synced movement and animations!

Now I can finally move on to making yet another PUBG clone

 

To explain further. When you inherit from MonoBehaviour what you're saying is that your script is a component.This means it has to be attached to GameObject.

GameObjects are forced to have the Transform component. So you can directly call (this.)transform or (this.)gameObject just by inheriting from MonoBehaviour.

When you want to add or get a component you want to add/get them from the gameobject. But by being a MonoBehaviour we already know we are on a gameobject. So again, some functions like AddComponent<> or GetComponent<> can be called without explicilitely stating this.gameObject.AddComponent<>. It is implied that it will be on the gameObject the Component/MonoBehaviour belongs to.

 

Hi @JanOtt
I just bought your asset, and didn't have time to test all the features but for your information,
I tried opening it in multiple Unity 2019.3 betas and the gravitational part of the Showcase scene is broken in this version.

Sorry, I can't provide more info about it, I will do some further tests tomorrow.

 

Thanks! And it's really cool to see my asset used in a networked project! I'd be very much interested to follow the progress of the PUBG-style game of yours!

Thanks for elaborating!
The reason why I'm assigning a reference to the gameobject's transform component has mostly to do with performance.
In older versions of Unity, there was a measurable decrease in performance when calling something like 'transform.forward' multiple times per frame. So back then, caching a reference to the transform in Start()/Awake() made a big difference.
I think that difference isn't as noticeable today, but I kept the practice just to be on the safe side. Maybe I should run some performance tests about this some time, to see how big the difference really is (or if there's any difference at all anymore).

Interesting, thanks for letting me know! The latest version I've tested the asset on was 2019.1.0, looks like there's been some major changes with the physics in the beta versions!
I'll definitely look into that soon!

 

@JanOtt I just realized that when I set the castType to "raycast array" with a box/sphere collider. Whenever the game starts it removes the box/sphere collider and creates a capsule collider component. Is that intended?

 

The issue probably comes from the PhysX update to 4.1 featured in 2019.3.
Everything works fine on 2019.2 versions.

EDIT: The gravity swaps are working fine, only the gravity tunnel is broken

 

I saw some things that I think could use an improvement:

1) Your code structure makes it so BasicWalkerController determines the movement but I think it's better if you change it to this structure of code:

Mover: handles how to move like it does now.
BasicWalkerController: you pass a velocity to it from some other script, it just knows how to transform that velocity into the movement the mover will do. This means you remove the movement speed variable from that script.

Now you can make scripts that give the BasicWalkerController a desired movement.

You then call BasicWalkerController.SetMovement(Vector3 velocity, bool AllowTransformVelocityForWallWalk). Where you discard the y velocity.

The 3rd script would then be for example: a PlayerInput script, or MonsterAI script.

Right now your structure works fine but it doesn't work well with the idea of making AI that uses the controller where you want to directly pass a movement and not a movement speed.


2) Step Height is not intuitive to set because it is relative to the height of the collider instead of being relative to the ground. A percentage makes it so that all the units that use the controller will have different step heights or at least hard to compare step heights.

3) The sensor's distance to the ground is not correct but I think you know this already.

These are just my thoughts, do what you want with them

 

Hello! I've been using this asset for a few days and gotta say I'm amazed by it. I needed a very optimized controller as I'm making a VR local multiplayer game (a player in VR, and up to 4 on split screen on the pc). This is working out of the box and some questions I had have been already solved just by reading this forum! And I'm very glad to already see split screen is doable with this!

But I'm currently struggling with something that I guess has a simple solution. This is all regarding the 3rd person controller with free movement and free camera (no strafe).

See, my character's jump is more of a "pounce attack", and I'm trying to make it so it actually pounces in the direction the camera is looking (including up and down). The AddMomentum seems to be the way to go, (so for example if I'm sprinting towards the camera and press attack while looking in the opposite direction, it will be less effective than if I do it while sprinting on the same direction), but I'm not sure where to add it and what values to use. I've fiddled around with the OnJumpStart but just managed to get it to add momentum in a single direction.

What would be the correct approach? BTW I'm using a script similar to the ExtendedCameraWalkerController user revanaii posted here, that I also use for sprinting, telling the controllers where to stop moving if the character is dead, etc. Could this be added in that script or do I need to go to one of the camera scripts?

EDIT: I managed to get kind of close by referencing the camera GameObject on the extendedcamerawalkercontroller script and making a method that applies addMomentum using the cameraobject "forward" vector (multiplied by whatever value I want)

Then on the basicwalker I added an event for the OnJumpStart that triggered the method.

Still I think I might be doing something wrong because it doesn't seem to care about the actual direction the camera is facing up or down but rather the direction relative to the horizontal plane... will keep tweaking though!

EDIT 2: Found the issue! I just had to comment out the BasicWalkerController lines that override the vertical velocity with jumpspeed when it's jumping. Now I can launch wherever I'm looking at! Still, if I did something wrong / there's an easier, more elegant way to achieve this I'll be happy to hear!

 

That's definitely not supposed to happen, I'll look into that as soon as possible!

You definitely raise some good points there.
Regarding point 1), that's something I've been thinking about as well. I'm planning to eventually do some serious restructuring of the whole project in the near future, to make it even more flexible and adaptable. That update will most likely also include the addition of namespaces, separating controller input into its own script (which is quite similar to what you're proposing, in fact) and maybe some streamlining of the example scenes.

I'll first to have to sort out a few low-level issues first though, like the unintended collider swapping you've described earlier.

About point 2): Yes, the term 'step height' will probably be replaced by a more fitting name in the future. Maybe it really should be called something like "Step height ratio" or something along those lines.

I didn't quite get what you were refering to in point 3) though. Could you elaborate a bit? What's incorrect about the current sensor distance?

By the way, you can also always contact me via email (support@j-ott.com) for more in-depth discussions (if that's fine with you). It's a bit difficult for me to keep track of multiple different conversations in a forum thread, unfortunately.

I think there (possibly) might be an easier way to accomplish what you're after, but it sounds like your solution is working great for you.
However, if you're interested in my approach, just send me a copy of your post to the support email (support@j-ott.com) and I'll be happy to explain it in detail!

 

I found that when the character jumps on the platform, it doesn't follow the movement of the platform and drop on the ground. I suppose it only increase the character's height only. Can you add support to this part?

 

That's strange. The moving platforms are supposed to move the character along both horizontally and vertically - and I can't reproduce this bug on my machine either.

I think it's best if you could contact me via the support email (support@j-ott.com) with a few more details about your scene setup and I'll help you solve this!

 

The gif above showing that the character didn't follow the platform when jumping

 

Just wondering; how hard would it be to make it climb walls ? If anyone is motivated to do it that would be nice

 

Ah, now I see what you mean!

The way the moving platform currently detects whether there's a controller standing on top of it is by using a trigger volume. If the character jumps, it leaves the trigger and as a result, it won't be moved by the platform anymore.

You can change this behaviour very easily if you just modify the size of the volume - by increasing its height (or 'z' size), the character won't exit the volume so easily by jumping.

The trigger volume is called 'TriggerArea' and it's a child of the 'MovingPlatform' gameobject. Just change the size of its box collider component until you find a setting that suits your game.

I hope that helps!

 

That fully depends on how you want the wallclimbing to work. There's dozens of different ways to implement it - do you have a specific type of gameplay in mind (or an existing game that features the kind of wallclimbing you're after)?

 

I came across your plugin earlier today and it looks impressive. The feedback that I see makes it seem like you've built something easy to understand and to implement. I'm going to check out the manual later since my work blocks Google Drive. In the meantime, I wanted to get your opinion on the project I want to use this for.

I want to make a multiplayer arcade hockey game. One issue that I can never quite wrap my head around is how to make it so that players can check each other by initiating contact. I would also like players to collide if they are moving quickly towards one another (more of an accidental collision). If players are slowly moving, I would rather them just slide around each other without really interacting.

Do you feel that your plugin would be able to accomplish something like this?

 

If the controller falls from higher altitudes (Pos.Y = 100 - 2000) it falls through the terrain. Have already tried a little with the sensor, but still no solution! Someone an idea?

Netter Controller btw.

 

Not sure if this is your exact issue, but I know that fast moving objects can pass through something without colliding. Maybe the objects are reaching a high velocity when falling from high heights?

Here are two documents from Unity on the subject:
https://docs.unity3d.com/ScriptReference/Rigidbody-collisionDetectionMode.html
https://docs.unity3d.com/Manual/ContinuousCollisionDetection.html

 

Thanks -.- That solve my problem
But what exactly is the definition of "fast moving"

 

I'm glad that worked for you!

As per the definition of "fast moving", that's honestly a good question. I believe it's relative to the size of the objects that should be colliding. This is from memory, but I believe that a small object can phase through a large object (such as a flat plane that only consists of 2 triangles) at a slower speed than two objects that are close in size.

I'm not too sure how fast your object would have been moving when dropping from 2000m, but you could print out the velocity's magnitude and see.

Be warned, however, that enabling Continuous Collision Detection will most likely add some performance cost, so I don't believe it's advised to use it on a bunch of objects. I wonder if it's possible to only enable it on your controller once it starts reaching a specific speed and to disable it once it goes below that threshold.

 

That's a good question!
So essentially, all the controllers in the package behave like regular rigidbodies. The only thing to keep in mind is that their velocity is directly controlled by scripts.
That means that by default, they will collide and slide along other rigidbodies.

For something like a "check" (which is the hockey term for pushing/bumping into other players, right?), you could make use of Unity's regular 'OnCollision' functions (OnCollisionEnter, OnCollisionStay, OnCollisionExit), which are called on each controller whenever there's any collision (because the controllers are essentially rigidbodies).

You could then use the collision data you get from these functions to implement what happens next (add a force to the character, play fitting animations...).

That's how I'd go about it, at least. I hope that helps!

Danke, das hört man gern!

So, just like @Pacana already mentioned, changing the rigidbody's collision detection mode is the best way to solve this.

To add to @Pacana's solution, there's also the option of artificially clamping the controller's top velocity (unless very high velocities are part of the gameplay, of course!).

 

Haha yes, sorry, that is what a check is. I should have been more clear.

What you said makes perfect sense. Thank's for the input!

 

One big issue I have with rigidbodies is that they tend to bump on the transitions/seams between colliders on flat surfaces (walls or floors). It's even more noticeable on 3d tile based games.
Do your controller fix this problem?

 

Since the ground detection is handled by a raycast-based system in my controllers, there shouldn't be any such problems with tiled geometry, at least when it comes to floors.

In addition to that, I've never encountered any problems with tiled walls either when doing general tests on the controllers. So I'm fairly confident that tiled walls shouldn't pose any problems either.

 

I was messing around with the sample scenes and trying to adjust Ground Friction. I thought that lowering this value would cause the player to slide, but that isn't the case. If I wanted my player to glide around as if they were on ice, would that be Mover or Controller behavior?

Also, I noticed that if you increase the Movement Speed then jump into a world boundary, the Movement Speed will revert to default until you jump once.

 

'Ground Friction' is only affecting the momentum of the controller - currently, only jumping, losing ground contact (by stepping of an edge) or calling the 'AddMomentum' function will actually add momentum to the controller. Regular walking doesn't.

For something like sliding on ice, you could smooth out the input you pass to the controller (by overriding the 'CalculateMovementDirection' function in a custom controller script).

Alternatively, you could also add some custom (pseudo-)physics to the controller script to handle sliding around, but that's a lot more involved.

Could you elaborate a bit? How do you increase the movement speed (with an external script)? What default value does it revert to? And what do you mean by 'world boundary', just a regular collider or something else?

 

Sorry, let me explain.

I was using your sample scenes, specifically ShowcaseScene. The Camera Walker Controller has a "Movement Speed" input parameter. By default it is set to 7. I changed it to 15 to make the character walk faster. When reaching the "world boundary", which is what I'm calling the edge of the walk-able terrain, the character movement speed reverts to normal (a value of 7). The inspector will still say 15, but the character will still move at the slower speed. By jumping, it seems to fix the issue.

Does that make sense?

 

I see! That's very strange, the 'movementSpeed' value is never modified in the controller scripts and the "world boundary" is just a set of invisible colliders.

I couldn't reproduce the problem on my machine either, unfortunately.

Did you maybe modify the 'BasicWalkerController' script in any way? Or are you using any external scripts that access the 'BasicWalkerController' component?

 

I actually didn't modify anything. I simply loaded the scene and changed the movement speed in the inspector. I think it only happens when you jump into the invisible wall. I'll try and grab a screen recording of it in the next few days.

This isn't affecting my development at all, so I don't want you to worry about it. I just happened to see something strange in the showcase scene and wanted to let you know. I'll get back to you on this with some additional details. I'll most likely send you a direct message about it.

Also, your quick replies are really nice to see. Thanks for being so responsive!