Projectile spawns in the wrong place: Page 2

Projectile spawns in the wrong place

xyz

The issue is clear. Thing is, there may be something else in the setup, beside the code itself, that causes the problem. That's why you should attach the whole (minimal) project so we can take a look.

cybereality

The code is working. I think the issue is either with your hierarchy scene graph or with using global positioning. I find the best way is to have all objects that interact with each other on the same level (such as the player, enemies, boxes, etc.) that way they have the same coordinate space and you don't have to use global or any translation. It makes everything much easier.

Meruva

@xyz said: The issue is clear. Thing is, there may be something else in the setup, beside the code itself, that causes the problem. That's why you should attach the whole (minimal) project so we can take a look.

Understood. Project Attached, there is nothing in the project that what you have seen already

cybereality

Okay, one second. It should be easy to fix.

cybereality

Actually it was not easy at all. Just spent about an hour or two looking into it and it's still not working. I did fix a bunch of bugs, but none of them were the issue. There is not a lot of code, and it appears pretty straight forward but something is moving the bomb, I don't understand.

cybereality

Honestly, at this point it would be easier for me to just create a new example project doing it my way. I don't think it would take more than like 30 minutes.

Meruva

@cybereality said: Actually it was not easy at all. Just spent about an hour or two looking into it and it's still not working. I did fix a bunch of bugs, but none of them were the issue. There is not a lot of code, and it appears pretty straight forward but something is moving the bomb, I don't understand.

Well this at least makes me feel better that it wasn't just my poor ability causing this lol!

Could you give me any tips based on the bugs you fixed?

Meruva

@cybereality said: Honestly, at this point it would be easier for me to just create a new example project doing it my way. I don't think it would take more than like 30 minutes.

Could i see how you would approach this then please?

cybereality

Yeah, I have to get dinner. I can code it later tonight.

TwistedTwigleg

I got it working! The biggest issue and why it was teleporting is because you are fighting the physics engine. A RigidBody2D wants to have it's position set by the physics engine every physics frame after _physics_process, but because you are setting the position on every _physics_process call, it visually shows the position you set, but in physics space it's actually at the last calculated physics call, causing the issue.

To solve it, you just need to set the RigidBody2D mode to Kinematic while you want to modify it's position so the physics engine knows you are directly controlling it's position. Then, when you are ready to launch, you just change it back to the Rigid mode and it works :smile:

I also fixed a bunch of bugs as well, mainly using global positions instead of local ones and making the RigidBody spawn as a node of the player's parent instead of a child of the parent, so if the player moves they will still stay in position. I did have to use a single yield though in the launch_projectile function. This is because if we try to apply velocity using apply_central_impulse on the same physics frame that we changed the RigidBody2D mode, it will apply the velocity to the RigidBody2D while it's in Kinematic mode, not in Rigid mode, and so it won't apply it and the RigidBody2D will just fall straight down. Yielding for a single physics frame fixes this though, since it's fully set to the Rigid mode. Outside of that though, the rest of the bug fixes were all just really minor changes.

cybereality

Nice find. I was considering that could have been the issue, but I assumed that setting the position in physics process would override the physics engine. Thanks.

xyz

I'd instance the rigid body scene at launch and just use plain sprite for aiming, to avoid yielding.

xyz

@Meruva said: there is nothing in the project that what you have seen already

On contrary. There is a lot in the project besides the code. Code can't show how you set up scene hierarchies and node properties. And as we've seen, code itself wasn't enough to reproduce the problem.

Meruva

@TwistedTwigleg said: I got it working! The biggest issue and why it was teleporting is because you are fighting the physics engine. A RigidBody2D wants to have it's position set by the physics engine every physics frame after _physics_process, but because you are setting the position on every _physics_process call, it visually shows the position you set, but in physics space it's actually at the last calculated physics call, causing the issue.

To solve it, you just need to set the RigidBody2D mode to Kinematic while you want to modify it's position so the physics engine knows you are directly controlling it's position. Then, when you are ready to launch, you just change it back to the Rigid mode and it works :smile:

I also fixed a bunch of bugs as well, mainly using global positions instead of local ones and making the RigidBody spawn as a node of the player's parent instead of a child of the parent, so if the player moves they will still stay in position. I did have to use a single yield though in the launch_projectile function. This is because if we try to apply velocity using apply_central_impulse on the same physics frame that we changed the RigidBody2D mode, it will apply the velocity to the RigidBody2D while it's in Kinematic mode, not in Rigid mode, and so it won't apply it and the RigidBody2D will just fall straight down. Yielding for a single physics frame fixes this though, since it's fully set to the Rigid mode. Outside of that though, the rest of the bug fixes were all just really minor changes.

Awesome! apologies I have been at work until late. Thank you very much for taking the time to find it. Thanks to everyone actually much appreciated the support and guidance on this!

You said you used a yield like it was a sub-opimal approach, can you elaborate on that a bit please?

If anyone has anything I could read/watch that would have helped me find an issue like this I would be very open to that, maybe something that explained to me more about the nuances of the physics_process so I could have caught this problem myself, it seems like there is a gap in my knowledge here.....as well as many other places haha

Meruva

@xyz said:

@Meruva said: there is nothing in the project that what you have seen already

On contrary. There is a lot in the project besides the code. Code can't show how you set up scene hierarchies and node properties. And as we've seen, code itself wasn't enough to reproduce the problem.

ahh I see, I realize this now. Thank you for the advice!

TwistedTwigleg

@Meruva said: Awesome! apologies I have been at work until late. Thank you very much for taking the time to find it. Thanks to everyone actually much appreciated the support and guidance on this!

No problem :smile:

You said you used a yield like it was a sub-opimal approach, can you elaborate on that a bit please?

Sure! The reason behind yield being sub-optimal in this case, and in several others, is that it can lead to timings being incorrect and hard to debug. Yielding, essentially, pauses execution of the function until the condition within the yield is satisfied, but other code (including in the node!) can still execute while the function is yielding (including another call to the same function).

This can lead to issues if you, for example, have a yield waiting and then delete the node, as once the yield resumes the node is no longer present. Another example is if you have a yield in _process that is waiting on the results of a timer, and because _process is called every frame, you might have multiple instances of the functioning yielding at once, which can cause issues when the yields finish waiting and execute.

All of that said though, there are times where using yields is fine and even advisable, it just needs to be used with caution. In this case, it's not really a big deal because it's yielding just for a single physics frame to apply velocity and only on the one object, where it's unlikely something could happen to the object in such a short time. In theory you could use a Timer node or another similar solution to remove the yield, but I think it's probably fine in this case. It's just something to be aware of as it can cause issues in certain scenarios.

If anyone has anything I could read/watch that would have helped me find an issue like this I would be very open to that, maybe something that explained to me more about the nuances of the physics_process so I could have caught this problem myself, it seems like there is a gap in my knowledge here.....as well as many other places haha

I don't have anything, unfortunately, that I can point to. I only tried changing the modes to work around the physics server because I've had similar issues and had to learn the hard way after hours of debugging :lol:

« Previous Page