Welcome to Open Carnage

A resource for Halo 1 modding and tech, with unique means of rewarding individual content creation and support. Have a wander to see why we're worth the time! EST. 2012

Sign in to follow this  
Followers 0

[WIP] LeafLock

Hey everyone! In light of all the cross-pollination between the MGM and OC communities (as well as the need to make breaking changes in my Quickbeam project) I am beginning a new project. It will be in the vein of Quickbeam, but designed to be cross-platform compatible with Mac computers.


Blah blah blah blah:

Quickbeam was named after the common tongue translation of the name of Bregalad the ent. He got his name when Treebeard declared him 'hasty' for answering a question before another ent had finished asking it. I gave the project that name because it was intended to read Entity-style plugins (.ent) and was originally a hastily thrown-together experiment. I'm actually surprised it survived so long.

Moving forward, the project will be primarily authored in Python and will be given the name LeafLock, the common tongue translation of the Finglas the ent's name.


Here is where development currently stands: Using the Cython C-extensions for Python, I have created code which reads in raw data and interprets it as C-structs. Cython objects (half C, half Python) use these structs to expose Halo datatypes to the Python environment.

These objects rely on a 'ByteAccess' interface which can be reimplemented to allow editing on-disk as well as in Halo's memory, just as with Quickbeam.


The next step is to allow Entity-style plugin support. I intend to use Python's lxml library to read and interpret Entity plugins and define Python classes based on them. These classes will allow interpretation of raw metadata as the tags we are used to: weap, bipd, effe, etc. My goal here is to recreate the functionality of traditional meta editors and reference swappers, but to expose it through a scripting interface.

At this point, LeafLock will be no more than a cross-platform Python script. I will be looking into exposing some sort of usable REPL, maybe using IPython.


Once the Python scripting API is in a workable state, I will investigate creating a GUI. I have more experience with WPF, and I like the concept of 'data-binding' that it so readily supports. With a combination of Cython and C++/CLI I will expose Python datatypes to C# and create a GUI which allows some manner of editing tags. I will also investigate embedding a Python REPL.

The Mac GUI is in territory that's more uncharted for me, but nil from MGM has informed me about the PyObjC library which allows seamless Python-ObjC interop. With that library it is possible to create Mac GUIs with only Python. We'll see how that goes.


Lastly, I have been thoroughly impressed by the d3.js library and would love some way to create HTML5-based design of editor controls. Since the XML plugins will be defining how Python can edit metadata, I think I will use XML plugins solely for defining what edits can be made, and allow editor customization through HTML instead. I could host a local webserver using Python, then connect with an embedded WebKit view. The Xilium.CefGlue project provides full Chrome embedding for Windows, and I will look into Mac options.


I will need to look into the security concerns, but in the far future I plan on allowing Forge-like shared editing by communicating edits across clients. Since all edits will be made through the Python API, it would only be a matter of sending plaintext scripts to the other clients.

At the very least, I will be looking into CSS* edits for server-side scripting of mods.
*Cascading Server Side, aka "joiner friendly"

Thanks for reading and happy hacking!

Tucker933 likes this

Share this post

Link to post
Share on other sites

Members of Open Carnage never see off-site ads.

Testing the new IPBoard editor, let's see how it handles XML:


Map Header:

<?xml version="1.0" encoding="utf-8" ?>
<layout for="map_header" size="132">
  <ascii name="integrity" length="4"  offset="0" />
  <uint32 name="game_version" offset="4" />
  <uint32 name="map_size" offset="8" />
  <!-- offset="12" -->
  <uint32 name="index_offset" offset="16" />
  <uint32 name="metadata_length" offset="20" />
  <!-- offset="24" -->
  <!-- offset="28" -->
  <ascii name="map_name" length="32" offset="32" />
  <ascii name="map_build" length="64" offset="64" />
  <uint32 name="map_type" offset="128" />

Index Header:

<?xml version="1.0" encoding="utf-8" ?>
<layout for="index_header" size="40">
  <uint32 name="memory_offset" offset="0" />
  <uint32 name="base_tag_ident" offset="4" />
  <uint32 name="map_id" offset="8" />
  <uint32 name="tag_count" offset="12" />
  <uint32 name="verticie_count" offset="16" />
  <uint32 name="verticie_offset" offset="20" />
  <uint32 name="indicie_count" offset="24" />
  <uint32 name="indicie_offset" offset="28" />
  <uint32 name="model_data_length" offset="32" />
  <!-- offset="36" -->

Index Entry:

<?xml version="1.0" encoding="utf-8" ?>
<layout for="index_entry" size="32">
  <ascii name="first_type" length="4" offset="0" />
  <ascii name="second_type" length="4" offset="4" />
  <ascii name="third_type" length="4" offset="8" />
  <uint32 name="ident" offset="12" />
  <uint32 name="name_offset_raw" offset="16" />
  <uint32 name="meta_offset_raw" offset="20" />
  <uint32 name="indexed" offset="24" />
  <!-- offset="28" -->

Looking nice!



Edit: This thread was dumb and I should have just posted in my Quickbeam topic.

Floofies, Ryx and Tucker933 like this

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.
Sign in to follow this  
Followers 0
  • Recently Browsing   0 members

    No registered users viewing this page.