Past Updates...
Controller Beta Update - v0.3
What a year! We have another set of Controller updates and fixes releasing today that address more of your bugs and feedback.
-
AirController.CancelAirMomenum
replaced withAirController.MaintainLinearMomentum
andAirController.MaintainAngularMomenum
to allow you to separately toggle whether you keep your angular and/or linear momentum when transitioning to this Controller. -
ControllerManager
input properties now replicate from client to server, so the player will maintain control of their character if it becomes owned by the server. - Using certain Constraints with the Controllers no longer causes the character to explode. (thanks @MikesDSL)
- Character no longer maintains their pre-jump ground speed after freefalling and changing direction in the air. (thanks @JoyfulFlowerMary)
- General stability improvements to the GroundController. Character no longer tips over when running into walls. We encourage you to disable
RigidityEnabled
again and experiment with balance torques! - Other small bug fixes for ControllerManager initialization.
Known Issues
- There are still issues with GroundController acceleration/deceleration, such as being able to continue accelerating by running back and forth.
- Certain stair configurations can still be a bit buggy.
Thanks again for feedback and keep it coming! This is the last update of the year, so see you next year!
Controller Beta Update - v0.2
Hello developers! I again want to thank everyone for their feedback and bug reports. It’s very important to us and we’ll continue to take everything into account so this system is perfect.
Here’s some changes that we enabled today that address some of your concerns:
- Deleting a Controller while running no longer results in crash
- Turning towards your FacingDirection now always rotates with the shortest distance rather than sometimes rotating over 180 degrees.
- GroundController now decelerates from your current speed rather than the top speed. This should address everyone’s running acceleration/deceleration concerns.
- The AirController.VectorForce value on the default JumpController should now better match the behavior with Humanoid.JumpPower.
- We still do not have support for configuring your jump height. As a workaround, you can view conversions between JumpPower and JumpHeight values based on your gravity setting from Game Settings > World.
- Increased internal friction limits so walking up very steep slopes is possible (like on the old controller)
- This unfortunately caused a new bug where tipping over from running into a wall is significantly easier. You can work around this by setting
RigidityEnabled = true
on the RunningController. Alternatively you can lower Friction.
- This unfortunately caused a new bug where tipping over from running into a wall is significantly easier. You can work around this by setting
Also, here’s a list of existing known issues and requests that are being worked on now:
- The aforementioned tipping over bug. We are also looking into how to make this more stable and customizable. This should also address issues
- Adding the ability to disable linear and angular momentum preservation in the air independently.
- Issues related to particular constraint combinations used in combination with the new controller.
- Fixing buggy stair climbing and swimming.
[/quote]
v0.1
Our first step in Humanoid Componentization (more info coming soon) begins with a new physics controller. We’ve rebuilt it from the ground up using the same internal objects and constraints that make up the rest of our physics engine. This should provide a more robust and physically accurate controller, open up more customization options, and simplify optimizations down the road.
Additionally, our goal is to fix outstanding bugs, eliminate mysterious extreme forces, and maintain the same feel as the legacy controller. This beta will give you a chance to experiment with the new controller and work with us to achieve this.
Key Behavior Changes:
-
Standing and ground movement are more collision-like. The force on the ground is equal to the weight of the character’s body when at rest, and movement is bounded by friction.
-
Air control when jumping conserves momentum by default for a better experience when jumping between moving Parts.
-
Climbing constrains you to the Parts you are climbing, meaning you will remain climbing on ladders that are moving.
How To Get Started:
THIS IS OUTDATED AND DOES NOT WORK
SEE RELEASE POST LINKED ABOVE FOR INFO
Enable the Beta Feature:
The new controller system is handled by several new instances. At the top of it all is the ControllerManager. This instance dictates which movement controller to activate, and what the characters desired velocities are.
Parenting a ControllerManager to a Humanoid will override the legacy controller and use our new movement controller. For now, there’s only one way to achieve this:
Parent a StarterHumanoid to StarterPlayer, then parent a ControllerManager to your Humanoid. Trying to insert the ControllerManager to a Humanoid at runtime will not work as expected.
Beyond the ControllerManager, we have four types of ControllerBase instances. They are all intended to live as children of a ControllerManager and do nothing elsewhere. These instances are the different movement modes your character can perform:
GroundController
Handles grounded movement along a BasePart floor.
AirController
Handles jumping and lateral movement/freefalling through the air.
ClimbController
Handles vertical movement up and down along a BasePart (ladder).
SwimController
Handles swimming movement in all directions.
For now, the ControllerManager will automatically create these ControllerBase instances and internally map them to Humanoid states. Controllers of the same type are given different names.
-
Freefall
→AirController
“AirController” -
Climbing
→ClimbController
“ClimbController” -
GettingUp
→GroundController
“GettingUpController” -
Jumping
→AirController
“JumpController” -
Running
andLanded
→GroundController
“RunningController” -
Swimming
→SwimController
“SwimController”
When following the steps above, your character’s Humanoid will look like this after loading into the world:
From here, you can select the different Controllers and edit their properties at runtime.
If you want to set the default properties the character will load with, you can insert a Controller of the correct type and matching name as the one above, and it will be used instead. This is just like the typical workflow of defining a StarterHumanoid.
What Now:
In this early beta version, customization beyond the default state-mapped controllers is limited. For now, we just want you to experiment. Some questions to think about:
- What significant inconsistencies have you found compared to the old controller?
- Do the default property values on the ControllerBase instances seem reasonable?
- Are there enough properties to tune the character movement to your liking?
- Was there a particular way you wanted to have the character move that you weren’t able to achieve?
In this early phase, the API is still fluid. We can make changes to names based on your feedback, and that is what we’ll focus on for now while still in beta.
Once we feel things are settled, we’ll exit the beta and allow you to use the new controller in live experiences. It will continue as an opt-in choice while we continue to work with developers on bringing it to everyone’s standard.
Once we’ve reached that point, this will fully replace the controller for all characters.
Known Issues:
- Crashes and general instabilities are still present. Use at your own risk.
- A couple of properties on the Controllers are not functional yet. While they exist in the API, they are hidden from the Properties window. We will announce when they are functional.
- Animations for deceleration aren’t correct, as they show you sliding (as if you had low friction). In the future, this will show you slowing the run animation.
- The default jump height is a bit higher than the old controller. We will fix this so it matches. For now, you can lower the JumpController.VectorForce to reduce the jump height.
- There are some other known minor inconsistencies with the legacy controller that we are aware of. We will use your feedback to judge their severity and focus on getting the new one to match.
Looking Ahead:
We have multiple planned updates that improve the flexibility of this new API. First, we will make the ActiveController property writable. This will let you choose what Controller to activate, whenever you want, for whatever reason. Then, we’ll open up the ability to use a ControllerManager on any Part/Model, not just a Humanoid.
FAQ:
FAQ
Thank you everyone that’s provided feedback so far! It’s very important to us to fit everyone’s needs, and everything from tiny nit-picky tweaks to fundamental changes will be considered.
For those that are excited but haven’t given it a shot yet, I want to encourage you to do so! I believe that by spending some time you can really get a totally unique movement style that can be really satisfying to play with.
Remember, this will eventually replace the existing controller , so the more feedback we can get now to fix things the better.
I’m now going to reply to all the feedback, questions, and requests so far. Some questions were asked by several developers, so I paraphrased them and tagged those that asked. If it looks like I skipped your question, it may be because it’s already answered by someone else or in the main post! Or if it seems like I may have skipped it by mistake or misunderstood, feel free to ask again. I may also reach out to some of you directly to get more details on a specific bug.
The performance should be about the same.
Another key difference with the new controller is that the underlying systems are the same as our Constraint system. That means in our physics step, there’s no longer a separate “Humanoid simulation” and an “everything else simulation”. So, as we make general performance improvements to our physics simulation, they will also impact the controllers.
Yes we are looking into this. Due to what I mentioned above, any general solution we have to simulation security will also apply the the controllers.
Short answer: yes. More news on this coming very soon.
Our first goal is to get this new controller to fully recreate our existing movement behavior. Once that’s done, we absolutely will start adding to the Controller instances to enable additional movement options (and if needed, add entirely new types).
The best way to give feedback on this now, would be to try and achieve the movement you want with what’s available now, then request a particular thing you want to adjust once you get stuck. I totally expect that there are ways to tune the current controller suite to achieve various vehicle-like movement.
Hover: I expect you should be able to use the GroundController to configure this. You can adjust the “GroundOffset” property in real time to adjust how far off the ground you are. We also plan to have other properties that will allow you to adjust how fast/how much force is used to tune how quickly that changes. (StandForce/StandSpeed may do this now, but aren’t working how we want right now and thus are hidden in the Explorer)
Flying: Yes, I’m thinking we can get the AirController to a place where you can comfortably enable full 3D movement through air with it, like swimming.
Climbing side-to-side: Yes, will also be adding this
Yep also agreed, I have mostly the same answer to your post as I do for above. Fixing things like Spacebar not working, and orientation glitches, the diagonal movement are the first priority. Then, we can start exploring how this controller can be made more flexible (control up/down speed separately, etc)
This is also planned! The current thinking is to start, we will add an UpDirection
property. Right now it’s always set to (0,1,0).
No, we are using the same floor/ladder detection as before. However, we are working on moving this to its own customizable system.
No, since moving parts this way has no velocity, there’s no momentum to conserve. There’s 2 ways to address this:
- Move parts physically, so they have velocity (ie PrismaticConstraint, AlignPosition)
- Set an AssemblyLinearVelocity on the anchored Part you’re CFraming/Tweening.
Agreed, I’m going to rethink how to handle jumping. Expect this API/Property to change.
Ah! That shouldn’t happen. Will fix.
I’m going to reach out about some of the bugs in your post. I want to explain this one here though:
This is happening because the MaxForce allowed for movement during FreeFall (AirController) is greater than gravity. So you can fix this by lowering the AirController.MoveMaxForce, and we probably want a lower default value for this.
Going to reach out for more info on the rest of your post, but wanted give some general tips on FallingDown and keeping upright
Right now, the FallingDown state is triggered when your character tilts past a certain angle (this will become customizable in the future)
With the new Controllers however, you can tune the “AlignTorque” and “AlignSpeed” on the GroundController that’s used to keep you upright. Right now, it’s a bit lower by default than before. This is so behaviors like getting smacked in the face with a beam look a bit more realistic. But you can adjust this so that you wobble around as much as you choose.
You can also use enable RigidityEnabled to really force you upright. The behavior of this should be identical to an AlignOrientation. You may notice that the “GettingUpController” (which is also a GroundController) has RigidityEnabled. This is so you always can get back up on your feet! But you can also disable this, forcing you to get up much slower if you choose.
Thanks for the feedback here. We will take the time to get it right, and I may reach out for more input later.