Four unique races to play as, huge universe to explore and conquer makes Warcraft III one of the largest Real Time Strategies of its day. Combine with this a modders ability to alter units, create new landscapes, new missions and you have one game which shall be attacked and enhanced by the huge modification following!

Post news Report RSS Revision Ripples: Spiked Carapace

Revisions are rarely simple...and never secluded. Yesterday's fixing of Spiked Carapace.

Posted by on

Rarely are things simple. Revisions and changes are sometimes seemingly a quick fix. But you soon realize that your little change has unwanted repercussions throughout the rest of your game. I witnessed this yet again yesterday while fixing the ability Spiked Carapace.

Spiked Carapace wasn't working. And for the longest time, I couldn't figure out why. Heroes with the ability Spiked Carapace return a percentage of the attacker's damage to the attacking melee hero. It's a pretty sweet defensive ability. But, though my hero had learned the ability, attacking units remained uninjured.

In the meantime, I had also noticed that the ability Spirit Link wasn't working, as issue which I also solved yesterday. Spirit Link is a ability that applies a buff to multiple allied units. When an ally buffed with Spirit Link is attacked, the damage dealt to that unit is split amongst the buffed friendlies, each unit taking a percentage of the damage. Spirit Link is another awesome ability and standard staple of Warcraft III.

So here was my issue: neither Spiked Carapace nor Spirit Link were working. But suddenly, while I was testing the issue, the solution sprang upon me: both abilities may only be activated upon being attacked by enemy units. That enemy part is the kicker. Since I began development on Manifest, the players have always been considered neutral to one another. Players were neutral for the very important reason that they would not attack one another automatically. A forced attack is the only way to attack a neutral opponent and an important detail in being able to tactically choose your actions.

I tested the obvious and made my players enemies. Eureka! Both abilities worked. It was a beautiful sight to behold. Naturally, however, I had created an entirely different issue: units automatically attacked their enemies. I now had two choices: sacrifice the use of these abilities, or find another way to prevent units from attacking automatically while still allowing them to attack manually.

To the forums! Yes, the forums, that mystical tree inhabited by ever-helpful, merry elves. This time, though, I conducted a forum search. Nobody likes to answer the same question over and over again, which is why the search functions exist. And lo and behold, I found exactly what I needed.

The answer to my new problem was to add the classification of "Worker" or "Peon-Type Unit" to all of my units. This special little classification prevents said units from attacking automatically (they're workers, after-all, not fighters, and RTS players are primarily interested in their survival rather than their damage output). Off to the Unit Editor fields I went, and another test later, units were performing exactly as I had intended. There was another issue, however, in the bottom-left corner of the screen there now appeared the peon icon, representing idle peons in my workforce, which was my entire five-hero army. I could go into the Advanced>Gameplay Interface options and change the icon to something more menacing than a peon, something representative of war. And I still may, since that would allow players to toggle through their army rather than click around the map. But I wanted to see if I could remove the icon all together, just for kicks.

Again, the forums to the rescue. The answer comes from a user named Weep:

Weep wrote: There's even a way to do that without the "idle workers" icon appearing in the lower-left corner of the screen...I think you have to add the classification via a trigger, but I'm not sure about that.

Well, Weep, you were completely right. Following this instruction, I removed the innate classification of Worker from my units and applied to them the classification of "Peon-Type Unit" via a trigger upon their being trained. Now, they were considered workers as soon as they finished training and never attacked automatically.

All was well and good. Except, in testing the solution, I happened upon yet another issue. I have an archer character named Longshot. She has an ability called Prone (based on Bear Form) that allows her to switch to a Prone stance, which is technically an alternate unit. As soon as Longshot cast Prone and switched forms, she would automatically attack whoever of the enemies happened to be in range. Ugh! More problems. I had already written a trigger to take place upon the casting of Prone, but I needed to make some amendments.

First, I tried adding an action to my trigger that immediately applied the classification of peon-type unit. It didn't work. But I quickly realized why. Most of the time, when you want a trigger to fire when an ability is cast, you use "A Unit Starts the Effects of an Ability" which happens when units first begin casting. However, in this case, the standard event would not suffice, the reason being that the unit had yet to transform. I needed to change my event to "A Unit Finishes Casting an Ability." When such event takes place I manually add the classification of peon-type unit to the unit who has casting the ability, thereby ensuring that the newly formed unit may not attack automatically. This is what the code looks like. I also have a similar trigger for turning off Prone stance.

Prone On
    Events
        Unit - A unit Finishes casting an ability
    Conditions
        And - All (Conditions) are true
            Conditions
                (Ability being cast) Equal to Prone [Bear Form]
                (Unit-type of (Casting unit)) Equal to Longshot
    Actions
        Unit - Add classification of A peon-type unit to (Casting unit)
        Special Effect - Create a special effect attached to the overhead of (Casting unit) using Objects\InventoryItems\Rune\Rune.mdl
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            If - Conditions
                (Owner of (Casting unit)) Equal to Player 1 (Red)
            Then - Actions
                Set SniperProne[1] = (Last created special effect)
            Else - Actions
                Set SniperProne[2] = (Last created special effect)

To my knowledge, all ripple effects of my sweep neutrality change have been resolved. But probably not. There are exceptionally good chances that, before too long, I'll discover some other issue involving units automatically attacking one another, or something else entirely. But when it arrives, I'll work through it, like always. Because that's what it takes.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: