Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scene files not updating region for sub-resources when the linked .tres file is updated, causing all animated sprites, etc to be wrong #56767

Closed
chucklepie opened this issue Jan 13, 2022 · 3 comments · Fixed by #56796

Comments

@chucklepie
Copy link

chucklepie commented Jan 13, 2022

Godot version

3.4.2

System information

PopOS

Issue description

If you have a .tres file pointing at a region of a graphic file and an animation file using it, then update the tres file region, any references to it in scene files (e.g./i.e. AnimatedSprite) are not updated because they are themselves hard-coding the region in sub-texture section and not updating themselves when tres files are updated. The result is while the .tres file is ok, all uses of it inside a scene file now point at the wrong place.

A typical example is a sprite sheet/atlas that is rearranged (e.g. texture packer), causing everything to become invalid.

Here a snippet from a .tres file:

region = Rect2( 96, 32, 32,32 )

Here is the .tscn file reference for the first region for an AnimatedSprite:

[ext_resource path="res://assets/image.tres" type="Texture" id=2]
[sub_resource type="AtlasTexture" id=12]
atlas = ExtResource( 2 )
region = Rect2( 96, 32, 32,32 )

As you can see it is referencing 96,32 for the region in the .tres file which is correct and has also duplicated this to refer to each sprite in my .tres file.

So, update the spritesheet and tres file now becomes:
region = Rect2( 64,32, 32,32 )

This is correct. Note the position has changed, opening the new .tres file shows the correct same image. However, the .tscn file still has this:

[sub_resource type="AtlasTexture" id=12]
atlas = ExtResource( 2 )
region = Rect2( 96, 32, 44, 64 )

It has not updated, i.e. it is ignoring completely the .tres file change. I don't know whether .tscn file should be storing region as an offset for .tres files or whether Godot should know there's been a file change and update sub-regions, but either way, it's not working.

Steps to reproduce

  1. Open the project and open the .tres file and note the graphic
  2. Open the scene Animated Sprite and note it is correct
  3. Close Godot, rename/delete the image.png and image.tres, and rename image-new.png and image-new.tres to be image.png and image.tres, i.e. to simulate changing the file because it is an atlas that will change (manually or via texturepacker)
  4. Repeat step 1 and 2 and note the tres file is correct, however the animated sprite is now wrong

Minimal reproduction project

tres_not_updated.zip
s

@chucklepie chucklepie changed the title scene files hard-coding pixel locations for sub-resource regions on .tres files causing errors when .tres file is updated scene files not updating region for sub-resources when the linked .tres files is updated, causing all animated sprites, etc to be wrong Jan 13, 2022
@chucklepie chucklepie changed the title scene files not updating region for sub-resources when the linked .tres files is updated, causing all animated sprites, etc to be wrong scene files not updating region for sub-resources when the linked .tres file is updated, causing all animated sprites, etc to be wrong Jan 13, 2022
@chucklepie
Copy link
Author

@Calinou I've simplified the text and added a test project with instructions.

@akien-mga akien-mga added this to the 3.5 milestone Jan 14, 2022
@chucklepie
Copy link
Author

@kleonc
Thanks, erm, when will 3.5 be coming out? and is there any workaround in the meantime?

@kleonc
Copy link
Member

kleonc commented Jan 14, 2022

when will 3.5 be coming out?

When it will be ready. 😄 Should be Q1 2022, I can be only guessing when exactly. But if my fix would be merged in then you could expect it in the next beta version I guess (beta1 is already out). So you could be using such version if you don't want to wait for 3.5.stable.

and is there any workaround in the meantime?

I don't see a simple workaround for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants