Add a option to support games with 3d disabled

[beicause]

Project Type

2D

Feature Description

Currently this addon doesn't work with export template compiled with disable_3d=yes becase it depends on Camera3D. Users have to manually modify the source code to support 2d-only export template, which is Inconvenient.

Use Cases

For games using export template compiled with disable_3d=yes

(Optional) Proposed Solution

No response

[ramokz]

Been looking a bit into this, and can replicate the issue.

Is the workaround that you're describing a case of modifying the source code and then compile an export template with disable_3d=yes, or "just" manually modifying the source code to achieve the same result as setting the disable_3d=yes flag?

[beicause]

@ramokz sorry, I mean modifying the source code of phantom-camera ( remove all PhantomCamera3D and Camera3D mainly in plugin.gd, phantom_camera_3d.gd phantom_camera_host.gd)

[ramokz]

Gotcha, yes, that's not an ideal workflow to deal with.

I am not sure if there's a way around it without having to make the reference to Camera3D and PhantomCamera3D weakly typed, which I'm not too keen on. The issue seems to predominantly lie in the PCamHost script in just a few specific places, more specifically line 33, 75, 348 and 364. This is just based on the 2D example scene, so can't say if there are more areas that could trigger the issue.

Can't verify if this is true, but would suspect it would be more durable with a GDExtension rewrite of the addon, as that would allow for better modularity, but don't see that happening anytime soon.

[beicause]

I think there is a way. Built-in class is registered in ClassDB so it can be detected if 3d is enabled by ClassDB.class_exists("Camera3D"). There is also object.is_class("class_name"), or object.get_class(), so PhantomCamera2D and PhantomCamera3D can be detected, too. We just need to remove static type. phantom_camera_3d.gd should be excluded in export_presets.cfg by user manually since PhantomCamera3D must extend Node3D.

[ramokz]

You're right, made it work without changing too many things. Have merged the changes (#311) into the 0.7.2 branch.

Only needed to override the built-in functions of get_class() and is_class() in the PCam3D to make it work.

From a few export samples, it doesn't appear that changing the export_presets.cfg is necessary. At least, I am not seeing any warnings or errors related to 3D nodes from the export.

I'm still not a fan of the loosely typed approach, but am an even less of a fan of not supporting this. Will just have to rely on this approach going forward, which isn't the worst compromise.