Releases: ramokz/phantom-camera
v0.7.1
✨ New Features
2D Physics Interpolation Support
Important
This enhancement is only available for 2D scenes in Godot 4.3 and later.
Any existing setup shouldn't be affected by this, this is mainly a behind-the-scenes change.
The addon still supports Godot 4.2.
With the added 2D physics interpolation support in Godot 4.3, the addon will now automatically switch the PCam2D
and PCamHost
nodes to use either the _process
or _physics_process
depending on the node type of the assigned follow target
. This should greatly reduce, and likely entirely remove, jitter when assigning a PhysicsBody2D
as a follow target
or when having a lower physics tick. More importantly, it should make the addon easier to pick up and use out-of-the-box without having to read and use any of the recommended tips on the documentation site.
For 3D scenes and Godot 4.2 users
The changes here will provide additional guidance in the Output tab when assigning a PhysicsBody
as a follow target
or look at
(3D). The intent is to better support addon newcomers until both 2D and 3D have physics interpolation.
The tip can be disabled from the Project Settings / Phantom Camera
.
Godot 4.3 specific 2D example scenes
As the updated system requires a different node structure between Godot 4.2 and 4.3, an additional 2D example scenes folder has been made that works using the changes from this release. Once Godot 4.3 becomes the minimum required version, these example scenes will be deprecated and its changes moved over to the existing 2D example scenes.
Note
3D physics interpolation will be supported in a future Godot release - until then, the recommendation in the guide still stands.
🛠️ Changes & Improvements
- The
cull_mask
property insideCamera3DResource
is now set to use the correct export layers. Used to beexport_flags_3d_physics
and is nowexport_flags_3d_render
.- Thanks @tiloc for reporting the issue (#290) and @ZenithStar for the fix (#293).
- Resolved an issue where
dead zones
would persistently appear in the viewfinder if aPCam
was set toFramed Follow
and had enabled it through the inspector and then switched to anotherfollow mode
before running the game. - Updated the wording for the Editor Updater to avoid confusion for larger releases.
- Thanks @Flynsarmy for mentioning this (#260)
- Improved the DX when setting a
limit target
. It will now trigger an output statement if an assigned value is either not of typeTileMap
orCollisionShape2D
as well as if aNodePath
isn't valid in the first place. It will now also prevent thelimit size
from resetting should either of these two scenarios occur. - Updated
append_look_at_targets_array
to now correctly apply the correct node type(s) to thelook_at_targets
array.- Note: The parameter type will change from
NodePath
toNode3D
, but not until the0.8
release, as it's a breaking change. This wasn't done in the0.7
release due to oversight.
- Note: The parameter type will change from
- Reapplied
top_level
setter for the character script in the 2D example scenes to remove jitter when not having any damping applied to thePCam2D
.
Ko-fi Donations
Added a donation link for those feeling generous. Donations will have no impact on the addon's development, it's purely a “thank you” system.
v0.7.0.6
v0.7.0.5
v0.7.0.4
🐛 Fixes
- Fixed a regression from the 0.7 release where
Limit Sides
that had their values set using either thePCam2D
number input fields in the inspector or via code, e.g.pcam_2d.limit_bottom = 40
, would reset to their default values on start-up or after a tween.- Thanks Codecuts (Twitter) for highlighting this.
- Readded
set_limit
andget_limit
function calls- Thanks @CantyCanadian for highlighting this (#270)
v0.7.0.3
v0.7.0.2
v0.7.0.1
v0.7
❗ Breaking Changes
Note
The breaking changes in this release are a one-time thing.
It's a combined number of system changes that needed to happen at some point, and so it was decided to do it in one go rather than over the course of multiple releases.
Important
Always be sure to have your current changes commited to source control before updating to avoid losing work.
Godot 4.2 Minimum Requirement
This release, specifically the property change, further down the page, relies on changes that were only released in Godot 4.2. As such, it will now only be compatible with that and future versions of Godot.
Addon Filename Consolidation & Dependency Errors
A lot of the addon's filenames have been changed to align with a general snake_case naming convention, but as a result will likely run into an error on start-up that looks like this:
If you're well-versed with Godot, then this should be a relatively simple thing to resolve, but if you're unsure how to solve this, follow the steps below.
Tip
After doing the steps below, if you're running into an issue where the editor will constantly say that it can't find Phantom Camera scripts, then it's likely due to there being a cached reference to the previous file inside .godot
directory. To solve that, try and delete the entire .godot
directory. It will be repopulate itself once you reopen the project.
Fixing Missing Dependencies
Revamped Property System

This is mainly an under-the-hood change and will only impact existing users of the addon.
TLDR
- All the property variables have changed from using
_property_list
to@export
. - For existing users, a lot of property names have changed as a result, which will break, or more precisely reset, existing setups.
- See the end of the section for a mitigation guide.
Why the change?
The shift to @export
was always planned, but for a later release — initial thinking was for v1.0. The reason it is being introduced now is due to a project export bug (#164), where an important feature didn't consistently work when exporting a project — despite working consistently in the editor. Suffice to say, that's a pretty big problem. From some initial tests, this issue did not occur when using the aforementioned @export
approach. So the decision was made to make the jump sooner than originally planned. So far, the issue has yet to reappear.
The change was also meant to coincide with a better editor experience, as @export
allows for supporting inspector property tooltips (#55) as well as an in-editor documentation page for all the addon's public node properties, functions, and signals (#168).
From a development perspective, the change also greatly simplifies the process of adding, removing and debugging properties, which in turn reduces the code complexity and time spent testing new and old features.
Why was @export not used from the beginning?
The addon has been in the worked since before Godot 4 was fully released. Not until Godot 4.2 was it possible to dynamically show or hide properties using @export
. If the addon had used @export
from the start, it would have resulted in all the available properties for a given addon node always being displayed. The vast majority of which being both irrelevant and confusing without contextual toggles or modes enabled — awful developer experience, in other words.
One of the changes made here is that property names do not have any nested names, e.g. follow_parameters/target_offset
, are now named as a single variable name, e.g. follow_offset
.
I have set up a lot already from previous release(s), what can I do to mitigate breaking changes?
Assuming you're using some form of source control, such as Git, the good news is that you can convert the property names manually from the individual scene files (.tscn
) directly and keep your existing property values. Below is an example of how I would migrate an existing setup from a pre-0.7 project to be using the new property names from this release. Note that the follow_damping_value
property is the exception to this - more in the Important section below.
Mitigation Guide
Once you've updated the addon and opened an existing scene that has PCam2D
and PCam3D
nodes, their values will have reset - you may have to re-save the scene first. From here, if you want to keep your existing setup, you can look at your source control and compare what values have been changed. In the example below, I've readded a follow_target
and damping
with random values.
As the image above shows, the names are not changed to be unrecognisable from the previous version. They are different, however, which does mean manual intervention if you wish to migrate the values over. Simply use your text editor of choice and add the values into the .tscn
file directly.
Tip
If you're unsure what a property name is called now I would suggest looking it up on the documentation site. It will have all the up-to-date names.
Important
As you may have noticed from the image above, some values have had their type changed in this release too. The only properties this relates to is follow_famping_value
. You need to adjust its value according to the new system — see the Improved Follow Damping Logic section further down the page for more info. As the effect of the value have, for all intents and purposes, completed shifted I would recommend doing a test in one scene, feel it out, and reapply values elsewhere based on that observation.
Logic Moved to _process
This might seem insignificant, but it does have a notable impact.
It will likely affect everyone, existing as well as new addon users, so would suggest following the steps in the “What can I do about it?” section further down for how to work with this change.
TLDR
- By default, setting a camera to follow a physics-based node will highly likely result in the followed node being very jittery.
- Again, see “What can I do about it?” section.
- Nodes that are moving in the
_process
or uses aTween
animation should no longer be jittery. - This isn't a complete solution and there is still work to be done.
A big thanks to @P5ina (for the PR) and @Lasuch69 for the discussing and helping with this change.
What was it before?
In previous releases, camera movement has been happening in the _physics_process
. This was initially in large part been due to playable characters, what the camera would also typically be assigned to follow, would be a physics-based node such as CharacterBody2D/3D
. This meant that as the physics object moved, along with the character asset within the physics object (i.e. sprite / 3D model), the camera followed it relatively evenly as the movement should both be happening in the _physics_process
.
Why has this changed?
While having the camera move in the _physics_process
meant that following a physic-based node was generally fairly smooth, it did also come with a few, no-trivial, issues.
The arguably biggest issue, was that animations that were being done in the _process
, such as anything using the built-in Tween
method, would always result in jitter. Either when it was being followed by the camera or were moving while the camera followed something else. Since not everything is, nor should, be moving in _physics_process
it highlighted an issue with the previous approach. As things stood, it was deemed not possible to solve while the camera moved in the _physics_process
and so it was changed to be occurring in the _process
instead.
Why is there suddenly more jitter, or jitter where there was none before?
If you're using a physics object as a follow or look at target, and it's set to move in the _physics_process
then you will likely notice jitter right away — even if you apply follow damping
.
A typical playable character would then often consistent of a node hierarchy like:
CharacterBody2D/3D
- Visual representation, e.g.
Sprite2D
or a `MeshInstanc...
- Visual representation, e.g.
v0.6.4
✨ New Features
Editor Updater Confirmation Step
As the addon gets more refined over time, leading to potential breaking changes, the updater now requires an extra step to be completed before it can be triggered for major or minor releases. The only practical difference is an added dropdown menu, where you have to select Yes
instead of the default No
option, which will then make the update button appear. This is to give a bit of friction and to give some thought before pressing the big green Update button and risk causing project side effects.
This will, however, not occur for patch or hotfix releases.
Major and Minor Releases | Patch & Hotfix Releases |
![]() |
![]() |
Term Reference Examples:
Major Release:
v0.8
->v1.0
Minor Release:v0.6
->v0.7
Patch Release:v0.6.4
->v0.6.5
Hot Fix Release:v0.6.4
->v0.6.4.1
Editor Updater Project Settings
Tip
You may have to enable Advanced Settings
in the top right-hand corner for the settings to appear in the panel. Alternatively, you can search for them.
Options to now disable the updater to two different levels (more below) have been added to the Project Settings
.
This is meant to better support released projects where no further work is happening, but where the project is occasionally being opened.
💡 Thanks to @lunarcloud for the suggestion (#203)
🛠️ Changes & Improvements
- Added support for rotational tweening in 2D scenes. (#225)
- 💡 Thanks to ZT2wo for the suggestion. (#214)
🐛 Fixes
- Resolved an issue where moving between multiple
Framed Follow
PCams would stack the dead zone fields in the viewport. (#226)- 🔍 Thanks @RichardStolp for the report (#208)
- Resolved an issue with setting various
SpringArm3D
properties such ascollision_mask
didn't get triggered during runtime. (#224)- 🔍 Thanks @eliaskowitz for the report (#222)
v0.6.3
🛠️ Changes & Improvements
- Added
follow_target_changed
signal that's emitted whenever aPCam
's follow target is changed.- 🏅 Thanks @ZenithStar for the pull-request. (#191)
- Added
Look At Offset
option forLook At Group
.- 🏅 Thanks @ZenithStar for the pull-request. (#197)