░░░░░ Kinematic 2D (v2.4.1) ░░░░░

I try to instantiate some prefab at the location where the character lands after a jump. For this I try to use CharacterEvent OnGroundCollision. However the transform.position in the callback function is not always the same y-location for some reason. So I tried characterMotor.GroundContactPoint instead. This always report 0,0,0 .

What to do?

 

Hi Eric!

Regarding the inputs my custom implementation in K2D relies on the Unity's input system, using GetAxisRaw, GetButton, GetButtonDown, etc. In your case you'll need to detect the touch event and send the input signals to the "brain" component (instead of letting the Update do its thing). These signals must change the "characterAction" struct state in order to create movement. In my case i'm doing this using the Update method, in your case you will need to first remove the Update method, then change the struct fields values directly (right, left, jump, etc), maybe by creating a bunch of public methods (i know a pain in the a$$) so you can trigger them from an typical Event trigger. In the next release i will include a Mask (big int number) to represent the inputs actions, this way you can easily call one public method, selecting the input and the state.

Is there a ground tag included in your package? I'm not sure if I understand you correctly, in my scenes the ground and any other static obstacle have the "Static Obstacle" layer assigned to it, same for the rest. I think the only tag that matters is the wall sliding ability tag (i could be wrong).

OK I will change that in the next release, it makes sense.

Thanks Eric!

 

Sorry I missed this post .... Could you please post the code you are using?

If you add the "CharacterDebug_Info" component to the character you will see all the information on screen, in my case the Ground contact point is working fine.

 

To supply touchpad input for the mobile version of my game I use Joystick Pack from https://assetstore.unity.com/packages/tools/input-management/joystick-pack-107631

The code below is what I use to inject the inputs for that into Kinematic2D. I added this component just above CharacterHybridBrain (on Roboto).

Code (CSharp):

1. using UnityEngine;
2. using Lightbug.Kinematic2D.Implementation;
3.  
4. public class CharacterBrainTouchpadInput : MonoBehaviour
5. {
6.     private CharacterHybridBrain brain;
7.     private bool jumpButtonWasDown;
8.  
9.     void Awake()
10.     {
11.         brain = GetComponent<CharacterHybridBrain>();
12.         jumpButtonWasDown = false;
13.     }
14.  
15.     void Update()
16.     {
17.         Vector2 dir = UIController.instance.joystick.Direction;
18.  
19.         CharacterActionInfo characterAction = brain.CharacterAction;
20.  
21.         characterAction.right |= dir.x > 0;
22.         characterAction.left |= dir.x < 0;
23.         characterAction.up |= dir.y > 0;
24.         characterAction.down |= dir.y < 0;
25.  
26.         bool jumpButtonIsDown = dir.y > 0;
27.         characterAction.jumpPressed |= jumpButtonIsDown && !jumpButtonWasDown; // Conflicts with up! Don't worry for now. (up seems unused anyway)
28.         characterAction.jumpReleased |= !jumpButtonIsDown && jumpButtonWasDown; // make sure to report only once (similar to GetButtonUp(...) in CharacterHybridBrain.cs)
29.         jumpButtonWasDown = jumpButtonIsDown;
30.  
31.         // TODO:
32.         //      dashPressed
33.         //      dashReleased
34.         //      jetPack
35.  
36.         brain.SetAction(characterAction);
37.     }
38. }
39.  

 

2.3.0

Added:

- Events for all the Character’s abilities (implementation):

OnEnterMovementArea, OnExitMovementArea
OnCornerAlignmentPerformed
OnDashPerformed
OnJumpDownPerformed
OnCancelJump , OnJumpPerformed, OnGroundedJumpPerformed, OnNotGroundedJumpPerformed
OnWallAlignmentPerformed
OnWallJumpPerformed
OnWallSlideEnter, OnWallSlideExit
OnCrouchStart, OnCrouchEnd

- Added a resetAirJumps toggle to the WallSlide ability.
- The VerticalMovementProfile introduces a descendingGravityMultiplier field.
- A new Walkthrough scene demonstrating the descendingGravityMultiplier effect.
- Added DynamicGroundDisplacement and DynamicGroundVelocity getters.
- Added Position, Rotation, Forward, Up and Right getters directly inside the CharacterMotor component (now you can call characterMotor.Position instead of characterController2D.CharacterBody.bodyTransform.Position ).
- Added “Roboto 3D-ish” Character, a 3D compatible character using Roboto sprites (so, not real 3D yet).
- Added a useWallSlideTag toggle. This allows you to choose if you want the character to consider a certain tag, otherwise it will do the wall slide action on every valid surface (same if the wallSlideTag string is empty).


Fixes:

- A JumpDown ability bug, when the platform was moving up the character couldn’t jump down from it.
- Removed some unnecessary lines of code from the CharacterHybridBrain component (... “if(Input.getKeyDown(KeyCode.L))” … ).


Changes:

- The CharacterController2D component now updates the DynamicGroundMovement before processing the abilities (previously this was done in the CharacterMotor after all the abilities). This allows the abilities to work with the accurate final position (affected by the dynamic ground movement).
- The walkDuration field (in the HorizontalMovementProfile) has been replaced for startDuration and stopDuration.
- The 3D scene now uses Roboto 3D-ish as the main character.
- The characterAnimation field (from CharacterController2D) now is a Serialized field (showed in the inspector), this means that the CharacterAnimation component needs to be assigned (drag & drop), so, you can have your animated character anywhere you want (not necessarily as a child of the character).
- A TimeScale of 0 won’t trigger the character actions (CharacterHybridBrain and CharacterHumanBrain components).


Notice that the movement data (horizontal and vertical) introduces some new stuffs, this might corrupt your custom movement data (scriptable objects), please backup your files, just in case.

 

Really awesome and great work!

 

Great stuff. This reduces the amount of work I needed to do in a customized version a lot. Will give it a go next week.

 

2.4.0 wishlist

• WallSlide.cs rename
  • OnWallSlideEnter -> OnWallSlideStart
  • OnWallSlideExit -> OnWallSlideEnd
  • OnJetPackStarted -> OnJetPackStart
  • OnJetPackStopped -> OnJetPackEnd
• CharacterAnimation.cs (?) add
  • OnSlopeSlideStart
  • OnSlopeSlideEnd
• CharacterController2D.cs:96 add
  • if (characterAnimation == null)
    • characterAnimation = GetComponentInChildren<CharacterAnimation>();
• Documentation changelog add
  • OnJetPackStart
  • OnJetPackEnd
  • OnSlopeSlideStart (todo)
  • OnSlopeSlideEnd (todo)
• hopefully a fix for this
• Assets/Kinematic2D/Core/Scripts/CharacterMotor.cs(2050,14): error CS0117: 'Utilities' does not contain a definition for 'DrawArrowHead' # (this is on WebGL export)
  
• • I find no way to get the correct point of impact during OnGroundCollision
    • transform.position is not updated yet
    • characterMotor.GroundContactPoint is always 0,0,0
• Questions:
  • Why can I initially (your prefab) move and after some changes to Roboto not push a rigidbody?? (after changing character_roboto from 0.42 -> 1.0 ?)
  • could you please give an example of Roboto push/pull/pickup rigidbodies in the world?
• Add OnFootstep events to CharacterRoboto_Walk animation
  • Add This PlayerEvents.cs to Character_Roboto (or add to one of the scripts already there)
    • using UnityEngine;
    • using Lightbug.Kinematic2D.Core;
    • using Lightbug.Kinematic2D.Implementation;
    • public class PlayerEvents : MonoBehaviour
    • {
      • private PlayerDelegateHandling playerDelegateHandling;
      • void Start()
      • {
        • playerDelegateHandling = GetComponentInParent<PlayerDelegateHandling>();
        • // Debug.Log(playerDelegateHandling);
      • }
      • void OnFootstep()
      • {
        • // Debug.Log("PlayerEvents.OnFootstep by " + gameObject.name + " @" + transform.position);
        • playerDelegateHandling.OnFootstep();
      • }
    • }
  • And propagate in a function on the parent (in my case in PlayerDelageHandling.cs on Roboto)
    • public void OnFootstep()
    • {
      • // Debug.Log("PlayerDelegateHandling.OnFootstep by " + gameObject.name + " @" + transform.position);
      • float groundBlend = animator.GetFloat(groundBlendName);
      • // Debug.Log("groundBend " + groundBlend);
      • if (groundBlend < 0.5) return; //this function got called while we were (mostly) on the Idle animation (of the blendtree) instead
      • StartEffect(footstepSFXGroup, footstepPrefab);
    • }
  • to make this cleaner I would actually suggest you emit the OnFootstep from HorizontalMovement.cs (like OnEnterMovementArea). The OnFootstep animation event might best be added CharacterAnimation.cs .

 

Hi @ericvrp , ok i will consider all your suggestions for the next release, thank you.

I'm really sorry about this problem, i noticed this right after uploading the package (recently when i was updating the online demo). This is caused because I was testing the Handles (instead of the gizmos) and in the way i forgot to revert the changles, a mix between Handles and Gizmos *facepalm* ...

Here is the solution: (CharacterMotor.cs , OnDrawGizmos method(at line 2036)
--> Replace the Utilities.DrawArrowHead for Utilities.DrawArrowGizmo

Sorry I don't understand those numbers, what would the "0.42 -> 1.0" be?

It depends on the method, i don't like to push rigidbodies simply by walking directly towards them (by this i mean using the normal state). Instead, I like to push the RB by entering a push/pull state, this has nothing to do with the character motor component, so you can do the following:

1 - check if your custom action is performed (for example if X key is being pressed ).
2 - check if the character is grounded.
3 - check if the left/right flag is true.
4 - check if the collided gameObject is a valid rigidbody.
5 - Push/Pull the RB, in order to do that you need to change its position in a Physics-compatible way (Force/Velocity/MovePosition)

This is only one way to do it, the other way is to modify the motor, detect an horizontal collision (MoveHorizontallyOnGround) and depenetrate both character and rigidboy (based on mass, force applied, etc). I will try to include some more events for the Character motor to allow this kind of behaviours.

 

Is there a reason you want to change it from Started to Start besides preference? In my opinion Start and Started have to different meanings and aren't necessarily the same operation.

 

For me the reason would be consistency. In this case they look identical enough to me.

But English is not my first language so I might not get some nuances and could be wrong.

 

> Sorry I don't understand those numbers, what would the "0.42 -> 1.0" be?

I can't reproduce this. What I saw happening is the Roboto can easily push a rigidbody with boxcollider through the scene. Then I changed the Roboto Graphics from 0.42 (scale of first child of Roboto prefab) to 1.0 and the pushing of the gameobject was still possible but 100x slower.

I thought it had to do with auto computed mass on the rigidbody or something like that. But since your code uses no AddForce my current theory is that the other gameobject with rigidbody slowly moves is because Roboto ends up inside the gameobject before depenetration code is run. And this seems to have an effect on the rigidbody. Perhaps my framerate plays a role here?

 

English is not my native language, so any English-related tip is more than welcome. I will have to look for more real-life examples and decide once and for all. I agree that the "Enter/Exit" version looks awful, that will be modified.

Mmm that's weird, I will look into it.

Yes, the framerate may be causing that. If your character is moving using Transform.Update then Update and FixedUpdate cycles are (99.99% sure) out of sync.

 

Hi everyone, small update ...

2.3.1

Added:
- Added a new scene called “Hybrid Brain” to the Walkthrough.
- Added two more presets to the Documentation folder, one for Physics and one for Physics 2D (default settings + Auto Sync Transforms enabled).
- Re-added the possibility to find the “CharacterAnimation” reference in the character object or its children, only if this reference is initially null.

Fixes:
- A problem related to the OnGUI function that was causing a build error.
- A missing InputData reference in the “Velocity Area” scene.

Changes:
- The “Dynamic Ground” scene has been modified.


PD: it was incredible, i clicked the submit button and 15 minutes later the version was uploaded to the store, very nice Unity!

 

Hello, how can fixed jerkin charater, if character controller use update method Fixed Update?

 

Hi @Martin9636, that could be happen because the platform is moving using Update and the character is using FixedUpdate (both character and platform should move using the same method). Or Maybe you are using "Transform" and autoSync is turned off? it should be turned on, otherwise every transform change (running at a variable time step) will not be updated in the physics world (running at a fixed time step).

I know that the motion and update methods sometimes lead to some bugs like in this example (also based on mails and my own experience), but don't worry, i'm well aware of this and (after some beers) i've decided to wipe out all this non sense for 2.4.0. Kinematics bodies should move using FixedUpdate + MovePosition/Rotation, and with autoSync off. I kept Transform(motion methods) and Update/LateUpdate(update methods) for one little bug with my approach on interpolation (which recently i solved). For the next version this will change, hopefully no issues will arise.

 

Hi. I'm new to this asset.
So i'm using the OnHeadCollision, just to make a mario hitting a block from below - effect.

I really wish i can just do this:

Code (CSharp):

1.     void OnHeadCollision()
2.     {
3.             Debug.Log("Head " + characterMotor.collisionHitInfo.gameObject.name);
4.     }

Because i know CharacterMotor.collisionHitInfo is reused per (almost?)every collision checking, so if a collision event is raised, this must be filled with something. (Unfortunately collisionHitInfo is private)

Or.. from:
public event CharacterEvent OnHeadCollision;
to

public Action<CollisionHitInfo> OnHeadCollision;
works too.

Unless there's a more "official" way to access OnHeadCollision.gameObject ?

 

Hi @Crouching-Tuna , yes you're right, CollisionHitInfo is used for every hit, but only the most relevant info from those hits is exposed to the public. What you propose is actually what i'm doing now with the new version, if your character triggers an event the whole collision data is passed to it, just like you said. Also the new CollisionInfo contains edge info (also ledge and step), for example: upper and lower Hit (from the "edge detector"), isAnEdge , isAStableEdge, isAStep, and so on.

 

I'm finally done reading through everything. Yep, i get why you practically wish you can just delete all the implementations from the package.
My game which is an older project, basically got most of the systems done. I just wanted to change the CC, and that means K2D will have to be implemented among the existing system

A few questions about implementing:
1. I need to update the motor with custom update. Means i'll handle the update myself. It used to be simply in FixedUpdate, but it also needs to be able to "tick" it multiple times at times.
So in my global game manager's FixedUpdate i'll tick every motor. Can this be done instead of each motor ticking themselves?
When paused, the manager won't tick. There's no consequence in not-ticking sometimes, right? (Of course some dynamic RB will also be Physics.Simulate non-automatically)
And sometimes it can be faster slower. Is it fine to just UpdateBehaviour( float varyingDt ) ?

2. For AI implementation, you mentioned i gotta make a few public methods so the AI can adjust the CharacterAction themselves. All in all i think i'll be implementing CharacterController2D and CharacterBrain myself. You expected the user will be implementing these ourselves? In fact, everything under the Implementation folder too, right?
I'm using a waypoint A* with behavior tree for the AI's "fine tuned" movement control, and although my old version don't have it, i think a few checks such as "aboutToFallOffLedge" which is if one of the slope ray hits nothing, and facing that direction. This is for timing the jump.

But i might also get by using a "right after you turn !grounded, do the jump". But of course along with a modification in VerticalMovement to allow "jump fall tolerance" (you can still jump for 0.1sec after you turn !grounded) <-- this is a common platformer feature btw, please consider adding it because i'll add this myself

3. After checking the CharacterAbility implementations, it'd be nice to have some docs about how/when to use certain methods from Motor/Collisions.
-Like CardinalCollision,
-ForceNotGroundedState - this is supposed to be called per frame (like in VelocityArea). Or if once like in VerticalMovement, means it's mainly to ensure a jump can successfully propel upwards without it immediately turning to grounded, within that frame only (implies most velocity.y change reliably, physically takes it out of ground checks in a frame)
-VerticalNotGroundedCollision is used instead of characterController2D.GroundObject.layer, in JumpDown ?

So yeah, gonna actually start implementing this myself. Wish me luck!

edit add:
I'm wondering about your decision to implement it in State + Ability. The more common way is just a single state active at a time and that state handles the input in their own way.
Your way, the ability can be valid for more than 1 state.
Is there a reason to organize it like this? I'm worried an input can be processed multiple times, like Jump + Down in JumpDown and VerticalMovement. Although it works in the example, i would have to add a priority to the abilities.
But the good side is, an ability can arbitrarily change the state based on whatever check.

However i think i'll re-implement this with the more common States handling, and separate "Normal" to more states like "Grounded, Air". It's another less important "implementation" question, but just asking in case i'm missing some advantage in implementing it your Ability way

edit #2:
So related to my question #1, slide on unstable ground on higher Fixed step (0.05) makes the slide speed seem very... SetVelocity rather than AddVelocity. Like it abruptly switches to the slide speed right when grounded on that slope is true.
And on even higher timestep this is much more obvious.

 

Well, that is (and was at the time) an interesting topic. In 2.x.x each motor is performing the Tick, called by the UpdateCustomBehaviour method (sorry if i missed some names). It can be done if change/comment a few lines from UpdateCustomBehaviour.cs:

Code (CSharp):

1.  
2.     protected virtual void Awake(){}
3.     protected virtual void UpdateBehaviour(float dt){}
4.     // protected virtual void UpdateBehaviour(float dt){}
5.  
6.     // Default Unity Messages --------------------------------------------------
7.  
8.     // void Update()
9.     // {
10.     //  if( updateMethod != UpdateMethod.Update )
11.     //      return;
12.  
13.     //  UpdateBehaviour( Time.deltaTime );
14.     // }
15.  
16.     // void LateUpdate()
17.     // {
18.     //  if( updateMethod != UpdateMethod.LateUpdate )
19.     //      return;
20.  
21.     //  UpdateBehaviour( Time.deltaTime );
22.     // }
23.  
24.     // void FixedUpdate()
25.     // {
26.     //  if( updateMethod != UpdateMethod.FixedUpdate )
27.     //      return;
28.  
29.     //  UpdateBehaviour( Time.fixedDeltaTime );
30.     // }
31.  
32.  
33.  

Maybe i should consider this for the next version.

All the Physics tests and movements are performed using UpdateBehaviour, so there should be no problem. And yes, the dt is just a translation from Time.deltaTime ( x1 ), affecting the lineardisplacement (velocity * dt), if you want to pass a custom value go ahead. Maybe the animation part will not behave as it should, i will have to check this out.

Yes, it's called coyote time, and the best way to implement it is using a timer. I will include it for sure (one for jumping and one for landing).

Yes, you're right, there are some stuff that needs to be fully explained in a document. Before there was no implementation at all, well just a simply script to move the character (that was the whole implementation). So my focus were directly to the Core, explaining the basics of the basics. The implementation grew bigger and bigger and went out of hand. By 2.1 (?) i was determined to start the guide so i started writing, and writing and writing, until some day (i hate those days) an idea came up and I ended up creating a new way of updating the motor (that was when v3 was born). My enthusiasm died shorly after, writing an entire guide knowing that for the next version will the obsolete wasn't a pleasent weekend activity. So, i decided to ignore the guide at all (i was probably at 60% of completion), give support/help in whatever i can and finish v3.0 asap.

Yeah, that was not a good name xD. Anyway that's just an Up, down , right or left raycast test, fired from the center of the character (used for Wall Sliding), it's just a little tool.

It does exactly what you said, it puts the character in "not grounded" mode, preventing the character from snapping to the ground. Is necessary to change the vertical afterward or modify the position directly (Teleport), otherwise the character will be grounded again the next frame (well almost, depending on the skin and the gravity). If you are "grounded" and want to be "not grounded" called this method, once should do it. This is used in: Jump (verticalMovement), JumpDown and JetPack ability.

Is this from JumpDown ? mmm i think you are right, i will check that out.

Ideally yes. It depends on the product you are making, though. The implementation has one big purpose: showcasing the package, the motor by itself does nothing. By offering an example implementation i could show also the default abilities, platforms, simple AI, inputs, gravity shifting scenarios, etc (of course this gives the package some more value). I could've given some random code to show just the same, instead i was trying to go for a more modular way of doing thing (and i'm now currently trying that).
I think the user should try to create its own implementation version, but not necessarily from 0%, maybe forking this one will do just fine (using the Abilities System by keeping X abilities and/or implementing their own, same for the inputs, animation, etc.). No matter what version of the package we are talking about, probably you will need to call SetVelocity( ..) or SetBodySize(...) at some point, this "interfaces" between Package and User will not change.

Best of luck!

There are pros and cons in every approach, especially state machines in characters.

The clear "Pro" is that by separating state from abilitiy you could transfer some X functionality from state A into state B (maybe maintaining the state of the ability as well). Every ability is modifying the velocity/rotation/size of the motor, some of them will add/reduce velocity, some will set a certain velocity, or change the body size. So, for example, if you want to create and ability that change the size in Normal state and WallSliding state you can do it by simply adding the component to the gameObject, without copy/pasting 'ability code' from one state to another state. And what if this change in size needs to be apply while swimming? just change the state condition (the enum) and done, the effect on the body size should be the same in any valid/allowed state. This sounds good but ...

The "Con" is that every ability must need to know if they are not overriding some other ability behaviour, for instance if the vertical movement ability is applying gravity, and suddenly X ability (in the same state) is setting the velocity.y to 10 every frame, that would be bad. The execution order is also very important, if you have dedicated code for every state perfect, you manage everying in your own way.

So i guess it depends on the situation (like everything in life). I'm currently more inclined (based on my previous experience) to create State behaviours (like you mentioned) rather than abilities+states, for a number of reasons, reusability is not that much important in this type of controllers, plus i prefer to tweak everything from one state.

I'm not sure about the Grounded/Air case, but it is totally fine if you want to implement it as separated. Once i had Idle state, walking state, running, jumping, falling, etc ... Where does one state end and the other begin? Is there a correct answer to this question? The only thing that's matter is the linear velocity, angular velocity and size properties.

Yes it's a SetVelocity, the value is directly related to an animation curve. Unfortunately since the slide is performed inside the CharacterMotor changing this behaviour could be complicated for the user (well not really, but it is not recommended) and that's bad. But i learned that, in the next version the slide is just a movement/state/ability implemented outside the motor. For example this is the next NormalMovement (with zero slide friction).


There are different modes: accelerated (the gif), "withoutANameYet" (based on the slope angle, like the one in v2.x.x) and constant (the slide velocity never changes). By default everything is gonna be more "realistic", even the grounded movement (now stable movement) is far better than the old one, especially with the ground/air friction and the air control. So, big improvements here.


Sorry for the big Post ...this is all your fault.

 

Haha sorry. I tend to do this actually, it gets too specific.

Anyways i can't read the whole thing now. But for the #1. Instead of commenting them, i just added a UpdateMethod.Manual and set it to that to bypass it

Thx for the reply, will check it soon

 

Just picked up this asset, as I was having some issues with slope edge cases and I liked the ideas behind the mechanics of this one.

I'm incredibly happy that you've chosen to separate your code sensibly. It means that (after testing) I should be able to drop your code into my state machine without much extra work at all. Thank you!

I have a quick question about the code that handles switching update methods. According to the manual, Time.deltaTime changes depending on the update method you're using.

https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html

Should we not be using "Time.deltaTime" in all cases?

It's a trivial thing, but I see so much misinformation about fundamental Unity features like this.

 

Hi, I guess it is up to you. I always used Time.deltaTime for update and Time.fixedDeltaTime for FixedUpdate, to be honest i'm not sure why since deltaTime is more versatile. In K2D the deltaTime is passed to the UpdateBehaviour as an argument ("dt").

You're welcome!

 

Hi,

Kinetic2D is on version 2.3.1 in the assetstore. Is 2.4 already available?

cheers, Eric

 

HI Eric, the new version is not ready yet, some recent events have delayed me (work most of all), i think it will be ready by mid-november (being optimistic). Cheers!

 

sounds good - thank you!

 

Hi! I have a question. How the dynamic ground collision is detected? I can't find any collision detection for the "Dynamic Obstacle" layer in the source code

 

Hi @jmprocco! Go to the CheckDynamicGround method in the CharacterMotor script. In order to detect a dynamic ground the character must be grounded + the ground layer must be contained/selected inside the "layerMaskSettings.profile.dynamicGround" layerMask.


Sorry for the late reply.

 

@lightbug14 I have read absolutely all this thread (post), and I think I need to buy your product, I only have 3 questions or points that I need you to help me solve. Thank you

1) When is the date of the next release estimated?
2) Could your package work on Unity 2019.3? It is the version in which I am moving.
3) In your package have you solved some problems that arise for Pixel Art? like snap, shake, etc etc, I mean, Unity has many problems with pixel art and we have to do a thousand things for a fluid Pixel, even beyond the solution of the current Pixel Perfect Pack, or else our character will move strangely. A solution to this would be so valuable! I would pay only to help me have a camera tracking engine, with smoothing, dead zone for a PPU 16Bits character project.

Thanks in advance. English is not my native language, so sorry

 

Hi @Juandapp, thanks for your interest in the package ... to the questions:

1 - Right now I'm facing some little problem for 2.4.0, once this is solved I will upload the new version. I've been really busy these last few weeks working on my 2D/3D Character Controller (not K2D, this one is different), and of course working on K2D, supporting interpolation/Fixed Update only, fixing some little bugs, changing some collision detection methods, etc ... among other things. This next update will be more of a low level update, important for collision detection, smoothness and performance in general, maybe some API changes as well. Once 2.4.0 is uploaded i will be progressively adding some features requested here in the forums (2.4.1 ... 2.4.2 ... etc)

A few weeks back i said "by mid November being optimistic", i hope it's ready by this week or the next.

2 - Yes, i tested it using 2019.3.0b1 (a beta) and it works fine. In theory it should work with the normal version.

3 - I haven't addressed pixel perfect in any way, so i can't help you here, sorry. I understand pixel perfect is a camera/PPU thing (?), at least the camera script included in the package is a simple movement camera.

Cheers.

 

@lightbug14
Thank you friend, it is an excellent job, I will soon write my review, I have bought the asset, I have already read the instructions (I have translated), and for now I have a question. I set up Kinematic in a new and empty project, I would like to take what is necessary for my other project, without having to take any examples or unnecessary files. I don't want my project to have extra weight. The question is.

What files should I take to my new project to have simple physics with kinematic ?, try to take only the PhysicsEntity2D Script, and it doesn't work for me. I mean, I just want to take what is necessary according to my need, and right now I just need my character to have gravity.

I have a low knowledge in C #, sorry if what I ask is nonsense.

 

@lightbug14
I have made progress with the asset. But, I have noticed, that the original asset demo, without me moving anything at all, just raised the speed to 6 to clearly see the shake, has a problem in the fluidity of the player. Please watch the video carefully, there are times when the player has a little shake, I want you to see the demo by defoult I downloaded, and see my project. The 2 behave the same. It was tested in the stable version 2017f, 2018f and 2019f.

My English is disastrous, what I mean is that there is a little shake, in the player, you can try the asset in version 2019.2.13f1 and raise the speed to 4 or 6, and just walk from one side to another .

and

 

Hi Juan, thank you very much.

The main part of the package is the "Core", in recent versions there is also a "Utilities" folder (that one should have been included inside the Core, i will do this for the next version). If you import just the Core and the Utilities folder it should work fine with the very basics of the package (No implementation, walkthrough , etc).

Yes i saw it, mmm that doesn't happen to me now in the 2.4.0 (maybe because of the fixed frame + interpolation). However, it happens to me in 2.3.1, i'm using the Editor v2018.3.2 in both cases. The thing is, in the demo this shake effect does not happen, neither in a standalone builld, maybe it is a problem related to the Editor (?). Try to make a build and see if this is happening again.

 

Hi bro, I don't have the 2018.3.2, but I tried the stable version 2017.4.34f1, 2018.4.13f1 and the same thing happens. . this is a test that I just did at the moment with a freshly made, totally clean project. I have an ultra screen, 2560x1080. at 60 and 75h, will it have something to do ?.

Hola bro, no tengo la 2018.3.2, pero probé en la versión estable 2017.4.34f1, 2018.4.13f1 y pasa lo mismo. . esta es una prueba que acabo de hacer en éstos momentos con un proyecto recién hecho, totalmente limpio. Tengo una pantalla ultra, 2560x1080. a 60 y 75h, tendrá algo que ver?.

 

@Juandapp What about making a standalone build? in your videos you are testing that scene from the editor. The movement is performed following these simple steps (at least the most simple one):

1 - Convert the character velocity into a displacement vector(displacement = velocity * dt).
2 - Do a Boxcast/Raycast (using the displacement from 1) to get a new available displacement.
3 - Move the character to the final position (pos += displacement).

 

@lightbug14 I did not understand what you want to tell me, however, this morning I followed the post in the forum with our native language, to cover the subject comfortably and when we have a final solution we can leave it in this forum.

Un abrazo.

 

Hi @lightbug14 I'm using your controller and it works just fine.
EDIT: I didn't see the Move() method

Can u please add a getProperty for forceNotGroundedState ?
thx

 

Hi, I'm glad to hear/read that.

"ForceNotGroundedState" is a public method that doesn't return anything, why is that you need this method to be a property? Or do you mean the flag value instead? ... In any case, in the new version this is handled a little better.

Cheers.

 

Cause I need to check grounded state on the same "Jump" (or move offtheground) update.
Wouldn't it be more correct if IsGrounded property would return false if forceNotGroundedState flag is set?
I had to add a forceNotGroundedState on my own but it's not elegant

 

OH i know what you mean. For this one i will do it (because is the grounded state involved), however it will be more easy for you to just keep track of the flag state (like you said), is not that bad.

All the actions that you required are not actually being "executed" at that moment. For example when you say SetVelocity ( vel ) the current velocity (the real velocity -> (pos_current - pos_before) / dt) is not actually "vel". Same happens with forceNotGrounded, you set the flag at any time but internally the action of making the character not grounded happens when the characterMotor wanted to. Every little action behaves the same (i'm not 100% for 2.3.1, in the next version it does). So, it would be more elegant and easy if you just keep track of your properties of interest rather than me generating a getter for each one of them.

 

Hey @lightbug14

setup a new project in Unity 2019.3.0f1 with some plugins. Then I imported your plugin and got this bunch of errors:



Did the same thing within a completely empty project. No errors.
I guess there are some issues with scopes/namespaces?

 

Wooow, i guess there are problems with the class name/scope/namespace of K2D and that particular plugin. The problem is clearly caused by the "Utilities" class, maybe this other plugin is using the same class name (a common name by the way).

Try the following:

1. (to check if this is the cause) Double click on one console error, for example in the first one ("teleport.cs"), then replace "Utilities.BelongToLayerMask" to "Lightbug.CoreUtilities.Utilities.BelongToLayerMask". See if the error is still showing up.
2. (A definitive solution, maybe) go to "Utilities.cs" and change the name of the class (via refactoring) for something different (for example "K2DUtilities").

If this is what is causing the problem i will change the name of the class.

 

Yeah, both of those solutions do the job, putting "using Lightbug.Coreutilities" within the namespace of the scripts works, too though, like:

Code (CSharp):

1. using UnityEngine;
2.  
3. namespace Lightbug.Kinematic2D.Extras
4. {
5.     using Lightbug.Kinematic2D.Core;
6.     // This line wasn't there before, insert for fix
7.         using Lightbug.CoreUtilities;
8.  
9. public class Teleport : MonoBehaviour
10. {
11. ...
12. }

Would be great if you could fix that in a (hopefully) soon update

 

Great! yes I will fix that for the next version...




Me: "@BTStone don't you fret, when I'm through the dev won't set foot in that class name again ... I can be very ...very persuasive".





------------



Me: "C'mon use another name for that class"
Dev: "No"
Me: "I'll be your friend!"
Dev: "No"
Me: "Oh, you're mean!"

 

Hi @lightbug14
what's the best way to "temporarily" align character rotation to a direction?
I need this for an airborne dash that would move 360° in any direction while still colliding with environment. (I don't want it to go through wall or ground).
I would have used an optional collider for this, avoiding to rotate main one but I need env collisions.
Do I have any alternative?

 

Hi @Flag74 sorry for the late reply, the rotation is governed by the "vertical alignment" settings, once the character is in the air it uses a vertical direction to orient itself. To do this in 2.3.1 you can set the world vertical direction everytime you want to rotate the character. The problem is that there is not a nice public method to call. However you can do this by getting the "verticalAlignmentSettings" and modifying the "worldVerticalDirection" field.

Code (CSharp):

1. motor.verticalAlignmentSettings.worldVerticalDirection = --> your custom up direction <--

This is one of the things i improved for the next version.

Regarding collision, if you're using depenetration you're good, at least it shouldn't go through anything (this of course will depend on the amount of angular displacement and the character body itself). Rotation is probably the main problem with kinematic character controllers, the Physics collision detection (with dynamic rigidbodies) can detect continuous collisions with linear and angular displacement as well. Doing this in a kinematic is kinda hard since there is no public method that contemplates rotation (all the physics queries use linear displacement, not angular), so depenetration is your best option.

 

the best way I found at the moment is:
1)set vertical alignment to Local
2)call BodyTransform.SetRotation()
3)call Motor.Move() to apply rotation.

of course it's just a bad workaround and I think I won't use it for the final product.
another issue I have is that I can't rotate around the center of character (I should use a position offset and then rotate), thus for example if the character is pushed away (in the air) by an explosion, I can't rotate him toward direction and I won't be able to make him bounce on the walls. (is there any method to set another collider on the fly?)

I was thinking about temporarily disable KM2D and set the rigidbody as dynamic, handling it separately, but really it would make the code more complex.

Your plugin is really cool for standard implementations but it has some restrictions that cannot be overridden. (for example having a manual rotation override, or having the chance to set space= world on Move() method)
Maybe you can send me a patch for the issues I described?
I struggled for so many days trying to find a solution..

thank you

 

Yeah I agree with you. There are little features and stuff that I miss everytime, and that's ok and perfectly normal for any asset. It wasn't designed to be more "restrictive" on purpose. Let me explain, about half a year back something similar to your rotation problem happened to the CharacterBrain component. Some user needed a more flexible component (to switch between AI and Human, change the sequence by script, etc) and after a few days it was ready. I'm not telling you this because "Hey look, I'm fast solving problems", not at all, I'm telling you this because I totally missed that feature. So yeah, i will probably solve the rotation and local/world Move problem as well.

Normally i don't send patches, but if you send me an email i will totally send you the solution, so you can give me some feedback.


---------------------------------------------------------------------------------------------------------------

By the way, ̶w̶i̶n̶t̶e̶r̶ the update is coming. So please be patient.I know i said November , then mid November , then December ... so I will say -> May 2020 ... i'm kidding, just don't expect a release date . Right now i'm struggling with my new character controller asset (most of the features there will be in K2D as well), once i hit the "Submit" button i will resume K2D full time.

Thanks for the patience.

 

sure, I sent u a pvt msg!

 

Hi! Is there a way to manage collisions with others CharacterMotor?