in my code, I have a jetpack and the player Is 0 gravity. it works completely fine until the character collides with an object, then it accelerates the other direction and the char gets flinged. I use render stepped but that isn’t the issue cus I put a print in there and the acceleration is happening when there Is no prints meaning that this isn’t happening cus of rapid input from the render stepped.
This seems to only happen in the x/z plane. if I use my jetpack to go downwards and I collide with the floor, I don’t rapidly accelerate upwards I just go up slower than I did going down to the floor which is the reaction I would expect for the wall however when I collide with the wall instead of going the opposite direction slower than the speed I went hitting it, I go faster and accelerate the opposite direction. Why is this happening and how do I stop? If you think you wanna look at my scripts, please ask. But Im confident the renderstepped im using isn’t the one causing this because if it was then bouncing off the floor should make me accelerate upwards and since there are prints in my renderstepped, it isn’t printing when I hit the wall/accelerate so it isn’t causing it. the only code in my script that messes with my assembly linear velocity is inside that render stepped, so im kinda sure the code of my jetpack isn’t causing this.
ALSO, I put a limiter inside my renderstepped code that prevents my inputs from the renderstepped from occurring if it goes faster than 50 magnitude. so anything manipulating assembly linear velocity in my code shouldn’t be causing it because nothing in my code manipulating assembly linear velocity isn’t being inputted because it detects im going wayyy too fast.
why is this rapid acceleration backwards happening and how do I fix it?
Probably some weird roblox physics bug, assemblylinearvelocity doesn’t really have maxforce, so it can build up or do weird stuff and go super fast like as you saw (I’ve also experience this before while using assemblylinearvelocity). Either use vectorforce or linearvelocity (the object) instead of regular linearvelocity. If you still want to use assemblylinearvelocity (vectorforce is very similar) then you can try either using bodygyro and disabling these states,
well, I want it so the character loses momentum when it interacts with its environment and the only way I thought I could do that is by using assembly linear velocity. do the other methods you proposed also support what I want?
I have a theory to why this might be bugging, maybe because my script is client sided that this is happening. instead I’ll execute the changes in assembly linear velocity server sided. testing to see if there’s any difference.
I think I know what might be happening. when im in first person, or shift lock mode, this flinging happens. for the client the orientation is locked on the look vector of the camera , however for the server this change in orientation for the character which appears for the client is not happening for the server. This might have something to do with it, im gonna mess with stuff relative to orientation in my code.
Okay, switching to cam.cframe instead of char.hrp.cframe seemed to have worked, no flinging issues at all. im just gonna have to disable shift lock and make it so the player can’t zoom in too close and I should be good to go! seems like this was all caused because I was in first person/shift lock.