Thank you for your message.
I have a few questions regarding the behavior of the lock system.
As a premise, we are creating knockback and other behaviors in the following sequence:
An attack hit occurs → Lock the object → Manipulate the locked object.
-
In the same state, locking an object that was hit by an attack → changing the game speed of the locked object does not work.
→ Even if I add a wait or other actions to wait for the lock to complete, the object does not respond as long as it’s set within the same state.
However, movement of the locked object does work, so I believe the lock itself is being applied correctly.
-
Sometimes the lock release does not occur.
→ This is a bit complex. For example:
[Attack State]
- Release lock (to remove any existing locks)
- Set attack hit detection
- Set attack parameters
- Lock
- Move the locked object
- Release lock
We have created two such states (A and B), and made them accessible from AnyState. When A and B are executed consecutively, movement of the locked object occurs even if B does not hit.
The expected behavior is that the lock should be released in the first action, and re-locked only when a hit occurs again. Is this the intended behavior?
I would appreciate it if you could kindly confirm this for me.
Sorry, but issue #1 has not been resolved yet, though the mystery may have been solved.
It seems that when changing the game speed, the only affected object is “the object locked by this object.” Since the object responsible for attack detection and the object running the .vs file are different, the condition “locked by this object” might not be met.
However, the object movement target is “locked objects,” which has a different scope, so movement might still work.
If this is indeed the cause, could you please add “locked objects” as a target for game speed changes as well?
Game speed adjustment is a great feature, so I would greatly appreciate your support.
Thank you for the update!
- We will report back after confirming.
- Regarding item 2, it appears that the lock release is configured to occur only at the end of the state, and we have reported this to the development team.
1 Like
Currently, the lock object does not support “cross-border locks” (one-to-many locks). While it is possible to configure one-to-many settings via the “parent object” specification when modifying variables, bugs still remain.
Hello,
Could you please provide more details about this issue?
I have tested the behavior, and it seems that locking multiple objects using the lock object is functioning correctly.
Is it correct that changes cannot be applied all at once unless a path is specified in the “Change Property” action?
I will check with the development team to see if it’s possible to avoid specifying the target path, similar to how the parent object is specified.
That is correct. Currently, it is possible to lock multiple objects within the hit detection range or on the screen, but when executing actions such as “self variable = locked object variable,” you must specify a single object. At present, only the “parent object” specification provides the functionality to batch-change related variables across objects.
1 Like
Thank you, I will try it.
This is a feature I was expecting, so I am very grateful.
1 Like
2.について色々試してみたのですがうまく再現できずでして・・・再現可能なプロジェクトを頂くことは可能でしょうか。gigafile便などでこちらに貼り付けていただくかメッセージでお送りいただけると大変助かります
1 Like
Thank you for your verification.
In this case, since the state is being switched and executed via AnyState, I believe the root cause is likely the phenomenon where “the lock is not released until the state ends.”
(This is because the state is being switched without going through a state end transition such as the end of an animation.)
If that issue is resolved, I will conduct additional verification based on the results!
Thank you very much.
Regarding this, it seems the issue where “it remains locked until the state ends” was actually my own verification error, and it appears to be unlocking correctly…
1 Like
I see, sorry for the trouble. This is happening in my own project…
I’ll recreate the state from scratch since its behavior is a bit off, and send you the project again once it happens again.
Thank you so much for your help late at night!