It looks like I won’t have all the stock node graphs done for release. The maps Blood Gulch, Damnation, and Rat Race have finished graphs. I did some of Hang ‘Em High and Wizard. Freelancer said he did some of Death Island too, so I’d like to include that as well. Freelancer is also going to be making a video showcasing the program’s capabilities. All the documentation is finished now so I’m going to write some more AI scripts while I wait for the video to be done, then it’s time for release!

In addition to the node graphs, AI scripts, tutorials, and example chat file, Halo CE version 1.08 will be included with Version Changer. GuiltySpark is made for 1.08 only, though 1.09 support is something I’ll be adding after release.

No more waiting

Today I’ve been adding a bunch of finishing touches, squashing bugs, and writing documentation and tutorials. Almost everything I wanted to have done by release is done. I couldn’t figure out the vehicle velocity improvement I mentioned earlier so I’m leaving that for later. Player structures don’t seem to store a pointer or object index to what vehicle they’re in.

When I say no more waiting, I’m also referring to busy waiting. I think I finally solved a problem that has been around for quite some time–the program would randomly start hogging the CPU and slowing down itself and the game, even though everything was running smoothly beforehand. I figured it had to do with my aimbot thread. The aimbot needs to keep following a target independently of the AI system. It aims, waits 10 ms, then continues. However, when you want to pause the aimbot then the execution of the thread needs to go somewhere. To avoid creating a new thread every time the AI was started again, I simply looped while a “paused” flag was true. I noticed this took up a lot of my CPU usage, so I added a sleep(150) to the loop which took the CPU usage down but didn’t get rid of the problem completely.

I learned this kind of waiting is called busy waiting and should be avoided because it doesn’t play nice with multithreaded applications. I felt it was kind of hacky from the start anyway. I now use a timer and catch its tick events to trigger the aiming code. I’m not sure how the timer works internally, but I haven’t had the problem since.

Oh, and the bot can type chat messages now. It’ll actually type out entire multi-line files for you in case you want to tell a hundred “Confucius say” jokes to the other players in the server (I may or may not have done this). You can also script it out fairly well by using the $ character, which causes GuiltySpark to wait a second before continuing the message. What’s great is that the chat FID expects numbers for file names and there’s a random number data source. This means you can have the bot select a random message by fiddling with the postfix expression.

Anyway, release soon.

DirectX adopted

GS used to take its sweet time with the CPU when you had the graph view open. This was because it wasn’t taking advantage of the GPU to draw things. Converting the  drawing code over to DirectX turned out to be way easier than I anticipated, and resulting in halving CPU usage when the graph view’s open. I had to learn a bit about the way DirectX expects primitives, then I implemented some wrapping functions to emulate the old ones I had been using in System.Drawing.Graphics. I did have some problems though.

Firstly, the panel control that DirectX was drawing to was flickering. The panel has a bunch of event handlers for clicking and dragging which lets the user zoom, pan, and rotate the graph view. After a long time searching online, I found one person who suggested that a redraw is forced by the panel before the event is raised, which would leave a slight time gap before it is redrawn again. Surely enough, using two panels (using a separate one to draw to) resolved the issue. I just made the clickable one invisible and placed them in the same location.

A second issue was that DirectX only comes in 32 bit. That means GS now has to be 32 bit as well. While it was easy enough to change the build option, it introduced a bug that I didn’t find until the end of the day. Because I was only testing the graph view, the fact that the bot could no longer walk slipped by me. What does walking have to do with drawing the graph? It stumped me at first, then I remembered that I had changed to 32 bit earlier. Little did I know that user32.dll’s SendInput() requires a slightly different argument on 32 bit vs 64 bit. It asks for an array of INPUT structures, but the “type” field at the start of the structure is either 4 or 8 bytes long. When it still didn’t work, I grew pretty frustrated until I finally noticed that my third argument in the call to SendInput was still 40. The third argument is supposed to be the size of the INPUT structure. I made the argument Marshal.SizeOf(typeof(INPUT)), which I should have done at the beginning to save me all this trouble. Lesson learned!

What’s left?

If you’re a member of the Halo community, you’re probably wondering when you can get your hands on GuiltySpark. What’s left? GS still can’t lead targets in vehicles properly because it doesn’t know they’re in a vehicle. This is something I can fix and also expose to the AI system. I’m considering giving the program the ability to type chat messages to the other players even though I know people will horribly abuse this. I’m not responsible for you getting banned from any servers! Perhaps I should add a disclaimer to the documentation. Speaking of the documentation, I have to finish that before release too.

There’s a few things I’ll add after release like 1.09 support, enhanced target visibility detection, and  a full automation mode for server operators (the program will select the right node graph and AI file to use). Source code will become available after release.

On cheating

In the Modacity.net thread, I said I would attempt to stop people from using GuiltySpark to cheat. Because the AI system both accepts keyboard input from the user and controls aiming, it’s incredibly simple to create an aimbot. I suggested not allowing key press detection and aimbot control in the same AI script, but I realize this won’t stop anything…

  • Aimbots already exist, and they don’t have introduced error either
  • People could just use their flashlight, jumping, crouching, or even a shake of the mouse to trigger the aimbot
  • Blocking input might accidentally get in the way of a useful AI script
  • GuiltySpark will be open source anyway; restrictions can be removed

That’s one thing off my to-do list.

Target visibility

As you may know, when you aim at an enemy ingame, their name fades in near the top of the screen. This name won’t show up when obstacles block the target from sight and it has a little bit of leeway in that you don’t have to be aiming exactly at them. This made it ideal for determining target visibility. Unfortunately, it has some drawbacks.  Firstly, the name won’t show up when the target is too far away, even if they’re in range. Secondly, the leeway I mentioned earlier is limited. In laggy servers or when using slow moving projectiles like rockets, the aimbot needs to aim far ahead of the target to get a hit. That means the name won’t show up anymore. A third drawback is that opening the ingame framerate monitor (ctrl+F12) interferes.

I see 3 alternate solutions:

  1. Use whatever function the game uses to determine target visibility
  2. Compare target distance with the depth buffer at their location
  3. Extract the level geometry and perform ray casting

I’m not a fan of option 2 because it requires a Direct X wrapper and the depth buffer is only so precise. Furthermore, I want something that will work even if the target isn’t within the view frustum. I see option 1 as a plan B because option 3 gives me the most options and opportunities. Option 3 would allow me to automatically generate node graphs or display the map within GuiltySpark. Mind you, those improvements are a long way off and I might not get to them. The priority is target visibility.

Sky told me the map cache data is at 0x40440000, so I fired up Cheat Engine and checked it out:

A list of tags starts 0x10 from the start. It wasn’t too hard to figure out the tag reference structure. What I need to do is scan through the list to find the sbsp tag, then follow its data pointer to get the actual BSP data. The next step is to figure out what I need from the BSP to do target visibility calculations. The picture shows that what’s in memory is basically the same as what’s in the .map file. If what’s in the .map file is similar to the structure of the various tag files, then examining the .scenario_structure_bsp tags with Guerilla (part of Halo CE’s editing kit) will make it easier to understand the sbsp tag in memory.

While we’re at it, here’s a list of changes made to GuiltySpark since 1.0.20

  • Added random number data source ($48)
  • The last 10 commands are now stored and can be listed with the “history” command. The command itself is not stored
  • Added “!!” command to re-execute the last command and “!<#>” to re-execute the <#>th last command. Not stored in history
  • Pressing the up arrow key in the command input box cycles through previous commands
  • Renamed “clear” command to “deleteall” in case people confuse “clear” for “cls”
  • Added a “where <#>” command to focus the graph view on the given node
  • Node numbers are no longer drawn over by links and are 1 pt larger for easier reading