How do I make M1 Cancelling like deepwoken

[TheCraftNCreator]

@synical4

Yes, I know. I’m helping a beginner. This solution DOES work just fine. It’s not perfect, and I’m fully aware it can be improved. I personally always do client animations. This doesn’t mean that server animations don’t work.

Client-sided animations are very easy to do and the price of not using them can be servere.

@synical4

The logic behind cancelling an M1 that I provided can easily be expanded into other systems with a bit of intuition. I provided help code; not a full system for him to copy and paste.

You’d have to make a new bool for every attack, whereas with a newproxy() (or incremented number, whichever is easier for you), you only need one.

@synical4

Disagree strongly.

What’s a use case for animation events where they aren’t outpreformed by other methods? Maybe if you plan on having a time-slow mechanic, but that would be very complicated for a beginner progammer. task.wait() is much easier to understand, adjust, and work with.

@synical4

Again, I provided a simple example that is easy to understand. I wouldn’t do hitboxes this way at all. But for a beginner, this is a great place to begin.

You’re telling me that task.wait() is more complex than using an animation event? Let me compare the two:

function Attack1()
	task.wait(x)
	Hitbox()
end

function Attack2()
	AttackAnimation:Play()
	local AnimEvent
	AnimEvent = AttackAnimation:GetMarkerReachedSignal("DealDamage"):Connect(function()
		Hitbox()
		--Sure, you could disconnect here, but what if there's multiple DealDamage events?
	end)
	task.wait(x) --oh wait, we end up using task.wait anyways.. shame.
	AnimEvent:Disconnect()
end

I’d also like to point out none of your functions appear to disconnect, causing memory leaks.

@synical4

Same reasoning for everything else above

Fair point, but if client sided hitboxes were to be used, your system could not send the RemoteEvent early (and then have the client wait based of the time it took for the event to go through) to sync up the hitboxes.

@synical4

There’s nothing wrong with using simple code to achieve results.

Simple code is great! Until the results needed cannot be given by adjusting the simple code, and you need to rewrite the whole system to be more adaptable anyways.

[synical4 (Synical)]

Alright alright I do realize my method was kinda trash but I honestly didn’t put a whole lot of thought into the reply before recommending a way to do it.

I do agree that client animations and hitboxes, not using animation events, and other ways besides bool variables are the better method in the end.

My reply wasn’t intended to be the end all be all of how you could accomplish an attack feinting system. There’s about a thousand different ways to do anything in this engine and I think it’s a bit silly to debate which is the best. It really just depends on the game itself, which we don’t have enough context for.

[Hierophant_Bean (Bean)]

it worked the best and I already have an animation client script anyway also i’m not that much of a beginner but for whatever reason this stumped me even though it seems as if the fix wasn’t too hard