Adding a(n) .ai file to a map file.

I'm loking to override the standard map .ai file generated by the WE GUI every time the map saves, and if possible I don't want to have to export and import files from the archive directly. Is there some map option or trigger I can use to ensure the .ai file I want used, gets used, without being overwritten when the map saves? Thanks for your time.

The GUI does not create any AI scripts, that are automatically put into a map. Are you talking about the map script?

I want to know how to write an .ai file, and have a particular player run and use it.

I want to know how to declare my own global variables using custom text. As there can be only one globals block, and I can't seem to declare it by clicking on the map name icon in the trigger editor (I get syntax errors,) I can only assume that the WE is tacking on the globals declared in the GUI before my scripted code, which I don't want. How do I stop it doing this?

What do you want the AI script to do? You can start any imported AI scripts with a specific trigger action. Note though that the namespaces are separated so you cannot access trigger globals and functions from AI and vice versa.

And yes, there can only be one globals block and I don't think you can prevent WE from putting its own globals block before your script. So what you can do is either putting all globals in GUI or creating your own pseudoglobals by having one global gamecache in which you put your globals. Note though that you should avoid that if you have very heavy access to it as it is slower than real globals (though by not that much).

Blast. I'm afraid I'm using a LOT of global variables in this case, so, using a cache or the WE GUI for their use would be fairly unfeasible. Do you know of any good 3rd-party syntax checkers for the Mac?

Alright. How about this instead: Would it be possible for me to import a modified version of common/blizzard.j into my map containing the globals and constants I need to declare? And would the syntax checker for the WE pick those up?

Yes, that is possible if you put the changed Blizzard.j in the Scripts subfolder of where you have Warcraft installed. But it has one big disadvantage (Blizzard likes to make things hard). If your map is the first map to be played, then it will not work as it will then not load your changed Blizzard.j but the original one. That means if for one of the players it is the first map he plays since starting Warcraft, then he will desync.
After that it works fine.

Couldn't I just import my own version of common.j into the map archive itself?

http://jass.sourceforge.net/doc/globals.shtml

Or is that out of date?
I mean, having to replace blizzard.j in the /scripts directory of every player sounds like a pain... but thanks.

ok, to make it clear: You can import Blizzard.j into your map but then it has the problems I described. If you actually put it in War3patch on each Player's computer then that disadvantage is not there (common.j should have nearly the same effects but I never tried it) but you have to manually move it there which should only be done with larger mods.
The putting in a local directory applied to you since only WE retrieves its info from there (unless you set a certain registry key).

OK. I was under the impression that the disadvantages you described would apply if I DID put my modified blizzard/common.j into the Scripts subfolder of the original installation archive. Whereas you are now saying that I can AVOID these disadvantages if I put the modified file into the War3patch.mpq archive.
Well, I suppose as a last resort I can overwrite war3map.j within the archive directly to stuff in the constants outside the WE. What about hitting command-F9 for map testing? Will the game load a modified Blizzard/common.j withint the map file for that, or will it count as a 'first map' problem?

I have some good news, for once. If you go 'test map' within the World Editor, a modified common.j (and I presume Blizzard.j,) will be loaded from the map archive, even if it is the first map to be played. Which is convenient, at least for testing purposes.