xyz That's just how the code is called. "bottom_checker" is the Area2D. It's connected with the "body_entered" signal.

When the enemy/object enters the Area2D body, that's when the code to have the enemy node (body) move in to the container node ($EnemyContainer) and stay there is called. That's what I'm trying to figure out.

It's not the Area2D that's the problem (I think). When it makes contact with the enemy, the code is called, but it's the code in my function that I'm struggling with.

I apologize if I'm not communicating myself well. 🙁

  • xyz replied to this.

      kkkkkkabc My enemy is on the enemy layer and for the masks, the enemy only interacts with the player and platforms as it should. How come that causes it to rise?

        NJL64 Then you can just re-parent the enemy to the container in body_entered

            xyz Hey! It worked! "body.reparent($EnemyContainer)". Thanks, @xyz. You always save the day. 🙂

            Thanks for being patient and taking the time to help. Your time is appreciated. I didn't even know about the re-parent method.

            Edit: Just one more thing. The enemy moves into the container, but not the center. It depends on where you jumped on it. I'll keep doing my own research and brainstorming to see if I can solve it myself, but if anyone has any extra ideas, I'd be grateful. Thanks again.

            • xyz replied to this.

                NJL64 Try setting enemy's position property to 0,0 (or wherever you want it) after reparenting.

                    xyz Hmm. I put "body.position = Vector2(0, 0)", after the reparent line of code, but that made it fall through the floor again. If I use global_position, the enemy just disappears.

                    I also get an error for the reparenting line: E 0:00:01:0689 Player.gd:86 @ _on_bottom_checker_body_entered(): "Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead."

                    • xyz replied to this.

                        NJL64 Well, then use set_deferred() to set the position.

                          I've decided that rearranging the node hierarchy is not an effective way of achieving the result I want.

                          I'd like the body to consistently follow the center of the EnemyContainer node.

                          When I use "body.set_deferred("global_position", EnemyContainer.global_position)" the body teleports to the initial global_position of the EnemyContainer, but then it stays there, instead of following the EnemyContainer node which rises above the player (its parent)

                          It works if I reparent the body to the EnemyContainer, but I get the concerning error: E 0:00:02:0592 Player.gd:86 @ _on_bottom_checker_body_entered(): Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead.
                          <C++ Error> Condition "body->get_space() && flushing_queries" is true.
                          <C++ Source> servers/physics_2d/godot_physics_server_2d.cpp:654 @ body_set_shape_disabled()
                          <Stack Trace> Player.gd:86 @ _on_bottom_checker_body_entered()

                          I just want the body node to follow the position of the EnemyContainer node's center, so I don't have to "unparent" the body when it is thrown and separated from the EnemyContainer node and its position (a later function I intend to implement).

                          • xyz replied to this.

                            NJL64 Add a boolean flag property to the enemy script, name it something like carried. Set this flag to true when the enemy needs to be carried and set it to false when it doesn't. Test this flag each frame and if it's true set enemy's global position to container's global position as discussed earlier.

                                xyz I added "var carried = false" to the Enemy script and I made these changes to the function in the player script:

                                But, the body node still remains still where the EnemyContainer position was instead of following it.

                                • xyz replied to this.

                                    NJL64 You need to assign position on every frame so that it's updated continuously. It should be done in _process() or _physics_process(), as those functions are automatically executed every frame. Currently you execute it only once when body enters the area.

                                        xyz That makes sense.

                                        Is there a way I can put this positioning code in _physics_process()?, because I get the "'body' not declared in current scope'" error, and I'm not sure how to define body in in the _physics_process() function.

                                        (I use body so that whatever body enters the bottom_checker can follow the same code, instead of the enemy scene exclusively. So I want to access the body rather the enemy scene.)

                                        • xyz replied to this.

                                            NJL64 This code should typically go into body's _physics_process(). The object can refer to itself via keyword self, which can also be omitted since it's implied it the context.

                                                xyz What's "body's physics_process()"? Is that separate from "func _physics_process(delta)"?

                                                • xyz replied to this.

                                                    NJL64 It is that function if it's situated in a script attached to body node.

                                                        xyz So you're saying you want me to write the positioning code in the physics process of the enemy script instead of the player script?

                                                        That would mean I would have to write positioning code for each individual object/node script, rather than having the player script position whatever body enters it's Area2D node (bottom_checker).

                                                        Sorry, if I'm getting this wrong.

                                                        • xyz replied to this.

                                                            NJL64 You can do it either way, whichever is more convenient for your current setup.

                                                                xyz Okay. I'll try to figure it out. Thanks.