I’ve got a WIP character controller character controller that I wanted to share, it might need some work/cleanup, but it is the best thing that I have been able to produce so far that can walk up and down hills without speeding up, slowing down or jittering along the floor. It also lets you set a maximum slope that the player can walk up ( but it needs a little bit of work ). It probably needs Armory 0.6 to work right.
Thanks to @zaethan and everybody else from my math question post. The vector project math was used in the controller .
Sweet! Once it’s ready we could bundle this into Armory, provided you would be ok with that. Those old rusty ones that are bundled now should have been replaced long time ago…
@zicklag Amazing work! thanks for sharing this, I will borrow the portion of code that sticks player to ground to use it in my game, thank god I don’t have to reinvent the wheel to do this
Awesome! I couldn’t belive that I couldn’t find any great Bullet examples when I tried to implement the controller ( I really only searched the Bullet forums, but still ). I had tried a whole bunch of different strategies before it seemed like this one worked. There are so many strange problems you run into when trying to do a basic character controller ( you should have seen when his head would stick to the ceiling when he jumped into it ).
I’m so glad that my example is helping somebody else out!
Hey!
I could really use a character controller,
but TBH I don’t know how to set this up.
Any help appreciated!
Here’s the error after I apply the script to the character as a(n) Haxe trait:
Invalid commandline class : arm.CharacterController should be player.CharacterController
Haxe compiler error.
Finished in 1.963179111480713
Build failed, check console
Is there any output in the console? I just ran a quick test with it, and I realized that the name of the class on line 12 was CharacterController2 not CharacterController. It doesn’t really matter what it is, but it needs to be the same as the name of the file, otherwise it will not apply the trait. That might be your issue.
BTW, something I forgot to mention, the controller actually only takes care of the walking movement of the character not counting rotation. The rotation of the character isn’t handled in the script because I had a simple node tree that would rotate the object according to mouse movement so that you could look around. It would be good to build all of the camera and rotation logic into this script eventually, I just haven’t had the time.
That’s just to keep people from spamming the thread with super short posts like smileys or 's when liking is more appropriate. The software has some restrictions like that that seem weird or overdone sometimes, but it does tend to help keep threads readable and productive, I think.
I’m just having trouble getting to appear in the add node list? I’ve added the uncompressed 'charactercontroller2.hx script into my ArmorySDK and also a library in the same folder as the blend files.
I’ve even tried changing the package to Armory in the script. Could you possibly help?
Hey @LeeMo, the reason you are having trouble getting this to pop up as a node is because it isn’t a node!
I just update the gist so the package is arm like it should be. After that change, you should be able to put it in your Sources/arm folder and then add it as a Haxe trait to your player object.
Even though it is a Haxe trait, you don’t need to write any Haxe to use it. You should just be able to apply it to your character and be able to move.
Now the script as it is kind of needs some extra logic nodes to make it fully controllable because the script has nothing to control the camera. Here is the node tree that I used to do that:
Tell me if you need any more reference for that. Essentially you just have to manage rotating the character and moving the camera yourself with nodes, while the character movement is handled by the player script.
.
Those old rusty ones that are bundled now should have been replaced long time ago…
).
's when liking is more appropriate. The software has some restrictions like that that seem weird or overdone sometimes, but it does tend to help keep threads readable and productive, I think. 
