ModHQ and UI Editing

I’ve integrated the UI viewer/editor into ModHQ and fixed up some performance problems. It now loads in about 2 seconds on my (fairly low specd) laptop. It also has a nice new loading screen.

ModHQ_Load

The program is essentially read-only at this stage, any changes you make with the unit prototypes or UI wont be saved back to your data files. However, all changes made through the Data Files tab will.

ModHQ_Dat

In this screen, double click any item to convert it to XML and open it, you can then make edits in your xml editor, and save it back to have it compiled and inserted back to the data file. Textures can be viewed through this tab, but will not successfully save back to the data file.

As before, you can check and uncheck items in the UI Editor tab to see their contents

ModHQ_UI

Download: ModHQ (.Net 4 + source)

 

 

Advertisements

Progress Report

Progress has slowed slightly, and I’ve been mostly bug-fixing and adding GUI bindings to existing functionality. This has bought the modder to a pretty significant milestone though, it is now able to be used to mod the game! All DDT formats are now supported too.

Mod HQ now displays items in a explorer-like file browser, and double clicking items will automatically convert and extract the item, and launch your default editor. After editing, it will pick up when the file changes, reconvert the file, and add it back to the .BAR file. I’ve tested if it works correctly with AOM, and I was able to change the hitpoints of the town centre by opening the modder, clicking Data Files, double-clicking protox.xmb, changing the hitpoints from 2800 to 50, saving, and opening AoM. I then went on to villager rush and won the game pretty fast :P.

Current progress:

-File formats-
Can load: BAR, DDT, XMB
Can save: BAR, XMB
Unsupported: BRG, SCN, SCX

-Parsing-
Proto.xml
Random map scripts (.xs)

-Loading-
Proto.xml
Random map generation

-Game-
Basic environment / entity / component framework

Future work:

This functionality is split over two separate projects, with the Proto.xml parsing not currently compatible with the game simulation, and it will be quite difficult to integrate the two projects. After learning more about how the AOM engine works, I’ve realised that the current game code is far more complex and flexible than it needs to be (entirely component based), so I am thinking it may be better to recode it work how it appears to work in AOM (a super unit class that contains most of the behaviours present in the game, and smaller components for more specific functionality). The problem with this approach is that I wouldnt be able to extend the game or use the code for a new game as easily as otherwise.


Download
Also the shadow is gone for now, so that the window can be resized, runs faster, and will have better compatibility. Might add it back in later.

Mod HQ

A fair bit of progress has been made over the last few days with loading the proto.xml data file, and more importantly, building an awesome looking GUI. The xml structure is fairly straight forward and simple enough to use an generic serialization class for most parts. I’ve found 3 unique mappings between XML and their object model representations:

  • Attributes packed in the parent node, such as the name of a unit
    <unit name=”Hawk”>…</unit>
  • Data stored in the value of nested elements, such as the line of sight of units
    <unit> <los> 12.000 </los> </unit>
  • Data stored in attributes within nested elements with complex selections, such as the action parameters
    <action> <param name=”MaximumRange” value1=”7.5″> </param> </action>

The first two are trivial to implement, and mostly cross-compatible, allowing a generic solution to cover almost all cases. The last one is much more difficult, as it requires looking into other attributes to select the correct element, and another attribute to get the value. To support these 3 cases, the following attributes were added to properties of classes.

ElementXml(tagName, requiredAttributes)
AttributeXml(attributeName)

The first case will use just an AttributeXml, the second would use an ElementXml, and the third would use both, signifying that an element must be found, and an attribute from that element used. This combination has turned out to be extremely flexible, and has covered all cases in the file so far.

A game developer I follow spoke about how trying to break large ideas down into small projects can help see the idea through to completion, so I’ve used this xml loading to start building an AOM-compatible mod creator. The program will load the data from proto.xml and display all of the units inside, along with their data. It is incomplete at the moment, but should serve as a proof of concept.

Download (includes source, will require .Net 4.5)