Finally, I want to add my tool here.
Since I have used it in many projects and it seems to work fine now I present it here. It is also able to inject itself into JNGP allowing easier usage.
An (outdated) discussion can be found in my old presentation thread:
http://www.wc3c.net/showthread.php?t=103939
This short presentation is copied from that thread:
IntroductionI want to present my latest tool GMSI to you. It is an advancement of my old tool GOSI, which I presented here, but I just earned some bad criticism. Well the old tool DID suck I admit.
However, it was already mighty enough to help me greatly with making my maps. As you might remember, I am the author of the (more or less) well-known maps Castle Fight and eeve!TD. I have used GOSI for creating those maps and it freaking helped me alot.
Okay, before I tell you what the program actually does, I will start with a story how the program evolved to what it is now:
HistoryAs you might know, in my map Castle Fight there are 10 races with over 100 buildings and over 70 units.
I was getting tired of writing the tooltips for these units. So I made a program that could resolve Object Editor data in unit tooltips.
So I could just put some keywords in the tooltip and my tool unfolded them to the actual unit values.
So I just made one generic tooltip and added it to all units.
Then I thought: Why adding the tooltip to every unit? Can't I just make my program pick every unit and inject the tooltip into it? Well I could.
Next step:
There are many values which stay the same for every building. However, when I created new buildings I often forgot to change the values to these standards, which caused strange bugs.
So I thought:
If my program already picks all buildings and injects tooltips into them, can't I make to program also be able to change the unit values to what I want. It took some time then it worked.
The next thing was:
Every building has to be inserted with some parameters into an initialization trigger. That was damn copy and paste work for new buildings and I often forgot to change the parameters to the ones of the new building, so again, it caused strange bugs. Hell, can't also do my program that for me? ...*codecode*... well, now it can do it ;).
Finally I thought: Okay, now my program can alter triggers, arbitrary object editor data, can even create new objects. Why not take the final step and let the program be able to alter EVERYTHING in the map? After around one additional month of work it is now able to alter EVERYTHING in the map. It can alter object editor data, triggers, placed units/doods, regions, general map information, even the heightmap of the map. And that is GMSI now.
So you might ask? Okay, sounds like a GUI where you can change everything in a map. But isn't that just another world editor?
And the answer is of course no. The program has no GUI (well, it has, but not for editing maps). It is just an interpreter for a script language. This script language has the tools to load and save maps and alter them.
So what does the tool do?It is just an interpreter for the script language called GSL. Before you start screaming: "What? Yet another scriptlanguage to learn?". NO, this script language is basically C with some small changes. So if you know C or JAVA you will need less than one hour to completely understand this language.
This script language is designed for altering wc3 maps exetremely simple and fast. To convince you that it is actually really useful, let me show you a few examples of how fast it can alter big parts of the map (remember the syntax is just like JAVA/C):
ExamplesMap map = loadMap("myMap.w3x"); //Loads a map to the struct Map
map.objects.hpea.Ubertip = "test"; //sets the peasant's ("hpea") ubertip to test
saveMap(map,"myChangedMap.w3x"); //Saves the map to a file
As you can see, loading and saving a map is done in one line with the language. Doing a change is also done with one line by just accessing the members (and their submembers) of the struct Map.
Next example: altering many units using the foreach syntax lended from JAVA:
Map map = loadMap("myMap.w3x"); //Loads a map to the struct Map
for(string s: map.objects){ //A loop iterating over the objects of the map
if(map.objects[s].HP != null)//Test if this object has Hitpoints (i.e. if it is a unit or item)
map.objects[s].HP = 50; //Change its HP to 50
}
saveMap(map,"myChangedMap.w3x"); //Saves the map to a file
These 4 lines of code change the hitpoints of ALL units in your map to 50.
Okay that is silly but I can think of many useful scenarios:
Think of a Towerdefense where you want to set the hitpoints of lets say 100 waves of creeps to a formula like: LEVEL²+10*LEVEL+100.
This would again be around 5-10 lines of code, you just have to filter units that are your creep waves (for example by checking if they are from a specified race), then getting their level and setting their hitpoints according to the formula.
Next example: Exchanging data between maps
Map map = loadMap("myMap.w3x"); //Loads a map
Map map2 = loadMap("mySecondMap.w3x");
map.objects.h002 = map2.objects.h005;
saveMap(map,"myChangedMap.w3x"); //Saves the map to a file
This would take the user defined unit "h005" out of map2 and insert it with the id "h002" into the map "map".
So since we can load arbitrary many maps, we can transfer data between them as we want.
So without giving you the code for it, since you can alter anything in your map, let me think of some more examples:
-Generating random terrain by setting the heights/textures in an area and putting different doodads on it.
-Gathering information from many maps and assembling it to one map. This would be interesting for teamprojects, where one creates the triggers, the other one creates objects, the next one the landscape and so on. The script would then be a "makefile" that assembles all the data from the members to one map.
-Setting the map version / authors homepage: Maybe your map version / homepage is written in your load screen in the questlogs, somewhere in the GUI and in a welcome message. With a script you could change all these when the version/homepage changes.
-Creating beautiful generic tooltips (which the program was originally designed for)
Quick usage:If I could convince you that this is useful indeed, and you want to try it, writing your own script then do the following:
Download the program and unzip it anywhere.
Start the GMSI.jar / GMSI.bat in the main directory.
Note that the program is written in Java, so you need an up to date JRE for it.
Choose a script and execute it.
Or write your own scripts and execute them :).
The program contains some small scripts to show you what is possible, like a "remove unused imports" script, that checks for every import your map has, if it is referenced somewhere in your map. If it isn't then it is removed.
For a full documentation on the Syntax and all possiblities the scriptlanguage/program offers, check the online manual (the manual is also included in the program's doc folder).
Links:
Download latest version
Online ManualSUPPORT FORUMNew stuff:The program is now at version 2.1.12. Many things have improved. It is now able to inject itself into JNGP generating a GMSI menu where you can execute the current map's script, taking and cropping a screenshot and opening a color picker.
It is able to alter everything. I currently use it for
my latest project YouTD.
I am currently working on a picture API that allows you to open and save pictures, even in the blizzard used formats blp and tga. Thus it is possible to create and inject the loadingscreen automatically. Just load it from jpg, let the program cut it, save it als blps and import it. New loadscreen with just one click :).
Try it and gimme feedback,
thanks and best regards ;)