Btcc22

Remove Haloader.dll and it'll be solved.

Updated and simplified architecture diagram:
 
I make these diagrams just to help myself understand my own program better, but I hope they make sense to other people, too. This diagram is much simpler than ones I've posted before. For example, I'm omitting the OS X stack from the diagram because cross-platform support is way off in the future. I still hope to provide it eventually, though.
 

 
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 to develop cool new features as well as...
 
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. Again, the design of this feature is hazy at the moment.
 
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).

Can you list the files in your Halo/controls folder?

Something about seeing a fan in classy packaging made me laugh. It's a fan.
 

 
P.S. Still wouldn't have their heatsinks ruining my PC's interior styling.

Just saying. There's no way I'd want a hideously ugly hunk of metal like a Noctua in my case when a decent CLC will give almost identical (if not slightly better) performance and look a whole lot better.

Fixed.

Ah. HAC has the bulk of maps available on HaloMaps. For those that are missing, the map name is logged so I can manually intervene by tracking it down and adding it to the system. Players are welcome to send maps to me to get them added too.
 
While it's a somewhat reactive system, I'd say that having to ask Nil to approve your maps is moreso. Apart from AI mods because I don't class them as true multiplayer maps, I'm impartial with HAC, as the several dozen BG log maps will attest to.
 
All that aside, the plan since the beginning has been to allow modders to upload their own maps into the system and eventually make the system open source. You know how it goes though; time/motivation/feature idea triage.

Unanswered: Arbiter's Misfortune.

Tribes: Ascend.

Unanswered: Arbiter's Misfortune.

The Stanley Parable.

UT2004, Hyperblast.

...I see no problem in your screenshot.

...I see no problem in your screenshot.

...I see no problem in your screenshot.

Just saying. There's no way I'd want a hideously ugly hunk of metal like a Noctua in my case when a decent CLC will give almost identical (if not slightly better) performance and look a whole lot better.

Liquid cooling is fun to play with (if you're not scared) and if done right, looks good. Air coolers, especially performance ones, just look horrible.
 
At the end of the day though, unless you're overclocking, it's pretty pointless to worry about coolers.

Liquid cooling is fun to play with (if you're not scared) and if done right, looks good. Air coolers, especially performance ones, just look horrible.
 
At the end of the day though, unless you're overclocking, it's pretty pointless to worry about coolers.

I promised WaeV I'd do a write-up on how I increased the BSP polygon limit back in June but it slipped my mind until this week, so here it is. Better late than never.
 
As a word of warning, I've tried to avoid being too technical and I've omitted some details for the sake of brevity. It'll likely be boring enough without mentioning my mistakes and being led down the wrong path by red herrings.
 
Introduction:
My goal with HAC 2 wasn't to improve the engine's graphical capabilities but rather to build an anticheat and provide a few features to enhance the multiplayer experience to sweeten the package. However, during the work on the field of view and draw distance enhancements, I found that some maps' BSPs would no longer render correctly, causing gaping holes in the terrain to appear.


Before increasing the draw distance.


After increasing the draw distance. Oh.
 
Some detailed/poorly optimised maps have always suffered from BSP gaps but bumping up FoVs and draw distances just made the problem much worse, given that they allow the player to view more of the map.
 
The Fix:
Before you can fix something like this, you need to figure out the exact cause of the problem and hopefully a quick way to locate the relevant code for reverse engineering. It seemed quite likely in this case that Halo was processing the BSP, hitting some hard-coded polygon limit and then skipping any polys that would exceed this limit.
 
Following my hunch, I decided to see if I could find the hard-coded limit with the help of CheatEngine, a nifty memory scanning tool and debugger. CheatEngine allows you to start by searching for an unknown value and then slow filter out the noise by setting conditions that you expect the remaining values to meet.
 
In this case, assuming my hunch was correct, I expected to find a counter that would decrease and increase in relation to how much of the BSP I could see at any one point and would hit some cap once gaps started to appear. I found three such values - one which appeared to be counting upwards during the processing between each frame and another two that were simply copies of the final value.
 

Bingo!
 
The next step was to suss out how this value was being used by the game engine. Thankfully, finding all of the relevant sections of code is just a case of placing a hardware breakpoint on the value in your debugger of choice.
 
The poly counter is accessed in quite a few locations but for the time being I was only really interested in the code responsible for doing the writing as that's where I expected to find the logic that would need to be updated to increase the limit.
 
The counter is only written to by two pieces of code. The first section simply sets it to 0 at the beginning of each frame and the second, shown below, is a simple check to see if its current value is below 16,384. If so, it increments the counter by one otherwise it'll exit the loop and continue.
 

The code of interest, as shown in OllyDbg. 4,000 (see the line marked 00557453) in decimal is 16,384.
 
Great! Now all I needed to do was change that limit to a higher value.
 

Maybe not.
 
As expected, increasing the limit just caused a crash. Halo allocates a fixed-size array for the BSP and so attempting to write extra data to it beyond the intended limits just causes an access violation (buffer overflow). In order to increase limit, a larger array has to be created and all code that uses that buffer has to be redirected to it. As a side-note, pretty much every buffer is fixed-size and allocated when the game starts up, likely to help ensure the game's memory usage couldn't exceed the Xbox's measly 64MB RAM.
 
Creating the new array just required figuring out how many bytes the game required for each entry, which was easily done by taking a quick look at the code that caused the buffer overflow in order to get the start and end address for the array and then dividing the size in bytes by the known number of entries, 16,384. The answer is that each entry takes four bytes. If you're wondering what each entry represents, I'm afraid I can't remember by this point.
 
With the new buffer allocated and all of the code patches in place to update anywhere that accesses the buffer, it was safe to increase the limit from 16,384 to 32,767. Why 32,767 rather than a higher value? The game uses a signed short (16 bits, minus one bit which is used to denote whether it's a negative value) to store the counter so anything higher would lead to an overflow and simply cause the BSP to completely vanish. Switching the signed short to an unsigned short would need a whole load of extra code patches to change the jumps and comparisons to their unsigned counterparts. Instead, for some future release, I've opted to switch to a signed int which should in require fewer patches while allowing for the BSP poly limit to be increased to a stupidly huge 2,147,483,647, ignoring all other constraints that'd prevent maps from actually making use of it.
 

Success!
 

 
The final touch was to add a poly counter that can be enabled with the budget_show 1 command, in hopes that it'd help map makers design and optimise their maps to avoid further BSP issues.
 

 
Addendum:
Just for fun, you can get some 'interesting' effects by preventing certain parts of the rendering code from accessing the BSP buffer.
 

No BSP at all. For those with low-end machines.

No textures, shaders, or anything much really.

Bump maps, possibly.

Fog (atmosphere) effect.

Textures sans specular and other effects.

Playing with the geometry.

Proprietary languages.
 

Proprietary languages.
 

Proprietary languages.
 

Proprietary languages.