[Trigger] Critical strike for 1 attack?

[Ironside]

Hello, I'm trying to make an ability which gives you critical strike for your next attack.

I tried adding critical strike and remove 0.2 seconds after the unit attacks, but it happened that he made either 0 attacks or even above 1 attacks.

So how would I make it for only 1 attack.

One hero using it is ranged and one is melee.

 

[PurplePoot]

Preferably write a damage detection system and just trigger the critical manually.

 

[Bribe]

Even better, use an existing one.

http://www.thehelper.net/forums/showthread.php/137957-GUI-Friendly-Damage-Detection
http://www.hiveworkshop.com/forums/jass-functions-413/snippet-damageevent-186829/
http://www.thehelper.net/forums/showthread.php/131287-Damage

Just to name a few.

 

[PurplePoot]

If you want to use an existing one then IDDS is probably better than all of those.

 

[Bribe]

I specifically ruled out IDDS because of it's flaws:

1) Its ill-conceived recursion-handling technique is much slower than the other systems when more events are registered.

2) It's "priority triggers" could lead to multiple libraries asking for priority 1 and only one of them actually getting it, a design flaw.

3) Lots and LOTS of event leaks over time as he's never destroying the trigger for units who were removed.

Yes Weep's library has those event leaks but it is at least in GUI which is a good start for a beginner whereas if he goes for vJass he should go for something that is coded with more modern and strict standards.

 

[Ironside]

Thank you for the answers +rep.

I have decided to use: http://www.thehelper.net/forums/showthread.php/137957-GUI-Friendly-Damage-Detection

EDIT: I'm unable to give reputation to PurplePoot yet, sorry.

 

[PurplePoot]

I specifically ruled out IDDS because of it's flaws:

1) Its ill-conceived recursion-handling technique is much slower than the other systems when more events are registered.

Unless I'm missing something it just fires all the triggers again. Even if there's some magically better way to do this that I'm unaware of, performance isn't a huge problem in damage detection systems.

2) It's "priority triggers" could lead to multiple libraries asking for priority 1 and only one of them actually getting it, a design flaw.

The only alternative is removing that function entirely. It's up to the mapmaker to use priority responsibly.

3) Lots and LOTS of event leaks over time as he's never destroying the trigger for units who were removed.

You realize there's a reason dynamic triggers are frowned upon and he leaves events there forever, right? DestroyTrigger is one of the most buggy functions in wc3 and was the cause of many years of nightmares for coders back in the days of gamecaches (although, strictly speaking, it can still cause problems even if you aren't relying on H2I/GetHandleId). Destroying triggers means you assume the user of your system knows much of the entire history of JASS bugs (and is aware that you're destroying triggers), which is a bad assumption.

The fact that all three of those systems use DestroyTrigger and nobody seems to care worries me.

 

[Bribe]

Whatever occurrences of DestroyTrigger that once existed have never happened for any scenario I've come across. I've spoken with a lot of people who have been coding post-return-bug and they have not come across any problems either. I've done a lot of work using GetHandleId mixed with plenty of destroyed triggers and haven't had any sharing conflicts. So all evidence suggests this bug was quietly fixed by Blizzard and you're welcome to prove me wrong because nothing I've done has been able to recreate this error.

As for the performance issue during iteration, it handles recursion by resetting all global variables to the recursion-safe local variables for every iteration. If he managed it better like Nestharus did or even like Jesus4Lyf did, the end-result would be much more logical and efficient code.

 

[PurplePoot]

I'll give the DestroyTrigger thing a shot later; I don't have access to the editor at the moment. However, I've definitely experienced "chaos" bugs post-vJass so I wouldn't rule them out just because a few people haven't had (or haven't recognized) issues with them.

As for performance, if your argument is based around setting a few variables that might be able to be set a few less times then it seems rather irrelevant.

 

[Bribe]

As for performance, if your argument is based around setting a few variables that might be able to be set a few less times then it seems rather irrelevant.

It's a logical anomaly for which the punishment should be letting it rot because painful to the brain.

 

[Ironside]

I tested it now, it didn't work for the ranged unit though.
All attacks were critical which were fired in the main time while the ranged heroes first missile was flying even when the critical was already removed.

 

[PurplePoot]

I tested it now, it didn't work for the ranged unit though.
All attacks were critical which were fired in the main time while the ranged heroes first missile was flying even when the critical was already removed.

You'd have to attach a flag to the unit which is turned off after the unit hits once.

--

Bribe, here's proof that the bugs with DestroyTrigger still exists (not sure where you got the impression that Blizzard stealth-fixes engine bugs anyhow...). Copypastad from the old wc3c thread on the subject to guarantee that it's the exact same thing.

 

[Weep]

This thread appears to have gone irrecoverably off-topic.




------------------

3) Lots and LOTS of event leaks over time as he's never destroying the trigger for units who were removed.

Yes Weep's library has those event leaks

Perhaps you should re-read the code? I do destroy triggers for removed units. That itself may leak, but if you have a suggestion for a DDS that does not create an event per unit, I'm curious to know.

Bribe, here's proof that the bugs with DestroyTrigger still exists

Oh, waiting twice after destroying a trigger? I thought that was well-known and that nobody would actually do that if they code a system that destroys triggers?

 

[PurplePoot]

Oh, waiting twice after destroying a trigger? I thought that was well-known and that nobody would actually do that if they code a system that destroys triggers?

It's less well known than you'd think. Also, it's a more general case of "don't destroy triggers until you're done with their threads unless you don't mind shit getting real".

More importantly, there isn't really any reason to destroy them. The event leaks are negligible and you're much safer to boot. As a general rule, if you must destroy triggers at least do so in a context where you control all the code they're executing, not in a public system which allows plugins.