Zatarita

Can you throw a performance monitor on network traffic and then check system logs around the time the network drops? I'm curious if maybe there are ddos protections that are set too low

Due Date: May 24, 2022 Voting Opens: May 31st, 2022 Welcome! So happy to have you here this fine Friday. @Takka has reached out to me with a fun opportunity. Like what they have done in the past, we're bringing you a mapping contest. The prizes sit at $100 for first, $50 for second, and 5 Raffle Tickets for third. Also first place ( Like our wonderful donors c: ) gets an exclusive badge next to their name they can use to brag to all their friends c; FAQ Q: What is it? A: All you need to do is create a custom map (not yet released), and submit a forum post about it before the deadline. This time our Halo overlords have blessed us with the editing kits for later games; so we felt it might be fun to expand our scope to allow any game from MCC. We've gotten some feed back from the community as well about previous mapping competitions and we hope this year we can fine tune things a bit better to the community. We will have a slightly extended submission duration at a month and a half from today. We wanted to keep the duration manageable, without incentivizing procrastination. This should also give some extra time to debug any issues we might have with the quirks of the newer editing kits. Submissions will be voted for 1 week, beginning a week after closing date. This will allow the community time to get acquainted with the new maps and form opinions. We are only going to allow one submission per person. Q: Can I work with a team? A: You are more than welcome to work in teams; however, this is not required. If you do work in a team though, you cannot submit individually. We request still that there is only one submission per person. This is to hopefully drive users to quality over quantity. In the case that you do work with a team, one user must be the designated liaison who will be responsible for receiving potential prize money and distributing it amongst the members. OC will not responsible for the distribution to individual members. This individual will also be in charge of hosting the map and creating the submission post. Q: How will I be contacted if I win something? A: In the event that you win a monetary prize, a moderator will reach out to you through the DM system on this website, and prize money will be paid out through PayPal. In the case you win tickets, the OC ticketing system will send you a notification on this website. Winnings 1st Place: $100 via PayPal 2nd Place: $50 via PayPal 3rd Place: 5 Raffle Tickets Additional Means of Reward Share the Knowledge: Tutorials based on an element of your submission will earn you 5 Raffle Tickets. Developer Commentary: Create a Work in Progress topic exceeding 100 words for your map, and you'll be awarded 1 Raffle Tickets per post per day, with a limit of 5 total tickets. Promotion: Share any link to Open Carnage, prove it, and earn 3 Raffle Tickets. Rules Maps must be submitted to our MCC Map Releases section. Only one submission per person or team. Voting begins 1 week submissions close. Teams must have a designated liaison responsible for managing the release, and any winnings received. Happy modding!

We are currently aware of the issue, sadly atm need to wait and see how long this remains an issue. If they fix it in a week/two, we may consider just extending the a bit. If it's an issue through the whole duration of the competition though we will have to come up with a more solid solution. Essentially we will accommodate for this as best we can. We hope for the best; however, we are preparing for the worst. I do apologize for the inconvenience though

Spent an embarrassingly long time writing a rubiks cube random scramble generator. I didn't realize there would be so many hoops to jump through. Had to account for coaxial movements to skip redundant moves, and set up xamarin forums and stuff. 100% new to me, and c# is confusing coming from years of c++.

Birfday

I love this ccc:

A bit late to the party, but to anyone else curious in the future you should be able to extract and rebuild with invader as well c: This is a more modern solution, that also allows you to specify other targets (such as xbox, or MCC) as well c:

Similar to the Tools Shortlist, you can find many of the most useful MCC tutorials listed here. MCC Compression Formats Detailed information on compression formats used by various files. Running MCC Modding Tools on Linux With Wine Tips on configuring wine for the MCC mod tools. Porting CE Maps To MCC Tips on how to port existing CE maps to MCC. Working With GBXModels Creating and working with models used by the engine. Editing Thumbnails and Loading Screen Map Names Modifying the main menu elements for MCC. S3dpaks Detailed information on the s3dpak and some of its contained files. Tutorials making it to this list earn 8 Raffle Tickets!

This song is lit

Ordered a new speed cube ＼(◎o◎)／ It has mag lev ._. we live in the future Edit: It has arrived! https://cdn.discordapp.com/attachments/252461260560400384/933379847617671249/IMG_3257.mov

Welcome! Recently I've been keeping pretty busy. I started going back to school, and the holidays have kept me going; however, I found some free time and I wanted to do something modding related. I read a lot of questions about custom models on some of the discords I frequent. I felt this would be an awesome opportunity to expand our knowledge base on OC. C20 has a lot of extremely useful information, but my hope is to teach you a deeper understanding of how the engine handles creating and managing a model presented in a scene. A GBXModel is the pc variant for the tag used to define a model used as an asset for Halo. A GBXModel isn't just "a model" but instead it is a collection of models. These models define the objects state for a given instance or condition. These models can be broken down into Regions and assigned Permutations for some variation, defined Levels of Detail for proper optimization, bound to Nodes for animation, and assigned Markers for special effects. In order to create a GBXModel we need to use tool's Model command to compile the raw model (jms) into a GBXModel. Tool will take all of our different models and compile them all into the collection of models discussed above. Of course this is an oversimplification for the introduction to the concepts, there's a bit more that goes into it. I will discuss each of these ideas later in the post. Table Of Contents 1. Nodes 1-1: Summary 1-2: Example Hierarchy of Nodes 1-3: Creating a Node Newer Versions Of Max Older Versions Of Max 1-4: Other Node Information 1-5: Common Node Issues Tool Ghost JMS Exporter 2. Regions 2-1: Summary 2-2: Example Region Variations (Permutations) 2-3: Creating a Region Blitzkreig & Ghost JMS Exporter FBX-to-jms 2-4: Creating a Permutation 3. Markers 3-1: Summary 3-2: Example Markers 3-3: Creating a Marker 4. LODs 4-1: Summary 4-2: Example LODs 4-3: Creating LODs 5. Creating GBXModels 5-1: Exporting FBX-to-jms Ghost JMS Exporter 5-2: Compiling a Model Additional Information PLEASE If I missed anything, or could make anything more clear lemme know c: I would like for this to be as accurate and complete as possible. It took me 8 hours to write this up, I want to make sure it wasn't for waste! Happy modding Updates: 12/22/21 Markers : TY Galap/Mata for the suggestion to clarify markers aren't required to be spheres, and reemphasize that orientation matters. Regions : Updated network sync details 12/25/21 Markers : included example LODs : Wrote introduction 01/06/22 LODs: Wrote "Creating LODs" Formatting: Adjusted nodes to its own post setup TOC. 01/11/22 Formatting: Finished To Do Once I have time to update: Discuss GBXModel Importer by ghost

Creating GBXModels creating a GBXModel requires us to export our data from 3ds max in a format tool can utilize. This format is called .jms and to get a model in that format we have a few options: Ghost JMS Exporter, Blitzkrieg, and FBX using H1A-EK's tool. For this tutorial I will touch on Ghosts JMS Exporter, and tool's fbx-to-jms converter which are the more popular of the options. All jms files are expected to be inside of a folder named "models" and this folder is expected to be found inside your "data" directory. Beyond this it is up to you how you wish to organize your folders. Tool will mirror the naming convention you used with the "data" folder in your "tags" folder for compiled files. If you save your models in "data\scenery\new_thing\models" tool will compile your GBXModel to "tags\scenery\new_thing\new_thing.gbxmodel" and create the necessary folders to facilitate that. Exporting Compiling a Model:

Levels Of Detail (LODs) LODs are (optional, but highly recommended) optimized versions of permutations that are chosen based off distance the object is from the camera. Your first instinct might be "My computer was built almost 20 years after this game has been made. It can handle high poly counts, let's crank up the detail."; however, I would like to temper your expectations. There are two main reasons for this: 1) High poly counts does not necessarily mean better detail (It may just be poorly optimized). It's better to say more with less. Not everyone has a high end system. We can't forget this is a game and people may wish to play competitively against each other. a versatile asset uses only the amount of detail necessary to say what it needs to say. 2) Something I call "Detail Dissonance"; When your mesh has more detail than surrounding meshes it contrasts more with the scene. Artistically this draws someone's eye more to that object. This this could be a good or bad thing depending on your desired outcome. It is in my opinion that high poly model surrounded by low poly models can break the cohesion, and unbalance a scene if not done properly. Using LODs will help prevent this for far away objects. Halo allows you to define 5 optional stages of LODs: super-high high medium low super-low Tool will remind you when compiling GBXModels to set the LOD cutoffs. These are set inside guerilla and determine the threshold where one switches to the other. (see below "Creating LODs") Something to note about LODs and markers and nodes. You still require all of the nodes to be in each LOD version; however, markers are only read from the Super-high LOD. This means if your mesh doesn't utilize a Super-high LOD your markers aren't going to be included. If you don't use any LODs the default option will be super-high, so this may not be an issue. Though, do keep it in mind. Example LODs: Creating LODs:

Markers Markers are points relative to the mesh that can be used to define a position (and rotation) used for things like spawning special effects or attaching an object to another. For example we could have a marker at the end of a gun that emits smoke, or a marker used to attach the pipe to the Keyes' hand. Markers are created similar to nodes; however their names must start with a #. They are represented with a scene object, such as a sphere or other primitive. The object is just a handle used to adjust position and orientation of the marker relative to a node. None of it's mesh data will be included once we export. When creating tags that utilize the gbxmodel we can define the effects that spawn at the markers, or in scripts we can reference the marker names directly. Any markers that happen to have the same name will have the effect applied to both positions at once. For example if you have two marker called "#steam_emitter" and you attach a steam emitting effect to that marker name, both markers will emit steam. It's also worth noting that markers are owned by the permutation. This means that unlike nodes there don't have to be the same amount markers for all permutations. You can have a permutation that has two steam emitters, a perm that has one steam emitter, and a perm that has none if you like. There are a few special case markers as well. Halo uses these for certain functionality like head position so AI knows where to look, or hand locations. For more information on this check out the c20 page on markers; They do a great job explaining this, and I don't want to reinvent the wheel. Example Markers: Creating a Marker:

Regions Regions are named sections of a model. This allows you to create different versions for that section of model that can be selected randomly or assigned with scripting. These variations are called Permutations. There are other uses for regions; however, they are covered more in the collision_geometry section of the tutorial. Because these permutations can be selected randomly the region needs to be mapped to the same bones as the base mesh. Which means they require the same amount of nodes even if the vertices that those nodes bind to doesn't exist in this permutation. There are special case regions used by the engine when specific conditions are met: ~damaged : Gets chosen when the object's health reaches a certain threashold. ~shield_off : Gets chosen when the object's shields run out ( If it has shields ) ~primary_blur : Chosen when a weapon reaches a firing speed threshold with primary trigger pressed. ~secondary_blur : Chosen when a weapon reaches a firing speed threshold with secondary trigger pressed. ~blur : Chosen when vehicle reaches a speed threshold specified in a vehicle tag. These special permutations are completely optional; however, they add a lot of life to a object. They will make a bit more sense when we get to collision models, I will hold off on explaining them until I get around to making that tutorial. Something to notice is that these names all start with a "~" which is a special character used to tell the engine that this region isn't one that we want to get randomly chosen. We can use this naming convention for our own purposes if we like; however, the only way we can utilize a permutation like that is through scripting. For people making campaign/coop missions this may be desirable. Also any permutation selected randomly will not synchronize over a network. This means in order to use permutations as variations for objects online, and have each player see the same one, you MUST select it with a script at start up. If not each player can have a different random permutation set. For some scenery objects this is not that big a deal. For example halo 3 uses this concept to change the position of stickers on a barrel. For other objects though you need to be careful as it may cause inconsistencies between clients. My general rule of thumb for this is "if the collision stays the same it's ok". A random pile of papers on a table, or different labels on a barrel won't impact game play; though, a soda machine being there for some people and not others can be game breaking. Having permutations can add some variety to your maps, but try to keep it to smaller details for multiplayer, or force the permutation with a script for all clients. (optionally you can also create LODs once you're done creating regions and permutations) Example Region Variations (Permutations): Creating A Region: Creating a Permutation:

Nodes Nodes are anchor points for our 3d models. They are called nodes because they determine the object hierarchy like a graph. Every model requires at minimum a root node. This node must be prefixed with "frame" or "bip01". Beyond that nodes act like "bones". You anchor a portion of the mesh to a node, and when we animate; it's the nodes that we are animating. Each part of a mesh that moves during animation needs to be assigned to a node. It's worth noting that each vertex can only be influenced by up to two nodes in the case of a rigged model. There are other uses for nodes as well; however, I will cover those later in the collision_model. Nodes don't have any mesh data themselves, they represent a point in a hierarchy with a 3d coordinate and orientation. We typically represent them as a scene object such as a sphere; however, this is only used to interact with the node in the scene. Once we export the models to jms the 3d position, orientation, and position in the hierarchy are the only bits of information passed through to the GBXModel. It's also important to remember nodes need to remain consistent between permutations. (discussed later) Example Hierarchy of Nodes: Creating a Node: Other Node Information: Common Node Issues

I like it c: not only is it "a single line" it's also branchless which is more efficient c: Mark it down as an optimization to make it sound fancy c; Not completely sure how the scripting language works, I'm assuming you're trying to toggle a value. but if you could xor you could theoretically avoid the comparisons as well by just xoring it against true If the state is false xor true -> true If the state is true xor true -> false I like the thought behind the move c: branchless programming can be pretty powerful. Awesome work

Sorry for the late reply. So, most of the UI elements are actually flash documents. You can decompile them with a flash decompiler (There may be better ones than this, but this is the one I used to poke around) You can find the loading screen in Halo The Master Chief Collection\data\ui\Screens Open it with the flash decompiler and you can mess around with it Same thing with the standalone H1A on 360; however, those screens are inside of one of the s3dpaks.

Awesome work! Quite thorough, but not overly verbose c: I’ll have to give it a shot. At one point we found out you can rearrange the text that gets presented during the loading screen too! I dunno if you’d be interested, but I’d be happy to share! Funny enough they use flash files.

Similar to the Tutorials Shortlist, you can find many of the most useful MCC tools listed here. Invader Strives to be an open source alternative to the standard HEK. Assembly Modding tool that spans multiple generations of Halo game. QuiCript Multi-generational (de)compression tool. CeaFlate Halo 1 Decompressor. Written by kava that utilizes threading. SuP Unpacks and repacks saber s3dpaks. Partial support for texture extraction. TexMod Texture extracting and importing. Rough around the edges, but the best we've got right now.

Yep! I need to update the tutorial, I appreciate the feed back c: Kava mentioned this in conservancy, along with the fact some script commands don't work in MCC. He also mentioned that it would be wise to refactor the shader_chicago and shader_chicago_extended into shader_transparent_generic Also mentioned that there may be conflictions with classic bitmaps now following the new multipurpose maps. I've been trying to think of solutions for the last one. Might have to create a emulated mod environment that's isolated from the main one. This would also reduce the need to strip and bludgeon EVERY tag every time. I definetly appreciate the feed back c: I will update this with the new info when I have some free time to do so

Hello! Recently I find more people asking how they can extract CE maps, and rebuild them into MCC. I want to state that this is possible; however, the modding community does not, and never will, condone ripping others' work. This should only be done for maps you have made in the past, maps you have gotten permission from the author, or maps used only for personal use. As far as the "preservation of modding history." discussion; I will refrain from discussion here. This is a moral grey area, and it's an issue the community will have to figure out. Lets do the thing! We're going to be utilizing invader, and the anniversary HEK for this. Step 1: Setting Up The Tools Starting off we need to install the Halo CE Modding Tools tool in steam. This link should take you right to it. ( for some reason OC doesn't seem to like this link: steam://run/1532190 paste into URL to open steam ) After this we need to download Invader, and install it into the Chelan_1 directory. ( It is a 7z archive, I use Win-Rar, but you can use any archive software really ) From here we want to navigate to the MCC Modding directory that steam made for us called Chelan_1. An easy way to do this in to click on the cog in the steam page for the modding tools. If you're having trouble locating the editing kit in your library, make sure you have "tools" enabled in the library filters. There will be three zip files inside Chelan 1. data, shaders, and tags. You'll want to extract each of these into the modding directory. Keep in mind that with the recent season 8 update there have been changes to some tags. if you have already extracted these folders, you may want to re-extract them to keep them up-to-date. You may experience HUD issues. With all of that out of the way, we should be all set to move on to the next step. Step 2: Extracting Tags I personally don't have any maps, or tags to port over currently. For this example I'm going to use the classic map Yoyorast Island. Remember we don't condone ripping others' work. This is just for an example. I'm going to install the map in the maps directory in the modding directory. ( note if it doesn't exist, just create a new folder and name it maps ) Back in the root directory of the modding folder, we're going to open a command prompt by typing in the folder URL bar "cmd" After we do this it will open a command prompt that is already opened in this folder. If you just have a tags folder to transfer over, copy the new tags into the tags directory, and go straight to step 3 from here. Next we're going to use invader-extract to...well.. extract the map. The only arguments that are needed is the exe ( yellow ) and the map we're extracting ( green ) It will print a bunch of text to the console showing the process of the extraction. Skipped tags are tags that already exist in the tags directory. ( you can over ride this if you like but it is not recommended. ) And once it finished you have finished with the extraction of the tags. You'll get a confirmation at the end ( I extracted none, because I already extracted them once before practicing for the tutorial. ) Don't close the command prompt, as we will need it in the next step. Step 3: Cleaning Up The Extracted Tags Lastly we need to do some clean up to the tags, as some of the tags for CE have invalid data for MCC. Invader makes this step simple as well, we're just going to run two commands. "Invader-bludgeon --all", and "invader-strip --all" Invader bludgeon is going to go through all the tags in the tags directory and sanity check them. It will attempt to fix any issues noticed. Keep your eyes out for any red entries, as these may require manual fixing. This typically is caused by tags extracted with really old tools like HEK+ that screwed up the tags so badly that invader can't assume the fix. I have found a few shaders like this. Once that finishes you'll get a confirmation, like with invader-extract. After we're going to run "invader-strip --all" This is going to strip hidden data from tags and recalculates their checksums. This is needed for MCC to not think the tags are corrupted. This will take a few mins to run through as it has to do this to every tag. Once it finished though the tags should be in a usable state for MCC. We can attempt to open the scenario inside of Sapien to verify that claim. Stonks, and for the icing on the cake, we'll build the map, and load it up in game: There are going to be many issues you run into. Feel free to comment down below and I will be happy to answer any questions. Any common issues ill add to the end here in a trouble shooting section

Operating system diversity approved

That is a good point; however, kava brought up the point of refactoring the shaders, and I'm trying to implement something that scrubs scripts for forbidden scripts Functions So to some extent we can expand the map to use new features

In my recent post I briefly touched on a discussion I heard in one of my discord servers discussing preservation of mod history. More specifically, porting maps from authors that are no longer in the halo scene. I had a few thoughts on the matter; however, I feel this is a discussion we should prolly have as a community. I feel OC is a civil grounds for discussion. I guess I should start off with my own stance. I believe that anyone porting a map that is not their own, cannot place their name in any other location besides "porter"/"converter". Author should remain the same. for the case of no author available, it should clearly state author unknown. If preservation is your key motivator, this would make that clear. Your name should be secondary to the initial meta data. I feel good practice would be to include an email so the author can take claim given that was lost to time. I also believe that if preservation is the desired goal, respect must be taken with ports. it should also be good practice to include your email to fix any porting issues. This means you would be taking responsibility for not just the initial port, but the maintaining of the authenticity. Treating it with this respect would make it clear that your intentions are preservation. I'm interested in others' thoughts on this matter. Please remember to be civilized c: