Inconsistent Jump height

Does this work better even if i didn’t put the collider on children(?) because until now i had the paradigma given by Rick to put on children only like sprite and rendering stuff and leaving the logic onto the parent

really on other parts of the course we did a lot of scripts and we used onCollision OnTriggers etc… but here i am just following what Rick primarly did, maybe it’s because this part of the course was made earlier that the ones before

do you think that maybe a onTriggerEnter etc… and maybe then checking for the layers would work better? tbh i am pretty tired of this ladder , it’s been almost 3 days im stuck with this pieces of wood, i would like to end this

also if you give a look onto my code you can see i already check for collisions in fixed update, yet they are still detected like shit and when the player is dropped from really above they get messy :sob:

also i remember you i am using tilemaps, don’t know if it is an useful info

Not sure if this has anything to do with the Rigibody then, check its Collision Detection, see if it is set to Continuos, that might help, but I’m not completely sure.

OnTriggerEnter Would definitely work, you could try that too.

Another suggestion, but you’ll probably get stuck with this a little longer, is to look into something called “State Machines”, which is a coding pattern that is exactly what you are trying to do here, the result I got from using that was far better than anything we tried, unfortunately, it might be a little advance, but hey, if you manage to get it right you can totally start using it not just to create fancy behaviours for your character, but also for the AI.

as i said before the first thing i’ll look after this will be state machines trust me, but before i’d like to solve this with these instruments ahahh
it’s already set to Continuos, I also don’t think it’s related to fixed update or update, if you loook at my code you’ll se i already put all the physics related stuff in Fixed and the input etc in Update, also after we do the checkinput in the Update later when i use them in other functions it’s only like i am reading the bool value i stored when i checked it in Update, so i think this is not the problem, (i already tried too)
don’t know why the Jump get boosted why on the ladder and why the collisions are so messed up

(also i remember again to you i am using tilemaps for the ladder, don’t know if it is an useful info, which have a COMPOSITE collider attached to)

After some tests… yeah, collisions are not going to work correctly with that sort of code and using OnTriggerStay will throw the same results according to Unity documentation, you’ll need to find out another way, the best idea I have right now is to use a component called Platform Effector 2D, the issue is that you won’t be able to get down when at the top of a ladder, so you’ll need to find a way to solve that.

My final suggestion would be to study how others games do it, Megaman X has a lot of stairs and they work perfectly, same goes for Mario games, you might want to look into them.

1 Like

i solved the jump issue, it seems like not setting the gravity scale in the jump method caused an issue where it went from 0 to 7 like a litttle bit later and it caused like a sprint (?) anyway i solved everything,
right now the only “issue” is this collision thing even if unlike the other ones i can let it a little bit more as a “working progress” or like a “ok i’ll be happy as it is” because i’m a little tired and it’s not like it doesn’t really work , it’s just a little unprecise mh :sob: :sob:

wherever i looked through the web everyone suggest what we did, i didn’t think a good ladder would have been so difficult to make

the only thing i can think of is to make some sort of invisible layer , with invisible cubes with box colliders which would activate only when i’m up the ladder/ not on it/not pressing down/ so that when jumping i would collide to it and then deactivate it. now that i think on this it could be a really good idea
it seems like this guy did something similiar
Ladder Climb: Turning the Mega Challenge into an Uber Challenge - Unity Courses / Show - GameDev.tv

the only problem would be that i should manually put everytime this on top of an existing ladder :confused:

Look into the component Platform Effector 2D, you are probably even going to use it during this section of the course, it will solve the issue of standing on top of the ladder and the character can climb through it, you’ll only need to find a way to get down when at top of the ladder.

1 Like

Thank you, i think i’ll improve my ladder later when i will have more knowledge, i have been stuck for too long here, it’s time to go on, still it was time worth spending, cause i learnt a lot of stuff, just tired cause it took too much time to get reasonable results

1 Like

Welcome to Game Development! :sweat_smile: :sweat_smile: :sweat_smile:

Thank you for the welcome ahahahhahaha
i have only one last question, in the last script you sent , could you jump on top of the ladders? cause right now it seems i cannot anymore and i don’t know if i moved something i shouldn’t hahaahha

update: ok it seemed that the gravityscale of the line where we checked for mathf.approx was “overriding” the gravity when i was trying to jump so i modified it and added a check for “if you are also NOT pushing space”

 private void CheckIfClimbing()
    {
        if(((!Mathf.Approximately(vAxis, 0) && onLadder) || onLadderTop) &&!checkjump) 
        {

            isClimbing = true;
            rb.gravityScale = 0; 
            
        } else if (!onLadder)
        {

            isClimbing = false;
            rb.gravityScale = gravityScaleAtStart;
           
        }
     
    }

only flaw is that doing so when i jump from top it will stay with gravity to not 0 unless i press UP again …but i have to say i like this (and also i not have the energy to trying solve this) i like this because it makes sense to fall if you jump on top of a ladder if you think about it , i’m just trying to convince myself but it’s ok ahhaahahahha
this is my jump

 private void Jump() 

    {
        

        if ((onGround || onLadder) && checkjump)

        {
            isClimbing = false;
            rb.gravityScale = gravityScaleAtStart;
            Debug.Log("salto");           
            rb.velocity = Vector2.zero;        
            Vector2 jumpVelocityToAdd = new Vector2(0f, jumpSpeed);
            rb.velocity += jumpVelocityToAdd;
            return;


        }
1 Like

In that script I was able to jump on top of the ladder, but it does make sense for that not to happen too, it’s a feature, not a bug! :sweat_smile:

1 Like

Exactly ahaahah i made it so i can jump from the top but then you fly down if you don’t attach again, at least like this i don’t have to worry about the collision when jumping cause there is a logic ahahaha

i wanted to give a last question, i noticed that in this section Rick uses a lot of onthouchingLayers to check collision as we have seen also in this instances, and he uses it later also to check if the Player hits the enemy, but i should say that i don’t like it very much, it seems to be like the opposite of what we did until now, i did the challenge of the enemy and player death by myself and i used something like these guys did
Using layers for collision - Unity Courses / Talk - GameDev.tv
Here’s another way of implementing player death - Unity Courses / Talk - GameDev.tv
and from what i see in these posts i’m not the one who felt confused by this, also because using OnCollisionEnter we don’t force it to check on every update with the LayerCheck, but i only check it if i collide with something in other part of the course we always used this way of doing things, was this only to show an alternative way? is it good if i stick it with OnCollision etc… for doing these things? it seems to me to be the global and common way to do it

Those methods and messages are actually quite different from each other, use whichever you want depending on the situation, here’s a list of the differences:

  • isTouching, you can control the number of times it gets called by placing it in Update or FixedUpdate. It works similar to On...Stay, not On...Enter. It detects trigger and colliders, which is quite nice. You can use it everywhere in your code, that gives a lot of flexibility.

  • OnCollision/TriggerStay only detects the collision if the object is moving, if it isn’t moving it won’t detect anything. Imagine you have a big bad beam of death and it deals damage as long as the player is touching it, if the player stops moving it won’t deal damage even if inside it, for constant effects is better to use isTouching. You can solve this by setting the “Sleeping Mode” of the “Rigidbody” to “Never sleep”, but I wouldn’t recommend that if you need to use the message in multiple objects.

  • OnCollision/TriggerEnter/Exit will trigger only once when there’s a collision, perfect for things that you only want to trigger once.

Keep in mind the following, there’s no real optimization benefit from using OnCollision/TriggerEnter/Stay/Exit messages or isTouching methods if placed inside FixedUpdate, all of them will be called once during each Fixed Update. OnCollisionEnter may sound like it only gets called when there’s a collision, but to detect if there’s a collision it needs to check every Fixed Update for it.

In other words, the following methods/messages will use the exact same amount of processing power:

private void FixedUpdate()
{
    if(collider.isTouchingLayer(layer)) { ... }
}

private void FixedUpdate()
{
    if(collider.isTouching(collider)) { ... }
}

private void OnCollisionEnter2D (...) {}
private void OnCollisionStay2D (...) {}
private void OnCollisionExit2D (...) {}

private void OnTriggerEnter2D (...) {}
private void OnTriggerStay2D (...) {}
private void OnTriggerExit2D (...) {}

Use whichever you like depending on the situation.

As a final note: there’s no equivalent to isTouching in 3D.

1 Like

thank you and what about something like?

  private void OnCollisionEnter2D(Collision2D collision)
    {
        if (collision.gameObject.layer == LayerMask.NameToLayer("Enemy"))
        {...}

anyway i prefer the private void OnCollisionEnter2D (…) etc they seems the better way to check for me,
also i understood why the collision here to me worked as a Penetrating arrow and not on the whole volume, Nina answered that in a post of an other User

In this project, we are using an edge collider for the tilemap environment. In the previous sections, we used “solid” colliders. Edge colliders do not have an “solid” body. The collider “area” is just the edge.

The composite collider is just a Perimeter not a Volume so i think this is the reason why collision are a bit messy too

1 Like

Even if as stated in this question
Trigger area versus perimeter - Unity Courses / Ask - GameDev.tv
i think that the if(collider.isTouching(collider)) may be the only way toto distinguish between the colliders attached to the same game object, i was just thinking about this
because since i had both the BoxCollider and the Edge as triggers it would detect collision when hitting an enemy with boths , but i need to trigger it only when hitting with the box so i think i’ll have to use something like

private void OnCollisionEnter2D(Collision2D collision)
    {
        if (BOXCOLLIDER.isTouching(LayerMask.NameToLayer("Enemy")))
        {...}

I like to use OnCollisionEnter2D and such because it gives me a much more sense of control

Don’t get caught on any sort of practice, see them as tools, just because you love the hammer it doesn’t mean you want to use it for every task, the sooner you realize this the better.

I don’t get why the composite collider would cause any issue with raycasting and detecting the ground. Are you using a composite collider for your terrain while using Tiles?

yes i am doing as Rick did , i have also seen this is a common practice for tilemaps, the composite as Nina said woks only on the edges because it does not have a solid body

Anyway i don’t want to stick to a practice just because i’m familiar with it, but this doesn’t mean i need to change the way i do simple things in every script, i’m practicing both ways of detecting collisions, and as i said in the previous post i also just used them combined to get a more powerful result, don’t see the problem to prefer one on other in specific situations

also i think i could switch the colliders i need only as triggers like the edge collider on a child object as you did and then get them as reference , doing this will avoid also some confusion when hitting enemies, even without doing a selection in the scrip

To be honest I haven’t done this section of the course, I’m not sure how Rick is doing things but now I’m wondering why he’s not using the Tilemap Collider 2D, which has volume and is way better because it eliminates the need to have a collider per tile. If you are using Unity 2017.2 or above you can use the Tilemap collider.

I’m not saying nor implying that you should change things everytime, just to be aware that there’s no such thing a better way to do things, also, be careful with the internet, just because people come up with the same solution it doesn’t mean it’s the best solution, more often than not, the solutions you look on the internet are way more complicated than they should or outdated (Unity updates way too much), I have many, many testimonies of that being the case, so please be careful with what you read, google is your friend, but only if you are an intermediate programmer or above, if you are a beginner you shouldn’t rely too much on it and according to much better programmers than myself, googling might even be quite harmful for beginners, of course not for all beginners, but I’ve seen some cases that get caught in google-hell being unable to truly code on their own.

You could set the colliders as triggers, that could work, you can use use the Collision Matrix and child the colliders in different objects with different layers.

Privacy & Terms