■ On a separate note, a small fix:
The character no longer flips direction when pressing the backward arrow key during an attack.
Thank you.
I see. Watching the video, it appears that during hit stop, the enemy (the one taking damage) doesn’t actually stop. Instead, the transition condition “when hit by an attack” keeps being satisfied, making it look like the enemy is rapidly bouncing back and forth between the “stunned” state.
In that case, each time the enemy’s stunned state changes, the hit stop seems to be overwritten, giving the impression that time is passing slowly from the moment of the final hit until the processing completes.
As a workaround, you could try configuring the enemy so that when it receives a jab attack, it toggles its own switch (or variable), and while that switch is ON, the stunned state is disabled.
Please test whether it’s possible to set up such a transition condition to prevent rapid, consecutive hits.
I understand that switches can be created using VariableSettings.
Disable hit detection while ‘on’.
Is there a tutorial or guide for this?
There are many mechanisms in the original ActRaiser that I haven’t encountered before. I’ve been trying various things, but it feels like I’m going down the wrong path and can’t reach the method you suggested.
I’ve tried disabling HitArea2D by changing properties, but there was no noticeable effect. I’m also looking for the optimal procedure to set the duration, but I can’t seem to find it…
1 Like
I mentioned it lightly, but for the ACT MV…
Parent: Transparent judgment object
Child: Enemy image (animation management)
I was thinking of a system that creates enemies this way.
I’ll become AGMaker and check if it’s possible with just one object.
This was a proposal to remove the “stun” state for characters who have taken damage, but doing so would likely prevent them from receiving attacks of other attributes.
How about removing the AttackCollision of player2 during the stun state?
This would eliminate the hitbox and serve as a measure to suppress consecutive hits.
Additionally, I sense behavior suggesting that “the processing for consecutive hit stops is not working properly.”
Please investigate and report back.
1 Like
Thank you.
Indeed, if the enemy’s hit collision is removed, it could create situations where other attacks, such as placed weapons or techniques, fail to hit. This might lead to player dissatisfaction.
Is my understanding correct that this method is implemented on the enemy’s damage state side? Or was it a method implemented on the player side?
It seems best to handle this in the [Enemy Defeated State] triggered by being hit.
Please try specifying the player2 attack slot by changing the property.
1 Like
It seems we successfully disabled Player2’s AttackCollision by modifying its property in the enemy damage state.
The issue of rapidly toggling between normal damage and continuous damage states, as seen before, has been resolved.
The return-to-idle animation also moves snappily and smoothly.
As a result, even when pressing buttons at a normal gameplay speed, combos no longer trigger.
If you perform rapid button mashing like Hashimoto Meijin, combos will activate, but as before, the hit stop and visuals become misaligned during these combos. We are currently investigating the hit stop functionality and appreciate your patience.
1 Like
How about adjusting the link transition for player2?
If “hit detection and collision” is active, player2’s attack detection is already nullified by the enemy, so I believe meeting the condition would be difficult.
■ Alternative Proposal
-
Assign an “attribute” to each of player’s attacks.
-
Enemies perform a dedicated “stun” state specific to each attribute.
-
While in the stun state, the enemy increments player’s variable [Attacked] by 1.
-
After recovering from the stun state, the enemy decrements the added amount.
-
Player can launch the next attack only if the variable [Attacked] is ≥ 1.
I will send the project adjusted in GGG for hitstop verification via GUILD email.