Follow Target & Limit Node Target at runtime

[Phanterm]

Hello again! I am having trouble understanding the specific behaviors of limit_node_target, as well as why my follow_target node field is empty at runtime despite being assigned in code.

I've been wrestling with this for a few days, so I'll break it up into one section for each.

Limit Node Target

I have a specific process for assigning camera limits for my game. My game contains multiple rooms of different sizes which are stitched together. Thus, whenever the player walks into a new room, I send a signal to the CameraManager autoloader that provides PhantomCamera2D an updated Node Limit Target for the purposes of camera bounds.

The room in Tiled. There's an entire box covering the room, import_bounds and you can see the width/height there. When imported into Godot, this node becomes the CollisionShape2D assigned to the PhantomCamera2D node's limit_node_target field on runtime, as well as whenever the player enters a new room.

Assignment

I use the camera limit box's on_body_entered signal to communicate whenever a new room is entered. When the camera bounds need to be updated, this signal sends one line of code: CameraManager.current_room = self.

And, on CameraManager, current_room is wired to a setter that runs some code whenever the value is changed (since I'll be adding more room-based logic besides just the camera later on):

var current_room : RoomInfo : 
	set = update_room

func update_room(new_room):
	pcam.set_limit_node(new_room.bounds)

update_room() sets the new limit node on the pcam PhantomCamera2D to the CollisionShape2D associated with our room, called bounds here.

Godot_v4.2-stable_mono_win64_u0ojijMXwx.mp4

This is the result when the game is run. Debug colors are on, and the camera bounds are yellow when the player is within them, so it's in the correct position, and extends to each wall as shown in the first screenshot.

When I look at the limit_sides during runtime, these values look correct, and the limit_node_path is set as it should be. My map's origin is 0,0 at the top left corner, and the values for right and bottom are exactly as they should be. So why is it that the camera is stuck in the middle of the room?

Follow Target

(For this section I have disabled limits.)

The next issue is probably more straightforward. I am getting some strange results from assigning the follow target node at runtime, as well as noticing that the field itself in the Remote node view is empty even when I print out the node and it is indeed assigned to the player node as desired.

My settings, excluding Limit, since I turned that off for this demo:

Assignment

At runtime, on _ready(), from the player script I have it assign itself to the PhantomCamera2D's follow_target field:

CameraManager.pcam.set_follow_target_node(self)

Pretty simple, right? I also use print(str(CameraManager.pcam.get_follow_target_node())) one line after to ensure the node was set correctly, which it is. I check each frame for good measure to ensure this value isn't getting changed, which it is not.

However, this is my result when I start the game, compared to where the player is in my room. I'm not sure why it isn't following correctly, though I notice that my PhantomCamera2D's position is (640, -360) for some reason.

Conclusion

My understanding is that limit sets the pixel limits of the camera, but are these limits relative to the scene in which the camera exists? As of now, I'm assigning a separate autoloader values based on other scenes. The autoloader contains the camera, and this is the only thing I can think of at the moment that could be the issue.

Thanks in advance for your help!

[ramokz]

When I look at the limit_sides during runtime, these values look correct, and the limit_node_path is set as it should be. My map's origin is 0,0 at the top left corner, and the values for right and bottom are exactly as they should be. So why is it that the camera is stuck in the middle of the room?

It's tricky to determine without seeing the scene setup exactly, but the only thing I would imagine is that the limits are much tighter than intended. The fact that it follows briefly in the vertical (y) axis in the video example suggests that it can have a bit of space above and below its initial starting point. Pointing to the camera limits work, but in an undesirably restricted area.

For testing purposes, if you assign the CollisionShape2D from the editor directly, does its limit restriction match what you would expect if you then move the PCam2D around? Basically, replicating what the code does, but in the editor directly instead.

You can also try to read the pixel positions of the left, top, right, and bottom of your room scene, or its bounds, from the rulers and apply those values directly. Either by updating the Limit values of the PCam2D, or the Camera2D (by temporarily removing the PCam2D) and see how the camera responds.

My understanding is that limit sets the pixel limits of the camera, but are these limits relative to the scene in which the camera exists? As of now, I'm assigning a separate autoloader values based on other scenes. The autoloader contains the camera, and this is the only thing I can think of at the moment that could be the issue.

I would assume so, yes, it applies the same logic as the built-in Limit property of the Camera2D. To my understanding, that means the limits should be restricted to the scene the Camera2D is in.
To your point, having the Camera2D being a child of the CameraManager might have something to do with it. If you've only ever got one Camera2D, you theoretically could have it as part of a root node in your project, rather than as part of the CameraManager, and see if that changes anything.

However, this is my result when I start the game, compared to where the player is in my room. I'm not sure why it isn't following correctly, though I notice that my PhantomCamera2D's position is (640, -360) for some reason.

Nothing in your inspector or code setup looks out of the ordinary. Only hunch is that something is interfering with the positioning of either the Camera2D or PCam2D. A place to start could be to try to add the PCam2D, Camera2D and PCamHost nodes into the scene directly and see how it reacts when you apply the various property values, including the Follow Target. If that works as expected, then it's either an issue with the code, which I very much doubt based on your descriptions and observations, or a node scene structure setup.

[ramokz]

The limits here do not function as they do in the normal example scene, or perhaps I should say, the scale of my project is affecting my perception of where those limits are (the camera also fails to follow the player to the boundaries).

Ah, that's interesting! The Scale option in Project Settings/Window does impact what you see in the Camera2D, but it should also affect how the PCam2D behaves in turn. It should, effectively, act as if you're multiplying the camera's zoom level by the same amount as the scale value, but obviously only when running the game. Though that shouldn't influence the Limit bounds, as those are based on Rect2 of your CollisionShape2D — unless something else is being scaled too.

So throughout this process, I had been referring to the example scenes repeatedly. However, I'd been doing so outside of my project, in a dedicated test project. I just tried loading the example scene within my current project and this is what it looks like:

The odd thing in your recording of the example scene is that is looks different from what I'm seeing. In your video at the beginning, the character not being in the centre is very strange, but then at 0:11 the fact the camera transitions to the right side where the ladder is visible and in focus, instead of the character, is also very odd. It's not something I seem to be able to replicate, so am not sure what the cause of that would be if the example script(s) haven't been modified.

I tried running the example scene using the Project Settings -> Window parameters you shared, i.e.:

• Mode: Viewport
• Aspect: Keep
• Scale: 2
• Scale Mode: integer
• Viewport Width: 640
• Viewport Height: 368

But aren't sure if something else is being applied in your case, or if I misread your setup?
The only other change I made was resetting the Follow Offset from the inspector and scene script from each PCam2D, though that only modifies the Y-axis.

This is what I'm getting:

195-640x368.mp4

---

Would you be able to potentially share a minimal reproducible project with your .godot project file + just the addon folder — i.e. exclude all your own project files (assets, scripts etc.).
Am curious if there's something specific in the project settings that differs from mine that could cause your example scene to look so different from what I'm seeing. Feels like something isn't adding up.

[Phanterm]

Can do! Project appended to this post.

It's also worth noting that when I tried this in a new environment with the same project settings, the result changed yet again:

Godot_v4.2-stable_mono_win64_BezzB2IToA.mp4

PCam-Scale-Test.zip

EDIT: I see in a previous post that I made an error. My project viewport size is actually 640x384, not 640x368. Sorry for the mixup.

[ramokz]

So running the scale test project you shared gives me a 1:1 result on both Linux and Mac with your video above. So it's definitely not a hardware nor (likely) OS related thing.

Given something changed for you again in a new environment, and assuming it's the same addon version and both are unmodified, then my only hunch is that the discrepancy might lie in the hidden .godot/ directory in each project. Though it's hard to say.

All that said, I think I know why the camera isn't moving from your original post now, based on a few observations when seeing what the Scale parameter in Project Settings actually does.

Mind, this is only a theory, and so might be wrong.

Looking firstly at the addon example scene with the scale set to 2 and 1, it looks like it's merely a case of the camera render is just scaled up and essentially cropping what the camera actually sees. As opposed to modifying its actual viewport size.

Importantly, the limit does not take Project Settings scale into account when it's drawn up. I.e. the scale just crops what the camera sees, but the limits are as if there was no cropping to begin with.

With that in mind, when I superimpose the video of your project's scene on top of the tilemap you shared, it starts to make sense for why the camera doesn't move.

My guess is that when the scale is set to 1 in the Project Settings for your project, the camera's viewport, at least the horizontal one, covers the entire room. When the scale is set 2, however, it only shows the middle section of the room (what the video shows), which gives the impression that that is what the camera sees, when it's really only half of it.

So it feels like the PCam2D's zoom property is what you would need to adjust, or apply a large negative margin to the limit margin property to compensate for the cropping.

As for why it moves slightly in the y-axis, my guess is that the aspect ratio of the viewport + size of the tilemap (the limit area) leaves the camera with a bit of room to manoeuvre up and down — at least if the pixel counting I drew adds up.

[Phanterm]

This has been very enlightening. After alternating between downscaling the limits and playing with the project settings' scale, it seems to be as you say. I think we're getting closer to the solution.

Godot_v4.2-stable_mono_win64_JJOd6ceABp.mp4

• Project Settings scale: 2
• limit_margin: Vector4i(-320, -192, 320, 192)
• Follow target has been assigned at runtime
• follow_mode: Simple

These limit margins seem correct no matter the room size, so that's perfectly fine as a workaround. Putting aside the strange follow behavior for now, things get a little weirder once I begin testing with limit values set in the inspector vs setting at runtime with set_limit_node():

The size of the CollisionShape2D Shape2D via shape.get_rect() is
P: (-640, -384), S: (1280, 768).
These are the same values I used in the above video when setting the values manually. But when using set_limit_node(), the values of the camera's get_limit(SIDE_TOP) ... each return as 0.

I saw this on the docs when starting out:

Note: For performance reasons, resizing the Shape2D during runtime will not change the Limits sides.

Note: During runtime, properties should be modified and read via their setters & getters respectively.

But I wasn't sure if this would affect me, since I'm not resizing the shape itself, just assigning the shape the camera uses as soon as the game runs. I also manually set_limit() during runtime to the identical values just to ensure the problem wasn't isolated, but it outputs the correct values.

As a workaround to keep using the shapes as a basis for defining the limits, I can extract the values from the Rect2 via the shape's get_rect(). But I am not sure if this current behavior for set_limit_node() is intentional.

Beyond this, the only other issue is how the camera is following the player, but one thing at a time. 😅

[ramokz]

These are the same values I used in the above video when setting the values manually. But when using set_limit_node(), the values of the camera's get_limit(SIDE_TOP) ... each return as 0.

If you're referring to the PhantomCamera's get_limit() function, then that is expected. The value of PCam2D.get_limit(SIDE_X) is not what the camera uses if you have a Limit Node assigned. It employs an internal variable called _limit_sides of type Vector4i, which is what stores that Limit Node values.
I.e. .get_limit() is misleading at this stage. This is mainly to store the pre-existing value in case the Limit Node gets removed from the scene.
Admittedly, there could be a helper function to get the current limit values of the assigned Limit Node to avoid that confusion.

From the 2DLimitExampleScene.tscn inside 2d_room_limit_tween.gd:

@onready var pcam_room_left: PhantomCamera2D = %RoomLeftPhantomCamera2D
@onready var camera_2d: Camera2D = %Camera2D

func _ready():
	# Camera2D	Returns -5784
	print(camera_2d.get_limit(SIDE_LEFT))
	
	# PCam2D 	Returns -5784
	print(pcam_room_left.get_limit(SIDE_LEFT))
	
	# Assigns the CollisionShape2D (inside RoomLeftArea2D) as the Limit Node.
	pcam_room_left.set_limit_node(%CollisionShape2D) 
	
	# Camera2D 	Returns -337
	# This is the value the size and position of the CollisionShape2D assigned above
	print(camera_2d.get_limit(SIDE_LEFT))
	
 	# PCam2D	Returns -5784
	# This isn't being used at this point.
	# Instead there's an internal Vecto4i that has the limit value
	# called _limit_sides.
	print(pcam_room_left.get_limit(SIDE_LEFT))
	
	
	pcam_room_left.set_follow_target_offset(Vector2(0, -80))
	pcam_room_right.set_follow_target_offset(Vector2(0, -80))
	
	# Rest of the script

Where the initial value inside the inspector looks as follows:

The above looks and behaves as expected, so it doesn't sound like you're doing anything inherently wrong based on your description.

I saw this on the docs when starting out:

Note: For performance reasons, resizing the Shape2D during runtime will not change the Limits sides.
Note: During runtime, properties should be modified and read via their setters & getters respectively.

But I wasn't sure if this would affect me, since I'm not resizing the shape itself, just assigning the shape the camera uses as soon as the game runs. I also manually set_limit() during runtime to the identical values just to ensure the problem wasn't isolated, but it outputs the correct values.

Correct, unless you're resizing, or repositioning, the Shape2D at runtime, then this should have no impact on what you get.

[Phanterm]

Hey there, I just thought I'd close this out with a video I uploaded talking through the issues I've been facing.

https://www.youtube.com/watch?v=ZRnT9AoDLOY

I'd love to continue using this plugin, if not just for the camera control, but also the smoothing which Godot doesn't seem to do a good job with using their default cameras (which is very disruptive to pixel art). But I'm completely at a loss as to why I keep having these issues, unless I am entirely incorrect in my implementation of this system. :(

Anyway, thank you again for all of your patience and help up until now. I'll keep trying for a while longer to see if there's anything I overlooked.

[ramokz]

Sorry to hear it's been such a frustrating thing to resolve. Can definitely understand your pain ☹️

Honestly, the main curveball I see is the Scale: 2 from the Project Settings. As it works fairly differently from changing the camera's zoom value. Especially when considering there are viewport calculations happening within the addon — in particular with the Framed Follow. Though I wouldn't expect it to significantly alter the end result. I have not tested it in the past, nor its potential side effects, so it is truthfully a bit of an unknown to me how different features respond to it in various setups.
I guess my question here is, is there a reason why you're modifying that value instead of adjusting the zoom property of the Camera2D (PCam2Ds)?

re: the issue about the Framed Follow stacking dead zone layers, there was another report about that just a few days ago (#208), so hoping to get that resolved within the next few days or so.

[Phanterm]

I guess my question here is, is there a reason why you're modifying that value instead of adjusting the zoom property of the Camera2D (PCam2Ds)?

It's just easier to control the scale from a single location when I know it would affect everything, like my UI and other game elements. Zooming the camera means I have to scale up such elements by 2 in the Transform.

I've made the logic for setting all of this up much simpler.

In this image I've assigned the CollisionShape2D to the Limit Node Target. Everything has been set in advance before running the game. No runtime calculations, no negative margins set, just the PhantomCamera2D's zoom set to 2 and the Project Settings scale defaulted to 1.

Godot_v4.2-stable_mono_win64_o1SwKRMRkk.mp4

I'm still getting odd behavior here. I've also tried setting the tilemap as the limit node, and setting the limits manually.

[ramokz]

Does it work any differently if you're using a non-Framed Follow mode? Only asking because of the known issues when the target has left the dead zone. It's further compounded by a contradictory logic between Limits and Framed Follow where the latter try to perform its follow logic, but where the former prevents it from doing it as the camera can't get closer to the edge. Not entirely sure if there is a good solution, certainly not in its current iteration, but hoping to address that with the refactor (#161).

Got a few ideas, but if you are comfortable with it, then I am more than happy to have a look at your actual project to see what the issue might be. Obviously, will not post anything publicly or share it anywhere else. Do feel that I'm dragging you along a bunch of testing paths, which feels like a poor use of your time.
It's also to partly test to see if the 0.7 branch produces any notable differences as its property system has been entirely reworked, which has so far resolved some issues that had no reason to occur in the first place.

Again, totally understand if you don't want to, or can't, whatever the reason.

[Phanterm]

Double-posting because I found some strange (possibly unrelated?) behavior throughout my time with this plugin. I noticed that, sometimes, when the limit node is assigned in the inspector, the position values will fluctuate between positive and negative. Sometimes it's just the x value, sometimes y, sometimes both.

Also note that the other cameras using TileMap and CollisionShape2D on this scene do not experience the same issue. I've tried to repro this for some time but have had no luck, which is why I haven't mentioned it until now.

EDIT: I saw that I had a second PhantomCameraHost in an autoloader that I got rid of from this example scene. Still experiencing the jittering camera positions, however.

[ramokz]

So this is not so much of a problem as it is an unideal setup.

What you're seeing is the PCam2D having a larger render viewport than its limit size. I.e. it's restricted to an area that's smaller than its own size. Godot's way of handling that is to push the node up and down so it fits at the top, which means it no longer fits at the bottom, so it pushes itself up, no longer fit at the top, then repeats.

You can tell by the green border (the PCam2D's Frame) trying to fit vertically within the CollisionShape2D, the blue border inside of it. It can be solved easily by either changing the Viewport Width/Height in the Project Settings, or adjusting the Zoom property.

I will look into adding some logic to log a console error that states that at some point just to make debugging easier.

[Phanterm]

Do feel that I'm dragging you along a bunch of testing paths, which feels like a poor use of your time. It's also to partly test to see if the 0.7 branch produces any notable differences as its property system has been entirely reworked, which has so far resolved some issues that had no reason to occur in the first place.

That's no problem! I'm just happy for the extra pair of eyes; if I help stress test the plugin then that's just a bonus. I had missed your reply yesterday about get_limit() and have since returned to using set_limit_node() on my collision shape. Now that I've swapped the Project Settings scale back to 1, the camera Zoom to 2, and Glued as the follow mode, I think -- I hope -- that it's working now!

Godot_v4.2-stable_mono_win64_XM6NRiF2Tk.mp4

Thanks for all of your help!

[ramokz]

That's great! Really glad to see that it appears to be working as intended! 🎉

I still think all the trials and tribulations raises some interesting points. Most prominently, why did it not work as expected sooner? Think it boils down to the specific setup you had, which I think the addon needs to account for either way, as I'm confident you are neither the first nor last to run into this.

So thank you for being patient and trying out the various solutions, it has been really educational as to where lots of limits (pun not intended) are still to be ironed out.