Inconsistent Jump height

[Shinos]

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;


        }

[Yee]

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!

[Shinos]

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

[Shinos]

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

[Yee]

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.

[Shinos]

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

[Shinos]

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

[Yee]

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?

[Shinos]

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

[Shinos]

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

[Yee]

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.

[Shinos]

he used the tilemap collider and then matched it with the composite to eliminate the gaps between the tiles,
he explained why do this and i approve personally, not doing so gives a lot of issues if you use box colliders to move and i have proven this by myself, if you zoom a lot you can see there are gaps between colliders and if you do not use a composite collider and get it be used by the tilemap the player would somehow get stuck on them
when i said this was a common practice and i have seen this get used also by other people it was not intended as a “ok if everyone does it , it should be right” but it was for explaining that this was not something i came up with random by myself or was some weird behavior from Rick, sometimes when something as a common problem and a common solution it is very likely to come useful

i already used the Collision Matrix, the method i’m using i showed above is working really good, i never said there are better ways in doing things i was just saying i choosed one method above others after deciding it was better for me in this use case, i am not copy pasting code from Rick or Google and got it done, like dude i have been 2 days on a ladder in trying to get a solution, i am a beginner not a fool i can decide by my self what to do and what paths i need to follow, i am here to learn not to copy-paste ,don’t know why you got this image of me.
Also everytime i look at “solution” on internet is just because as a beginner obviously unless i get to Read all the docs of unity i cannot know what instruments are in the engine or not, unless i get to put random things in my scene.
I really REALLY thank you for the help you gave me , and all the time you spent in teaching me new stuff while you are on your own projects, but please i would also like you to have more trust in me and not assuming things, i also did a lot of stuff, scripting and all by myself i am a navigated programmer , but i’m absolutely not an unity expert, to become one i have to learn stuff and asking to people more experienced like you for is the best thing, i would like you to be confident in my learning skills, , do not think i just copy and paste stuff and notions just beacuse i like to ask… that’s what i am saying lol also for me seeing youtube tutorial videos and googling question has been fundemental for learning in these months and i won’t stop, i usually get a lot of material and then elaborate a solution by myself, (also that’s like the main reason gamedev.tv exist to help people learn with videos, interaction and advices) i don’t have anything else to say as i said i am a Unity beginner but not a “beginner”

[Yee]

I still personally don’t like the idea of using composite collider, I rather round the edges of the player’s collider to prevent the stuck you described, I hate volume-less colliders since they tend to behave very, very weirdly, at the end is a matter of choice, I suppose.

Regarding everything else, I think it’s better to address it in a non-public way, so I’ll send you PM.

Have a nice day.

[Shinos]

I like how the composite works in combination with the tilemap collider for it’s advantages in the creation of big maps with different physics shape, now that i understood better the Edges collisions if you would need better collision triggering you can not use it for specific layers like for the ladders, for general platforms design it’s really good from what i experienced.
For the everything else if you want you can send me a PM but i didn’t wanted to argue, i just wanted to give you coincise explainations on misunderstandings.

[Yee]

The main reason why I don’t like volume-less colliders is because those are basically traps waiting for something to get stuck in them.

There’s a Tilvania project around here that has that issue, which curiously enough it’s caused by stairs, when going up (or down) the character can get stuck in the terrain if not centered, I didn’t see the code, so it might be caused by how that person handled the stairs, but, as far as I’m aware, it’s impossible to get stuck with in the edge of a collider that has volume, the character gets pushed instead, which is a lot better than having to restart a level.

[Shinos]

As i said before i think you could adapt your colliders to what you need, i changed for example the colliders for the ladder layers and also i changed the option for the Composite from “Outlines” to “Polygons” and it works a lot better.
is it just a matter of preferences and what you need/suits you