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

About Kavawuvi

  • Birthday April 10

Extra Information

  • Gender
  • Contributed
    $100 (US) to Open Carnage
  • Raffle Victor

Computer Details

  • Name
    Dark Citadel
  • Central Processor
    AMD Ryzen 5 2600
  • Motherboard
  • Graphics
    MSI GeForce GTX 1070 Gaming 8G
  • Memory
    32 GB [2x 16 GB] G.Skill Ripjaws V Series
  • Storage
    500 GB Samsung 970 EVO SSD (NVMe) + 240 GB ADATA XPG SX930 SSD (SATA III)
  • Power Supply
    EVGA SuperNOVA 650 G3
  • Case
    Fractal Design Node 804
  • Display
    LG 27GL850-B 27" 2560x1440 144 Hz IPS
  • Keyboard
    MAX Keyboard Nighthawk X9
  • Mouse
    Logitech M510 Wireless Mouse
  • Operating System
    Arch Linux

Recent Profile Visitors

132,948 profile views
  1. AAAAH!!!! Wow it's been that long???
  2. Oh, wow. This is actually really good and useful. Nice!
  3. This is a small fix. Basically, every April 1st, it'd add a cartridge tilting effect. This originally did it on all maps. However, I've changed it so it only does it on the main menu. Sorry, that was an oversight on my part.
  4. I updated the review a little bit to better distinct Variable Refresh Rate and FreeSync. Basically, FreeSync is AMD's proprietary standard used on both HDMI and DisplayPort. Adaptive-Sync, however, is a DisplayPort standard. Not everything supports FreeSync, but some things support DisplayPort's VESA Adaptive-Sync (for example, non-AMD GPUs). I've also noted that it does claim to support HDR, but it actually isn't really HDR (the contrast ratio, while fine, isn't good enough). It also supports 10-bit color. I found that pretty much all games benefit from it in some way. Obviously genres can play a role, too. An FPS or an RTS is going to benefit a lot more than, say, Tetris. Halo: Combat Evolved look fantastic. Killing Floor 2 looks really good, too, though it's pretty CPU heavy and may dip below 120 FPS sometimes, even when lowered to 1080p. Adaptive-Sync is extremely useful here. Goodness. I haven't tried Minecraft with this, but this is definitely a game I thought would benefit a LOT from the high refresh rate. The Bedrock version (Windows 10, mobile, and console) probably benefits the most from it, as that version gets a very good frame rate even on toasters.
  5. Holy shit. This is amazing.
  6. I've been using this monitor for about a week now, so it's time to write a review on it! For reference, this monitor replaces my older Acer G257HU smidpx 25" monitor which I reviewed here: What's good about it? This monitor has a 2560x1440 (quad HD) 144 Hz nano IPS display. Nano IPS is a better version of IPS which cover more than the sRGB color space. You can read a whole article on it on DisplayNinja or ViewSonic, but in a nutshell, it's IPS but better. Anyway, like most IPS displays, the viewing angles are really good. The gray-to-grey (G2G) response time is also pretty low. I wouldn't say it's 1 ms as advertised, though. Sure, you can set the Response Time to "Faster" and you'll technically get an average of 1 ms response time, but the result is tons of inverse ghosting artifacts and trailing due to overshoot, which kind of defeats the point of getting a low response time (less ghosting!). Thankfully, this is not the default setting. In fact, the default settings are pretty good - MUCH better than my previous Acer monitor which maxed out the overdrive setting by default, resulting in LOTS of the aforementioned artifacts. I primarily do programming, so 1440p, while not necessarily required, is extremely useful for what I do, and going back to 1080p would've been a far bigger downgrade than the upgrade of going to 144 Hz. I also play video games, though, and I wanted to try something better than 60 Hz. It also support for variable refresh rate (VRR). This results in the monitor adapting to the frame rate of the game - basically a reverse form of vSync with none of the input lag. The on-screen display controls for the monitor is also pretty good (it uses just one button under the display!). It lets you configure a wide variety of settings, including two custom profiles and a few built-in profiles for various use cases (FPS, RTS, sRGB, "reading") as well as two other settings "HDR Effect" and "Vivid". The custom profiles let you configure most of the settings, while the other ones only let you configure brightness and contrast. sRGB mode is nice for viewing content, and the two custom profiles are really useful, but I'm not sure what the point of the other settings are. The stand is also pretty good, too. You can pivot, tilt, and raise/lower the monitor (but not rotate - you have to rotate the stand, itself). And if you don't care, you can use your own VESA mount, instead. Lastly, the monitor is not terribly expensive. I got mine for about $480 (after tax) which really isn't too bad considering it's a 144 Hz, 1440p, IPS display. Can I use Adaptive-Sync or FreeSync with my PC or console? To use VRR with this monitor on a PC, you need an AMD (GCN 2.0 or newer), Nvidia (1000 series or newer), or Intel (11th gen or newer) GPU to take advantage of this feature. Older Intel, Nvidia, and AMD GPUs do not support the standard. If you're on a console, currently only Xbox One X/S and Xbox Series X/S will work via FreeSync. The Nintendo Switch does not support either standard (it does not use DisplayPort and it uses an Nvidia chipset), but the PlayStation 5 is planned to get support for this in a future update. Also, you cannot use VESA Adaptive-Sync over HDMI. Only DisplayPort actually officially supports variable refresh rate, where with HDMI 2.0, you have to use the proprietary FreeSync standard (only HDMI 2.1 or newer natively supports Variable Refresh Rate - this monitor only has 2.0 ports though!). So, depending on your device (basically any device with a non-AMD GPU), you may have to use DisplayPort to get this feature. And, of course, the game needs to actually run below the refresh rate of the monitor. If it runs at or above the refresh rate, you'll get tearing as usual. At 144 Hz, it's probably not going to be that bad (assuming you even notice it), but it is something to watch out for. Is 144 Hz so much better than 60 Hz? Let me start by saying the difference between 60 Hz and 144 Hz was immediately noticeable. Merely moving the cursor on my desktop was immediately better. Scrolling on pages looks really smooth, too. And, of course, gaming, itself, looked so much better. Of course, I wanted to know if this was placebo! After playing on 144 Hz for a while, I did a blind test where I did not know the refresh rate. To do this, I wrote a Bash script that changed my refresh rate to randomly either 144 Hz or 60 Hz without telling me which one, and then ask me what I thought the refresh rate was. I found I could, indeed, reliably tell the difference between 144 Hz and 60 Hz, even though I had not used this monitor for more than a few hours. But does 144 Hz look twice as good as 60 Hz? After all, 144 is more than twice as high as 60. Personally, I think it's a matter of opinion depending on what you play. First, let's invert the numbers to convert refresh per second to seconds per refresh. 144 Hz is 6.944 milliseconds per refresh 75 Hz is 13.333 milliseconds per refresh, or 6.389 ms worse than 144 Hz. 60 Hz is 16.667 milliseconds per refresh, or 9.722 ms worse than 144 Hz. 30 Hz is 33.333 milliseconds per refresh, or 16.667 ms worse than 60 Hz. While it refreshes more than twice as fast, going from 60 Hz to 144 Hz is really only 58% as much of an improvement as going from 30 Hz to 60 Hz - something mostly seen on consoles. However, smoothness isn't the only improvement of going to a higher refresh rate. Because more information is being presented to you ever second, that also means the time between button input and response is effectively improved. Therefore, 144 Hz not only looks better, but games play better, too. What's not so good? My main gripe is that there is only one DisplayPort port while there are two HDMI ports. This doesn't seem like a very bad thing until you consider the following: You can only get DisplayPort Adaptive-Sync if you use... well... DisplayPort. As stated earlier, HDMI 2.0 does not natively support this technology, thus you have to use a proprietary standard like FreeSync if you want VRR over HDMI, where anything else would have to use DisplayPort. Also, if you use the HDMI port and have FreeSync enabled, the refresh rate is capped at 100 Hz when at 2560x1440 and 120 Hz when at 1920x1080. If I can only fully take advantage of the monitor with ONE of the ports, then the other ports are mostly pointless if you care about variable refresh rate. A second DisplayPort port would've been really nice. So, yeah, I ended up disabling FreeSync on the HDMI ports and just used Adaptive-Sync on the DisplayPort input. The monitor, itself, has no speakers, which, itself, isn't a problem since most monitors' built-in speakers are terrible, anyway. However, the audio quality from the headphone jack on this monitor isn't great. It's noticeably worse than motherboard audio. Also, the black aesthetic of the monitor is really good, but the slight "gamer" red accents on the stand and back of the monitor, while not garrish, feel a bit unnecessary. Maybe I'm just being very picky? At least they're using a matte black for everything facing the front, but the red accents would look weird anywhere except in a home environment. Lastly, do not bother with HDR on this monitor. The contrast ratio is okay, but not really good enough to be called HDR. Forget that it says HDR anywhere on the box. Other notes This monitor has a crosshair you can turn on. If you're playing something like a first-person shooter that has a shoddy reticle, you can use this to compensate for it. You can also use the crosshair in games that intentionally do not show you a crosshair without anyone knowing. However, note that doing so makes you a gigantic tool at the same time, so use with caution!! Conclusion This is a pretty good monitor. In fact, it's certainly the best monitor I've ever personally owned. The display looks nice. The colors and viewing angles are good. The refresh rate provides a really good experience in both gaming and regular desktop usage, and I've finally been able to properly watch the 120 FPS version of that one somewhat popular MCC video I made. The only real drawbacks are that there's only one DisplayPort connector and the HDMI inputs only support up to 1440p @ 100 Hz or 1080p @ 120 Hz if you have Adaptive-Sync turned on. It doesn't matter for stuff like my Nintendo Switch which would only ever support 60 Hz anyway, but if I connect a second PC (which I sometimes do), it actually does matter. And, of course, if your input device doesn't have a built-in audio jack, the monitor's 3.5 mm audio jack doesn't have very good audio quality. Pros IPS display (good viewing angles and color accuracy) 2560x1440 (plenty of pixels for regular usage) 144 Hz (smooth, responsive) 10-bit color support Adaptive-Sync / FreeSync Premium support (with compatible systems) Good grey-to-gray response times Good on-screen display Good stand (and VESA) Cons HDMI ports do not support 144 Hz with FreeSync turned on, only 100 Hz (1440p) or 120 Hz (1080p) Only one DisplayPort input, which makes the above con an even bigger issue Poor audio quality via 3.5 mm headphone jack Does not actually hit 1 ms response time without significant overshoot (but the default setting is pretty good) Not actually HDR If I had to rate this out of five stars, I'd say... it depends. If you only have one DisplayPort-compatible device you plug into your monitor and you have your audio coming from your motherboard, as is the case with most PC gamers, this monitor is easily a five star experience. Otherwise, I'd give it three stars. If you need to use the audio from the video cable (i.e. no direct audio from the system you're plugging in), the audio is terrible. You can probably split the audio from the video feed, but you'll have to buy a separate device for that, and they're usually around $20 for HDMI. I can't find anything on DisplayPort online except using a series of adapters. And if you need Adaptive-Sync support from multiple inputs, switching input to input is a pain. Sure, you can buy a $30 DisplayPort switcher, but it's not going to switch the audio (unless you're okay with the monitor's really bad audio). All in all, it's a good monitor, but having only one DisplayPort input, having a maximum of 100 Hz maximum refresh rate on the HDMI ports with FreeSync on, and, of course, the poor audio quality from the headphone jack all hold it back.
  7. Today I bought an LG 27GL850. I'm going 144 Hz!
  8. Well, no, of course I wouldn't want to do that. Blender is a good modeling tool, and its Cycles renderer is really good for making lightmaps, but even that requires a lot of set up to get it right. I suppose the tags could be used to import these lighting settings, and I might try writing something that can let you do that in a later date. However, I'd prefer a 'headless' option which just lets you run a command to bake lightmaps into something that resembles traditional Halo lightmaps. This is easier for the user and possibly even less demanding on hardware.
  9. We are just five features away from replacing the entire Halo Editing Kit with open source software! What we need is the following: A collision model compiler (JMS -> .model_collision_geometry) How hard can it be? A BSP compiler (JMS -> .scenario_structure_bsp) The collision model compiler is required to generate the actual BSP tree, since collision models are also BSP trees. Prepare for utter hell. A 3D scenario editor We need an accurate renderer. Presently, I'm working on a Vulkan renderer, but I can't focus all of my time on this because Chimera desperately needs tended to. Lightmap baking Blender could be leveraged for high quality lightmaps thanks to Cycles, but ideally we should have a command line tool for this so people can essentially mass produce lightmaps. Script compilation Invader needs to do this in order for invader-build to be feature complete, since tool.exe compiles scripts when merging child scenarios.
  10. I've added a new model compiler to Invader. You'll never guess what I named it! (*cough* invader-model). This program supports compiling .jms files to both gbxmodel and model, allowing you to make Xbox model tags directly without any necessary conversion while still creating gbxmodel tags at a slightly better file size than tool.exe. It has both a default and legacy mode. The default mode uses a more logical structure where you'd put your models folder in the directory where your model tag will be compiled to, allowing you to have multiple model tags in one directory. So, weapons/pistol/pistol.model would require a data/weapons/pistol/pistol/models directory. You can make an equivalent weapons/pistol/fp.model model with a data/weapons/pistol/fp/models directory, too. The legacy mode is for backwards compatibility with tool.exe data folders, thus you'd put your models folder in the parent directory, instead, and your model tag will be named the parent directory. So, weapons/pistol/pistol.model would require a data/weapons/pistol/models directory instead. You can't make any other model in this directory, so if you wanted to make, say, a first person model, it'd be put in data/weapons/pistol/fp/models, making a weapons/pistol/fp/fp.model tag, instead.
  11. Oh my goodness, this is really nice! Personally, I don't really think it'd be a big deal to use it on everything unless it screws up something else. Maybe space might be a concern, but I don't think runtime cost will be that much different, if at all.
  12. This is a small update, but I'm sure you'll like it! You can now specify the maps directory in chimera.ini (thanks, pr0ps!). This may be useful on certain installations of Halo. Bug fixes: Widescreen fix can now be disabled again (Jerry) On some system locales, the chat was invisible. This is fixed. (Jerry) Fixed compressed maps crashing on Halo Trial (me) Maintenance: Updated zstandard (Vaporeon) In other news, I'm getting started on the Lua scripting and I'll be working with Jerry on this soon. He's been responsible for a number of bug fixes and really nice Lua scripting improvements, including porting the old Lua scripting API to Chimera, so I'm really looking forward to this.
  13. It isn't selfish to want these things, but map protection really isn't the answer anymore. Ironically, plenty of forms of map protection can result in irreversible damage to the tags even without extracting the map and just playing the map as-is. This is because map protection, in itself, is a form of corruption. Sure! From querying the HAC2 repo using a protection checker a couple years ago, we found that around 1/3rd of the maps out there end up getting flagged as protected. The HAC2 map repo has 6000 maps today. If the average is the same as it was a year ago, then that's 2000 maps. And if each map, on average, took 10 hours to make, then that's 20000 hours of total effort from hundreds of people. Of course, many of those same protected maps have assets stolen from other maps and are more-or-less just copy-paste rips, and some maps may be outliers with tons of time put into them, so it's difficult to assess how much time was put into designing those maps. All-in-all, it's a lot of maps and some real time put into those maps, and I'm certainly not going to discount that. I never said it was selfish (though I think most reasons are selfish). My argument is that there's no valid reason to do it since maps are trivial to deprotect. What I personally think is selfish is expecting someone like me to write 500+ lines of C code to support a shader tag that might actually be an object or sound tag because the map was protected. You see, Halo doesn't care because, in most tags, it relies on context for when those references are read (e.g. I'm firing a projectile from a weapon I spawned a while ago - the projectile is obviously an object because that's what weapons reference in a trigger, and the weapon is obviously an object because it was spawned) - context a program, script, or mod can't have because it's not a game engine. Therefore, I have to go through every single possible tag in a chain to find all of the shader tags (or tags that can be shader tags), thus I'd basically be writing a map deprotector at this point in every single script if I wanted to query all of the shader tags in a map while supporting protected maps. With the Vulkan renderer I'm working on which contains my exact usecase, I've found this work to be utter hell. So, I've been considering adding behavior that disables it and uses Halo PC's crusty, broken D3D9 renderer if a map is detected to be protected, though it probably won't be feasible, so I'll likely just have to write down in the readme that if you enable this, protected maps may not work anymore. Here's another way to look at it: People who have protected their maps clearly did not want other people to read them. So, by not supporting protected maps in tools, scripts, and mods, we are honoring their wishes. Surely you can appreciate that? Sadly, yeah, if you want to ensure your stuff doesn't get stolen, you don't post it (which kinda makes making maps pointless if you won't share it). Map protection may have only guaranteed this at first, but nowadays, it's not the answer. Having the community look out for each other? I really like this idea!
  14. That's a fair point, and I agree. My two big Halo projects, Invader and Chimera, are open source and publicly available for all the world to see. As for if I'd delete either project's source code, well, I am certain I'd never do that. That being said, I have not been offered a job at any sort of gaming studio that works on Halo in an official capacity, so admittedly, you only have my word (and no proof) to go by at this time regarding that. I always recommend archiving things you care about.
  15. Same. The first party client is shit.