Rarely, the properties of the state’s execution action are modified incorrectly.
The two execution actions in the attached image are identical, but the upper execution action does not work, while the newly created lower execution action works. The version is 1.41. I apologize if this is due to some oversight on my part, but if verification is needed, I can send you the file.
Yes, I think it would be nice if you could send in the file so we can take a look at how that Object is configured more deeply, if you don’t mind?
Out of curiosity, was the upper action copied or duplicated from somewhere else, or made fresh on that state? I’m wondering if it’s holding onto an older resource somehow, which could explain why the newly created one works and that one doesn’t. Paste as Unique or right-click and making it Unique might solve it.
This major version update has indeed caused many compatibility issues with resource configurations.
For example, I encountered an issue where overlapping two objects resulted in screen artifacts.
However, by right-clicking the resources and reimporting the assets, the issue was resolved.
Additionally, some object instantiation processes threw errors, which I suspect were also caused by the version upgrade.
Therefore, I didn’t rush to fix them immediately. Instead, I plan to investigate which specific areas are causing conflicts between the old and new versions.
PS. Some of my audio resources also threw errors after the new version update. I resolved this by manually reloading each resource one by one.
Thanks serbow, that lines up with what I was wondering. @PIero, was the upper action created before you updated to 1.4.1? With the backend moving up a Godot version, I think maybe actions saved under the older version are holding onto resource data the new version reads a little differently, while ones you make fresh get written the new way. That could explain why the new copy works and the original doesn’t even though the inspector shows them identical.
Before sending the file, maybe try Project → Reload Current Project first. If that doesn’t change anything, close the editor, delete the .godot folder at the project root, and reopen so everything reimports clean, that’s what cleared a stale cache for someone on Discord recently. If the upper action still misbehaves after that, sending the project in like Bellamy asked would let us compare the two actions at the resource level.
The non-functional action was created by copying and pasting an action made before the update into one created after the update, and then uniquifying it.
The “Reload Current Project” option had no effect.
I haven’t tried reimporting all resources, but since my project already uses a large number of sounds and animations, doing so would be a massive undertaking.
In serbow’s case, it was an image bug, whereas in my case, it involved changes to collision masks and collision layers. Although this is just my amateur opinion, I don’t think there is an issue with the resources themselves.
Since the newly created actions are working properly, I will continue using them as is. If I encounter any issues with images or sound, I will try reimporting.
I have already sent the file, so please feel free to ignore it.
Thank you. So there are such issues as well.
If I encounter similar symptoms, I’ll refer to the solution method.
Back up the project files, then manually delete the .godot folder as Mr. Baz suggested. After deletion, start AGM. This won’t cause any loss; it simply clears the cache from the previous version of AGM, so just wait a moment for AGM to reload. AGM will clear the operation history from the previous version, but this has little impact—simply reopen the scene. If an error occurs after clearing the cache, click “Reload Project Files” again to try.
Thank you. I launched AGM after deleting the .godot folder.
The previous history and opened scenes were reset, but the issue’s property changes still did not work. I’m not sure of the cause, but it feels like this execution action itself broke for some reason, unrelated to the update.
Well, it doesn’t seem to be a version update issue. Honestly, if you’re not too keen on digging into it, you can just delete the old stuff and use the current version to resolve it—haha. That said, a deeper investigation is also worthwhile.
Thanks for sending the project in, I was able to reproduce it and dig into what’s going on. The copied action isn’t broken. Comparing the two at the resource level they’re identical, so copy and paste and Make Unique are fine.
What’s happening is that when the object starts moving in a state, AGMaker writes the base collision_mask from the object’s settings back onto it. The collision_layer isn’t touched, only the mask. In ダッシュ素通り the upper pair runs before MoveInDisplayDirection, so the mask gets set to 1 and then immediately overwritten back to 3 when the move starts. The lower pair runs after the move has already started, so its change sticks. If you drag MoveInDisplayDirection above the upper pair, that pair works too.
So for now, any ChangeObjectProperty on collision_mask needs to sit below the movement action in the list.
