WaeV

In order to actually release something that much faster, I've spent the last couple months polishing up the scripting layer. Halolib 1.0 is now available for use! http://opencarnage.net/index.php?/topic/5878-introduction-to-memory-editing-with-python-and-halolib/ It works a lot like the scripting demos shown above (from 2013, I know). However, the code is a lot cleaner. It's written in straight Python 3 and requires no non-standard libraries. Currently it only memory-mods Halo PC 1.10. In theory it can memory-mod CE as well as dedicated servers, but I need to put the time into discovering the correct offsets for everything.

So when you said "I'm trying to find an Assembly version that is not too new but now too old since the newer one doesn't work on it for some reason" you meant "since the newer one doesn't work on [Windows XP] for some reason"? Windows XP support has been abandoned by Microsoft and 99% of the developer community. Assembly now requires the .Net Framework 4.5 which is only supported by Vista or later. If you're on the last version of Assembly with XP support, there are no newer versions which will work for you.

connorlawd means to say that the exact text of the error message is very helpful when trying to diagnose a problem. Where you said "something like it doesn't support older models or something", can you find out *exactly* what it said and get back to us?

If you plan on writing or editing code at all, you really should be using git anyways -- once git is installed, just do "git clone https://github.com/XboxChaos/Assembly.git" from the command-line. Edit: you need the full URL, no ellipses (stupid forum software). Alternatively, there is a "Download ZIP" button on the bottom of the far right side of their GitHub page https://github.com/XboxChaos/Assembly

Okay, I've fixed most everything I wanted to. Link to the pull request: https://github.com/XboxChaos/Assembly/pull/162 Here are a few additional things which occured to me while working on this... Unused Assembly code Why does the Atlas branch include Assembly? Atlas doesn't depend on it to run. Reusable Library? It would be great if we could refactor Atlas' GUI into a project-independent library, so we can both continue to use and improve the code. For the moment I'm feeling lazy, and I think a simple fork will suffice.

Awesome. I hope to get much of this done in the next week or so.

Some months ago, I forked Assembly, tore out Blamite/XBDMCommunicator, and started using the GUI for my own purposes. (mentioned a few posts up) However, I really like Atlas' explorer/treeview control. Plus the rewrite is more cleanly coded and thousands of lines smaller. So I'm going to go back, fork Atlas, and redo my GUI. Before I start making changes specific to my project, I could make improvements to the GUI and submit a pull request, if you'd like. Some of the things I have in mind: Remove dependency on P/Invoking that DWM dll, but preserve transparent look. (Simpler, improves performance)Remove redundant grid tags. (Simpler, improves performance)Fix the hitbox on the Maximize button to match Minimize/Close buttonsImprove resizing behaviorResize in all eight directions (resize diagonally from all corners)Corner grips resized for better use from touch devicesGood resizing performance in all directionsProbably some small UI tweaks/fixes as I encounter themCleanup anything Resharper recommends (indentation, variable name conventions) I figure you'd like me to submit at least a few of these improvements in a pull request. I can also submit them separately, if you'd like to consider them independently.

New update! I have switched from CPython3 to IronPython to make C# interop easier. Thanks to that switch, the edit boxes (traditional HMT/Eschaton-type controls) are seamlessly integrated with Python scripting -- whenever scripts make changes, the GUI updates to reflect this. Here is an overview of Quickbeam's (planned) architecture. So far, many of the pieces are in place, with the exception of add-ons. Binary Access At the very bottom is the layer that makes reading maps from memory feel exactly the same as reading from disk. Most users need not think about this layer; they can just take it for granted. Plugins One step up is the plugins layer. Whereas user-contributed plugins have been popular for older programs like HMT and Eschaton, Quickbeam's plugins will be moderated by me. This is because script compatibility depends on everyone having the same plugins, and we've pretty much mapped Halo out anyways. I can update plugins after the fact if they do need to change, and you can always substitute your own if you really want to. Scripting In the middle is the celebrated (by me, anyways) scripting layer! This should hopefully be intuitive to most modders. Scripting is done via Python, and I intend to publish a few tutorials and examples. Besides being cool, the scripting layer will make it easier for me to develop new features. Additionally, it will open the door for... Add-ons This feature is less fleshed-out as the rest, but I want users to be able to create and publish their own special-purpose buttons and controls. This could be as simple as a button for automating some tedious task using scripts, or something more complex. The design of this feature is hazy at the moment, and will not be present in the initial releases of Quickbeam Classic Editor Interface Finally, at the very top is the HMT/Eschaton-like editing controls we all know and love. Except these ones won't be glitchy or laggy (I hope).

Ooh, purdy. I love the meta-editor/plugin-editor split! Reminds me of VS's xaml editor.

Hmm... well I know the windows have really flexible docking, like so: Although one limitation of the current system is that docking layouts are not preserved across sessions -- it just opens the start page again on next launch.

Aiie! Just after I started a fork of Assembly for stripping down the GUI for my own Halo editor. :S What's planned to be different in Atlas? Wasn't the original GUI modeled after Visual Studio to begin with?

What is 'Atlas'? I thought :/src/Assembly had simply been renamed to :/src/Atlas, but they appear to both be present in the repo right now.

Demo images! Sorry the text isn't very readable; imgur resized these on me. Choose Halo's resolution with the sliders Once you have the desired resolution, click launch Observe Halo and the Python console (the 'console' is pretty hacked together right now; that may change in the future) Load the map, observe the needler's projectile reference Presto change-o! See the needler's projectile reference has changed

Topic title is a tad confusing; I thought you were going to literally use x86 assembly code.

First off, sorry for my stupid [WIP] Leaflock thread from months back. WIP threads are only worthwhile if you've actually accomplished something. Therefore... Check it out! Scriptable runtime reference-swapping! I think a few of you remember my Quickbeam project. I decided scripting was an important feature, so decided to rewrite the backend in Python, which has been a huge success. I've had a lot of help getting this far from the Halo Mac users at MacGamingMods, and using Python means this can potentially be cross-platform so the Mac modders can use it as well (as LeafLock was supposed to be). My next step is baking this functionality into some sort of UI. If I heavily borrowed Assembly's ideas, it could look something like this (no promises, though): http://i.imgur.com/1cVrtiw.png