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.
You are missing the new input system package. Download it from the package manager.
is this where i should get it? if yes where is it?
I finally decided to try this new character controller asset - however I can't get it working.
I got an error after Unity was done opening the project:
Library\PackageCache\firstname.lastname@example.org\InputSystem\NativeInputRuntime.cs(129,50): error CS1593: Delegate 'NativeUpdateCallback' does not take 3 arguments
OS: Win10 Pro
Unity Version: Unity 2018.3.8f1 Personal
I downloaded the "Standard-Assets-Characters-master.zip" from Github as zip using "Clone or Download" button, so I assume I got the latest version.
- Project started automatically with "Input System 0.2.0-preview" it gave the mentioned error
- Tried "Input System 0.1.2-preview", I get the same error message
- didn't try/do anything
I've been using 2018.2 for a while, and decided to update to 2018.3 because of the potential remote access issue.
So - any Ideas what I could do?
Which version of Unity I should use?
Or did I download wrong package... or such.
Thanks @PhilSA for putting some of my concerns into proper words
I can't test this asset up until I finish hair shader stuff, But I'll be back with a flurry of feedback when I got this down.
You need to revert to Unity 2018.3.7f1 Personal
The Input System 0.2.0-preview needs an update in order to work with newer Unity versions.
Thank you for this information.
If this is the case, maybe I'll just wait until Unity gets things working - although I have no other reason to be in 2018.3.8f1 other than it was the easiest way to get a patch for supposed remote access vulnerability.
I'm a little confused, I used Unity a few years ago and remember importing the 3rd person character but this does not appear anymore. How do we now import the standard characters?
I think there is going on some sort of update to standard assets, but luckily these are still available from asset store:
This definitely needs to be addressed.
Is anyone working on this?
hey there, does this character controller support walking in a boucning ship that has riggidbody?
is it just me or nobody notice the weird sensitivity of the cinemachine camera control? like it's not responsive and there's a smoothing/easing on the camera rotation.
I think it does feel too damped/unresponsive, but it's probably tweakable (and also probably intented for gamepad; not mouse)
Generally I think a bit of damping feels good with a gamepad (BotW and Dark Souls have it, as far as I can remember), but with a mouse it really needs to be 1:1 frame-perfect responsiveness
EDIT: I was wrong. Even Dark Souls/Sekiro/etc don't even have any damping on gamepad
Thing is, i never get a good sensitivity using cinemachine. I Guess that's because i'm looking for 1:1 mouse response :/
Seems like a good use-case for a feature request. I'm sure lots of people are looking for that 1:1 response (and not just in the mouse, as was illustrated here.)
and i guess that request might be better for cinemachine team
will this(OpenCharacterController) port to new dots Unity Physics ?
It's not written for dots so the current github version won't work. It's not that difficult to port to but there are a few blocking things here so I really wouldn't expect it yet.
There's also https://forum.unity.com/threads/released-kinematic-character-controller.497979 which I own but don't use (I am using my own rigidbody solution). I checked it out though for comparison's sake and it's quite good. Author is interested in dots version.
It looks like the 0.2.1-preview package fixes this issue in 2018.3.8f1. I just updated it, restarted unity and no errors.
I would like to see character controllers be agnostic to the direction of gravity.
Hey all, just checking in - we're still working on the proper Cinemachine implementation, and we're reading your feedback notes regarding moving platforms - thanks for spotting this stuff! Appreciate all your help so far.
I tried to bring that up with the Cinemachine devs, but doesn't look like the feature was added so I ended up making my own camera controller (again). Here's the thread with my custom implementation included: https://forum.unity.com/threads/cin...-speed-for-axis-controls.548341/#post-3656842
The issue is not only the 1:1 linear velocity / smoothing, but the fact that the camera always uses a spline to move vertically, so its vertical speed changes depending on the part of the curve the camera is at right now. Which is bonkers honestly, as most games have linear speeds when moving a camera vertically.
Hmm that sucks, cinemachine are a good system to be honest. But doesn't have option for 1:1 sensitivity are annoying
Is there a way to completely disable the controller? Just disabling the components doesnt't work (as opposed to deleting them..) and in its current state, the CC seemingly overwrites the characters position when running a timeline (which prevents root motion movement in the timeline.)
@willgoldstone I like the controller the cameras still seem a bit clunky. the sliding down slope needs animations because it doesn't look great. other that that it seems a nice solid base.
2018.3.7f1 isn't available from the hub; wonder when 2018.3.14f1 compatibility will land?
Is this still be worked on? Not having much luck with the latest version of the Input System,
Just tried updating a Unity 2018.3 project to Unity 2019.1 and it seems like this package has a lot of problems with it. After updating the Cinemachine and InputSystem packages it relies on, I get 37 errors, many of which are because it can't find the InputAction namespace.
There haven't been any commits since March... is this package going to be developed further and supported in 2019?
edit: tried downgrading the InputSystem package to 0.1.2 which is what the 2018.3 version of the project was using and I get an error:
Library\PackageCache\email@example.com\InputSystem\NativeInputRuntime.cs(107,25): error CS1593: Delegate 'NativeUpdateCallback' does not take 3 arguments
Hey folks sorry for delays in updates, honest answer is we're delayed refreshing contracts with our external devs that work on this. I'm on it, and we should have fixes for the Input system and Camera issues soon. Sorry again!
Will this controller work based on rigidbody or ECS, or will be better performant in general or will be useless like the previous one?
With default character controller, empty map, plane, one default light source, and default camera, around 100 characters it's like 50-60fps max, 200 characters is 25fps max. In my opinion, performance is the key element in this case.
Any progress on this project, as it's been delayed by a year now, would be nice to hear about the schedule as well.
You've lost me a bit here - Are you asking if the current project is going to change to an ECS based one? no plans for that until we have shipped a fully fledged DOTS based Animation system. So no time soon - but that is in the works for sure.
Also what do you mean its been delayed by a year?! we have had to pause whilst we reallocate contracting budget but it hasn't been a year - not to say I'm not super appreciative of the feedback and patience of everyone here though! I know this isn't ideal.
I think the most important question is this controller is using default character controller, or is it rewritten controller based on rigidbody. I'm sure you are aware, that if you will make nice and shiny controller which will have some additional functionalities like sliding, etc. but it won't perform better than the present one, then I'm sorry, but imo it will be useless.
Try to run an empty scene with 200, or 500 characters on the scene, and tell me if you will be able to achieve playable 60fps, as you should.
Here is an example character controller vs rigidbody performance.
Character controller (500)
Of course, the character controller has a bit more functionalities like step offset, slope limit, but the difference in performance is huge.
I mentioned delay because in the first post you said
From my perspective, it's a delay, without getting into details much, I know there can be numerous factors which can affect a project and depend on the complexity, the controller can take a month, or year, but performance should be your priority in this case.
I also mentioned ECS, from curiosity, but we all know, that ECS won't be production ready for 1-2 years, but it's a huge element and it needs time.
Are you aware that it has been "shipped" in a preview state last December? Yes, delayed, but still.
@willgoldstone, maybe update the first post with the Github link?
Btw., I'm using this in production right now, and while the current project's needs are nothing out of the ordinary, the simple code structure made it really easy to remove unneeded features and put in new ones. Great work so far!
Yea released and almost production ready as far as I can see
I think that using a preview package in production is like a suicide.
What Unity are you using, because it's basically a mess, in the description, there is info about Unity 2018.2, but in the project files, there is Unity 2018.3.
Maybe I'm missing something...
I just think its absurd that if Unity is going to sub-contract the development of something potentially as core as this, which in and of itself seems like a bad idea, that they would then let some kind of contract negotiations drag out for months, halting all progress on the development.
How would a prototyping tool be "core functionality" by any stretch? You have countless alternatives in the mean time to prototype.
We're rolling with Unity updates for now, so we're on 2019.1f8 at this moment. This is in large parts because we're a small team and all know Unity to a point where we can quickly work around issues, and we're implementing most things ourselves and don't depend on the Asset Store that much this time around. Keeping all the things working is not that hard after I ported our render pipeline from 2018.3 to 2019.1. The project started on 2018.1.
And, well, we only used this character controller as the base for the stuff we need. So we "version locked" the character controller a few months ago and will not pull anything from the repo anymore unless there's some really interesting and useful stuff going on.
Competing engines seem to think their default character controller should allow their users to make non-prototype games without forcing the users to spend extra time and/or money. So 'core' as in 'essential'. Unity should be showing more urgent attention to the basic element underpinning a large percentage of 3d games. I've been using the github version in 2019.2 and the modifications needed to make it work were fairly minimal. I like it so far and agree that it seems nicely extensible. So the question is why hasn't there been any activity on github for months? My suggestion to Unity would be to treat this as a 'core' issue - pay top developers what you have to pay them to get this done well and quickly! If contract negotiations are dragging on for so long then perhaps consider offering higher salaries?
TL;DR I wish I could get a refund for all the money I've wasted on half-baked solutions from the asset store and donate it all towards Unity's budget for the contract.
You can get rid of most of those errors by changing UnityEngine.Experimental.Input to UnityEngine.InputSystem. InputActionAssetReference becomes InputActionReference, cancelled becomes canceled and then a few bits need to be deleted it and, aside from that, just a couple of other minor tweaks are needed I think. That's to make it work with the latest version of the preview Input System.
I'm shocked and amazed that this work was being done by contractors. It's not as if you guys are hurting for money and can't afford a few guys to permanently work on improving all the standard assets. I'd actually prefer it if Unity would just say use the asset store rather than this kind of thing that can get abandoned at any point without warning.
To be fair, any asset on the Asset Store can be abandoned at any time.
Unity just makes it a huge pain to get on the asset store, so devs who bother jumping through all the hoops tend to stick around (mostly) because the high barrier-to-entry keeps competition down (which is good for authors, but kinda bad for customers). Unity definitely sticks it to the devs on the store a lot though -- 30% cut of every sale just to be listed -- and many people are getting fed up with it.
Whether they use contractors or not, I think the concern shouldn't be that a contractor might abandon the packages -- Instead, the concern should be whether UNITY decides to task someone with upkeeping those packages.
While I definitely think a good character controller should be supported by Unity officially, having a team of contractors as a go-to once and a while isn't a terrible thought. At the end of the day, Unity takes on the burden of a bad product if they hire crackpots. It might be good to have a little outside blood coursing through the veins of Unity every once and a while. I suspect we might get better, longer-lasting approaches out of this setup -- which, in my opinion, is what we need.
Besides, the only reason an asset needs a developer to support it is because the asset doesn't fit everyone's needs as-is. After making a solid asset with good documentation, support could easily consist of bringing on a team of contractors at regular intervals (say, every 3 months) to check/fix bugs, add in features, etc. for a week or two.
Seems to work really well for Blender so far.
I can't say I've found it much hassle to get on the asset store, but I do agree 30% is too much. To me, at the moment at least, an asset store dev has a much better incentive to maintain a project like this. For example, the guy who made Bakery is going to make a lot of money for the next couple of years while Unity sorts out its GI solution. On the hand, Unity didn't make any progress with their terrain tools for years and it didn't seem to bother them. I think the contractor set up you describe could work, but for this project I wouldn't be surprised if there are no more updates.
Hi this projet still in progress ?
we can see youtube in action ?
somethink's move !
Apologies for the longer than desired period of inactivity on updates to the SAC Beta. Yesterday we pushed an update to the master branch of the repository with the following additions:
Up to date support for Unity 2019.1, Cinemachine 2.3.3, InputSystem 0.2.10-preview, and PostProcessing 2.1.4
Updated Cinemachine camera settings for the Third Person Characters
A big fix to how the mouse axis input accumulation and processing is done
Please pull it down and give any feedback that you have regarding it!
While here, I'd like to address one of the major recent points of discussion in the thread, which seems to be regarding how the updating of the character is handled and various members running into issues / unexpected results, etc.
All updates for the character movement and animation, cameras, and moving platforms are purposefully done in the Fixed / Physics Timestep as they involve physics interactions and collisions. This is the best practice approach that was decided upon to demonstrate here. However, if your needs require these to be in the Update Loop, you can totally make those changes yourself. The key thing to keep in mind is that that *ALL* object updates (character, animations, camera, platform, etc.) MUST be updated in the same Timestep, or you will run into issues of jittery characters / cameras / collisions as the updates phase in and out of sync. This is fully expected behaviour when updating objects that interact with each other across different Timesteps.
There also appears to be a lot of confusion or assumptions made as to what this new Standard Assets Characters package is meant to be. SAC was designed to be a package that you can drop into any project that you are working on and easily get a First or Third Person character up and running with input and various default animations. It was designed to make it easier for game makers to prototype their worlds and gameplay without having to engage in out-of-the-box customisation for the average user, and was built with the understanding that confident developers could still dig in and easily modify the systems where required in order to create a controller system that would meet their needs, should the defaults not be sufficient for them.
We want SAC to be useful to everyone and to help everyone make their games great, and in order to achieve this we are listening to everyone's feedback and will look to improve the product as it fits with the overall direction; don't forget, it is in Beta still!
However, making an out of the box character controller that will meet the needs of everyone and can be used to ship any sort of character based game under the sun is not the goal of SAC.
Please keep the questions and feedback coming; it is all welcome and helpful in shaping SAC going forward
We're not sure actually... it's not something that has been specifically tested but in theory it should work! Try the SimpleMovingPlatforms demo scene with all of the different sorts of moving platforms there to see the behaviour as it is and let us know if you are having any issues
A bug was just now fixed regarding how the camera look axis was being processed for mouse input. Please have a look when you can and see if it's better compared to what you were experiencing; we'd love to hear your feedback on how it behaves now
Additionally, we have now added separate Mouse Sensitivity and Controller Sensitivity values to the FirstPersonInput and ThirdPersonInput components to help tweak this more.
We're not sure what you mean by this exactly... could be explain the behaviour that you are looking for here please?
We'd like to look into this as your use-case seems to be a really good one that the Character Controller should support. Is there any way that you can send through a simple project that does what you are trying to do and we can use it to to investigate and get back to you?
Thanks! Your experience is exactly what we are going for with the design of SAC
Is this on master branch?
Yes it is. Please note that we will likely be adding separate X and Y sensitivity shortly. It is a single value currently however.