Next patch, all six campaigns will be broken

[RazorclawX]

Due to some JASS changes to fix an exploit there will be some ramification that the campaign won't be playable in the next 1.23 patch.

I have thought about converting things to be compliant with the new patch, but that is both time-consuming and something I really don't want to do.

So enjoy it while it lasts.

[manstein]

Isn't it just possible to avoid this patch so that still all campaigns will be playable?

[Xenon]

Did you test the maps on the public test realm and find them to be broken? It sounds like it will affect maps that use the H2I and I2H functions and systems based off them, so unless you use those it might be fine.

[Larc]

So enjoy it while it lasts.

What? 

[chris]

oh great, now we are going to need a WCIII downgrader.

[RazorclawX]

I'm revising my preliminary evaluation.

The first 3 campaigns don't use the return bug at all. The latter 3 do. Book 4 hardly uses it at all, but it exists; Books 5 and 6 use it in every map.

[chris]

return bug? I'm confused now.... I happen to be playing book 4 right now while I'm typing this.

[Mucky]

RCX, do you use Kattana's Handle Variables?

[RazorclawX]

I don't know who made 'em.


I decided that I can't stand the idea of my campaigns being playable, so I'm going to make an attempt to convert everything. On the other hand I'm not terribly happy about doing this for 45 maps, but there isn't much of a choice in this.



ED: stupid world edit doesn't compile anything. Guess I'll have to wait.

[Xenon]

chris> The "return bug" is a bug in the War3 scripting engine that JASS coders can exploit to attach variables to units, timers, and the like, and store different types of variables in the gamecache. Apparently some scumbag found a way to use it to write malicious data, so Blizzard is going to remove the "return bug" in an upcoming patch. The current version of WoS will work until you download this patch.

RCX> If you're going to go over Book 4 again, I think I know why the cantrips aren't working.

        Set SpellCantrips[SpellCantripsIndex] = (Ability being cast)
        Set SpellCantripsIndex = (SpellCantripsIndex + 1)
        -------- Do not allow more than 4 stored Cantrips --------
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            If - Conditions
                Or - Any (Conditions) are true
                    Conditions
                        (Ability being cast) Equal to Release Cantrips (Cantrips)
                        SpellCantripsIndex Greater than 4
            Then - Actions
                For each (Integer A) from 1 to 10, do (Actions)
                    Loop - Actions
                        Set SpellCantrips[SpellCantripsIndex] = Drop Pilot                        <- should use Integer A
                Set SpellCantripsIndex = 0                                                                    <- should be 1
            Else - Actions
                Do nothing
        -------- Check to see if a Cantrip chain produces a spell --------
        -------- Thunderclap --------
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            If - Conditions
                SpellCantrips[1] Equal to Cantrip Earth (Cantrip)
                SpellCantrips[2] Equal to Cantrip Wind (Cantrip)
                SpellCantrips[3] Equal to Cantrip Wind (Cantrip)
            Then - Actions
            ...

The default value of SpellCantripsIndex should be 1. The section at the bottom that makes the undead dissipate sfx has the same 2 problems shown here. Also, the Do not allow more than 4 cantrips section should go after the cantrips list, because it is deleting the array of 4 cantrips before it can be checked. An additional "SpellCantrips[10] Not Equal to Load Pilot" condition for the moved section should keep it from interfering with the section that gives the undead dissipate sfx.

Also, the triggers for some spells have the wrong unit group filters (such as allied buildings).

I hope this helps, and good luck.

[Mucky]

I don't know who made 'em.

Well, there's Kattana's Handle Variables and Vexorian's CSCache. They both make use of the return bug, which is why I was asking.

[RazorclawX]

Well it turns out to be... BOTH.  Both systems are present in Book 6. Looks like I'm going to have to fix both of them.

The funny thing is the Vexorian system is only used for the Knockback abilities, so I don't have to actually touch those. The Shield abilities use the other system and do have to be changed.

The only problem is even if I do change these things World Edit doesn't compile.

[RazorclawX]

Found out why WorldEdit wasn't compiling. I had a custom TriggerData.txt in my UI folder that wasn't making any of the hash stuff show up. Furthermore, I was misspelling GetHandleId as GetHandleID.


For some reason Blizzard took out the GUI trigger "Save Game Cache" so I had to modify the TriggerData.txt to add it back in; it hurts that it's in EVERY SINGLE MAP EVER MADE.


ED: Book 4 is done; it had the least amount of that junk in it because that was around the time I was looking into it. In fact the only thing it's used for is a custom Fade function which is used in only two maps. Unfortunately I think the changes actually killed the function, but at least it's better than not working.

I need people to let me know if in Books 1-4 if any maps don't work in 1.24



ED 2: I really hate Vexorian's system. No wonder I only implemented it when I found something that HAD to use it.

[chris]

I'm going on a 1 month vacation starting tomorrow morning. When I come back I'll replay all the campaigns under the new patch and test... actually I'll be playing them again regardless of this patch, the campaigns are so great they deserve to be played at least two times.

[RazorclawX]

I'm seriously considering going back to the older campaigns and fixing them up to; if there are any lingering bugs left over better voice them now.