souplamp
commented
5 months ago Even the ability to put in an offset would be a significant improvement to its functionality. As it stands, you might as well create your own RemoteTransform2D/3D class to add the ability to respect the original transform (as I'm doing), but I expected this behavior to be available out of the box. Not to mention there might be a trade-off in performance (albeit slight).
Describe the project you are working on
A 2D game with cutout/skeletal animation.
Describe the problem or limitation you are having in your project
I created a plugin to automatically place all of the various sprites for my character rig using a json file (spine.json) generated from my graphics software. I wanted to try the simpler route of using cutout animation as seen in this tutorial: https://docs.godotengine.org/en/stable/tutorials/animation/cutout_animation.html
When I create a remote transform, and assign it's remote path, the sprite that it is being assigned to has it's transform overwritten. This renders preplacement of sprites useless.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
It would make sense to me that the remote transform should respect the original transform of the path that it is being given, rather than overwriting it. I don't know if this should be an option, or if I am misusing it, or if this is actually a bug.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Either remote transform should copy the transform of the remote path that is assigned to it (on assignment), or there should be an option that would allow you to do this.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I'm sure I could create a custom remote transform node that might work, however I don't see why developers should constantly have to reorganize and hand place graphics.
I can currently work around this by creating the remote transform as a child of the remote path that it will be assigned to. I can then assign the remote path. Then I can finally move the remote transform to where it is supposed to be.Edit: This turns out to be error prone and difficult to pull off as well.Another option is to use a full blown skeletal rig; I wanted to try this because it was supposed to be a bit simpler.
Is there a reason why this should be core and not an add-on in the asset library?
This seems like a borderline bug to me. I'm not sure if it is, which is why I am creating a proposal instead. This effects a core node and should not be an add-on.