Regarding the subject above, the game crashes when returning to the original scene after the object with BindObjects configured (as described below) is destroyed.
Configure BindObjects on Object 1 (add connection data to connect and generate the object).
Place Object 1 in Scene 1.
Destroy Object 1 in Scene 1.
Transition from Scene 1 to Scene 2 using a portal.
Return from Scene 2 to Scene 1 using a portal.
The game crashes.
The issue does not seem to occur when generating objects via Visual Studio.
We would appreciate it if you could look into this matter.
■ godot.log
Action Game Maker 1.2.10 based on Godot v4.4 - ACTION GAME MAKER 公式ホームページ
Vulkan 1.2.154 - Forward+ - Using Device #0: Intel - Intel(R) UHD Graphics
CrashHandlerException: Program crashed
Engine version: Action Game Maker v4.4.1.stable.custom_build
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] <couldn’t map PC to fn name>
[1] <couldn’t map PC to fn name>
[2] <couldn’t map PC to fn name>
[3] <couldn’t map PC to fn name>
[4] <couldn’t map PC to fn name>
[5] <couldn’t map PC to fn name>
[6] <couldn’t map PC to fn name>
[7] <couldn’t map PC to fn name>
[8] <couldn’t map PC to fn name>
[9] <couldn’t map PC to fn name>
[10] <couldn’t map PC to fn name>
[11] <couldn’t map PC to fn name>
[12] <couldn’t map PC to fn name>
[13] <couldn’t map PC to fn name>
[14] <couldn’t map PC to fn name>
– END OF BACKTRACE –
I attempted to reproduce the issue under the following conditions, but it did not occur. Is there any step I might be missing?
Set Object 2 on Object 1 using BindObjects, with no enable/disable switch settings. The connected object is set from the moment the scene loads (Object 2 is in its initial state, an empty object).
Set Object 1 to destroy itself after 1 second, and place it in Scene 1.
Prepare a separate player object, wait for Object 1 to disappear, then use a portal to transition from Scene 1 to Scene 2.
Return from Scene 2 to Scene 1 via the portal.
No crash occurs, and Object 1 appears and disappears again.
I believe the steps are correct, so it’s possible that some of my settings are affecting the issue.
I have attached a test project that reproduces the issue. Could you please take a look when you have a moment?
■ Test Project
testproject_2026-05-11.zip (1.4 MB)
① After launching, Object 1 disappears after 1 second.
② After launching, the child object disappears after 2 seconds (the issue occurs even if the child object is not destroyed).
③ Move the player and transition from Scene 1 to Scene 2 via the portal at the edge of the platform.
④ Move the player and transition from Scene 2 to Scene 1 via the portal at the edge of the platform ★ Crash occurs here.
Thank you for the reproduction project!
I was able to confirm it in this project, and I will report it to the development team.
I tried changing various settings, but I don’t know what the difference is… I wonder what it is…
I was unable to perform the desired actions, but the crash stopped occurring after I enabled the “Release Movement Control” checkbox on the child object.
I’m not sure if this will be helpful for your investigation, but please let me know if you need anything else.
Thank you for the additional investigation!
It seems like it might be crashing while trying to follow the vanished parent object…
I’ll submit a report.
Regarding this issue, the crash problem has been fixed in version 1.2.11, which was released today.
However, this issue involved two combined factors:
A crash occurs when the parent object is marked for deletion during object generation via BindObjects (← the issue reported by you).
For the respawn condition “when the scene switches,” when returning after switching scenes, the objects originally in the scene and the respawned objects duplicate, resulting in two instances.
Regarding point 1, I have also confirmed that the crash does not occur.
Thank you for your prompt response.
Regarding point 2, as you mentioned, I confirmed that after the object disappears, switching scenes and returning causes the disappeared object to stop moving or duplicate into two objects.
We appreciate your continued support in addressing this issue.
Regarding this, the splitting issue is also reproducible in version 1.2.12.
Additionally, there appears to be a bug where the “Execution State on Spawn” is not executed.
Please review the steps we performed below.
■ Steps Performed
① Delete one object, switch scenes, and return
The splitting event does not reproduce, but the object’s “Execution State on Spawn” is not executed.
Switch scenes again and return.
→ The object’s “Execution State on Spawn” is executed.
② Delete two objects, switch scenes, and return
The splitting event does not reproduce, but the “Execution State on Spawn” is not executed for either object.
Delete the objects in the above state, switch scenes, and return.
→ The deleted objects are splitting.
Regarding this issue, while the splitting behavior is not reproducible for certain objects, performing steps ②-1 to ②-2 causes a different problem: damage processing triggers the moment the object enters the camera frame, resulting in the object disappearing.
It seems that the “Execution State on Spawn” not running is likely the culprit, but the exact conditions remain unclear…
Regarding this, the “execution state upon appearance” is, as the name suggests, triggered only when the unit first appears and does not activate upon revival from destruction.
Therefore, would it be possible to work around this by creating a link that returns the unit to its initial state after it is destroyed?
When returning to the initial state unconditionally after destruction, the object becomes invisible, but the VS (Visual State) after the initial state is still being executed. (Enemy attacks still hit the player object)
If I wait for the object to completely disappear before returning to the initial state, the object is already gone, so it cannot be returned to the initial state.
－－－－－－
The following are my thoughts, and I would appreciate it if you could review and consider them.
Due to my implementation, I am managing multiple (minion) enemy objects in a single VS, so the above workaround is difficult to apply.
→ It would be necessary to branch the target initial state using variables, etc.
I find it somewhat unnatural that objects revived via the post-destruction revival condition in BaseSettings do not execute the initial state.
→ Considering the splitting event, since revival internally places a different object, the initial state should arguably be executed. Also, in an action game, it feels more natural for enemies to execute their initial state upon revival.
→ If the initial state is not executed upon revival, I would like an option to set a “state to execute upon revival.” (It would basically be the initial state, so it might not be very useful, but still.)
Since this involves a change in behavior, we want to consider it carefully, but you’re right—it does seem like the better option. We’ll discuss it with the development team.
In any case, since it doesn’t seem to be working well to transition to the initial state after disappearance in VS, I think at least some kind of workaround is necessary.
Sorry for the inconvenience, but I appreciate your help.
We checked with the development team, and it turns out my understanding was incorrect.
It was clarified that the state executed upon revival is not the last state that was running, but rather the “initial state”.
If a state other than the initial state is being executed, it might be a bug.
Regarding the “state at spawn”, we are currently exploring whether we can support this for revival as per your request.
To avoid conflicts with the existing specifications, we may add a new setting called “state at revival”.
I just checked, and it seems that upon revival, the “Initial State” was executed. Therefore, it doesn’t appear to be a bug.
However, as it stands now, if we were to:
Place zombies that move left and right on this platform,
And place zombies that track the player on that platform,
then executing the “Initial State” upon revival would likely prevent each zombie from performing its intended behavior after reviving.
It might be possible to create separate objects and VS for each behavior, but that would feel overly complicated.
Regarding the “State at Appearance,” we are currently exploring whether it can be supported upon revival as per your request.
To avoid conflicts with existing functionality, we may introduce a new setting called “State at Revival.”
Thank you for your consideration.
Personally, I believe that simply executing the “State at Appearance” instead of the “Initial State” upon revival would be sufficient to resolve the issue.
That said, as you rightly noted, there may be aspects I’m not fully aware of regarding interactions with existing features and legacy behavior. I apologize for troubling you with your busy schedule, but I would greatly appreciate your continued consideration on this matter.
We have implemented this issue by adding the “State on Resurrection” setting in version 1.2.13, which was released today. Thank you for your understanding.
Thank you for adding the execution state on resurrection.
I have confirmed that the newly added feature is functioning without issues.
We sincerely appreciate your consideration of our proposal and your prompt response.
However, while the issue does not reproduce in the test project, I am encountering an object splitting phenomenon in the project I am developing for some reason.
As the cause is unclear, I will conduct some investigation and verification.
Additionally, although it is uncertain whether this is caused by the recent revision, the following issue is occurring.
I have attached the test project for your review. Thank you for your confirmation. testproject_2026-05-26.zip (2.1 MB)
■ Reproduction Steps
Prerequisites (Enemy Settings):
• Display Direction: Set to face the player using FaceDirection
• Movement: Set to approach the player via Template Movement
• BaseSettings: Enable the Left/Right Flip Mode
• Execution State on Appearance and Execution State on Resurrection: Set to something other than the initial state
Steps:
After launching, press the Z key to attack and defeat the enemy object.
Transition to Scene 2 via the portal on the right.
Transition back to Scene 1 via the portal on the right in Scene 2.
★ The enemy object approaches the player while facing backward.
If you repeat steps 1–4 without ending debug mode, the enemy object approaches the player facing the correct direction.
It appears that the above issue does not occur (and the enemy faces correctly) when the Animation Category Name for the Initial State is left unset (blank or a hyphen).