Help! My player is teleporting when I go left or right and I have no idea why.

I click to run the game, the player sets down and then is teleported below the level.

Can anyone help? I'm trying to insert new animations from a pixel artist I commissioned and this started happening.

drive.google.com/file/d/1BFioyRM_NoVW9cUagCJHeAEEBellXNqQ/view Here is my google drive for the file. I'd really appreciate any help because I'd really like to not start over on my hobby project.

Your image origins are off. Go into the animation editor and, on the left side find the button to edit image points. Then, you just need to set the location of the origin to the correct point of the image.

This fixed it, but now there's a wonky animation ocurring when my character moves left to right. Do you know what that might be? I'm trying to figure it out.

Is it the animation getting mixed up? i changed it to animate from the current frame instead of from the beginning just in case.

Thank you for the help btw. I took a few weeks off to commission and get this pixel art made and now I'm all out of practice and wondering why my guy doesn't even animate running lol.

I see this all the time with newer users. The animation is switching between the run and fall animations. Take a look at this screenshot:

The arrow shows the distance between the floor and the collision bounds of the image while running. Since the collision bounds are not on the ground, the platform behavior thinks it is falling and swaps to the fall animation. I know intuitively, you think the collision bounds should stay wrapped exactly around the player but that isn't really the case in a game. Keep the collision bounds on the ground to avoid this problem.

I've moved all the collision bounds to the ground and the effect is still happening. I hate to keep bothering you with this, but any ideas? I've even made it so two points are on the ground while it sits there and it still seems to be ocurring.

Never mind, just took redoing all origin points because apparently there were some saving issues.

Hey a good trick and best practice is to use a different sprite object for controlling your collision and movement (usually a simple rectangle that never changes), and pinning your visual representation of the character to it

also make sure that when you get a sprite commission to ask for the character to always be centered, so you don'T need to edit image points or things like that when you import files

Wouldn't your collision box be incorrect though if the character isn't perfectly rectangular?

Incorrect how ?

eleanorjmorel, please stop spreading this flawed logic. It has been passed around this forum for years but is only really useful in specific situations. The sprite has collision bounds for a reason. It is so you can define your collisions based on the sprite shape easily. A separate sprite which defines collision bounds is FAR more difficult to fit to the sprite object you are working with.

Incorrect how ?

If you fired a bullet at a sprite that isn't a square but has a random square shaped collider the bullet would not collide with the correct collision point on the sprite

eleanorjmorel I don't know your background in game developement but, I have over 10 years of experience working with Construct as well as Unity, Garage Games, Godot, XNA and programming games in Java, C++ and C#.

Your examples are not relevant in this situation. For Honor is a full 3D game as well as Unities pill shaped colliders. If this sprite was a composite object made up of multiple sprites, then this could be a little more approriate to the situation.

Your Celeste example actually shows a reason the separate collision object is a bad idea. If you define a hazard but your collsion bounds allow you to touch that hazard without being affected, that is a bad thing. I am not the developer of Celeste so I don't know what all decisison they made leading up to that situation so I can't really judge it.

What I can say is, using a separate sprite for collisions instead of Constructs built in collsion bounds SHOULD NOT be passed around as the "best practice" for every situation. It adds another object that takes up memory. It creates a generic collision size/shape for objects when the developer may want something more specific. It adds complexity which is harder to upkeep (especially if the project winds up being handed off to another developer).

Finally, I am not saying it is wrong to do. Just that pushing it as the end all be all for every situation is wrong. In this particular situation, I would not use a separate collision object. Your example of using the single object for multiple object types that have the same behaviors is one of the "specific situations" I referenced (however, this can be done using families without causing these other problems). As is composite objects. This will be my last responce in this post about this subject. boomerfreak1, hopefully you have enough information about this to make your own decision about which method is the best one for your project.

I'm taking your word over his. I don't think its correct to wrap sprites in things that aren't the correct shape in this instance at all. If it was unity it would be a separate issue which I've programmed in. For a precision platformer it doesn't make sense to have the wrong shape. Super Meat Boy is a great example of how they made the character square just so they wouldn't have to change the shapes, Other platformers like yooka laylee and such use collisions that wrap to the object or sprite correctly anyways. Thank you man. Your advice was helpful. I'll add juice in other ways and not have incorrect collisions.