A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Editor & General Support' started by willgoldstone, Apr 13, 2018.
Weren't just talking about mecanim's little brother kinematica? Ie motion matching with ML?
No. They demo'd a multiplayer game with the controller. Not Kinematica. But you know better than to wait for Unity's motion matching solution @neoshaman ! Try this absolutely awesome asset instead: MXM motion-matching-for-unity . That's the asset I've been integrating with this beta SAC controller. Working well so far but I'm worried Unity will pull the rug out from under me by ditching this controller or breaking things some other way. I'd love to avoid using 2019.3 & URP but as I'm a solo developer not working to a deadline, I don't want to be in a situation where all the work I've done is rendered useless via deprecation.
/// Note: The capsule is always upright. It ignores rotation.
This is not cool, it's a big limitation of the old character controller. Being able to rotate it is an important feature to implement mechanics like the physics in Super Mario Galaxy, where the gravity and player rotation changes depending on the planet/platform shape. Other example is any Sonic game, where you're able to follow the ground normal and run through loops with full 360º character rotation. It's true that I still able to code my own controller for those situations, but if you guys pretend to implement a better solution for the older character controller, then make it really better! The capsule being always upright is an awful limitation.
Here you can see a kinematic character controller that is able to match it's rotation to the surface normal:
After struggling with the old 3rd person character controller I found this thread and the new SAC. Looks great! It solved my problem of having the character step at a target every time.
But.... after I tried this in a separate project I decided to copy it to my own project. Got compile errors because Cinemachine and InputSystem were not installed. Installed Cinemachine and then InputSystem (I think I chose the same version as in the Github project, version 1.0.0 preview, not the preview.1 version). Then I got a message about upgrading native backend, which required a restart of the editor. Clicked yes and the editor closed.
And then my project won't open anymore. Unity 2019.2.6 start, I get a message Compiling Assembly Definition Files scripts and then the editor crashes.
I tried restarting the editor and then restarting the PC, no effect. Tried removing the inputsystem line from the manifest.json in the Packages folder, but that also made no difference.
Decided to go all the way back and delete the _StandardAssets folder and the cinemachine line ffrom the manifest. Now I could open the project again, thankfully.
Tried to do it in a different order, first import Cinemachine, but already at that step the editor crashed again. After I removed the cinemachine line again from the manifest and reopened the project it started recompiling pretty much everything!
Please help. How can I include this new SAC in my own project?
@joostbos It's promising but you should know that Unity doesn't consider this package to be ready for "preview" status and at the same time there have been no commits on GitHub in a month (and very few before that). But report your issues in GitHub anyway and see how you go. Otherwise... consider a more feature complete third party solution, one that is regularly being updated. This one we've been told is only intended for prototyping and hence shouldn't see basic features like swimming or climbing added anytime in the foreseeable future. Saying this with some degree of regret.
@transat Thanks. Yes, I noticed that this seems to be dying out, unfortunately. I'll report the issue anyway.
And I was able to fix my problem with the old character controller. The reason it was not consistent was because it was messing with rigidbody verlocity. When I changed that to simply move the object using its transform the character steps at the same spot every time.
I may have encountered the same on Windows now, on 2019.2.8 with Input System 1.0.0 preview 2. Had to switch from Both to only use the new system, and input to FPS controller from this project started working.
How should I modify the keyboard input bindings?
I would like to add the arrow keys to work for FPS control, in addition to WASD.
I read CharacterInput : MonoBehaviour, StandardControls.IMovementActions and saw how it says m_StandardControls = new StandardControls();
// GENERATED AUTOMATICALLY FROM 'Assets/_Standard Assets/Characters/Scriptable Objects/Control Map/StandardControls.inputactions'
But that file does not exist.
I tried to modify the JSON there directly, but changes there did not have any effect. So am left clueless so far.
Hey everyone sorry for radio silence! So we've finally found a proper home for this project with the Education Content team based in the UK - who are planning to take it more in-house. I'll be passing comms over to their team to tell you more about where the project is going and updates to what we have so far. I'm hopeful they can share some updates with you next week about where they plan to take it.
@willgoldstone I'm not sure if I should be happy or pissed off about this. Unity is like the Trump of tech... you desensitise your users through repeated mismanagement! So when a new flop happens, what used to be frustration now becomes "oh, this is just Unity being Unity."
Question for you: does this asset relate to the announcement made at the last Unite about an exciting new character controller with lots of bells and whistles that would be made available soon? ie. Is this it? Surely not, as this asset has gotten 2 commits in the past 6 months! Can you then confirm that there is another character controller in the pipeline, one that will indeed be released soon? I'd appreciate an honest answer here because I feel I've been taken for enough of a ride this time.
let me make a guess, "exciting new character controller" would be the upgrade/animated version of DOTS-sample's use case , but i doubt it's versatile and stable
We should crowd source one like the UMA group
Though I'm looking at GKC now and the developer is so responsive to feedback I'd say it's virtually crowd sourced.
it's also way beyond a simple character controller
If you are looking to add or modify bindings for actions, you wont need to edit any JSON manually.
Find the 'StandardControls' InputAction asset in your project view, and double click it. The Input Action window will open, and you can simply add or change the bindings for a given action.
So, open the Input Action asset, next to the move Action, click the + button, select "Add 2D Vector Composite", a new field will appear under the move action, it will look like the existing WASD binding. Now, you can just add key bindings for the Up, Down, Left and Right parts of the 2D composite vector.
Hope that helps, for more on this, see the New Input System Docs. https://docs.unity3d.com/Packages/c...ActionAssets.html#editing-input-action-assets
@willgoldstone Are we due to hear from the Education Team? Or is it back to radio silence?
I'll still recommend Kinematic Character Controller for those who can actually program (it's not code-free but it is easy).
Radio Silence you say? how about no! Here's Peter..
Hi all, I’m Peter, for those who don’t know me - I’m Creative Director for our Learn content at Unity!
As Will has mentioned already, we’ll be taking the New Standard Assets project under our wing going forwards.
Recently we’ve asked you how you’re using the product and what we can do to make them better going forward. If you haven’t had your say and would like to, please find the survey we’re conducting here.
For a long time now we’ve been painfully aware of issues with the old Standard Assets, such as:
Outdated implementation (some of this stuff dates back to Unity 4!)
One huge mega-project with a web of confusing dependencies
No support for modern Unity features (packages like Input, SRP, etc)
Huge amounts of maintenance with little time for new features
This was especially bad for the long period when they shipped with the installer as we had to submit changes and fixes for every mainline change to the Editor
Some of the content is incredibly niche
Not modular or reusable enough for prototyping or beginners to use
We’ve already replaced many parts of it with things like the Particle Pack, Cinemachine, and the New Input system.
So, on to our plans for the future! We’re going to do a complete rework of the old Standard Assets, using modern Unity features and approaches:
We want to break up Standard Assets into individual products (this is based on what was previously most-used from our data gathering efforts)
1st Person Controller
3rd Person Controller
3rd Person click-to-move Controller
2D Controller (this may be a platformer and a top-down but not set in stone yet)
Unify the code and architecture approaches for each product, so that once you have a good handle on one, you should understand how the others work
Deliver these as separate packages through the Package Manager
This allows us to handle dependencies much more easily (the right version of Input Manager, Cinemachine for each Unity version, etc, and no crazy cross-platform input shenanigans)
Rework each Controller and provide editor tooling for common tasks
UX for the controllers should be simple, tune-able and easy to understand
We want to provide tools should help users swap out character meshes, etc
Provide Documentation and Tutorials
Tutorials or docs on how to extend or modify the controllers
Tutorials on how to easily add controllers to your own projects
Deprecating or finding a new home for some of the old, niche parts of Standard Assets
We’ve already created new Particle Packs to replace the old Standard Assets particles
Older assets, like Legacy Image Effects or Nature Shaders are either already deprecated or put on the Asset Store
But Wait! Didn’t we already do this?
Right now we’re heavily reviewing the approach we want to take to unify the new Standards Assets and respond to the feedback we’ve had so far. We’re also going to update the current GitHub version of Standard Assets Characters up to Unity 2019.4LTS whilst my team handles the migration of the project.
We’re looking to start production on new packages in the new year and have our amazing team of programmers, artists, instructional designers, and QA handling these going forward. We’ll keep you updated in this thread once we have some more to share during development!
Any questions, please feel free to reply here and I’ll do my best to answer.
While it's not my personal use case, I wonder how it will address the most demanded feature I spot, that is sprinting, swimming and climbing, on top there is borderline gameplay ideas (ie they are contextual to a project sadly) like melee and shooting. I did say address, not implement it's just that people keep asking for that in any controller thread. I feel like climbing is a big one but it's also the "generic" one that is also part of the borderline.
For people interested in eventually rolling your own:
cat like coding has started a promising tutorial, the part on surface contact really go in depth in stuff beginner overlook.
I think it's a great move.
Sometimes you get a lot of content by Unity, but are thought as whole frameworks and sometimes conflicting with each other.
I think that having the basics of a robust and tuneable controller is a must, and you can expand the scope via add-ons / examples (instead of having many full projects).
I didn’t want to risk using a third party asset because the developer could suddenly disappear and abandon their project. Well I think this is now the 3rd time Unity had done just that to this package. And your generic response, which barely addresses anything from the long thread it was posted in, tells me I’m right to look elsewhere. Rather than telling us when you’re hoping to start work, by this stage I wanted to hear when you’re hoping to have the previously promised work finished. Disappointed.
I did the survey and it’s not about the package in this thread at all. It seems more like a PR exercise to tell your users that you have decided to start next year what your users thought you had already been working on for the past 2 years. The survey should have restricted itself to the 1st and 3rd person character controller and should have been asking about the basic functionality we expect from Unity’s version. What I expect is a super solid foundation that taps into all of Unity’s new features... DOTS, rigging, physics, AI, etc. One with all the basics such as climbing and swimming. But something users can build upon rather than a simple prototyping solution.
One survey question asks use what they would use this asset for. Options include prototyping, learning and a couple of others. There is not option that says “I want to use this to make an actual game”. Please make it clearer. I suggest the following warning: ”When we finally build this thing, it will not be a controller you would ever want to use for a shipping game but only something to be used for the very early mockup stages. So bare in mind that this is only to be used for super basic character movement of the kind you can get with any other controller because any game-play related features will have to be redone. Also please note that any advantage we can provide by integrating with DOTS will be lost as soon as you switch out to a non-prototype asset.”
Unity 2019.1 github repository should be made too
OK, so I just found out that this thing exists, completely randomly, because people were talking about it. WTF? Why do I need to yet again find that some official feature is on GitHub? What's the point of this package manager nonsense if you're not even putting your own stuff up there as preview packages?
You should be happy you did not find this earlier. I did, and have waited since... ever.
Don't think it's a good idea to wait any longer. If your can not create you're own, buy one instead. If you know how to program, buy Kinematic Character Controler, KCC.
Although this thing seems to be dead or whatever, after checking the github, it is like the c# source for the unity character controller. Which is a good thing to learn from and know the missing pieces.
So, thanks for the effort.
The only catch with using UPM for something like this is bloat. If all I want is the very minimal base character controller, there should be a package for just that. One script. No dependencies on camera scripts or fancy input systems needed.
I want to second this -- the surface contact stuff is a great gem!
I guess we won't get the "Zelda: Breath of the Wild" or "Super Mario 64 / Overgrowth" styled character controller we were all hoping for from Unity. Maybe if somebody at least makes a decent enough (configurable) character controller from that information that handles stuff like wall-kicks, swimming and climbing, they might be nice enough to share it freely.
I see where you're going with this, but a package just for one script is not ideal. Maybe a package with 5 different (clean) character controllers that could be used (or given the option to simply not import them) would be much better for usability purposes.
No dependencies of course (except for maybe the better Input System), but the camera and post-processing dependencies should definitely be nixed.
We should pull a UMA and do some community asset, like a custom controller and a custm srp, as alternative to unity's solution, since they don't make games...
Am I to understand that there is no standard asset package for unity 2019.3!
That renders the program completely useless for the vast majority of users that I have talked to.
Is this the beginning of the end of unity?
Not really, there's still the pretty strong point of 0% royalties compared to something like UE4 or CryEngine.
Part of what makes Unity so popular is that it was easy to use. Now it is taking steps backwards and becoming more difficult and time-consuming and requires specialized knowledge. It is easy to tell someone "Go learn the knowledge". It is another thing altogether take the months or years it takes to learn it. Unity will stop being a top choice. Not having a standard assets package is a very very bad idea.
They probably will have a standard asset, just not the botw 64 base controller people think they would have. Making a solid but generic controller is hard, and they probably didn't understand the commitment needed for that when asking what we wanted. And we expected something beyond simple prototyping.
Expectations of both side simply didn't met.
I am all for the way it was before. Just a generic 3rd person controller.
Radio silence since dec 13...
Wrong frequency? Ha.
The sad thing is that this asset had promise despite it's over-complicated UX and 200 console warnings. It just needed someone/some team to be improving it weekly based on feedback rather than leaving us guessing as to its future. I'm sure UT will learn lessons past with this reboot though, and communicate more frequently once they've come up with a plan.
At this stage, if this is going to be just for prototyping and not the BOTW controller of our dreams, then I'm leaning towards what @incenseman said: keep it as simple as possible. I'm assuming this is why it's now with the Education team? So please make this a very basic foundation of what a pure DOTS character controller could do and how it could integrate with other DOTS packages such as physics, rigging, AI, etc. In other words, it should be designed to be hot-swappable with other 3rd party DOTS controllers (when they arrive) by providing a common framework / interface that can be used for other assets. It should provide something for other asset developers to build on top of or extend if flexible enough.
Right now, integrations between packages are a pain for users and developers. Ideally, all these different controllers should talk to 3-6 UT provided scriptable objects. ie. I want to be able to switch one controller for another and not lose my existing design choices for stuff that should be common to all character controllers... the fact that my character slides on slopes greater than X percent, is affected by gravity, can jump, can double-jump, can swim/climb/vault, orients towards the camera, is grounded, has headlook, etc. Many of the settings that this asset had but in a re-usable scriptable object, essentially. With this asset, it was very hard to replace a component due to all the hard dependencies.
Speaking of 3rd party solutions... I'm keeping an eye on this one...
...as UT dashed my hopes they were going to hire @PhilSA, its developer, pay him big bucks, and get him to lead the charge on this project. So now I just want DOTS to be stable enough for Phil to come up with the extensible (or complete!) solution of our dreams. It can take time to build trust and Phil definitely has that from his users.
That part of the video where it
shows that by the way it's a lot of characters at the same time
is pretty cool
Now the Dots sample is out, has anyone checked out the character controller?
@Shizola the DOTS sample is HDRP only as far as I know. And from what I’ve read in that thread, it’s not intuitive and there are no docs to explain how the controller works. I’d definitely want to check it out if they make a stand-alone one that works in URP.
I just want a character controller that can handle slopes, ground check, an arbitrary up direction and what not, packaged with Unity. The OG CharacterController is too unreliable, and the OpenCharacterController isn't much better really, breaks all the time.
I don't care for whatever character movement they have like swimming or climbing, I do all that stuff by myself anyway. I just want reliable collision.
@PhilSA's is one of the only two character controller artisans left, a dying breed, and thus deserves a lot of credit. His KCC seems like it does almost exactly what I want. But this stuff REALLY shouldn't be relied on by asset developers - though I could say that about a metric ton of features (baking, input, splines, level design, etc).
Unity devs often come around and say, "oh, we'll get that done in a couple of years if you're lucky." I get things take time - I really do. But I don't want to make great games in 3 years when all this stuff is relatively stable, I want to make great games NOW. And Unity actively makes this difficult for me.
I'm not a professional. I make games for fun. Yet even someone of my amateur caliber can recognize your deep running faults. Industry professionals incredibly smarter than me have no excuses.
If any of the devs are reading this, I don't mean contempt this against you personally. But you guys understand where we're coming from.
Blegh. Rant over.