collision

[deep glacier]

.

these sound like separate problems that should be tackled separately

a laser hitting the player doesn't really depend on direction: either we're getting zapped or we aren't

[mystic tapir]

the wall jump one matters the most to be honest

[deep glacier]

let's focus on that, then

[mystic tapir]

the thing is I want to know which parts of the body should be getting hurt

[deep glacier]

I feel like it's going to be very hard to meaningfully remember which side a collision came from, and to also correctly discard that information when the collision ends

[mystic tapir]

(whether a player is fully covered by the laser or just his left hand)

[mystic tapir]

hmm

[deep glacier]

If you have multiple places that can get hit by a laser, I'd just give each one its own hitbox

each one can then independent learn that it is or isn't being zapped

[deep glacier]

for the wall jump, I would do a physics query when you try to perform the jump

I guess I'd do an overlap-circle to check for a wall, and then an overlap-circle to check for anything that isn't a wall

or maybe an overlap-box

depends on the shape, I guess

it's going to be way harder to keep track of all of the collision events and to keep all of that straight

[mystic tapir]

the thing is, if I try to make those 4 colliders not overlap it will either make the game feel weird or make the player have a weird overall collision shape

[deep glacier]

I would separate colliders used for movement from colliders used for hitboxes

The movement collider should be nice and smooth: no weird lumps to get caught on things

The hitboxes should be lumpier: better matched to your visuals

(and i'd use triggers for the things that can damage you)

a laser shouldn't be a thing you can collide with and stand on, probably!

[deep glacier]

i say this specifically because you're talking about taking damage on individual body parts

if that wasn't the case, then you could have a simple damage collider (or even re-use the movement collider, at that point)

[mystic tapir]

That might work

[analog elm]

those are options you weigh by testing the collision. either use separate hitboxes (what i've done myself), or get the direction based on the contact point and a center point to determine the direction (i've also done) . . .

[mystic tapir]

but won't even more colliders overlaping make it have even weirder detections?

[deep glacier]

If damage is purely directional (and not a feature of specific parts of your hitbox), then I'd just measure the direction from the bullet to the player

maybe mix in the bullet velocity, too

[mystic tapir]

I was thinking of a laser that is being charged, when it fires and you get in its way you get a lot of damage

[mystic tapir]

what do you mean?

[deep glacier]

get a vector from the bullet to the player's center

[deep glacier]

I'd still say you should separate movement and hitboxes

That would avoid the issue entirely

[mystic tapir]

I currently have the second option implemented, the only problem is I don't know any way of checking which side was a collision exited from

[deep glacier]

i don't currently see any reason to check which side a collision exited from, though :p

wall jumping is handled by just doing a few OverlapBox queries

[mystic tapir]

and then compare the x and y of the bullet and the player to determine the side?

[deep glacier]

you'd just see which direction the vector points in, yeah

[mystic tapir]

hmm

it'd work for bullets , not really for walls tho

[deep glacier]

which is why you should be doing separate things for those two

you don't have to use a single collider for everything

[analog elm]

it's the same way you determine which direction the collision entered, by checking the direction of the contact point or colliding object to a specific or center point of the object . . .

[mystic tapir]

It literally doesn't work

[mystic tapir]

is this healthy for the game? optimization-wise

[deep glacier]

premature optimization is evil

[analog elm]

yes, tons of GameObjects can have and will have multiple colliders . . .

[deep glacier]

having a few colliders is fine

[analog elm]

what and where (line of code) is this from?

one collider cannot always represent the shape of an object, so yes, you can use multiple . . .

[analog elm]

which line does the error throw? no numbers in ss . . .

[mystic tapir]

so I'd have a square collider covering the whole playre which would only collide with the terrain and then 4 colliders for determining where the attacks are coming from?

[deep glacier]

Right.

Different colliders for different duties.

[mystic tapir]

how does it fix my walljump problem then

ohh

[deep glacier]

you don't get a prize for using just one collider

[mystic tapir]

I could do it using tags

different for walls and walls

wait no

[deep glacier]

I would raycast.

you can get the normal of the surface you hit

if that normal is mostly horizontal, allow a walljump

[mystic tapir]

I don't have a clue about raycasting 😭

[analog elm]

casting is sooo much easier for all this . . .

[deep glacier]

yeah, you definitely got XY problem'd, haha

http://xyproblem.info

[mystic tapir]

I really thought there is no other way since I tried doing it so many ways 😭

I will try raycasting and different colliders then, thanks

[analog elm]

have you tried looging contactCount before accessing contacts?

[deep glacier]

https://docs.unity3d.com/ScriptReference/Physics2D.Raycast.html for reference

if you get a hit, check the normal field of https://docs.unity3d.com/ScriptReference/RaycastHit2D.html

(also, make sure you're always using the Physics2D functions)

[mystic tapir]

I'm pretty sure I tried that but it didn't work