Map to XML Converter (Pre-Alpha)

[WaeV 5,049]

I just thought I'd drop in and let you know about something I've been working on recently.

BASICALLY, the idea is that it's pretty easy to edit a text file. Why bother looking up addresses with an offset catalogue, or being stuck with old, unmaintained programs? With XML, structured data is stored in human-readable plain text.

Having data stored in an open format like XML makes it easier for different people to write programs. Think about how HMT, Eschaton, and uh... well think about how each of those programs goes about rebuilding maps in its own way. If there was an xml-to-halomap converter, they could simply rely on that program instead of duplicating effort.

Thing is, in order to make a proper converter, I need to know how to properly rebuild a map. So this isn't going to be ready by next Tuesday or anything. But I have done some work on it. Right now I'm using some map comprehension code from my previous release of PyHaPa the Python Halo Parser.

Here's a mockup of what Halomap XML might look like. This was actually generated by my script. All the tags can be read, although the references are all fake, since I don't have code which can comprehend tag references yet.

 		 game_version="PC"
	 map_name="infinity"
	 map_version="1.00.00.0564" >


	 			 first_class="scnr"
		 second_class="null"
		 third_class="null" >












	 			 first_class="sky "
		 second_class="null"
		 third_class="null" >











	...

[Takka 13,376]

Badass. Make sure you get the rebuilding process in the right order though xD

[Modzy 165]

Not sure about the usefulness of a cache-to-xml converter, but the research is good. In order to properly build an application like this you would also need complete information on tag formats (that's where the good research is at).

Rebuilding is no issue, most modern programs rebuild the same way.

[WaeV 5,049]

Rebuilding itself isn't an issue (as you point out, we know how to do it), the issue is the high barrier of entry. If a modern program can't perform the functionality I want, I'm stuck in the mud unless I want to make a new program with that functionality. In which case I need to potentially reimplement the rebuilding process. Ideally the xml converter opens up the process a bit more, giving people more freedom in how they mod without needing to reimplement rebuilding. (Or they can opt for easier-to-use menus and buttons like other programs offer.)

There is PLENTY more research to do of course. I haven't pushed the bar any further at all - I've only used others' research up to this point. I've been peering into editor plugins for a bit, but there is plenty still to be mapped.

In lieu of a complete mapping of each tag... ugh. Well, I'd hate to just dump binary data somewhere. I'm thinking of a way to specify a .map to pull unmapped default values from, but even that's an icky solution.

Edited July 7, 2012 by WaeV

[Modzy 165]

XML files would make the process of creating new programs easier, I suppose. Full documentation of existing cache files and open source parses/rebuilders would make it similarly easier.

[SnipeYa 248]

What language you going to use , I have source for a vb.net app thats very similar to hmt so if you would like i can upload it for you.

Edited July 7, 2012 by SnipeYa

[WaeV 5,049]

I'm continuing to use Python for my exploratory prototypes. I already have source for a lot of programs, but thanks. You should make sure that source is included in that big ol' source code thread.

XML files would make the process of creating new programs easier, I suppose. Full documentation of existing cache files and open source parses/rebuilders would make it similarly easier.

That is a good point. I'd rather code than document someone else's project, though. This doubles as a way to work on coding as well as a way to (eventually) help the Halo community.

[WaeV 5,049]

So I've been peering into various plugins lately.

It's weird - as an end-user, I always liked the old, HMT-style .xml plugins best, because they work everywhere and tend to present their information in a straightforward way.

But as far as reading plugins goes, Entity-style plugins are clearly superior.

I vaguely remember that there is something that .ent plugins are able to handle that HMT plugins can't. I haven't run into that yet (or wasn't aware of it if I did), but even so. .ent plugins are so much clearer.

<value><type>id16</type> ... </value>

becomes

<enum16> ... </enum16>

for example.

So. Still trucking along. While continually progressing, my ideas and goals are all over the place. I'll eventually release something, but this xml-format idea is no longer at the forefront. Pretty much anything I would do revolves around map comprehension, though, so consider it all in the name of research.

[Takka 13,376]

Good to hear this is still going on =]

[WaeV 5,049]

Thanks. Every time I get a notification from one of these threads it motivates me to and put a little more effort in, haha. =]

In related news, I got a RealBasic trial, and reading Esch's source is so much better than via that dumb ol' pdf. Eschaton won't compile, though - RB doesn't seem to be importing the ComplexMatrix plugin properly. Also the way that it only reports one usage of ComplexMatrix as an error leads me to believe that there could be many more silent errors that the compliler didn't get far enough to tell me about. Blrhh...