Godot-proposals: Allow Spritesheets using the Frame property to expand horizontally

[golddotasksquestions]

Describe the project you are working on:
2D action game, card game

Describe the problem or limitation you are having in your project:
When working with the Sprite node and spritesheet textures, it's possible to expand the spritesheet in the vertical direction, but not the horizontal direction without breaking animation. (see minimal testproject below)

Issue:

Detailed description of the issue:

Graphic is from: https://github.com/godotengine/godot/issues/22553

Describe how this feature / enhancement will help you overcome this problem or limitation:
As it is now, for all practical sense and purposes, it is infeasible to increase the amount of drawn frames without tearing them apart on your spritesheet because of this limitation. Tearing them apart makes frame animations terrible to work with. Allowing horizontal expansion would allow me to iterate on those spritesheets without braking animation, something desperately needed. See minimal test project below.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Minimal test project:
expand_spritesheet.zip

Run the project and see the correct frame cells playing. To see the issue,

• drag the "test_spritesheet_expanded.png" into the Sprite texture,
• set "Hframes" from 7 to 11
• run the project again to see the wrong cells being displayed in any but green,
  Green is the first row, the cell attribution for green obviously is unchanged.

Describe implementation detail for your proposal (in code), if possible:
The Animation resource Frame value would just have to update if the Hframe property changed in the editor.

Download and try this visualization: Win, Linux, Mac.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This is about fixing a current poor design/implementation that impedes production.
The only workaround is to delete all done work on animation and reassign all animation key values again once the Hframe property changed.
Since 3.2, there is the option use the Frame Coords property instead of Frame property, but this means also deleting all work done on animation and reassign all animation key values again. In my case that's hundreds of frames per character. Worse even, because the Frame Coords property requires two values to be set, not one like Frames property, doubling the work load.

Is there a reason why this should be core and not an add-on in the asset library?:
It's an issue with an already existing and otherwise working built in feature.

[willnationsdev]

I've encountered this before. It was definitely an annoyance. +1 for this enhancement.

[groud]

I've encountered this before. It was definitely an annoyance.

Just to mention, if you start from scratch. The frame_coords property, which is a proxy for the frame property, does allow you to choose the frame you want with independant x and y coords.
So that if you layout your animation horizontally, you can use a fixed Y coordinate value on this vector and animate the X coordinate from 0 to N, N being the size of your animation.

Edit: And of course, if you use this, you don't have a problem if you increase the texture size.

[willnationsdev]

@groud Ahh, I see. So this is more about being able to, say, convert your properties from using frame to using frame_coords then? To make it easier to convert mid-project?

[golddotasksquestions]

@willnationsdev
This issue (like https://github.com/godotengine/godot/issues/22553) is about the Sprite Frame property, not the Coords Frame property, the Coords Frame property is a new addition since 3.2.

[groud]

So this is more about being able to, say, convert your properties from using frame to using frame_coords then? To make it easier to convert mid-project?

For me, yes, this the solution I suggested on the main repository issue, as that could be done with an editor script I believe. If someone want to work on that he/she is more than welcome. ;)

[groud]

Though, such script could only convert frame to frame_coords in animations, not the logic inside scripts. But such logic inside scripts should not be hard to convert.

[groud]

Also, if the problem is about not having it 3.1, we could eventually cherry pick frame_coords. It's not a big deal I think.

[golddotasksquestions]

For the thousands time Groud: This issue is not about the newly invented Frame Coords noone has asked for. It's about fixing an already existing issue with the existing Frame property.

If you want people to only use FrameCoords from now on, it means total breakage of comparability.
Maybe that's an idea work looking at for 4.0. But then where is the proposal for this feature? Where is the discussion to have that workflow changed?

[groud]

Sorry, you still don't understand that there are no fix to your problem by only using a single integer property. The solution to you problem needs two integers, which frame_coords does provide.

If you have a solution to this problem that 1) uses only the frame property 2) does not break compatibility with projects, you are welcome. Otherwise you are just chasing windmills.

[golddotasksquestions]

If you have a solution to this problem that 1) uses only the frame property 2) does not break compatibility with projects, you are welcome

A solution has already been proposed in the original issue as well as here in my proposal:

Describe implementation detail for your proposal (in code), if possible:
The spritesheet cell IDs would just have to update if the Hframe property changed in the editor.

So far I have not heard a single reason why this is not a good idea or why this would break anything or why this would not work with the Frame property.

Using something like Frame Coord might work as well, but it would completely and definitely break compatibility, so it's definitely no option for 3.X or anyone who already has a project.
Also, where is the proposal and discussion about this implementation?

[girng]

Hmm, I think in this case, having animations in a spritesheet structure like that, you can use region_rect with the AnimationPlayer to key frame what frames you want animated.

Or, you could just separate those card animations in their own file, instead of having 1 huge texture for a lot of animations. For example, Diablo 2's spritesheets have a fixed size with all frames filled up with a texture.

I'm pretty sure it's done like this for performance reasons (don't quote me though :P)

[groud]

The spritesheet cell IDs would just have to update if the Hframe property changed in the editor.

This is compatibility breaking, sorry. It would break projects that do change their sprite textures, and would also annoy all people that did not rely on horizontally layered animation. So this is not an acceptable solution.

[golddotasksquestions]

@girng My project is set up like diablo2 spritesheets, so they work with the Sprite node and the Animationplayer. Using region_rect is for optimization, using it during production would make things worse this, because iteration is even more difficult and laborious with region_rect.

[groud]

Also it would be a huge pain to keep track of the new mappings everytime they are updated. This would require a complex GUI (like a dictionary editor) which is far from ideal.

[golddotasksquestions]

This is compatibility breaking, sorry. It would break projects that do change their sprite textures, and would also annoy all people that did not rely on horizontally layered animation. So this is not an acceptable solution.

Can you please elaborate how this would break anything? Or how it would make a difference if spritesheeds are expanded vertically or horizontally? Because I honestly don't see it. The result of

Describe implementation detail for your proposal (in code), if possible:
The spritesheet cell IDs would just have to update if the Hframe property changed in the editor.

would be that the displayed frame in the animation stays the same, no matter how Hframe or Vframe changes.This would break exactly nothing, but the opposite, it would keep things from breaking.

[girng]

Wait a minute.. how does Godot know the developer is going to change the proportion in advance (and to what size) -- to update the keyframes accordingly?

[groud]

Let's say you have this 3x1 layout (situation 1):
1 2 3

When you reduce you hframe:
1 2

Increase vframe:
1 2
3 4

Increase hframe :
1 2 5
3 4 6

Decrease vframe (situation 2):
1 2 5

For the same hframe and vframe values, you end up with different results in situation 1 and 2. This is not acceptable.

Basically changing hframe and vframe (even to set them at the beginning) can lead to unexpectedly different results. So such solution is not acceptable.

[KoBeWi]

Yo, grab this script
convert_to_coords.gd.txt

This will convert all frames in currently selected AnimationPlayer to frame_cords. Make sure to run it before updating hframe values. You can test it with your example project, but it won't work in 3.2 alpha, because of bug which is already fixed in master.

As @groud said, what you are proposing is pretty unreasonable/impossible. When you increase hframes/vframes, the spritesheet isn't "expanded". It just calculates atlas offset based on the new values. If we made it vertical, it would totally break every animation. If your issue is only about conversion not frame_coords itself, the script should do fine.

Also frame_coords are the correct solution and don't break compatibility. If you are making a new project, you will probably use them. If you however have old project that use frames, just don't use frame_coords and it stays compatible lol

Hope the script helps. Cheers.

[groud]

@KoBeWi Thanks a lot for you hard work !

[girng]

Wow @KoBeWi , nice one

[golddotasksquestions]

Increase hframe :
1 2 5
3 4 6

Decrease vframe (situation 2):
1 2 5

@groud
You seem not to have fully understood the proposed solution @metaphoricalsasquash has proposed in their original post of https://github.com/godotengine/godot/issues/22553

As a reminder the problem we are talking about here is that the displayed cells _don't change_ while the assigned cells of the spritesheet _do change_:

To me, the solution proposed already in the original issue is simple enough:

Update the frame value and therefore the assigned cells of the spritesheet animation when Hframe has changed.

This would have all these advantages over other proposed solutions:

• No breaking of compability at all, be it with future projects or past projects
• No patchy scripts necessary
• How cells are assigned would stay exactly the same
• How cells are displayed would stay exactly the same
• How Godot users work with Frames would stay exactly the same
• Godot users could still use all existing features of the Animation Frame property, like auto-advance when keying.

Nothing would change, except we finally could expand spritesheets horizontally

This issue is a real hindrance to my productivity and creativity, and it's bugging me to no end. For this reason I also made a visualization of the solution for you specifically and to anyone interested. Please have a look at it:

You can play around with it for yourself if you want and I invite everyone else here too:
Win(tested): expandable_spritesheet_win.zip
Linux: expandable_spritesheet_linux.zip
Mac: expandable_spritesheet_mac.zip

[groud]

Update the frame value and therefore the assigned cells of the spritesheet animation when Hframe has changed.

This is impossible to do in a clean way. A node (Sprites included) is not aware about which Animation nodes are going to animate its properties. It's always the animation that references the animated object, never the other way around, because it would cause a lot of self-reference problem. Imagine you animate the hframe property in the animator, this would lead the animation to be modified while playing, an potentially screw up a lot of things.

Sorry, but this solution is not acceptable too. Kobewi's scripts solves the problem in a significantly less dirty way.

[golddotasksquestions]

As I would have hoped you would see from this visualization which you can try yourself, for this to work, the Sprite node only has to know about it's own Hframe and Vframe property values ... which I most certainly assume it does.
If Hframe changes, all it has to do is to tell AnimationPlayer that a change happened, and let AnimationPlayer know by how much so that AnimationPlayer Node can update the Frame values.
How can it get any more clean??

[groud]

If Hframe changes, all it has to do is to tell AnimationPlayer that a change happened, and let AnimationPlayer know by how much so that AnimationPlayer Node can update the Frame values.
How can it get any more clean??

Yeah, you made your point perfectly clear here. Still, this is not possible, for several reasons :
1) An AnimationPlayer will never modify its own Animation resources at run time, as resources might be shared,
2) An AnimationPlayer does not keep track of the properties of the node it modifies, so it cannot detect the change itself. This is not going to change, as this would lead to breaking behaviors if the Sprite was replaced at run time (remember that and AnimationPlayer node only store paths to the animated nodes, not the node themselves).
3) A Sprite node is not aware about the node that is impacting its properties, so there is no way to get a reference to the AnimationPlayer from the Sprite (and eventually tell it that to modify the corresponding animation track).

But in any case, that will not happen, simply because an animation will never be modified because a field in another node was modified. That would be a terrible design and UX idea, confusing a lot of people. An animation will stay the same, unless you willingly modified it in the editor (or via the API).

[golddotasksquestions]

An AnimationPlayer will never modify its own Animation resources at run time, as resources might be shared

It does not need to happen at runtime (though I do think it could). It's more than fine if it happens in the editor. It does not need to happen in real time in the editor either. For all I care there could be a button "Update frames" or a checkbox that is off by default.

An AnimationPlayer does not keep track of the properties of the node it modifies, so it cannot detect the change itself.

Again, the Sprite knows, Hframe is a sprite property. The Sprite detects.

(remember that and AnimationPlayer node only store paths to the animated nodes, not the node themselves)

The AnimationPlayer stores paths to the Animation Resource, which contains the frame values.
Just as the AnimationPlayer changes those values of the Animation Resource when changing an animation in the Editor, the AnimationPlayer can change the values of the Animation Resources it uses then the Sprite sends a notification that a change happened.

A Sprite node is not aware about the node that is impacting its properties,

Signals do exist for exactly this reason, do they not? What's wrong with having the Sprite node emit a signal "hey my Hframe changed" (this much)

[groud]

It does not need to happen at runtime (though I do think it could). It's more than fine if it happens in the editor. It does not need to happen in real time in the editor either. For all I care there could be a button "Update frames" or a checkbox that is off by default.

The problem is that, if you don't do the change right away (with a button), it means you have to store the previous value in the Sprite node. Such value must also be stored per AnimationPlayer, since you might have different AnimationPlayers animating a signal node. This is pretty messy and is unlikely to happen.

What's wrong with having the Sprite node emit a signal "hey my Hframe changed" (this much)

We generally avoid sending signal just to notify a property has changed. At runtime, signals might be heavy to process.

Well anyway, I think the discussion is stalling. I still don't understand why the solution of converting your frame animation to frame-coords is not a good solution to you. It keeps compatibility, is simple to do thanks to @KoBeWi, and does not involve a weird workaround to solve the problem. Anyway, I will let you convince other contributors that your solution is better.

[golddotasksquestions]

I still don't understand why the solution of converting your frame animation to frame-coords is not a good solution to you.

The difference is Frame Coords is a different and NEW property, only available in 3.2.

Using Coords _means_ breaking compatibility!

Users would have to experience this issue, go online, find this discussion, find KoBeWi's script, understand what it does and how to use it, apply it, and then end up with Animations that won't work in versions previous to 3.2. If they ever have to go back, because 3.2 has something that breaks their project (not unlikely considering what happened between 3.0.6 and 3.1), they can't use their animations any more.
Also as of now, auto-advance when keying is not working since Coord are Vector2. Because they are Vector2, they also double the workload when keying 2D animations, which is already a horrible experience because 2D animation does not have a working auto import like 3D animation does. Now you are suggesting making this experience worse for animators by doubling their work.
I'm amazed how you do not see those massive disadvantages. My only explanation is that you don't care that much about what this means in consequence for users like Animators, which is totally fine, but why engage here then?

On the other hand, using this proposal here whould have non of the disadvantages while having many advantages:

• No breaking of compability at all, be it with future projects or past projects
• No patchy scripts necessary someone has to find first
• How cells are assigned would stay exactly the same
• How cells are displayed would stay exactly the same
• How Godot users work with Frames would stay exactly the same
• Godot users could still use all existing features of the Animation Frame property, like auto-advance when keying.

I would actually appreciate if something like KobeWi's script would be built into to the editor, allowing people to switch between animating Frame property and Frame Coords
(which is a feature that had no proposal. Never was it inquired with users if this is wanted at all, or if it is practical to use for them, while other feature requests that are of immense practical use, have a proposal, are explicitly asked for by users, get shut down).

Anyway, a built in feature like KobeWi's script to transfer back and forth between Frame and Coords unfortunately is not reality right now. Discussing Coords is also not on topic:
This issue here is about fixing the Frame Property, which is still part of Godot, even in 3.2. Nothing else.

[groud]

The difference is Frame Coords is a different and NEW property, only available in 3.2.

No, as I said, frame_coord is a proxy for the frame property, it's not that different.
It's not even stored in the scene, as it internally modifies the frame property.

And yeah, it will be added into 3.2, but since it's not a compatibility breaking release, so it should not be a problem... And in the worst case, it could also be cherry picked into 3.1.x, but that is unlikely it will happen as this is, once again, not a bug.

Also as of now, auto-advance when keying is not working since Coord are Vector2. Because they are Vector2, they also double the workload when keying 2D animations, which is already a horrible experience because 2D animation does not have a working auto import like 3D animation does.

The auto-advance problem problem requires a dedicated issue. The auto import for 2D animations also.

Now you are suggesting making this experience worse for animators by doubling their work.

That's wrong, instead of choosing a frame out of col * row number, you choose a row an a column. It's even simpler than before to select a frame, especially when you have animations horizontally layered.

If they ever have to go back, because 3.2 has something that breaks their project (not unlikely considering what happened between 3.0.6 and 3.1), they can't use their animations any more.

Yeah, that's the problem with all updates. You have sometimes advantages and disadvantages in switching. It's up to you to choose what you prefer between having the newest features (may they be crucial to your workflow or not) and having less bugs.

fixing the Frame Property,

There is nothing to fix, it's not a bug. ;)

[golddotasksquestions]

That's wrong, instead of choosing a frame out of col * row number, you choose a row an a column.

You don't not even read what you write your self. This is twice the amount of work. It's setting one value versus two. Multiply this by a few hundred of frames an animator has to key, and you will see how doubling this kind of work is not a great idea at all.

[willnationsdev]

@golddotasksquestions Just trying to catch up here:

If I'm understanding the above content correctly, frame and frame_coords properties both manipulate the underlying frame property. So this is what people will need to do when starting fresh projects in 3.2.

For people in 3.1 migrating to 3.2, they will need to port their data over to use frame_coords from previously being frame. This entails needing to run a one-time tool script to update the animation data.

You are not satisfied with the above scripted solution because...

1. it requires people needing to encounter the problem, search for a solution, happen to find this proposal, find the script in the comments, and then...
2. run it in all of the instances of their project (so if they have 50 scenes that have AnimationPlayers, they would need to run this script 50 times by manually opening each of the scenes).

So, the discoverability isn't satisfactory and the execution is too manual for it to be a practical "fix".

Please elaborate on whatever parts of this are inaccurate. Just wanting there to be a productive conversation.

[golddotasksquestions]

Will, I have listed all the disadvantages above:

Users would have to experience this issue, go online, find this discussion, find KoBeWi's script, understand what it does and how to use it, apply it, and then end up with Animations that won't work in versions previous to 3.2. If they ever have to go back, because 3.2 has something that breaks their project (not unlikely considering what happened between 3.0.6 and 3.1), they can't use their animations any more.
Also as of now, auto-advance when keying is not working since Coord are Vector2. Because they are Vector2, they also double the workload when keying 2D animations, which is already a horrible experience because 2D animation does not have a working auto import like 3D animation does. Now you are suggesting making this experience worse for animators by doubling their work.
I'm amazed how you do not see those massive disadvantages. My only explanation is that you don't care that much about what this means in consequence for users like Animators, which is totally fine, but why engage here then?

And Coord _DO BREAK_ compatibiliy!
It's a Vector2. They are saved in the .tscn. Besides the massive downgrade in efficiency and usability, you cannot simply use those animations in anything prior to 3.2 without finding, using and understanding KoBeWi's. script, and write a reverse version of it.
How is that even considered as an option?

Here is it Black in White:

[gd_scene load_steps=3 format=2]

[ext_resource path="res://test_spritesheet04.png" type="Texture" id=1]

[sub_resource type="Animation" id=1]
resource_name = "default"
tracks/0/type = "value"
tracks/0/path = NodePath(".:frame_coords")
tracks/0/interp = 1
tracks/0/loop_wrap = true
tracks/0/imported = false
tracks/0/enabled = true
tracks/0/keys = {
"times": PoolRealArray( 0, 0.1, 0.2, 0.3, 0.4 ),
"transitions": PoolRealArray( 1, 1, 1, 1, 1 ),
"update": 1,
"values": [ Vector2( 0, 3 ), Vector2( 1, 3 ), Vector2( 2, 3 ), Vector2( 3, 3 ), Vector2( 4, 3 ) ]
}

[node name="testing_coords_scene" type="Node2D"]

[node name="Sprite" type="Sprite" parent="."]
texture = ExtResource( 1 )
vframes = 5
hframes = 11
frame = 37

[node name="AnimationPlayer" type="AnimationPlayer" parent="Sprite"]
anims/default = SubResource( 1 )

"values": [ Vector2( 0, 3 ), Vector2( 1, 3 ), Vector2( 2, 3 ), Vector2( 3, 3 ), Vector2( 4, 3 ) ]

[groud]

And Coord DO BREAK compatibiliy!

They break backward compatibility, not the forward one. We never ever guaranteed backward compatibility. Just do a backup before switching.

[golddotasksquestions]

So your "solution" is to force users to use the workflow which has never been asked for, is new, doubles the effort, is super cumbersome, not tested, not backward compatible. And if they are dumb enough to create new work with this method they are stuck with this workflow that is just worse in every aspect of usability, or loose it all.

Great.

How about something that is:

• Not breaking of compability at all, be it with future projects or past projects
• No patchy scripts necessary someone has to find first
• How cells are assigned would stay exactly the same
• How cells are displayed would stay exactly the same
• How Godot users work with Frames would stay exactly the same
• Godot users could still use all existing features of the Animation Frame property, like auto-advance when keying.

[groud]

So your "solution" is to force users to use the workflow which has never been asked for, is new, doubles the effort, is super cumbersome, not tested, not backward compatible. And if they are dumb enough to create new work with this method they are stuck with this workflow that is just worse in every aspect of usability, or loose it all.

Listen, do whatever you want... As I said before, what you propose is unlikely to be implemented as built-in as we try to avoid workarounds when simple alternative solutions exits. But I'll let other contributors tell their opinion.

[golddotasksquestions]

Coords is the workaround (a workaround that does not make things better, but worse). The simple solution would be to have a Sprite emit something like a signal when it's Hframe changes.

[groud]

Coords is the workaround. The simple solution would be to have a Sprite emit a signal when it's Hframe changes.

How do you know, did you ever contributed ?

[clayjohn]

Okay. This is getting too far. Both of you have said what you need to say. Let's let others who are interested come and add their opinions.

[LikeLakers2]

I read a bit through this issue, and talked with golddotasksquestions on Discord about it, and I would like to address two points.

---

First off, I think many people in this issue seem to be misunderstanding golddotasksquestions' issue. golddotasksquestions' issue is about the frame property not updating automatically when hframes changes. The reason he takes issue with that is for two reasons:

1. When hframes changes but frames does not change with it, the sprite changes to a different texture, which can be a problem when we're changing hframes because we added new sprites.
2. Since frame_coords is simply a wrapper around frame that returns a Vector2 by doing some math with frame and hframes, the frame_coords property itself gets a different value, as hframe has changed but frame has not adjusted with it.

As frame_coords is a wrapper around frame, and is not its own value, frame_coords would not be able to solve this issue even if he used a script 50 times over.

--

Just to make this clear, let's give an example. Let's say we have a 3x5 grid of frames -- hframes is 3, and vframes is 5. This means that the frame property can be anywhere from 0 to 14. Now let's say our current frame property is 3. This means that frame_coords will return Vector2( 0, 1 ) -- 1st column, 2nd row.

Now let's say we wanted to change the number of horizontal frames, because we've added new sprites farther to the right than our current sheet goes. Let's say we go from 3 hframes to 4 hframes. However, frame has stayed at 3 because it did not change with hframes.

Because hframes has changed, but frame has not, we now get a different texture. frame_coords now also reports as Vector2( 3, 0 ) -- 4th column, 1st row -- which is correct, but it does not solve the issue of frame now referring to an incorrect frame.

--

The solution to this issue, then, is to have frame change with hframes. In the example above, frame would need to be adjusted from 3 to 4 in order to continue referring to the same frame. This is what golddotasksquestions is asking us to do, as it would allow the frame value to continue referring to the same coordinate in the sprite-sheet.

---

Second off, I want to address you directly, @groud. (I apologize @clayjohn, but I really can't let this sort of thing go unmentioned.)

Coords is the workaround. The simple solution would be to have a Sprite emit a signal when it's Hframe changes.

How do you know, did you ever contributed ?

I find it disheartening that you consider this an appropriate way to treat our users, groud. The Contributor tag that GitHub gives you upon a PR merge is not some special crown that you should be flaunting. It does not give you the ability to say "yeah but I know better" any time you want, especially because even you should be able to admit that you don't always have the correct answer.

Really though, this "I'm a contributor, and you're not, so you don't know like I do" comment is just plain rude. It can push people away from wanting to contribute their ideas and PRs to Godot, as it tells them their contributions are unwelcome. It tells them that their thoughts are worthless, that they shouldn't bother commenting because some dude with a name-tag is gonna get on them for not being a contributor next time they suggest an idea.

If you want to tell someone that their solution would not work in some way, then say so. Say "I don't think this solution would fit with the engine." Say "I see a problem with that solution." Please, say literally anything that would actually help to further their understanding of what could be the correct solution. Many people will usually appreciate being shown how their ideas don't fit, so long as you aren't being rude about it...

But please, don't say stuff like this, because this sort of comment is just... wrong.

[groud]

This is not how we treat our users, groud. The Contributor tag that GitHub gives you is not some special crown that you get to flaunt like some special privilege. It does not automatically give you the ability to say "yeah but I know better", because even you should be able to admit that you don't always have the correct answer.

Sorry, but someone who never contributed to a software codebase does not have everything needed to understand what is a good solution or not. As I already stated, his proposal goes against a lot of Godot basic design principles, so calling that "simple" is quite wrong. If he has the best solution, then let him implement it.
Otherwise, let users have problems and contributors solutions, not the other way around.

But yeah, sorry for the ad-hominem attack.

Because hframes has changed, but frame has not, we now get a different texture. frame_coords now also reports as Vector2( 3, 0 ) -- 4th column, 1st row -- which is correct, but it does not solve the issue of frame now referring to an incorrect frame.

That's why you should animate the frame using the frame_coords property, not the frame one. In that case everything will stay the same.
Though for the default situations (no animation), if we want to keep the visible frame the same, we should likely replace the stored value by frame_coords (frame would become a proxy to frame_coords). That should solve this problem.

[golddotasksquestions]

Sorry, but someone who never contributed to a software codebase does not have everything needed to understand what is a good solution or not.

I forbid my keyboard to type a single letter, but the arrogance in this comment as well as the ones you made before is slowly oozing like thickened clustered septage from the cracks between the letters of my display and falling directly onto my keyboard keys. Ruining everything.

[LikeLakers2]

someone who never contributed to a software codebase does not have everything needed to understand what is a good solution or not. As I already stated, his proposal goes against a lot of Godot basic design principles, so calling that "simple" is quite wrong.

If you insist on that line of thinking, then I question why you can't just... I don't know, tell him how it goes against those principles? It's a more productive use of your time than simply insulting someone, and it helps people to understand what is a good solution or not so that they can contribute.

If he has the best solution, then let him implement it.
Otherwise, let users have problems and contributors solutions, not the other way around.

I think this completely goes against the way Godot's userbase is meant to be handled. Indeed, contributors will typically have more knowledge, and non-contributors will typically not have more knowledge (that's just how it happens to go). But this statement tells me that you still only care if they have that shiny Contributor tag, which is why I got on you: I want you to stop that sort of behavior because it's just plain rude. It tells people that their ideas are unwelcome simply because they don't have a piece of text next to their name.

Knock it off, groud. Please. It's rude. There's absolutely no excuse for treating people this way. If you can't stop yourself from treating people this way, then please prevent yourself from commenting, because you're making the other contributors (like me) look bad.

---

That's why you should animate the frame using the frame_coords property, not the frame one. In that case everything will stay the same.

I'll admit that this would be the way to go, (and you seem to agree that we should update frame when updating hframes) but I would like to point something out.

As willnationsdev previously said (albeit, it was him trying to understand golddotasksquestions' side), it's not really a practical fix for existing animations (which can be a problem in big projects). To do it for existing animations, one would have to find this script, and then run it again and again, once for each of the scenes that contains an AnimationPlayer. It's really tedious.

I wonder how we could fix that... perhaps by including this sort of script in the engine itself?

[willnationsdev]

@LikeLakers2

perhaps by including this sort of script in the engine itself

This is, to my knowledge, generally something that shouldn't be included with the engine. If anything, it would be in some kind of dedicated repository in the godotengine organization that contains utility scripts and tools for handling Godot (in a meta sense). I don't think anything like that exists, but it probably should, for exactly things like engine version migration utilities and whatnot.

To do it for existing animations, one would have to find this script, and then run it again and again, once for each of the scenes that contains an AnimationPlayer. It's really tedious.
I wonder how we could fix that

You would probably have to iterate over all scenes in the project, detect which ones are scenes, load them, instantiate them, insert the current script's logic against that scene, re-pack that node tree into a PackedScene resource, and re-save that resource, all without breaking the code. And this would all be something you can put in the one EditorScript.

Edit: You would probably also need to detect if a scene is a derived scene and then process its base scene prior to handling the current scene, ensuring that you take care of any base scene's AnimationPlayer nodes before attempting to override things in a derived scene.

[groud]

tell him how it goes against those principles?

I already did that countless times.

Ok, I will stop here. I already did enough for this issue to be solved, and my point has been made countless time. I know for sure that what @golddotasksquestions suggested will never be implemented, for reasons I stated above.

Edit: and that is basically all I tried to explain.

[LikeLakers2]

@willnationsdev

This is, to my knowledge, generally something that shouldn't be included with the engine.

My first thought was "why not?" But I think I can agree with you, too.

That said, we would still need to make it easily visible, even if it's in a separate repo. That's sort of what I was getting at (and it's my fault for not clarifying that). I worry that it won't be easily known about, and I was wondering how we could fix that. We'd probably have to advertise it in multiple places.

---

@groud

I already did that countless times.

Would you mind showing me where? I took a quick look through all your comments, and I could not find a single place where you explained what principles it goes against, let alone how it goes against those principles. Perhaps I missed something? Or perhaps my understanding of your comments is different from yours? I would like it if you could help me with that.

[groud]

https://github.com/godotengine/godot-proposals/issues/151#issuecomment-542301053 (maybe not countless time though, I have to admit ^^. I indeed spent more time trying to explain why we don't consider this as a bug)

[willnationsdev]

My first thought was "why not?"

My understanding of Godot's design policies (not written down anywhere, but just from contributors' sentiments in decision-making over the years) has been to avoid storing any sort of one-off functionality/utility needed as a built-in feature.

For example, anything related to fixing version migration problems is not something that should be bundled into the engine itself since that would needlessly bloat the engine source code with stuff that is not actually relevant to building and editing games on a daily basis. It is a meta problem, related to transitioning between editors.

If anything were to be added to the engine source code related to editor migration problems, it would be some sort of info popup accessible from a Help submenu that would provide users with more information about where to go to get help with migration problems (e.g. a link to a repository dedicated to engine migration scripts).

The editor should never be dealing with meta problems imo. It should just be concerned with being itself, dealing with the problems that it generates on its own.

[golddotasksquestions]

I don't know what the best solution to this is. I was just trying to provide a solution, with the very limited means I have.
The only thing I do know for sure, is that Coords are not at all the solution (not an improvement) coming from a perspective of a user who would have to use them a lot.

[phantomdesvin]

I think it is clear that you have different opinions and have explained them quite well. I am not going to give an opinion because I do not understand the subject in depth, but I believe that this topic would benefit from the attention of more experts in the field.

[groud]

Also I wonder about two things.

You said it doubles the work of the animator because you have two values to set. But when you are animating, most of the work is only incrementing the x values, since your animations are layered horizontally. Are you referring to another specific situation ?

Also, I don't understand how is it easier for you to index a frame in a 2-dimensional matrix with only one index value instead of two row and column indices. Could you elaborate? Because for me using two indices definitely makes more sense.

[KoBeWi]

@golddotasksquestions With https://github.com/godotengine/godot/pull/32973 and https://github.com/godotengine/godot/pull/32992 merged, there's no disadvantage to using frame_coords instead of frame. I also submitted my script to Asset Lib, so if someone ever wants to convert their animations for whatever reason, they might eventually find it.

IMO, the proposal was satisfied. You can of course keep this open and wait for someone that'll code what you proposed, while sticking to Godot's coding standards, but personally I doubt it will happen.

[golddotasksquestions]

@KoBeWi Thank you! These look like great improvements to the Coords property usability that seem like they bring the Frames property and the Coords in terms of UX pretty much on par. I will have to do some testing as soon as they are in a nightly build!

As for the Frame property, which this issue is about, this leaves me with a bunch of questions:
Is the general consensus here to completely replace the Frame property with Coods property? Because if those PRs are merged and work as expected, we will have two almost identical properties.
If Frames won't be fixed, are we going to silently assume everyone will migrate to Coords knowing what the differences are? As you can see in the lengthy introduction to this issue here, they are not easily explained within a tooltip.
What's the Frame property's purpose then? Should it be removed in 4.0? Considering new and old users will have considerable difficulties telling their purpose apart (rightfully so).

Personally I think it's generally very problematic to invent new properties to fix existing ones, but if inventing a new property to fix an old one in this case really is the _only_ proper way to fix this issue and UX is on par, I'm extremely thankful for the addition.

I actually was in the process of preparing a longer reply in to the last questions here directed at me, however if those work as expected, I won't finishing it and instead change it into a new proposal when I find the time.

Thanks again!

[gioele-santi]

I found out this today. I have to admit I have always worked with premade spritesheets and using frame was never an issue. But when working while an artist takes care of the sprites, it sounds problematic and confusing to use a different properties. I think there should be just one way to reduce confusion. So it can be consistent for all workflows.

[golddotasksquestions]

I still don't know why the frame property can't be fixed.
If I rename a node in the Scene Panel, the track Node paths in the Animation resources get updated as well. How is that different from updating frame value in the Animation resources when the Hframe property changed in the editor?