Zephyr Contest #9 - Results

Pharaoh_ · Sep 4, 2012

-Kobas-

Concept (7/10)

Creative (4.5/5)

Unique (2.5/5)

Well, it's pretty much an overpowered impale ability, but there are some nice extra effects in there. It's not very unique, but somewhat creative.

Coding (15/20)

MUI & Leakless (6.5/8)

Bugless (5/5)

Efficient (2/5)

Documentation & Comments (1.5/2)

It's MUI.

You have no leaks, except for one drastic mistake: You need to remove the dummy units. UnitApplyTimedLife applies timed life, meaning the unit will DIE when it's time finishes. This is why you need to remove the dummy by registering a death event to a function in which you remove the dummies.

It's bugless, as there are no bugs that I could produce.

It's not really that efficient in terms of function call handling. You stored GetTriggerUnit() into a variable, but you repeated the call inside the code anyways. Also, it would have been better to store the triggering player into a variable too since you're in need of him inside a loop. GetOwningPlayer(GetTriggerUnit()) could be replaced with a variable pointing to the triggering player. Finally, you have a ton of dummies in there, so it would be very beneficial to use a dummy recycling system like Dummy by Nestharus. The GetTargetsAllowed function could be inline friendly here. GetUnitState could be replaced with GetWidgetLife.

Well, you have documentation stating the requirements and giving links to them, and you have comments in important places (meaning the globals and the configuration functions), so I can't actually remove points here, but it would've been nice to have more comments inside the code. And since I don't know where to remove points due to the lack of configuration for the effect and the number of spikes and some other misc things, I'll remove a 0.5 here.

Visuals (7.5/10)

Relevant-to-Theme Effects (3/4)

Quality of Tooltips (2.5/3)

Quantity of Effects (2/3)

Well, the effects are sort of relevant to the theme of assassination in terms of gore and stealth, but I'm incredibly unsure here. The tooltips do explain exactly what happens. Colors would have been nice though. As for the quantity of effects, well, 36 dummies is not a good choice, but you chose very light models with low polies, so good job. It still looks like it's hogged with effects. :/

Total: 29.5/40

Dr.Killer
Concept (3/10)

Creative (2/5)

Unique (1/5)

Okay, with all due respect and complete honesty, it's not a very good concept. The only unique part I can point out is that enemies with low hp in range are shown.
Coding (8.5/20)

MUI & Leakless (4/8)

Bugless (2.5/5)

Efficient (0/5)

Documentation & Comments (2/2)
Well, it is MUI, but you have several leaks here and there. You need to null local agent variables (units, players, etc...). You should also null the struct members when you destroy the spell instance to avoid having handle ids that never get recycled.

There is one bug that has to do partly with Multi-unit-instanceability. If I continuously cast the ability, the wind walk will wear off depending on the first instance of the spell. A good solution for this would be to add 1 to some array for each unit so you can support stacking instances of the ability.

This would really benefit if it used UnitIndexer by Nestharus because your current GetUnitById function is incredibly slow. Iterating over all units on the map for a simple task that can be replaced with one simple and fast inlining function that just does an array lookup is a no-no. I mean really, that function is what made me deduct like 2 points on it's own because of how FEROCIOUS it is.
I'll quote myself to list all the improvements that the code could have:
I would totally recommend looking into UnitIndexer by Nestharus. It has a GetUnitById function. A fast one too. Your method of enumerating over every unit on the map to get the unit given the id is very inefficient. His function is just an array lookup that inlines. I /can/ approve this while using AutoIndex, but the cost is just too much :/

The GetDistance library's functions should just be in your spell resource. In fact, you don't need them because you can do them in the actual code directly and optimize them by removing the square root =o. You can remove the square root and just compare the retrieved distance value with your maxDist thing multiplied by itself.

You can merge the actions and conditions into one function that has an if block to determine whether the spell should execute or not, and you'd just register that function as a condition and return false at the end since conditions run faster than actions. In fact, you can even use a system like SpellEffectEvent by Bribe for this.

In the onInit function, you should null the triggers.

In the attackCondition function, you should null the units. You don't even need to store them into variables, just use GetAttacker() instead of 'attacker', and don't declare victim because you aren't using it.
I would totally recommend handling all the targets differently.Use a hashtable or a Table to store the targets and an integer to store the number of targets. The IsUnitGroupEmptyBJ functions enumerates over all units in the group, thus, it's slow. And you don't need to the set the movement of the unit to UNIT_MAX_SPEED inside the if block in this block of code since you're setting it at the end anyways:
JASS:
        if not IsUnitGroupEmptyBJ(object.targets) then 
            set originalSpeed     = GetUnitMoveSpeed(object.caster)
            set object.speedBonus = originalSpeed*SpeedBonus(object.lvl)
            set finalSpeed = object.speedBonus+originalSpeed
            if (finalSpeed > UNIT_MAX_SPEED) then 
                set object.speedBonus = object.speedBonus - finalSpeed + UNIT_MAX_SPEED
                set finalSpeed = UNIT_MAX_SPEED
                call SetUnitMoveSpeed(object.caster, UNIT_MAX_SPEED)
            endif
            call SetUnitMoveSpeed(object.caster, finalSpeed)
        endif
Modifying movement speed is not a very good thing to do. It could conflict with other systems. A good solution would be to use some standard movement speed system. I think there are a few in the JASS section on this site, but I never really use any of them, I just code my own.

You don't need to initialize tempGroup inside the onInit function, you can do that in the declaration of the group.

GetWidgetLife is faster than GetUnitState when wanting to retrieve unit HP values.

Why are you repeating GetOwningPlayer(caster) if you just stored it into a struct variable? And it would be faster to set the owner variable to the triggering player since it points to the same thing but takes less arguments.

When I mentioned how you should handle the group-emptiness checking differently, I forgot to say that you can simply set a boolean to true inside the loop after you add units to your target group. Then, instead of checking if the group isn't empty, just use that boolean in the if block.

== true is the most redundant thing ever. You can remove it and get the same results.

GetOwningPlayer(temp.caster) -> temp.owner
Although it doesn't really affect the mechanics of /this/ spell, using onAttack events is frowned upon. Using damage detection is way better in my opinion. Still, I won't let that harm your score, I'm just pointing that out.

You have a ton of comments, and your documentation is present. Good job.
Visuals (8/10)

Relevant-to-Theme Effects (4/4)

Quality of Tooltips (1.5/3)

Quantity of Effects (2.5/3)

Okay, I didn't judge this based on special effects, but spell effects. The effects are totally relevant. The spell doesn't have too many of them too, but the tooltips could be clearer. It wasn't very clear that the damage would be dealt while I was wind-walked. Another thing, you put the wrong damage value in the tooltip, because now, the tooltips seem to mean that while windwalked, I'd deal 300, else, I'd deal a bonus 100; Which I don't. Colors would've been nice too :<
Total: 19.5/40

mckill2009

Concept (7.5/10)

Creative (2.5/5)

Unique (5/5)

Okay, I have to be honest, it's quite unique, which is great, but it's pretty boring. Still, there are some creative effects put in there, so I can't give you a very low score. I only deducted points because of irrelevancy. If it was more relevant, it would get a 9 or a 10.

Coding (17/20)

MUI & Leakless (8/8)

Bugless (4.5/5)

Efficient (4.5/5)

Documentation & Comments (0/2)

Dude, I really wish you could've done this in JASS. GUI hurts my eyes ._.

It's MUI, and there are no leaks. Okay, well done.

As for bugs, there are none that I could produce.

It would be a bit more efficient if you would cache the triggering player into an array variable instead of repeating it inside the loop (you aren't actually repeating it, but you're getting the owner of the portal unit :/

The number of projectiles and the effect should be configurable.

Currently, it's not very readable, and since the "Documentation & Comments" field is only there to take into account readability, I'll have to deduct points there.

You don't need to preload the effect currently because it's in the MPQ file, but if you make it configurable, then leave the preload line there since the effect may or may not be in the MPQ.

There is only one small error. Your enemies would have vision on you when you cast the sub-ability on an enemy unit for a fraction of a second. I don't know how to fix, so I'll only deduct 0.5 here.

Visuals (7/10)

Relevant-to-Theme Effects (1/4)

Quality of Tooltips (3/3)

Quantity of Effects (3/3)

The effects were not really relevant to the theme of assassination (Fire-balls, beacons, etc..). The tooltips are well done. The spell is not too hogged with special effects.

Total: 31.5/40

Jazztastic

Concept (7/10)

Creative (4/5)

Unique (3/5)

It's an upgraded version of the default wc3 fan of knives, and it's a pretty good spell.

Coding (16.5/20)

MUI & Leakless (7/8)

Bugless (4/5)

Efficient (3.5/5)

Documentation & Comments (2/2)

The only leaks you have are unit leaks. These units do not actually get removed unless you remove them. You should create a trigger, register a death event, and if the unit type of the triggering unit is equal to a dummy, then remove it from the game. This means that you shouldn't be killing them, but adding 1-second expiration timers to them. This is because you want the death animations to play.

This simple spell lags Warcraft III to 0.4FPS for me after about 6 simultaneous casts :/

To improve performance, you should only store the group of units in the loop trigger once, then check if the number of units in that group is greater than 0, and deal damage to a random unit in that group. In fact, you could deal damage to FirstOfGroup(udg_group) because that retrieves a unit from the group without having to do an enumeration. The group enumerations are the reason this spell lags so much.

In the cast trigger, you can cache the owner of the caster (or the triggering player) into a variable because you're repeating him over and over again. (If it's in a loop, it's repeated)

As for bugs, well, other than the fact that knives can move on top of cliffs, I couldn't produce any. It would've been nice if you removed knives that tried to escape the map bounds instead of keeping them in though.

You have comments, and importing instructions, /and/ configuration instructions, so good job.

Visuals (9/10)

Relevant-to-Theme Effects (4/4)

Quality of Tooltips (2/3)

Quantity of Effects (3/3)

What can I say? It creates knives that move and go 'poof' when they hit something. The quantity is good, and they are relevant, so "ok". The tooltips were descriptive enough, but it would've been nice to see some colors in there :3

Total: 32.5/40

defskull

Concept (10/10)

Creative (5/5)

Unique (5/5)

I really like the concept. It's pretty unique and creative.

Coding (17.5/20)

MUI & Leakless (7/8)

Bugless (5/5)

Efficient (4.5/5)

Documentation & Comments (1/2)

Okay, this spell is completely MUI, but there is only one leak. The dummy shuriken is not completely removed from the game. It still exists occupying a handle id. You should remove it from the game instead of killing it.

There are no bugs that I could produce. I have the ability to shuriken units that have already been shurikened, but I don't think that's a bug, it is actually supposed to be possible to launch more than one shuriken at a unit.

This spell is very efficient, as it uses a single dummy throughout the game to cast dummy spells, it uses coordinate setting in some places rather than using the slow GUI MoveUnit action. (Of course, you are using it once when moving the dummy, but that shouldn't matter much because this isn't the kind of thing that makes you lose points here.).
Improvements:

In the loop trigger, when you have an if block to determine the value of z1, you can simply set it to z2 in the Then block of code.

The above point also applies to the cast trigger.

When moving the shuriken, you can cache it's coordinates into local variables or something, because while the shuriken is being moved to the target unit, you'd end up calling it twice.

In the cast trigger, you can cache the ability as a real so you don't have to continuously call I2R(SS_AbilityLevel).

These are all just minor improvements, and they aren't very significant.

As for comments and documentation, well, you have lots of documentation in the setup trigger, which is awesome, but there are no comments inside the actual triggers to make the spell a bit more readable or anything :/

Visuals (8.5/10)

Relevant-to-Theme Effects (4/4)

Quality of Tooltips (1.5/3)

Quantity of Effects (3/3)

Shurikens, strings, transparency, -> relevant.
The tooltips only list raw information. They could be much better.
The quantity of effects is perfect.

Total: 36/40

chukkyjr

Concept (8/10)

Creative (4/5)

Unique (4/5)

Okay, it's somewhat unique and creative. Good job.

Coding (17/20)

MUI & Leakless (6.5/8)

Bugless (5/5)

Efficient (3.5/5)

Documentation & Comments (2/2)

The spell is MUI, but you have a group leak, and there is a double free error. temp_group leaks because clearing the units in a group is not enough to free the memory. You need to destroy the group using the DestroyGroup call. Also, you don't have to remove those 3 points inside the "Then - Actions" code block in the looping trigger since you're going to remove them at the end of the trigger anyways.

There are no bugs that I could reproduce.

Your function call handling is good in some places, but a bit off in a lot of others. Key(...) is equivalent to GetHandleId(handle), so you could store whatever handle you want
into a variable, then get it's key using GetHandleId(udg_handle) in custom scripts. You can also cache the facing of the target and the angle between the points inside the 3rd group enumeration code of the periodic trigger. Finally, the owner of the caster should be stored into the hashtable and looked up, then stored into a variable in the group enumeration code because the owner of the dummy is going to point to the same value as that of the caster, so you might as well just store the owner into the hashtable and look him up as well.

You have a good amount of comments inside your code, so, good job.

Visuals (10/10)

Relevant-to-Theme Effects (4/4)

Quality of tooltips (3/3)

Quantity of effects (3/3)

The effects are relevant to the theme of assassination.

The tooltip looks just like the standard wc3 hero ability tooltips.

The effects in this spell are very elegant and subtle.
(Never thought I'd use that word to describe assassination effects)

Total: 35/40

bowser499

Concept (4.5/10)

Creative (2/5)

Unique (2.5/5)

The concept is relevant, but it's quite generic :/

Coding (13.5/20)

MUI & Leakless (7/8)

Bugless (3.5/5)

Efficient (1/5)

Documentation & Comments (2/2)

The spell is MUI. You have one leak though. You need to null 'newclone'.

There is one issue. When I cast the spell the first time, about 12 or more apparitions are created in a large radius, but every other time, only 2 are created. Note: They aren't being created next to enemy units. Also, using bj_lastCreatedGroup is never a good solution. It /will/ create bugs if a trigger is triggered inside your enumeration code using bj_lastCreatedGroup as a group to enumerate over as well. It's always better to just use your own global group :/

Efficiency problems and general code issues:

One timer per spell instance is really not a good idea for high speed timers.

SaveUnitHandle is faster than SaveAgentHandle

You don't need to cache the triggering unit or the spell target in your cast function since you're only referencing them once.

WEAPON_TYPE_WHOKNOWS is the same as null.

ATTACK_TYPE_NORMAL and DAMAGE_TYPE_NORMAL should be configurable.

Would've been better to cache the owner of the caster.

Would've been better to use a local trigger in the init function instead of the silly udg_ global.

Documentation is present and you have decent comments.

Visuals (6/10)

Relevant-to-Theme Effects (2/4)

Quality of tooltips (3/3)

Quantity of effects (1/3)

Creating dust everywhere and on every tick of the spell is both not very stealthy and inefficient. The tooltips were excellent though.

Total: 24/40

Xiliger

Concept (9/10)

Creative (5/5)

Unique (4/5)

I like the concept. It's creative, but not 100% unique.

Coding (5/20)

MUI & Leakless (4/8)

Bugless (2/5)

Efficient (-1/5)

Documentation & Comments (0/2)

The spell is MUI, but the code is full of local handle leaks. Not a single local handle is removed.

You have a location leak in the GUI trigger (Dagger Shadow Step)

You aren't nulling struct data.

You're leaking a rect in your crowLoop method.

The Shadow Step trigger uses the "Begins casting" event making the spell exploitable. (Bug)

The unit death checking is done incorrectly. 0.405 is the magic number, but besides that, you should use the IsUnitType(u, UNIT_TYPE_DEAD) approach while checking if the unit type of the unit is not 0. (Bug)

The spell can destroy bridges and uses no form of tree detection. (Bug)

This spell is not efficient. You have one timer per spell instance, you're using slow, buggy libraries (EasyDamage, Basic Library), you're using an entire group to check for units range WITHOUT ending the enumeration upon finding one, you're using dynamic groups, the bounds checking is more complicated than it needs to be, etc..

In the GUI triggers, you aren't caching data into variables to avoid repetition.

The libraries you're using are not encapsulating their globals when needed.

The libraries you're using have no proper documentation with a listing of the API (The functions)

The documentation only contains a spell description instead of a listing of importing instructions and such.

In the Conditions function, you don't need to return true. Just check if the spell is equal to ABT1, call Data.create(...) and return false at the end of the function.

Not all values are configurable. They should not be hard-coded. A user should have the ability to modify almost everything concerning his spell in one configuration block without having to go through all the code.

The reason I said using one timer per spell instance is inefficient is because you're using high-speed timers. If you were using low-frequency timers (Expiring 2 or 3 times a second or less), it would be fine. Here, you're using timers that expire 20 times a second. As soon as these timers accumulate, the map will lag. Timers expiring at the same time cause lag spikes.

Visuals (10/10)

Relevant-to-Theme Effects (4/4)

Quality of tooltips (3/3)

Quantity of effects (3/3)

The effects are relevant, they are perfect, and the tooltips are excellent.

Total: 24/40

Radamantus

Concept (7.5/10)

Creative (3.5/5)

Unique (4/5)

Okay, the spell is a combination of non-unique spells with one unique twist.
In terms of creativity, it's good, but I found it pretty boring.

Coding (17/20)

MUI & Leakless (7.5/8)

Bugless (4/5)

Efficient (4/5)

Documentation & Comments (1.5/2)

The spell is MUI and leakless. There is one tiny issue though. You're destroying a floating text which you're loading from a hashtable and then recreating one. This means that you would be destroying a null floating text the first time.

There are no bugs that I was able to reproduce. But there is one issue. You're using an Attack-event for a trigger to deal damage to a unit making the spell very exploitable.

The spell is fine in terms of efficiency. I don't like having many group enumerations done, but I can't expect all of you to know how to work with linked lists.

There are parts of your code that could be a tiny bit more efficient, but it would be silly to remove a lot of points for them. (Setting a variable, then using it could sometimes be replaced with simply using the value if the variable is only going to be referenced once)

You have a ton of comments and configuration information, but you lack importing instructions.

Visuals (6/10)

Relevant-to-Theme Effects (2/4)

Quality of tooltips (2/3)

Quantity of effects (2/3)

The tooltips are excellent, but the hero isn't actually hid from the minimap, so -1. (It was either this, or a -1 on the "Bugless" field in the coding D
The effects are actually very good, but you're giving the dummy units collision and you're not creating them based on whether the caster is moving or not making them look quite wierd. Also, the "100% transparency" thing is quite strange. Casting the ability makes me less transparent and yet the enemy heroes /can/ see me and fight me, but the passive 100% transparency makes me approachable

Total: 30.5/40

InfinateAnswers

Concept (10/10)

Creative (5/5)

Unique (5/5)

The concept is perfect.

Coding (11/20)

MUI & Leakless (4/8)

Bugless (2/5)

Efficient (4/5)

Documentation & Comments (1/2)

Unfortunately, the spell is not MUI. The Decieve_Dummy variable can be overwritten. (I tested of course)

As for leaks, I'm glad to tell you there are none.

The spell has no bugs I can produce, but there are terribly unwanted effects that take place. The caster should not be removed from the game. This could potentially mess up the entire map. What if I stored data to the unit using a unit indexer or a hashtable? Both the handle id and the unit custom value will be different if you remove the unit from the game and recreate it. This is a /huge/ bug.

Another problem with the spell is the fact that the "backstab" detection is not perfectly accurate. Facing values in Wc3 can be negative you know :/

In terms of efficiency, well you could've cached some things into variables instead of repeating them over and over again. (Like the triggering unit, the attacking unit, etc..)

As for the comments, good job, there are comments everywhere, and the code is quite readable! ^.^

The only thing missing is the importing instructions.

There is one problem with the code involving the configuration, as there are some things that should have been in the initialization trigger present for the user to configure the spell to his liking (The out-of-combat duration for example). There is no field here concerning configuration, so I'll remove a 0.5 from the Documentation & Comments score and a 0.5 from the "Bugless" score. (1.5 -> 1 and 2.5 -> 2 respectively)

Visuals (10/10)

Relevant-to-Theme Effects (4/4)

Quality of tooltips (3/3)

Quantity of effects (3/3)

The 'effect' as in, what the spell actually does, is relevant to the theme of assassination. The tooltips are excellent. The spell is not overloaded with effects.

Total: 31/40

Kingz

Concept (5/10)

Creative (2/5)

Unique (3/5)

The concept is relevant, but it's not all that good :/

Coding (16.5/20)

MUI & Leakless (7.5/8)

Bugless (4/5)

Efficient (3/5)

Documentation & Comments (2/2)

The spell is MUI. There are no leaks, but it really would've been better to null /all/ the struct globals.

There are no bugs that I could reproduce. There is only one issue. You're pausing the dummy units in the DummyCast library. This will be a problem because 'Dummy' could be used by other systems, and if they retrieve a paused dummy, they might not function correctly.

Spell efficiency is pretty good in some places, but it would've been better to merge the timers of both those structs into one timer. For instance, you could've just looped over the chains for each spell instance.

You could've gotten rid of the SquareRoot call by comparing the resultant value with whatever you want squared.

You could've used a First-Of-Group loop and a GroupEnumUnitsInRange call with a null boolexpr to speed up the spell ^_^

It's awesome that you used dummy recycling :3

It's always nicer to use Tables instead of struct instance arrays :3 (Not something I deducted points for)
The reason is because it allows you to max out possible struct instances, and this way, converting the structs to extend arrays is far easier.

The comments rock, and the documentation is sufficient. You may not have direct importing instructions, but you did mention the required libraries and the used imports, so 'okay'.

Visuals (10/10)

Relevant-to-Theme Effects (4/4)

Quality of tooltips (3/3)

Quantity of effects (3/3)

Okay, assassination in the sense of inflicting pain and crippling. That's totally fine and relevant to the theme. The tooltips are excellent. The spell is not hogged with effects. The only problem I have is that the chains are barely visible because of how fast they're actually pulling targets in the default configuration D:

Total: 31.5/40

DeathChef

Concept (7/10)

Creative (4/5)

Unique (3/5)

Parts of it are not very unique, but I liked how the spell would make units in range attack random enemy units. Still, this is closer to the theme of deception rather than assassination.

Coding (13/20)

MUI & Leakless (4/8)

Bugless (4/5)

Efficient (3/5)

Documentation & Comments (2/2)

The spell is not MUI. I know it's MPI, but it has to be MUI as well :/

The spell is leakless.

There aren't any bugs that I was able to reproduce in-game.

Instead of the 'begins casting' event, you should've used the 'starts effects of ability' event.

You could've merged both triggers that run when a unit casts the ability into 1 trigger that runs when the "Starts effects of an ability" event fires.

It would've been more efficient to cache things into variables so you don't have to repeat the function calls over and over again.

All that crap used to get a random unit is non-sense. It could've been replaced with a simple: set udg_randomUnit = FirstOfGroup(udg_myGroup)

The 11.11 should've been configurable.

You have importing instructions and lots of comments which is great.

Visuals (6/10)

Relevant-to-Theme Effects (1/4)

Quality of tooltips (2/3)

Quantity of effects (3/3)

The effects are more relevant to the theme of assassination. The tooltips are descriptive enough, but colors would've been nice :3. The spell is not hogged with special effects and spell effects.

Total: 26/40

Calculation Formula: ((Poll Votes / Total Poll Votes) * 30) + ((Judge's Results) * (70 / 40)))

-Kobas-: [((7/36) * 30) + (29.5 * (70/40))] = 57,455
mckill2009: [((4/36) * 30) + (31.5 * (70/40))] = 58,458
Jazztastic: [((0/36) * 30) + (32.5 * (70/40))] = 56,875
defskull: [((4/36) * 30) + (36 * (70/40))] = 66,333
chukkyjr: [((3/36) * 30) + (35 * (70/40))] = 63,75
bowser499: [((0/36) * 30) + (24 * (70/40))] = 42
Xiliger: [((2/36) * 30) + (24 * (70/40))] = 43,666
Radamantus: [((5/36) * 30) + (30.5 * (70/40))] = 57,541
InfinateAnswers: [((5/36) * 30) + (31 * (70/40))] = 58,416
Dr.Killer: [((0/36) * 30) + (19.5 * (70/40))] = 34,125
Kingz: [((5/36) * 30) + (31.5 * (70/40))] = 59,291
DeathChef: [((1/36) * 30) + (26 * (70/40))] = 46,333

1) defskull
2) chukkyjr
3) Kingz
4) mckill2009
5) InfinateAnswers
6) Radamantus
7) -Kobas-
8) Jazztastic
9) DeathChef
10) Xiliger
11) bowser499
12) Dr.Killer

Contest | The Poll

Pharaoh_ · Sep 4, 2012

Congratulations everyone!

Kingz · Sep 4, 2012

Mag, i talked to nestharius. Every Dummy unit is paused by default to reduce lag somehow (Nes said so).

but it really would've been better to null /all/ the struct globals.

I had mixed responses when dealing with this issue in the past.

Other than that, i agree completely on my part of the submission. Congrats to everyone.

rulerofiron99 · Sep 4, 2012

Congrats defskull!

Maestros · Sep 4, 2012

Congrats to the winners! Awsome stuff here!

baassee · Sep 4, 2012

Congrats guys!

InfinateAnswers · Sep 4, 2012

I thought i'd be mad with the results, but this is actually great. Being creative and artistic isnt something you can improve. But you can definatly improve coding. So im happy i lost because of coding and not because i lacked creativity or strayed from the theme.

mckill2009 · Sep 5, 2012

congrats guys!, defskull!

Lambdadelta · Sep 5, 2012

Congratulations to the winners!

Magtheridon96 · Sep 5, 2012

Mag, i talked to nestharius. Every Dummy unit is paused by default to reduce lag somehow (Nes said so).

I see. :/
Sorry about that.

I am prone to making mistakes.
Of course, even if I did give you a 5/5 on the Bugless field, you'd still be third place

bowser499 · Sep 5, 2012

Aw crap.
Even if I've got 40 pts in judging, I'd had no chance to win.
Anyways, I'm surprised that weapontype whoknows is null.
Gratz, winners!
And shame on me.

Magtheridon96 · Sep 5, 2012

Nah, it's always an accomplishment to learn something new ^_^

edo494 · Sep 5, 2012

but mag, if unit dies and it had cant raise, does decay it will decay after some time and the wc3 engine will remove it from game wont it?

InfinateAnswers · Sep 5, 2012

No it wont, its still there as a fragment of data.

Magtheridon96 · Sep 6, 2012

I've the done the tests using the JASS native GroupEnumUnitsOfPlayer because it has the ability to catch units with locust as well.

The units actually do remain :/

Pharaoh_ · Sep 6, 2012

The awards have been distributed!

defskull · Sep 8, 2012

Congratulations to all other contestants for showing passion and effort in submitting resources.

I, myself, would never thought would win since this is my first contest, I may not know all the procedure and stuff.

Keep moving forward to all contestants, hope we have more participants in the future

Almia · Sep 8, 2012

Congratulations to all of us
phew,the top 3 in the poll didnt got in the top 3 of the winners

SA Dashie · Sep 11, 2012

Cool I didn't come last on my rushed spell.

concrats to the winners and thanks for judging Magtheridon.

Zephyr Contest #9 - Results

Similar threads