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:
This short presentation is copied from that thread:
I 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:
As 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.
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):
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:
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
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)
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).
Download latest version
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 ;)
Can this replace the object merger (assuming youre familiar with it)?
In the first line I cast Size() up to its parent struct (so upcast). In the second line a cast a parent down to its child (downcast).
I am not too familiar with object merger. The stuff I have heard about it can surely be done by gmsi. As far as I know, it can do a lot more. It can basically do anything, even change the heightmap / terrain textures of your map.
It cannot handle if you have an Ability h005 AND a unit h005.
It will probably malfunction if your map contains more objects with the same ID. (It will just overwrite them with the last one loaded).
I have never seen maps where it was useful to have an ability h005 AND a unit h005.
However, if you only have an ability h005 and no unit h005 it should be no problem.
You can test for each object if it is an ability like this:
To make it a bit more clear what this can be used to. Here is a script from my YouTD project that injects a tower from an XML file into a map.
As you can see, it can do really complex things. That's what it was meant for.
i don't care... i just wanted to point out what it shouldnt be map.objects but -> map.abilities, map.units etc. but it's your toy so you decide how to organize it.
when I designed it I also asked myself if I should split things up. I chose not to do it because with only one object space you can iterate over all objects in just one loop. And I didn't think about people using the same ID for two different things (which I think is still not a real problem).
The only way an ability could have a rawcode id of 'h005' is if you object-editor hacked it to have that ID, which is probably pretty rare of an occurrance. Not saying it wouldn't happen, but...
SLK Files are not very complex. It should be easy to code a write API for them. (You could however, even write an API in the script language itself, since it allows arbitrary file access).
Can you give me some links / hints what it should do? Just dumping your object data to slk like the widgetizer or something else?
It's pretty cool.
Do you have an icon that should appear in the tools overview?
I'm also considering a rewrite of Widgetizer in C++ btw.
This is why I'm going to marry you :)
this tool is so genuine :)
I use it for many things...and now I'm going to build a hero-description script to build html pages.
Are you going to add real OOP into this? :)
Approved then. :D
i tried injecting gmsi in jass new gen pack 5c, and when i tested a demo map (im player 1 red) with a hero owned by player 1 red on the map, i cant select it, the cursor turns red, but the selection circle for the unit is yellow (an enemy which is an ally? wtf!), and when i click a unit in the map, the upkeep title updates to the owner of the unit being picked
then i tried to delete all of my jass new gen pack 5c folder (to remove gmsi in jngp), now it works fine
It must be something else in your folder.
|All times are GMT. The time now is 06:26 AM.|
Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services