Welcome to Open Carnage

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


  • Content count

  • Joined

  • Last visited

  • Raffle Tickets



About Zatarita

Extra Information

  • Gender
  • Location
  • Occupation
  • Contributed
    $90 (US) to Open Carnage
  • Raffle Victor

Contact Methods

  • Discord

Recent Profile Visitors

4,759 profile views
  1. Stonks We can now store plugin associations between use, as well as define new preferences. I now need to include this in the plugin management options because you can't really remove them yet. This would allow us to define a specific plugin to handle a certain file extension in the case of general purpose data (hex, or text) OR allow us to define which plugin we prefer when there are multiple options available. There are still some bugs to iron out; however, the basics are there.
  2. Pogress of open as and manage plugins dialogs. Open as is really pretty simple, I actually just yoinked the manage plugins and stripped out the list widget. Really these are basic. I'm thinking I'm going to remove the windows bar at the top, and create a completely custom bar. That's why I left the border on the top as well. This will unify the aesthetic across platforms as well. I feel it's a bit jarring having the high contrast differences. Majority of the stuff presented inside of the manage plugins dialog in uneditable; however, I plan on having an uninstall option, and disable option. As well as manage things like user preferences (say if the user has designated a file can be opened as a text document, it can store that over ride and use it to open the file again.) For now though, I'm happy with this. This means that editing settings would be separate. I'm thinking of making it a dock; however, I have to do some more brainstorming on this. The same issue I had before will carry over here. If I change the settings I'm not sure it would propagate to the existing open windows. Ultimately, I dunno if I want to stress this too much. I think most people would assume if you changed the settings you would need to reload any tags you had open in order to see the changes. In fact having it update automatically might be counter intuitive to the user. Maybe I'll create a setting editior for the plugin instance. That way once the plugin is created, settings that can be changed at run time will be available to edit for that instance of the plugin alone. Say one tab has word wrap enabled, and the other one doesnt; however, they both opened with the same default parameters. Unsure; however, as for now I just need to wrap everything together a bit better, do some house keeping. Comment passes, run through the code and make sure everything is following the same conventions. Hex plugin would be nice as well; however, I want to implement that later. I was thinking I could create a plugin that creates plugins. That way someone could create a generic data template. Theoretically plugins are just definitions for raw data and archives. If I create a hex editor that is smart enough to be able to define blocks, you could map out any file and supply it with generic rules to create an interface to interact with the data. This will be done at the VERY end when I plan on implementing tools for more general use. My primary focus is halo as of now, anything outside of that is irrelevant
  3. Fleshing out some more of the "misc" functionality of the core program. Got slightly distracted by the text editing plugin. This can be worked on over time. I should focus some more of the last few days on core stuff. Rescanning plugins is working-ish. First attempt shows a plugin failed to load (output in red), So I fixed the config file and it rescanned loading successfully this time. --The only issue seems to be when the rescan is called, the main application loses the handles to the existing children. This isn't TERRIBLE as each plugin is to be designed to be ran independently, just mediated through the core; however, these derelict plugins are programatically isolated and, while I can manually click the x, it leaves the potential for a memory leak. It'll be fixed on my next day off, its as simple as making sure all open instances of the plugin are closed before deleting the handle. (inb4 not simple) Also started the foundation of the "Plugin Manager" Dialog. I'm on the fence still if plugin settings should be separated out from management. The way I see it management would allow for high level editing of the plugin. Things like if this plugin should be used, which plugin should be prioritized if multiple definitions exist for the same file type, a high level description, and link to the github repo, etc. Settings would be plugin specific settings. For example the text editor has a "word wrap" setting, and "allow formatting". I could make theoretically as many settings as I want. It's just a list of a key-value pair of strings. "setting"="true" It's up to the plugin to define how the setting gets used, and to ensure they are defined (or what to do if they arent) I'm leaning more towards combining them into one. I feel there isn't enough meta information either way to necessitate splitting it. My aim for this project is to keep it simple. Check for updates turned out to not be as straight forward as I had hoped. Though, Qt does have a well known auto updating library I've been looking at. That is in the back burner for now, but will be finished before the first batch of plugins. For the "finalize ui" stage I plan to -Wrap up the plugin manager -Decide on how I want to do settings -Implement an "open as" dialog to force a plugin to be used ( There will be generic options. You saw text, but there is a hex editor in dev as well ) This will also allow for specific plugins if two definitions exist for the same filetype A few things to note though about the core, before moving on. -Work will continue on archives and the cmd output. It's kinda hard to test and write code for undeveloped parts of the application. So I write "black box" code if you will for what I think ill need. console functionality wont really be testable until I create a plugin that utilizes is; same with archives. I have the foundational code for how and archive will integrate into the hierarchy; however, since these are abstract classes, until I write a class that defines these functions I can't test anything. So it's likely they'll need to be developed as the plugins that utilize them are developed. This is what I was talking about in the last post. -I will NOT add any more functionality than is required for base line functionality. I don't want to fall into the infinite development cycle. Version 1.0 will be just that. From then on I plan on extending functionality. Also, still REALLY need to fix up the project file. I can only get it to build on one of my PCs x.x P.S. Interesting thought as well. I think I'm going to make console interaction strictly a Data plugin feature. If you want to use a console function on an archive you treat it like a file instead. Meaning I'll likely create two separate plugins for each archive type. A plugin for treating the archive as a file, and the other plugin for treating the archive as an archive. This would also allow me to bypass the archive loader if I wanted. This may seem undesirable, but for other games it may be useful. Lowkey testing functionality by defining sonic adventure 2 battle files, and I feel the OPTION to do this is extremely useful
  4. Did some more work on the text plugin Utilising icons from Googles open source collection. I think this will be enough for now. And it's time to flesh out the functionality of the buttons and such. Next I need to start finishing the archive plugin implementation so I can test opening archives and editing their contents. Since I haven't officially started "Halo" plugins yet, this will likely be an implementation of KArchive to let us see archives like zip. Edit: We should start to see the beginnings of our first batch of halo plugins being made soon. I have decided there WILL be a delay between the finishing of "finalize UI" and the beginning of "create h1a plugins" This will be for a quality management stage. I will go through the code make sure everything is commented, and the documentation is up to date, and ensure any misc "todo's" that might of slipped through the cracks are taken care of before moving on. I also plan to profile the code, and attempt to do any optimizations. Also, I'm not exactly sure the features I'll need to do what everything I need to do. So during the development of each set of plugins, there will be a stage dedicated to updating the core application if it is needed. I'm going to be allocating ample time to this. I want to make sure the project moves at a reasonable pace. I don't want to be scrambling to meet a deadline and have to sacrifice quality, but I also don't want to keep saying "When I make SeK that wont be an issue anymore." Because of this, there is a chance, when I start h1a plugins, I may realize there is something fundamentally problematic with the core application and stepping back for a week or two may be required to maintain quality. All of this time SHOULD be accounted for in the deadlines. I would rather project a later date and get done sooner, than the other way around. So from your guys perspective nothing will change. Though, I feel updates like these are helpful Also I think from here forward, I'm going to start putting screen shots inside of spoilers Hopefully this will save load times, and some mobile data.
  5. Don't worry it'll be ok, I still have the source files, i just lost the project file. I just have to set everything up to build correctly, and stop waiting on source control once I fix it Oof, Hurt a bit, but we're back in business. Definitely going to have to remake the project file from the top. The duct tape patch job got me running again. Turns out Qt kept the build path as my documents, which was redirected by one drive. So I have to reconfigure Qt completely. Gotta say, If I wasn't a certified IT tech, removing one drive and setting things back to how they're supposed to be would of been near impossible without losing all my data. I had to edit the registry (and it's still not completely fixed) I'm kinda disappointed in windows in this move. It's very mac like to force something like that on the user, especially if you're going to ask for more money once the drive fills up. I see that as extremely predatory of the older generation. I have a feeling soon I'll have more calls about how "my computer said it was running out of memory, so I bought some more" when they're only talking about OneDrive. Windows came installed with almost my entire user redirected to a folder inside of my documents. This some bull. Microsoft knows though that all their customers use windows not for windows, but the software that runs on it. So there is nothing we can do. Text Editor Widget coming along. Got me some icons going, and blocked out where things are gonna be laid out.
  6. https://zatarita.github.io/SeK/ First test of documentation. Also found out that everything stored to OneDrive because windows now forces it on you. Upon disabiling it proceeded to destroy my project. So current status is: Plz help I didn't deserve this. More updates when I fix things
  7. Less exciting, but needed update. Simplified the core application a bit. I Broke some pieces from the core application and put them into their own widgets and setup communications between the parts and the core application. Hierarchy is now it's own widget, this is in prep for different project scopes. What we've been seeing is the global scope. I plan to narrow that down to project (multiple scenarios) and mod (single scenario). It still works how it did, just standing alone now. Console output has been update a bit. Now stores the current directory as placeholder text. Can navigate using cd commands, can also force navigate by right clicking on a folder in the hierarchy. This pipes to system commands, or CLI style plugins. Meaning both the UI version of the plugin and CLI version of a plugin are available from the main widget. Also, the base for scripts has been laid out. The hope is to be able to streamline the building process (kinda like a bat file). Also will allow for us to do something similar to cmake for projects. building each map, and applying certain commands to them as they go through the pipeline. Since it pipes system commands as well you could do some creative things. for example Create a build folder Use Invader to build into that folder Create a readme Rename the maps and add a version number to the ends Rebuild s3dpaks Rebuild Imetas Rebuild Fmetas Compress the files into a zip/rar for deployement Hell you could even create a shortcut to halo that opens halo straight to the map once it's done. (ps, this is why people like having CLI support, and why i will always try to support it.) It all really depends on how creative the user is. All of this is optional of course. I do plan on implementing a visual means managing these files; however, the option will be available if that's what the user wishes to do. Plus piping system commands means you could theoretically expand functionality by using external applications all together. You could of course just use the application on the file and it does the EXACT same thing, but the goal is to reduce the amount of application switches one has to do during modding.
  8. Template for a generic plugin has been made. I plan on using Qt's generator to create a data plugin template and allow you to name the classes and such. Comes with a default widget layout to get you started with save and save as menu options created by default (kinda the whole point of an editor, so I figured it would be save to assume it would be needed for all plugins) Invoke still takes a path to open files that aren't inside of an archive, I think my last post made that kinda vague. Also includes a plugin meta predefined for example. This is also in conjuction with the doxygen supporting documentation. Hopefully anyone could create a plugin for anything if they wanted. Also thinking of a way to create a "generic" plugin as well. Some thing where you could map out a binary file, and it would create a default form for interfacing with the data types. C++ isn't very reflective; however, if I use Qt properties, I could likely pull something together that manages that.
  9. Still alive! Good news, I now have access to a more decent machine. I migrated from my chromebook running linux, to an actual desktop running windows I plan on mostly programming windows; however, having access to the linux machine makes checking deployement on both systems possible. The code carried over well since I used the integrated plugin system with Qt. Basically just had to rebuild the advanced docking system and relink. I can achieve this with smarter make file management. Now that I know I'll likely do some clean up and optimize things a bit better. Text plugin can load and save text documents. So now it's just adding functionality. The core program is all here I did some work on letting archives call plugins. The plugin interface takes a raw data reference instead of a path. The flow would be as follows (The interfaces are abstract classes, so it's better to just think of them as a black box. Since each plugin will handle these steps in their own way) Hierarchy scans folders. Directory/File -> display like a normal files system tree Archive Supported Format -> load the plugin that supports the format The plugin exposes six functions the hierarchy will use to display the contents. Directories - Called first and used to create the directory nodes in the tree. Names - Called after to place the children in the nodes. Operator[path] - Used to get the raw data reference for a specific child at the path specified. Changing this data propagates back to the archive. Changes are queued, and remain desynched until the Update command is called. Update - Used to update any queued changes to the archive. Extract - Extract the contents of the archive to a folder Build - Build the selected files into an archive If a file in the archive was requested to be opened: raw data gets passed to the plugin using the Operator[path] function where the path is the path to the root from the current branch inside of the hierarchy. The plugin realizes it was called from an archive. The plugin creates an interface to edit that raw data. We do our modding thing. The changes propagate back to the archive. We Update the archive when we save the core application (or force a rebuild from in the plugin) This treats all the parts as a whole file though, and I don't personally like it as much as extracting and rebuilding. Since all plugins are editing a reference to the raw data in the archive when an update is called on one element, it saves everything. Not just the element you edited, This type of editing should be used sparingly and for "lazy" edits. This is because you save the "file" being the archive, not the "file" being the piece. You can instead extract the archives pieces to a directory, then edit the pieces, and rebuild. The difference between editing a map, and its tags if you will. Also trying something new with Imeta/Ipak children. I can get the list of textures from the files by decompressing the first few chunks. And thread the loading of the rest in the background prioritizing any files the user attempted to load. I was also thinking in circumstances of "read only" I could selectively decompress sections of archive. Since each zlib chunk is 0x20000 bytes(except the last one) I could very easily find out which chunk the content of the data is in, and which chunk it ends in and just decompress that data inbetween. Reducing the need to decompress the entire file in one pass. These are back burner thoughts, but shower thoughts are always fun
  10. hi, your tex mod tool doesn't seem to work with halo cea, the game crashes on map loading screen, i followed all the instructions, binded and re-created each imeta. just get UE fatal error, also the file size changed from 6xxmb to around 577mb

    1. Bakgamon


      i finally got it working, figured out the prob, it had too many mip maps on the saved image, that and being in the wrong format. i don't do much texture editing so am a bit rusty.

      had to save as rgb in the nvidia dds plugin and untick generate mip maps. now the game loads without crashing and the texture is gone. thanks for the great tool and the heads up about the format. i knew i was doing something wrong...

  11. Created another plugin type. We now have the option to create Archive plugins. Which tell the hierarchy view how to display the contents of an archive. And we have Data plugins which tell the application how to display the contents of a binary file (potentially contained within an archive). The hope is to be able to expand any compressed file format as though it is just a folder on the computer. I laid out the foundation for the secondary plugin format, and added the checks to load them appropriately. I just need to think about what information is needed to communicate between the two. Also since I'm working on the plugin interfaces, I added the ability for plugins to call other plugins and pass raw byte data, instead of just a file path. With this though, I need to be able to intercept a save request if it's contained in an archive. I would need to rebuild the archive when a change was made (or extract everything into a temp directory) or queue up multiple changes to be rebuilt for larger files. More thought needs to go into this for now. Example how It should feel in my opinion.
  12. Did some more ui work. I think this is close to the final "feel". The directory view wont show every file on the computer all the time unless you're in global mode. Project mode will allow you to specify specific directories, and plugin preferences, and map mode would allow you to break things down even further and see only dependent files for a specific scenario (this will likely be the last to be implemented, as project mode set up correctly can do the same thing). Also cleaned up some of the code and did a commenting pass. Haven't really made much progress forward, but I did some house keeping on what I have done Decided to go with the Advanced Docking System. With some color tweaks, it'll work perfect for what I envisioned.
  13. Had a day off, and I CHUNKED a big portion. Using Qt's built in plugin loader I was able to design the plugins to load at run time, while being system independent. Officially began the "verify plugin functionality" stage by starting to make a text editor. If I can get the text into the plugin, and saved from the plugin. We're SET. Also, since I'm using Qt's built in system, passing Qt objects around has become much easier. Plugins can now connect to slots supplied by the core application. You can now do things invoke a plugin from inside a plugin, and send logs and errors to the main log output. Also gave up on XML. My source code was getting so bloated trying to keep up with it, and everything about c++ goes against xml. I want to maintain a simple, but effective workflow. Now the metafile is this: Loads easier, still human readable, and I can actually read and write this data without 200 lines of code and an external library ;-; While not very fleshed out yet, this is the block out of the text editing plugin that corresponds to the plugin.cfg file above. Since practically everything on my list has been shifted forward a bit, I'm going to dedicate a lot of time to the text plugin widget. I feel we're going to be spending a lot of time looking at it. In the end I plan on having radium's syntax highlighting, autocomplete, and formatting for halo scripting. I have already augmented the parameters a bit for invoking. Arguments are ALWAYS sent now. Even not in CLI mode. This will be useful for passing runtime config. I plan on being able to do something like Plugins["txt"]->Invoke("File.txt syntax=H1A-Script") Plugins["txt"]->Invoke("File.txt" syntax=SceneData") This would allow me to specialize the text editor for specific tasks. Any plugin could utilize this format; however, it means the plugin must split the single string it's passed into a list of arguments. Since I'm using QString instead of std string, it has a split function that will return a QListString, if arguments are going to be used. Started to document the process of creating a plugin for doxygen, as well as creating template classes. Each function is required to define certain classes, The template will allow you to just load up a blank widget, and start designing. I'm also going to start programming generic plugins. 3D model viewer, texture viewer, etc. This is where I'm going to leave it for tonight. I can't seem to get the dock widget style sheet to work right :c Will likely remove the bar on the top of the text editor and go for the more stream lined look like this. Oh, and plugins have menu bars. None of this is implemented; however, this is the concept for what I am going for. You can open files from the primary window. I'm on the fence about docking. I'm not 100% what I want to do there. Error logging and cli interface. I think this will be useful for calling tool or invader from inside the application. Colors will likely be changed around a bit still. Plugins now open the appropriate type when double clicked. I just need to decide how im going to implement the widget into the application. I think I might try to do a docking system I feel this would work well. Being able to stack windows together, detach however you like. like in the previous example. We will seeee
  14. Laid out goals and time allocations. Now that I've successfully prototyped the things required to achieve the project in spaghetti code, it's time to actually create the project correctly and organize it. Setup a time line. The container program has a projected timeline of ~2 months. This should be enough time to realistically do the things that need to be done. Plus some padding. Beyond this I will begin working on each plugin independently. Starting with the h1a plugins and working my way down. This isn't a complete project scope timeline as there are further intended goals. I had an interesting thought though when it came to blam plugins. Since we already have many different editors I figured maybe I should take a different approach to things and try to push the bar a bit further. The goal for Blam plugins will be a node based editor. That displays as much related data as possible in the viewing area (Super_high_quality_mockup.jpg) The node design would expose all tag parameters, relationships to other tags, and the contents of those children recursively. There may be some hurtles to overcome with this method; however, I think it might be a helpful way to organize the data c: Doxygen setup. Project setup going well as well. Noticed that Qt already has a plugin system that is platform independent. So despite all the testing I did, I feel implementation using their system lean towards a more stable foundation. Plus it's designed to work with Qt widgets. Since I intend to use QWidgets for the ui interface, Constraining the plugins allows me to ensure things like Qt version and other higher level information. Plus it has better integration into the flow of the source code. I am really reevaluating my decision to use XML. as time progresses forward I'm realizing the xml is not well suited for c++. I feel like every "solution" is actually more of a patch work approach. I'm sure this is due to c++'s lack of self-a w a r e n e s s I realized that my one plugin per definition couldn't work. I realized I would have to literally create a thousand different identical plugins for any text document. i'm sorry, but n̴o̴ t̸̖̗́ h̴͓̄ a̷̞͑ n̷̯̈́͘ k̷͈̇ͅ s̶̮̣͒̀ I feel like I could make it neater by just smacking 5 lines into a text document and reading it like by line. Name: Author: Settings: blah blah Simplicity will likely be the method I take. The point is practicality. After this. I am going to attempt to create a text editor plugin.
  15. Plugin meta got exported to an xml document. and the parameters get read on load. I felt this may be a better addition. This allows me to edit the plugin metadata without recompiling the plugin. For generic types I can add a supported format easily. For example, with a text editing widget I could add .txt, .xml, and other text formatted files just by appending a new format to the xml. This also gives me something to check against with the autoupdater. The updater will download the XML document and validate version. This means each plugin needs to have a "plugin.xml" file along side the .dll/,so Also added a generic string based settings system. Settings map a name to it's value as another string. The settings can be read any modified easily, and then the plugin reloaded. Besides that, I decided instead of exporting Invoke, Draw, and Save I would have an Initialize function return a pointer to a base type Plugin, and have Plugin require an Initialize, Load, and Save function. This works practically the same; however, the plugin now returns an instance of a class instead of allowing you to interface with the class remotely. MERGED UPDATE: Pretty sure this will be the final XML tweak for now. Implemented autoupdate feature. works by downloading the plugin.xml from the url supplied in the DownloadURL tag in the plugin meta. When the plugins get loaded the application will look for a plugin.xml in the URL directory supplied and if one is found it will download the file and check the version against the local XML file. If they don't match, the program will then look for the Lib file in the same url and attempt to download that. The old plugin will be temporarily stored in a backup directory in case of compatibility issues. In the event of the new plugin causing a crash, the program will notify the user that a plugin has caused stability issues, and will be rolled back to known working plugin. Made some decisions as well for design paradigms. One plugin per file type. The plugin of course can handle sub documents no problem; however, one plugin can't define imeta, fmeta, s3dpak, map, ipak and just be called a suit of anniversary plugins. One must be designated to a specific file type. Settings are to be modified external to the plugin (in case you cant load the plugin to change the settings.) This was one major reason to migrate to XML. Recently had to get covid tested :c so im out of work for a bit until I get results. Hopefully that means I can dedicate some time to the project c: Also did some A E S T H E T I C I dont think im going to focus too much on relocatable widgets. I have enough on my plate for now.