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

All Activity

This stream auto-updates   

  1. Today
  2. It's a dead game, what do you expect after nearly 2 decades?
  3. Updates: Updated script documentation in all files. Added the option to prevent players from @mentiniong users on Discord. All messages can now be edited from inside the ./Discord Bot/settings.lua file Updated original post to match what is seen on the GitHub project release page.
  4. Yesterday
  5. Updated the download link to a Mediafire link.
  6. Sorry for the inconvenience everyone, I most likely deleted a Discord server or channel that contained the download. Updated to a permanent Mediafire link now.
  7. 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.
  8. Last week
  9. Oh, yeah, this is primarily intended for custom maps first and foremost. This is never going to produce Halo-like lightmaps. That said, I DO intend to reverse engineer tool.exe's radiosity and make my own lightmapping tool, possibly with modern features such as threading.
  10. Upping the resolution on the lightmaps to achieve higher quality/cleaner/crisper shadows clashes horribly with Halo 1's low-poly aesthetic. This is tried over and over again and the first impressions are all wows and high fives but it never really feels right. Stick to just emulating exactly what the old lightmaps looked like, but rendered faster and open source.
  11. For your first point, the built-in errors for the toolset is often highly cryptic. You MIGHT get a useful error message sometimes. But often times, you just get a generic exception error which CAN'T be searched, making them very un-user friendly. When it does have errors, many people often have to resort to messing up their tags until the tools are finally happy with them. And when it doesn't report errors where it should, the game crashes. Invader, on the other hand, is very impressive and well-polished for the feature set it provides. Error handling is also way better, often telling you exactly what is wrong with your tags if you have errors and even providing an automated means to fix tags if it's too much to try to fix everything yourself by hand. Not only that, but Invader supports a variety of inputs besides .tif and .wav for creating assets. Tool's LibTIFF implementation may not work with some TIFFs made by newer image editors. Invader also lets you use .png, .tga, and .bmp in addition to having a newer LibTIFF implementation. Invader also supports FLACs for audio input, allowing you to keep sizes down. Unlike tool.exe, it also does not require you to violate the law to make Xbox ADPCM sound tags, and the Xbox ADPCM sound is a bit better, too. Invader also has really good performance with large tags. The tag editor, for example, takes less than half a second to load d40_b. Guerilla, on the other hand, takes about a million years to open it. For your second point, the documentation may not be that much yet, but that's because I value quality over quantity and I've had to write it myself. Here are some examples: Want to make a bitmap? I have one of the best tutorials for that. It not only explains how color plates work and the many different quirks of them, but it explains all of the different formats you can use for making bitmaps including the pros and cons of them. https://github.com/SnowyMouse/invader/wiki/Creating-a-bitmap Want to make a sound? There's hardly any tutorials on that, but the Invader tutorial not only tells you how to make a sound tag, it tells you how pitch ranges and permutations work and also explains the various formats. https://github.com/SnowyMouse/invader/wiki/Creating-a-sound Invader also does a number of things the base tools simply do not do, and it is way more reliable at finding errors that the base tools do not do. It also does not introduce a number of errors the base tools do. I and many others consider this "very impressive" but the fact of the matter is that people use the stock tools because they're the stock tools. Not because they're actually any better to use, and certainly not because they have more documentation available. Such is the way of things here. And honestly, it's feedback like this that make me wonder if making a reimplementation of the Halo Editing Kit is even worth it (not blaming you of course - this is just what people tell me all the time). Not a lot of people test it, and no one actually lends a hand. I am lucky if someone even says "I'd help if I could program" here. I have had to pull so many hours and sleepless nights just to get Invader where it is by myself because, let's face it, no one cares. Almost everyone is perfectly happy using a broken, buggy, closed source toolkit for making their maps. Again, my concerns with this are that no one will use it, especially with MCC's modding support potentially being right around the corner, thus most people aren't going to use this format, thus it wouldn't be worth the added confusion. If MCC CEA was never ported to PC or I was certain it wouldn't go anywhere modding-wise, I would be fully on board with making this new format. And, of course, MCC CEA's new format is still .map, which all seven games are already .map.
  12. You should give it play now
  13. Ah, good to know! Yeah. It's a shame the CEA map formats aren't being versioned well. People prefer the stock tools for two reasons: 1. The stock tools are more "searchable". This is because... 2. They have a long history of use and documentation in the form of tutorials, and–therefore–community support. Only a polished product offering the same features and more in addition to documentation and tutorials will be able to overshadow the usefulness of the stock HEK. Even then, the only way it could become well-known is if news outlets pick it for a story. For that to happen, Invader needs to be impressive. Very impressive. A well-though-out and extensible format will solve a lot of headaches in the future.
  14. 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
  15. Tues, May 11th 2021 Updates: Corrected an error that appears when the script is unloaded. Added 3 new customizable messages: 1). You cannot re-vote at this time. If a player tries to vote more than "re_vote_count" times, this message will be sent to them. 2). Please wait X second(s)... Message sent to player when they attempt to vote too early. This is after the game ends but before the PGCR is shown: 3). Invalid map vote id. Please type a number between 1 & (max) Message sent to player when they type an invalid map vote id: Tweaked script documentation. Added new "error_log" property. If there are any errors, this will be the file to which they are logged (located in the root directory)
  16. I've downloaded this before. Redeemed something from Twitch Prime. And then just never played it.
  17. This is a very nice tool. I was researching stuff about the cycles renderer and I found that Blender has a new experimental one "Cycles X". It's supposed to be 2 to 7x faster. Here's the article: Cycles X — Blender Developers Blog I see that it took a lot of time baking the lightmaps with Cycles. I was wondering how much less time it'll take to bake lightmaps with Cycles X? Can you do some tests please?
  18. I can't get enough of this game and custom games nights bring moments like this https://clips.twitch.tv/SpicyIgnorantPeachBigBrother-Zevr0UK2BhrLiTyM
  19. And we're probably back. More than likely semi-permanently unless I need to restart my PC and forget to reboot the server. Or if it goes vacant for a few months. But at the very least it will be active until 1.17 comes out and my friends and I have had our fill. Assuming some other friend doesn't decide it's a good idea to spend money on a Realms server again. There are plans to get a Zen 3 powered NUC-like PC in the future but that's only whenever AMD decides to actually sell the APU's. From then the server will be permanently available unless my ISP says otherwise and blames the gravitational force of the moon and the solar flares of the sun.
  20. Sun, May 9th 2021 Updates: Added the option to limit how many times a player can re-vote (once by default). In the case that all maps voted for have equal votes, the script will now pick a random one. Added the option to clear the player's console each time we need to print the vote options. Refactored a couple of functions for improved performance & updated script documentation.
  21. 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
  22. I am new to this, I need help! Let's say I have my "halo ce server" and I want to put this "Halo CE servers - DDoS Firewall" The question is, what do I have to do? Where do I start? there is no video or something showing how to install this "Halo CE servers - DDoS Firewall" from scratch?
  23. why is that strawberry so angry? :v
  1. Load more activity