[WIP] LeafLock

Everything related to programming.
User avatar
Posts: 126
Joined: Tue Aug 28, 2012 11:21 pm

[WIP] LeafLock

Post by WaeV » Sat Jun 15, 2013 3:54 pm

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.

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 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!

User avatar
Posts: 126
Joined: Tue Aug 28, 2012 11:21 pm

Re: [WIP] LeafLock

Post by WaeV » Fri Jun 21, 2013 9:11 am

^blah, blah, blah :roll:

I'm at the stage where I need to think about what map-editing Python scripts will look like. Here's a candidate, but I'm sure it has plenty of faults that need to be worked out:

Code: Select all

from halolib import HaloMap

# rw for editing with read/write access
# r for read-only access, import tags
bg = HaloMap('bloodgulch', 'rw')
b30 = HaloMap('b30', 'r')

# Mod #1: Andrew_b's perfected pelican import
with b30.find('vehi', 'pelican') as pelican:
    # get a better coll
    with b30.find('coll', 'pelican', 'crashed') as peli_coll:
        pelican.collision_model = peli_coll

    # make driveable
    with bg.find('vehi', 'warthog') as hawg:
        pelican.seats.driver = hawg.seats.driver

    # enter at the loading bay
    pelican.markers.driver.x_translation = 2.22336
    pelican.markers.driver.y_translation = -0.59117

    #replace scorpion
    with bg.find('scnr') as scnr:
        scnr.scorpion_slot = pelican
        scnr.matg.scorpion_slot = pelican

# Mod #2: change quality of all shaders to high
with bg.findall('shdr') as shdrs:
    for shdr in shdrs:
        shdr.detail_level = 'high' # use an enum?
Self-Criticism #1:
I'd love for importing tags to be as easy as "tag1.reference = tag2", but I'm sure I'll hit a snag pulling that off.

Self-Criticism #2:
HaloMap.findall works fine when more than one tag matches the search, since it just returns the whole list. But what should HaloMap.find? If there are multiple matches and you're only expecting one, should it throw an error or just go with the first match?

Stuff to think about... If you have suggestions post here or talk to me on IRC, please.

User avatar
Delta Force
Posts: 4194
Joined: Wed Mar 31, 2004 8:59 pm
Location: New Jersey, USA

Re: [WIP] LeafLock

Post by Sparky » Mon Jul 01, 2013 12:12 pm

I don't know if you care, or if this applies, but I have developed Zeus in its PHP application form, abandoned it, and now am developing Zeus as an objective-c application. The PHP version used Sparky's Plugins, which are entity plugins. The objective-c version is more hard-coded and deliberate.
Either you are groping for answers, or you are asking God and listening to Jesus.

User avatar
Posts: 126
Joined: Tue Aug 28, 2012 11:21 pm

Re: [WIP] LeafLock

Post by WaeV » Mon Jul 01, 2013 2:24 pm

Oh, you're not using plugins anymore? I'm not particularly fond of XML, but I do like the flexibility that plugins provide.

One option I've been considering is shipping Cython/Python files instead plugins, like so:

XML Plugin:

Code: Select all

<?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" />
Cython file:

Code: Select all

struct MapHeader:
    char[4] integrity # these chars ought to read 'daeh',
                      # which is 'head' in reverse

    uint32_t game_version # xbox = 5
                          # trial = 6
                          # full = 7
                          # ce = 609

    uint32_t map_size # size of the .map file in chars

    char[4] unk_12

    uint32_t index_offset # index header's location
                          # valid on disk, invalid in memory

    uint32_t meta_size

    char[8] unk_24
    char[32] map_name
    char[64] map_build # version information
    uint32_t map_type  # SP/MP, I forget the values

I find the Cython much more readable, but on the other hand XML plugins are shareable between applications whereas hardcoded Obj-C or Cython values would not be so. :| Decisions, decisions.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest