- Joined
- Apr 19, 2008
- Messages
- 2,562
So I was writing a PM that got entirely too long about an aspiration I had, and I was wondering if others were interested in this.
I had been asked what I was trying to do, what I was trying to ask this guy for, and it led me to a memory about a project idea that I started pursuing but did not finish.
JWC3
A set of Java libraries for editing all relevant Warcraft filetypes, as well as dropping them into program GUIs.
This would in theory include:
Here's what was going to be in my overflow-edly-long PM:
Sometimes I'm not altogether sure exactly what I want to do, either. Earlier this year I had the idea of trying to gather together Java Warcraft libraries (not all my own code) to be able to build a new, better Object Editor and Trigger/JASS Editor program that could save as runnable EXE game mods, so that I and other people would not have such a hard time making melee-type mods.
Here was a picture of a running mockup of one small part of it all (Note that this is, in fact, a JTree and a JTable and NOT the world editor. It is interactive and actually loads all the game units in the tree on the left, and displays their unit data on the right):
However, without the borrowed code from ODE, this system was only using its Java-based MPQ loading stuff to load SLKs, and then Java-based BLP parsing to make some BufferedImages out of that stuff.
Both of those, however, involved wrappers for native C code, which are quite a bother. I had it all put together for my model editing software, the Matrix Eater, to have it able to load textures out of the MPQs.
I had also had in mind to embed the 3d modeling aspects of my other software right into the 'Art - Model File' option for units, so that in the same workflow as choosing a unit's model you could also make modifications to it.
I recently acquired a native MDX parser to go with the MDL parser I wrote in high school, and wrote a translator between the classes used by the two. The MDX parser, or my use of it, however, has proven to me to be notoriously bad at things, and the hacky OpenGL code I wrote a few years ago does not draw models well (relative to their true in-game DirectX appearance):
The MatrixEater's interface, however, leaves a lot to be desired. With no true animation editing, and selection by vertex instead of VertexGroup, it would almost be more ideal to re-code the whole thing (which might prove not-too-difficult given the MDL/MDX java parsers that my repo has now) and have its interface take after 3DSMax 5 instead of after Oinkerwinkle's Vertex Editor.
In my recent conversations with other Warcraft content developers, my other aspirations like nesting helper abilities inside of main abilities via a customizable Java re-write of the World Editor's Object Editor were conceptually shoveled into JNGP injects for the time being, where I would not have to rewrite a vJASS syntax highlighter, or the trigger editor, or most of the rest of that stuff.
In truth, what I'm striving for is a faster way to make our ideas into game content as Warcraft content developers. When I was in middle school I thought it was cool that I knew how to make a disabled icon by adding a border texture, and then reducing Saturation and Lightness in photoshop. Thought it was cool to make a missile projectile with a dummy unit, dummy model with 1 attachment point, and a mountain of JASS.
They're not. Both of those things are complete wastes of time. A content developer should be able to pick a picture file, perhaps even just a relevant portion of the screen where a unit is currently being rendered, and have that instantly become a unit's icon including a disabled border. Whether an autocast or passive border is applied should be decided by the editor when it saves, based on whether an ability is actually an autocast or passive ability (With the potential to change the templates, of course, for those who prefer their own art style).
Missiles should not be thought of in terms of goofy dummy units, but with a system like I mentioned before:
So to be honest, I could say that I don't know what I'm doing, but there's one thing for certain: the closer we get to all aspects of Warcraft modding being accessible through clear and logical Java classes, the sooner somebody could easily just write one streamlined editor for all of Warcraft 3. And parsing the .W3A format is one more step in that direction. (Hence I was PM'ing this guy about how to do that in the easiest way)
Description of what I was envisioning that I mentioned to someone else a while ago:
My most anticipated objection: why Java? For me, it's because I already have half of these libraries there, and relevant knowledge to use them. However, if a good argument could be made of a language where all of these tools could be amassed efficiently and used for developing new stuff, I could see there being an argument out there that that might also be likewise worth doing.
I just don't want to be told I'm not a good programmer if I don't use pointers. I do not want to live out my days thinking about how the computer was built in the 1970s, but rather thinking directly of what type of Warcraft game content I wish to develop.
I had been asked what I was trying to do, what I was trying to ask this guy for, and it led me to a memory about a project idea that I started pursuing but did not finish.
JWC3
A set of Java libraries for editing all relevant Warcraft filetypes, as well as dropping them into program GUIs.
This would in theory include:
- JFlex MDL Parser
- Pure-Java MDX Parser
- A set of format-independent MDLX classes representing all components within WC3 models
- Pure-Java MPQ Parser
- Pure-Java BLP Parser to convenient classes such as BufferedImage
- A JASS syntax highlighter and IDE that could be dropped into any application
- A Trigger Editor with advanced functionalities, a lot like the SC2 trigger editor but using a system such as vJASS for support of class definitions
- An Object Editor interface, almost exactly like the one in WC3 but with advanced potential for customizeability
- All open source, so those who come after us can add features
- W3A, W3U, W3T, W3H, etc parsers, so that you could read and write object data with ease
- So-called 'Profile' parsers, things that could real (maybe write) the game's general format of .txt files outside of the unit data SLKs
Here's what was going to be in my overflow-edly-long PM:
Sometimes I'm not altogether sure exactly what I want to do, either. Earlier this year I had the idea of trying to gather together Java Warcraft libraries (not all my own code) to be able to build a new, better Object Editor and Trigger/JASS Editor program that could save as runnable EXE game mods, so that I and other people would not have such a hard time making melee-type mods.
Here was a picture of a running mockup of one small part of it all (Note that this is, in fact, a JTree and a JTable and NOT the world editor. It is interactive and actually loads all the game units in the tree on the left, and displays their unit data on the right):

However, without the borrowed code from ODE, this system was only using its Java-based MPQ loading stuff to load SLKs, and then Java-based BLP parsing to make some BufferedImages out of that stuff.
Both of those, however, involved wrappers for native C code, which are quite a bother. I had it all put together for my model editing software, the Matrix Eater, to have it able to load textures out of the MPQs.
I had also had in mind to embed the 3d modeling aspects of my other software right into the 'Art - Model File' option for units, so that in the same workflow as choosing a unit's model you could also make modifications to it.
I recently acquired a native MDX parser to go with the MDL parser I wrote in high school, and wrote a translator between the classes used by the two. The MDX parser, or my use of it, however, has proven to me to be notoriously bad at things, and the hacky OpenGL code I wrote a few years ago does not draw models well (relative to their true in-game DirectX appearance):

The MatrixEater's interface, however, leaves a lot to be desired. With no true animation editing, and selection by vertex instead of VertexGroup, it would almost be more ideal to re-code the whole thing (which might prove not-too-difficult given the MDL/MDX java parsers that my repo has now) and have its interface take after 3DSMax 5 instead of after Oinkerwinkle's Vertex Editor.
In my recent conversations with other Warcraft content developers, my other aspirations like nesting helper abilities inside of main abilities via a customizable Java re-write of the World Editor's Object Editor were conceptually shoveled into JNGP injects for the time being, where I would not have to rewrite a vJASS syntax highlighter, or the trigger editor, or most of the rest of that stuff.
In truth, what I'm striving for is a faster way to make our ideas into game content as Warcraft content developers. When I was in middle school I thought it was cool that I knew how to make a disabled icon by adding a border texture, and then reducing Saturation and Lightness in photoshop. Thought it was cool to make a missile projectile with a dummy unit, dummy model with 1 attachment point, and a mountain of JASS.
They're not. Both of those things are complete wastes of time. A content developer should be able to pick a picture file, perhaps even just a relevant portion of the screen where a unit is currently being rendered, and have that instantly become a unit's icon including a disabled border. Whether an autocast or passive border is applied should be decided by the editor when it saves, based on whether an ability is actually an autocast or passive ability (With the potential to change the templates, of course, for those who prefer their own art style).
Missiles should not be thought of in terms of goofy dummy units, but with a system like I mentioned before:

So to be honest, I could say that I don't know what I'm doing, but there's one thing for certain: the closer we get to all aspects of Warcraft modding being accessible through clear and logical Java classes, the sooner somebody could easily just write one streamlined editor for all of Warcraft 3. And parsing the .W3A format is one more step in that direction. (Hence I was PM'ing this guy about how to do that in the easiest way)
Description of what I was envisioning that I mentioned to someone else a while ago:
My vision would be something where you could change things like unit codes more easily, import/export groups of units conveniently, and drop units in custom "folders" while editing, although they would all end up back in something the original editor and game could use and understand. Having to use a separate program to create enabled and disabled icons (even with the Button Manager I started using right around the start of HF v2 instead of GIMP or PSD) troubles me. Importing each one and setting the "ReplaceableTextures\CommandButtons" path, or even setting it for a large group, seems like a colossal waste of time.
So, my vision for this program would be that you could click the "Interface Icon" option on a unit, then choose not just an internal blp but also any image file on your computer's hard drive, and have the borders/disabled/importing all done for you internally by the program. If this is executed correctly, I'd also like to see something where a unit's model wasn't set to a path, but to an actual model. Thus, since in the "HFv2" map I was developing I went back to using "war3mapImported" paths to speed up time, there should be some code that understands if I move that model I want to change the unit's reference path as well as the position of the actual model both in the mod and in the Import Manager. Doing things like setting all three of those separately is simply a waste of my time.
For what it does, the world editor (and JNGP) are particularly useful tools, so I'm not entirely sure that some of the more fringe features I'd like to see for modding would be as useful for true mapping.
Another feature I was visualizing would be the embedding of code into abilities. It doesn't seem that unreasonable to think that an ability could have an "On initialization" and "On use" JASS sections in the program I'm visualizing (or maybe "On Use" could just be replaced with a general code section that you could setup triggers in). I also would like to implement model editing directly into this new data editor.
So, my vision for this program would be that you could click the "Interface Icon" option on a unit, then choose not just an internal blp but also any image file on your computer's hard drive, and have the borders/disabled/importing all done for you internally by the program. If this is executed correctly, I'd also like to see something where a unit's model wasn't set to a path, but to an actual model. Thus, since in the "HFv2" map I was developing I went back to using "war3mapImported" paths to speed up time, there should be some code that understands if I move that model I want to change the unit's reference path as well as the position of the actual model both in the mod and in the Import Manager. Doing things like setting all three of those separately is simply a waste of my time.
For what it does, the world editor (and JNGP) are particularly useful tools, so I'm not entirely sure that some of the more fringe features I'd like to see for modding would be as useful for true mapping.
Another feature I was visualizing would be the embedding of code into abilities. It doesn't seem that unreasonable to think that an ability could have an "On initialization" and "On use" JASS sections in the program I'm visualizing (or maybe "On Use" could just be replaced with a general code section that you could setup triggers in). I also would like to implement model editing directly into this new data editor.
My most anticipated objection: why Java? For me, it's because I already have half of these libraries there, and relevant knowledge to use them. However, if a good argument could be made of a language where all of these tools could be amassed efficiently and used for developing new stuff, I could see there being an argument out there that that might also be likewise worth doing.
I just don't want to be told I'm not a good programmer if I don't use pointers. I do not want to live out my days thinking about how the computer was built in the 1970s, but rather thinking directly of what type of Warcraft game content I wish to develop.