AAH! Functions no longer reference in seperate triggers??

Hi, I'd been making a map about 8 months ago that had some pretty complex JASS triggers in it, and some of the functions used functions that were in seperate triggers. This used to work; as long as the trigger containing the referenced function was created before the trigger referencing that function, the script would compile. However 8 months later I bought FT and installed the new patch, and suddenly the referencing no longer works. It just tells me that the function isn't defined.

So what's the deal? Is there some way to get these functions to see eachother? I really don't want to have to manually set up my .j, and there's way too much code to fit in one trigger (the text box is capped at 32000 chars). What can I do?

Put functions in the header which are not used directly in a trigger.

Does this mean that blizzard somehow changed the compilation order?

It has to, because if I open up my old map and click save without even opening the trigger editor, it gives me about 90 compiler errors to click through before the save completes. Maps that previously compiled no longer do with FT and the newer patches.

As for the header, it's still too small to hold all my global functions, and I'm pretty sure it won't work anyway because I have global functions that use many functions in their own trigger; moving them to the header would require moving everything to the header, and there's just not enough space. I can try, but I don't think it's possible to move it around, and it will leave my code all disorganized.

Is there anything else I can try?

Uh, the header can hold a ton of things. More than 32,000 characters.

And, what do you mean by using functions in the original trigger? If the function is executed in the header, any functions executed by it should also be in the header.

Anyway if it doesn't compile because the functions are not there, then use code variables instead of referencing the functions directly.
And of course putting them into the header would also solve that problem. I've had 12000 lines of code in the header so I don't think it's too small for your functions.

But I think the compile errors are there because the map is so old and not necessarily because of the way it is parsed.

Why would the map being old have any effect on how it was parsed? I'm telling you dude, this is what I depended on when I was writing the JASS for the map; if I needed to reference another function and it didnt work, I had to create a NEW trigger and copy-paste all the code from the old trigger into the new one. The triggers remained identical; all that this procedure changed was the order they were created in. This allowed it to work. The compiler wouldn't see the referenced function unless the trigger containing the referencing function was created AFTER the trigger containing the referenced function. I can even send you my map if you like; you can open it and click save without changing a thing, and it doesn't compile anymore. It wouldn't have let me save in previous versions if it didn't compile now would it? Would you like me to uninstall Warcraft, reinstall an old patch, make an example map, reinstall the new patch and then show you how it doesn't compile anymore? Because I will if I have to. I'm telling you man, they changed something, because maps that previously compiled don't anymore.

Code variables are an absolutely awful way to do it. You need to create a trigger variable (or an entire trigger) for EVERY single function (there's at least 40 in my map that get references by outside triggers), as well as variables for the arguments and return types (some of my functions use up to 4 arguments, and they all vary in type; this is a nightmare for code variables). This makes well over 100 extra global triggers, unless you make trigger arrays; running udg_GlobalFunction[34] doesn't really explain much now does it? Worse, the trigger call then goes on top of the stack, so you have to either wait for the trigger stack to expire before checking for a return value, or using another variable to hold whether or not the called trigger has done executing. This means to call a trigger with say 2 arguments and a return value, your 1 line of code is now about 15; setting the arguments, calling the trigger, checking the stack, getting the return value... Basically an absolutely horrible way to program, and there's no way I'm using code variables. I'll GLADLY do the war3map.j manually before I even touch code variables.

Anyway, I tried to test how much data I could put in the header, and the editor promptly died on me. I'll take this as a sign that it's not capped, since it used to just stop adding data after a while. I can try moving the stuff now, but it just makes everything so terribly disorganized. I have about 30 triggers organized in 8 categories, and now I have to mash all that together to get the same damn thing to work. That really sucks.

Do you use Win98 ? Blizzard screwed the header there so you cannot put much in it (without problems).
I am not sure but I think the order in which the JASS triggers get put in the script now is the order in which they appear in the editor except when they were just created.

rofl
no, you don't have to show me anything, because you are saying the same thing I did.
It's not due to the way it's parsed, it's simply the fact that the map was created with a older version of the editor.

Ah, this is very possible. I'm pretty sure I was using Win98 when I was working on it 8 months ago, so it makes sense that the UI was different then. Good thinking!

I also tried putting the JASS triggers in the order I wanted them added, and that doesn't work either, not in the old patches nor in the new. Now they just don't see eachother at all, no matter in what order you put them or you create them.

I tried moving the required functions to the header, and I've almost got it compiling now. I should be able to get it to work. It will be harder to maintain because I have about 4 or so full triggers that needed to be moved to the header, so it's more disorganized, but it should work. It I also have other problems though, because I made functions whos names are now used by Blizz functions. Apparently there's a GetItemName() now? I have to go rename this in all of my triggers now because I have my own custom GetItemName(). That's a pain, but it's manageable.

So anyway, the problem is successfully worked around. It's too bad Blizz changed the compiler, but I'll manage. Thanks all.

I had the same problem when I tried to organize my functions into different triggers. Then I realized after putting triggers in the order you want, you need to save the map, close it then reopen it. Seems the WE will reorganize the code it generates everytime it closes & reopens a map.

Seem to be working fine. They didn't seem to change a thing, My map is working fine with functions in triggers in the order I have em.

Yes, I made intensive tests in the last patch for how it compiles the triggers. And the result was:

1: Saves Header
2: Saves all "old" triggers (triggers that were in the map when you loaded it) in the order they appear in the trigger list. NOTE: Moving triggers in the trigger list does not change the compilation order of these triggers until you reload the map!
3: Saves all newly created triggers in the order they were created.

However, if you save a map 2 times in a row, it will save it exactly the same. So the only way to get the order correct is to reload the map (save, close (even if you got compile errors) and open up again).

For fun, I confirmed all this just now for 1.15, and they still apply. So, if you got the triggers in the order they should be, it should be as easy as reloading the map....

~Cubasis