[WIP] GuiltySpark

[Con]

What is GuiltySpark?
GuiltySpark is a user-programmable automation engine for Halo CE. Users can create scripts that control the player's ingame reactions and behaviours. Scripts can range from simple key macros to bots that play the game without any user interaction. When activated, GuiltySpark controls the game for you by simulating mouse movement and keyboard input. Advanced scripts can take advantage of user-created pathfinding graphs.

http://img263.imageshack.us/img263/1047/gs1p.jpg

Videos

SpogBHQXg5k
rHVixLzxVMI
thC8REcOWjI
C9Ul82x1oEQ
XkObevIwVP4

Left to do:


Overhaul link implementation (http://www.modacity.net/forums/showthread.php?t=21417&p=535165&viewfull=1#post535165)
Saving and opening networks (http://www.modacity.net/forums/showthread.php?t=21417&p=535661&viewfull=1#post535661)
Pathfinding (A*) (http://www.modacity.net/forums/showthread.php?t=21417&p=536078&viewfull=1#post536078)
Allow the program to move the biped (http://www.modacity.net/forums/showthread.php?t=21417&p=536751&viewfull=1#post536751)
Allow the program to drive vehicles (http://www.modacity.net/forums/showthread.php?t=21417&p=538195&viewfull=1#post538195)
Upgrade pathfinding (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=558743&viewfull=1#post558743) and following (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=558743&viewfull=1#post558743)
AI file definition & loading (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=560366&viewfull=1#post560366)
Create an AI to control the player (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=561300&viewfull=1#post561300)
Integrated aimbot (program-use only, with error) (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=567250&viewfull=1#post567250)
Create more functions and data sources for the AI to use (http://csauve.wordpress.com/2011/01/31/a-jack-of-all-trades/)
Create some node graphs and AI files, fix bugs, add final touches (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=598850&viewfull=1#post598850)
pre-release testing (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-(formerly-HaloBot)&p=599002&viewfull=1#post599002)

It's done, download here:
http://www.modacity.net/forums/showthread.php?24206-GuiltySpark-for-1.08-automate-your-player

[p0lar_bear]

Very interesting... I like where this is headed...

Then again maybe not, I always hated joining what I thought was a populated server in a Source game just to find that it's all bots. :(

[Alwin Roth]

So, this program can make it so the bots actually can grab the flag in a CTF match?

Or did I read this wrong?

[TEMPTii]

So does this control the player, or can you create a biped to take over with it? And this is pretty awesome for things like machinima and stuff :v:

[Con]

So, this program can make it so the bots actually can grab the flag in a CTF match?

Or did I read this wrong?
Eventually, yes.


So does this control the player, or can you create a biped to take over with it? And this is pretty awesome for things like machinima and stuff :v:
This controls the player (doesn't yet, but will eventually). I didn't even think about machinima though; you could set the player off down a path then following it with the devcam. The only problem is the WADS keys would be pressed by the program while you're trying to move the devcam. Maybe there's a way to force the player to walk without simulating key presses. Korn?

[Limited]

Eventually, yes.


This controls the player (doesn't yet, but will eventually). I didn't even think about machinima though; you could set the player off down a path then following it with the devcam. The only problem is the WADS keys would be pressed by the program while you're trying to move the devcam. Maybe there's a way to force the player to walk without simulating key presses. Korn?
You could inject via the memory new player coordinates.

[t3h m00kz]

Best way to AFK

[TEMPTii]

This controls the player (doesn't yet, but will eventually). I didn't even think about machinima though; you could set the player off down a path then following it with the devcam. The only problem is the WADS keys would be pressed by the program while you're trying to move the devcam. Maybe there's a way to force the player to walk without simulating key presses. Korn?

It would work in conjunction with solstice cam

[Con]

You could inject via the memory new player coordinates.
The player wouldn't be walking though; they'd just be teleporting short distances. It's also not multiplayer friendly.


It would work in conjunction with solstice cam
ah, good idea.

[Limited]

YOu might be able to hook the player move method, therefore animation plays and it simulates the keypress without having to manually set it.

[Con]

I haven't a clue how to do that, could you give me a hand when the time comes?

[Donut]

lol linkpen = new pen(Color.teal, 1)
i see what you did there

[Con]

:-3

[Limited]

Drawing the lines?

[Con]

They like the teal.

[Inferno]

I don't like the teal.

Also. When I saw this thread title I thought "I bet someone is requesting a download link for a aimbot".

[TEMPTii]

Also. When I saw this thread title I thought "I bet someone is requesting a download link for a aimbot".

Trolling opportunity

[Dwood]

Hey Con, grab UserTool, and add me on xfire, I have an idear.

[malolo420]

Will it be usable in SP maps? This could be really useful for OD, since I have a lot of geometry that doesn't create path finding data for my ai.

[TEMPTii]

He said it uses the WASD keys so I'm pretty sure it would work

[Con]

This is simply meant to control your player, not the AI in campaign. You'll have to solve your AI problems on your own since this is totally different.

[malolo420]

Ohh Ok.

[Con]

finished revamping links

http://img691.imageshack.us/img691/2577/capturenr.png

this should be much clearer with big arrows

[Inferno]

Can you lay down path nodes or anything?

[chrisk123999]

This controls the player correct? In theory, would it be possible to make fake players then control them?
Don't tell me no one else was thinking this.

[Dwood]

I suggested to him the using of importing cutscene flags from lone scenario files, as pathnodes.

[TEMPTii]

This controls the player correct? In theory, would it be possible to make fake players then control them?
Don't tell me no one else was thinking this.
We already established that it controls the WASD key, thus the only way to control a biped is to bump posses it.

[chrisk123999]

Yes, but I would think you could fake the movement keys via memory hacking.

[Con]

I don't know why you would want to move other bipeds around.. it's not like they would sync at all. If it's SP then whats the point? All the path-finding is laid out for them already in SP.

[chrisk123999]

Assuming you could make fake clients, it might sync.

[Con]

The save button now serializes your graph into a file, which can be opened again later:
(opened bg.wmap after clearing the old one, and continued editing with move 5)
http://img27.imageshack.us/img27/9781/captureqg.png

edit: I also added a little line to the "you" circle to show which direction you're facing

[Con]

Pathfinding is almost done. Here you can see it find and highlight the nodes you need to visit to reach the goal.

http://img59.imageshack.us/img59/5189/capturetk.png

It doesn't actually move the player yet, and it fails on any subsequent attempts because I forgot to reset node cost values at the end of the algorithm. Right now it's set up so that when the program can eventually follow a path, you can still type in goto # and it will start following the new path immediately. This will allow the final version of the program to make decisions on its own and change its destination when it does. I also have to correct the cost calculation for teleporter links, so the program will know their distance is 0 and will prefer them over walking to the destination.

[Kornman00]

That or retain information about nearby vehicles which it can hop into and drive :P

[Con]

So I'm simulating key presses using keybd_event, but it won't move the player around. Only when I open up the ingame console does it type WWWWWWWWWWWW.

Anyone know what's up?

edit: I've tried the SendKeys class (says Halo isn't processing messages) and user32.dll's PostMessage function, but that always returns 0 meaning it didn't work. I've only had *success* with the keybd_event function.

[TEMPTii]

So I'm simulating key presses using keybd_event, but it won't move the player around. Only when I open up the ingame console does it type WWWWWWWWWWWW.

Anyone know what's up?

edit: I've tried the SendKeys class (says Halo isn't processing messages) and user32.dll's PostMessage function, but that always returns 0 meaning it didn't work. I've only had *success* with the keybd_event function.
I too want to know the problem with that. I used to have that problem while making one of those things that makes you jump up and down :X

[Con]

Used to? Does that mean you found an alternative or gave up?

[TEMPTii]

Gave up. :S

[Con]

Good news, I found the solution. Limited suggested I use SendInput (http://msdn.microsoft.com/en-us/library/ms646310%28VS.85%29.aspx) instead.
you'll need these



#region constants
const int INPUT_MOUSE = 0;
const int INPUT_KEYBOARD = 1;
const int INPUT_HARDWARE = 2;
const uint KEYEVENTF_EXTENDEDKEY = 0x0001;
const uint KEYEVENTF_KEYUP = 0x0002;
const uint KEYEVENTF_UNICODE = 0x0004;
const uint KEYEVENTF_SCANCODE = 0x0008;
const uint XBUTTON1 = 0x0001;
const uint XBUTTON2 = 0x0002;
const uint MOUSEEVENTF_MOVE = 0x0001;
const uint MOUSEEVENTF_LEFTDOWN = 0x0002;
const uint MOUSEEVENTF_LEFTUP = 0x0004;
const uint MOUSEEVENTF_RIGHTDOWN = 0x0008;
const uint MOUSEEVENTF_RIGHTUP = 0x0010;
const uint MOUSEEVENTF_MIDDLEDOWN = 0x0020;
const uint MOUSEEVENTF_MIDDLEUP = 0x0040;
const uint MOUSEEVENTF_XDOWN = 0x0080;
const uint MOUSEEVENTF_XUP = 0x0100;
const uint MOUSEEVENTF_WHEEL = 0x0800;
const uint MOUSEEVENTF_VIRTUALDESK = 0x4000;
const uint MOUSEEVENTF_ABSOLUTE = 0x8000;
#endregion

#region structures
struct MOUSEINPUT
{
public int dx;
public int dy;
public uint mouseData;
public uint dwFlags;
public uint time;
public IntPtr dwExtraInfo;
}

struct KEYBDINPUT
{
public ushort wVk;
public ushort wScan;
public uint dwFlags;
public uint time;
public IntPtr dwExtraInfo;
}

struct HARDWAREINPUT
{
public int uMsg;
public short wParamL;
public short wParamH;
}

[StructLayout(LayoutKind.Explicit)]
struct MOUSEKEYBDHARDWAREINPUT
{
[FieldOffset(0)]
public MOUSEINPUT mi;

[FieldOffset(0)]
public KEYBDINPUT ki;

[FieldOffset(0)]
public HARDWAREINPUT hi;
}

struct INPUT
{
public int type;
public MOUSEKEYBDHARDWAREINPUT mkhi;
}
#endregion

[DllImport("user32.dll", SetLastError = true)]
static extern uint SendInput(uint nInputs, ref INPUT pInputs, int cbSize);




INPUT structInput = new INPUT();
structInput.mkhi.ki.wScan = (ushort)0x11;
structInput.mkhi.ki.time = 0;
structInput.mkhi.ki.dwFlags = KEYEVENTF_SCANCODE;
structInput.mkhi.ki.wVk = 0;
structInput.type = INPUT_KEYBOARD;
SendInput(1, ref structInput, Marshal.SizeOf(new INPUT()));
Here's a list of key codes (http://community.bistudio.com/wiki/DIK_KeyCodes).


EDIT: success!
HaloBot has just walked from one side of bloodgulch to the other following the paths perfectly. You can even look around while it does this; it calculates the right combination of WASD to use based on the angle you're looking and where the goal is.

[Cortexian]

This will be awesome when it's finished... When I want to go idle or AFK for awhile I can just enable this plus an aimbot and auto-shoot bot!

[Pooky]

This will be awesome when it's finished... When I want to go idle or AFK for awhile I can just enable this plus an aimbot and auto-shoot bot!

Wouldn't you also need some way to get it to lock onto people in the first place? :S

Also, Conscars, what happens if you try to type while it's moving? Do you end up with a chatbox full of "wwwwwwwwwwwwwwwwwwwwwwwwwwsssssssssddddddddaaaaaaa aa"?

[Cortexian]

Wouldn't you also need some way to get it to lock onto people in the first place? :S

Also, Conscars, what happens if you try to type while it's moving? Do you end up with a chatbox full of "wwwwwwwwwwwwwwwwwwwwwwwwwwsssssssssddddddddaaaaaaa aa"?
Yea, aimbot.

[Kornman00]

If this was done in something like open-sauce, I don't imagine it would be too hard to hook the input_update function of the game. Before the update function is ran you could preprocess with a routine which gathers whatever data from the bot input, applies it to the input state that the game tracks, then diverts the game back to its input_update function. After that it could also then postprocess with another routine when then removes the input state changes it applied so that it doesn't affect other systems. However, I think the postprocess part may not even be needed as the input states aren't used by by the keystone system (the ingame ui which halo uses) and the game console uses the actual win32 api console functions.

[Con]

Also, Conscars, what happens if you try to type while it's moving? Do you end up with a chatbox full of "wwwwwwwwwwwwwwwwwwwwwwwwwwsssssssssddddddddaaaaaaa aa"?
yeah unfortunately. I'm gonna have to add some sort of pause feature.

I've encountered a bug where occasionally the bot will hold down just one key instead of correctly walking to the next waypoint. Jiggling the mouse seems to fix it, but I'm gonna look for a better solution. I also need to make it so the player jumps and crouches on special links. Moreover, ladders aren't supported right now.

[Kornman00]

For that it sounds like you'll need to make a 3d viewer. You could have it so that a person can use an .obj export of a map, then use that in the 3d view. Or even load the bsp tag (I could help in that area in the future). With the latter (bsp tag), you already have collision information pre-built so you could do some automatic linking I think. It also stores information when it comes to things like surfaces which act as a ladder, which could assist in making weighted paths.

[Con]

It might be better to use a navigation mesh instead of nodes in that case, right? It would be pretty easy to set the walkable surfaces as polygons in the nav mesh I think.

[Kornman00]

Of course, it would be better to use your own information that is built (baked) from Halo's preexisting database of information. However, if you just wanted a purely dynamic form of interfacing (that required no data baking) then you'd just use the bsp data as input.

[Dwood]

I suggested to him the use of Cutscene flags as points, and importing them from the scenario tag.

[Inferno]

So when this is done we will have servers with multiple instances of the game running with lots of bots. Sounds lul.

[Con]

I just found a magic address that's true when you can move and false when you're typing in chat, in console, or in any menu. I just made it only press buttons when this value is true and the active window title is "Halo".

GIT 'ER DONE

edit: Added some view features. It's pretty obvious what they do, but whats not quickly apparent is how much they help when you're building the graph and things are cluttered. I found it hard to link nodes in places like the base where you have lower and upper level nodes and nodes right next to each other. I increased the zoom limit to 20 to really look closely, and I made the link arrows half as wide which greatly improves the appearance. Also, the highlighted path circles now fade to purple towards the goal as an indication of order.

http://img689.imageshack.us/img689/3438/capturegtm.png

I found the program has trouble walking around in tight spaces. This can be improved by decreasing the radius in which it considers you at a node, which I may give the user the option to do since vehicles require a slightly larger radius, and by better placement of nodes. Keep the nodes towards the outside corners of hallway bends so the player doesn't get hung up on the inside edge.

The suggestions in this thread have got me thinking, and I have some ideas for improving this, but I think I'm going to continue with the current systems until completion and then possibly make a version 2 once I've gained some more experience. The limitations I have right now, such as ladders, are easily fixed. The only problem with ladders is that the goal reached radius is used on a 2D basis only. If the user just places a node a foot away from bottom of the ladder and one at the top, then the program will just continue to walk forwards to reach the upper goal (just need to lock view in an upwards and forward direction, which I have to implement for jumping and warthogs anyway). Heading back down the ladder would require something else, but I'm sure it can be done.

[Cortexian]

So when this is done we will have servers with multiple instances of the game running with lots of bots. Sounds lul.
Except you'd also need multiple copies of the game, since one CD key can't run multiple players in the same server that's checking with the authentication servers for legitimate keys. However you could use a server that doesn't check CD keys to have bots probably...

Con, your next project is to work on a Halo client that runs with minimal system resources in order to act as a "bot" that can be used online. Should be pretty easy right? :v:

[Kornman00]

Would be easier to rework a dedicated server to function as a automated client

[Dwood]

Would be easier to rework a dedicated server to function as a automated client

Do it.

[Con]

Hey halo hacker people, what's the best way to force the players view in a certain direction (like an aimbot)?
I'd like my app to control vehicles as well, but for everything besides the ghost you need to aim where you want to go.

[Pooky]

Yea, aimbot.

For the bot to use an aimbot it would need to know to press SHIFT, since shift is not normally used in Halo you'd have to deliberately set up the bot to use it somehow. Also it would be completely helpless against anyone in a vehicle, since we all know how aimbots react to those <_<

[Cortexian]

I had an aimbot that worked on vehicles at one point, at least I'm fairly sure I did... It's been awhile though.

Not that I bot :)

[Con]

Update:

The graph view has been reworked to use less resources and be more flexible with the new orthogonal 3D viewing. You can now view the graph from any angle to help you build it in those tricky vertical maps like Boarding Action. I'm replacing the scroll bars with a not yet implemented click and drag panning. The app also crouches along crouch links and repeatedly jumps while following jump links. Moreover, it jumps when its velocity drops below a threshold while following a path, meaning there's an obstacle there like a vehicle. You can pretty much clear any vehicle by mashing jump and moving towards it.

edit:
:haw:

http://img243.imageshack.us/img243/9305/appani1.gif
(I know, still gotta fix the "you" direction line)

BTW, I still need help with http://www.modacity.net/forums/showthread.php?t=21417&p=537923&viewfull=1#post537923
Is a code cave the only way to do it? They're pretty complicated so it'll take some time to learn it first.

[Pooky]

Moreover, it jumps when its velocity drops below a threshold while following a path, meaning there's an obstacle there like a vehicle. You can pretty much clear any vehicle by mashing jump and moving towards it.

Wouldn't that be really easily exploitable by human players in the server? I could see people duping the bot by parking a vehicle right near a powerful weapon on a ledge (like the snipers in gephy) and laughing as it jumps to its death over and over again.

[Con]

There aren't many cases where it would result in death. The bot would know there's no path from the ledge into the pit, and so it wouldn't overwalk it in most cases. However, it could jump and overshoot when people park vehicles right on top of nodes. The vehicle will prevent the bot from reaching the node's radius and so the bot will be trying to climb the vehicle and get to the node until it respawns or moves. You can't assume that it's safe to increase the radius in which it considers itself at a node in such cases. For example, if the bot needed to traverse some thin structures over a pit then it needs to follow paths very closely. There are some solutions, but it's best saved for version 2 when this is done. Don't expect the bot to play perfectly. It's not gonna stand up in a server full of regular players, but it will be fun to watch. If it can win against my non-gaming friends, then I'll be happy. I think it would be cool to just set it up on my laptop driving a hog around while I gun in the back (can't expect better from drivers in halo anyway ;p).

[Pooky]

Wasn't expecting it to be perfect obviously, just wondering. Besides, even if that did happen, it would be hilarious to watch the bots die like lemmings.

[TEMPTii]

I think it would be cool to just set it up on my laptop driving a hog around while I gun in the back (can't expect better from drivers in halo anyway ;p).
amen

[Choking Victim]

Hey halo hacker people, what's the best way to force the players view in a certain direction (like an aimbot)?
I'd like my app to control vehicles as well, but for everything besides the ghost you need to aim where you want to go.
There's an aiming vector value you can use to change the players looking position, if that's any use to you. If you're interested I can find it's address again.

[Con]

Yeah, that would be super helpful. The one I'm reading right now seems to be the camera direction because this whole thing stops working when you go into dev cam (seems I'm also relying on camera position for player position). This is for 1.08 btw.

Is there anything more to it than just writing to those vector addresses?


edit: In the meantime, I set the bot up to pres < and > which I bound ingame to looking left and right. HaloBot is a bad driver but eh gets the job done :|

[Choking Victim]

Yeah, that would be super helpful. The one I'm reading right now seems to be the camera direction because this whole thing stops working when you go into dev cam (seems I'm also relying on camera position for player position). This is for 1.08 btw.

Is there anything more to it than just writing to those vector addresses?
Alright, the looking vector is located at offset 0x1C in the player_control_globals structure, it consists of two floats since it's a 2d vector. A pointer to the player_control_globals structure is located at address 0x64C2C4 in the haloce.exe.

There's nothing more to it, just write to those floating point values and the players looking vector will change. If you need anymore assistance let me know, I'll be glad to help.

[Con]

Sweet, thanks. I'll have an update later tonight for you guys.

edit: Thanks to Choking Victim, it can now drive the path without giving the viewer a seizure. Users will still need to make a new graph that's specialized for vehicles (avoid places you could tip over, put more space between nodes, make smoother curves).

[TEMPTii]

You should make a video of the bot ingame (:

[EX12693]

And release it publicly. (:

[Con]

Yeah, I've been considering recording it in action.

It will be released publicly when it's completed.

[TEMPTii]

Yeah, I've been considering recording it in action.

It will be released publicly when it's completed.
And it will be completed when?

[Kalub]

Never if you keep pestering the man... mind your manners.

[Con]

It's not something I can pin a date on. The list in the OP isn't fixed, nor does it go into any detail of my plans. I'm just doing what I feel like doing.

[Cortexian]

Not sure if this is feasible or not, but would it be possible to add "alternate" routes that the bot can randomly choose to take? Would make it more life-like than having a bot that just runs around a set path all the time.

[Con]

What it does right now is the pathfinding algorithm is given a destination and it returns the shortest path there. It's creating a list of points you need to visit in order to reach that goal. That list is then used by the walking thread to direct you along it. To create alternate routes, perhaps it could pick random points near the goal, then from there go to the goal?

I need a way to simulate a human player and a lot of variables go into that. I'm not sure what the best way to tackle the AI is.

[Cortexian]

Or it could get approximately half way to the goal, pick a new and completely random location, navigate to that, and then navigate to the goal. That should add lots of variety. Then add random goal choosing and a loop option (just a tickbox or something) so the bot is constantly going from goal to random sub-goal to goal, choosing a new goal, etc...

Edit: Actually, if you add the random goal choosing after it hits a goal and the "loop" option is checked, you wouldn't need the sub-goal stuff since it would be going from random goal to random goal.

[Con]

I was thinking about that, but then I realized I can randomize the paths right inside the pathfinding algorithm. At each step of the algorithm, it find the most promising adjacent node and moves on to that one. This is determined by it's distance from the start along the path and its distance from the finish in a straight line. However, what I can do is add a random number to this cost, meaning it won't always choose the shortest path. This may end up in a jagged path though, not necessarily an alternate route. A solution might be to add a persistent cost to all nodes in the areas visited recently so that it won't reuse them.

Additionally, if I add additional information to the graph like openness, then I can add the openness score to the cost at each step meaning it will prefer areas with cover. Users will still have to define which areas are open/dangerous.

[TEMPTii]

Con, what method did you use to send the keystrokes to halo? Given the sendkeys function didn't work, what did you use, keyhook? I'm making an application that spams a certain key or keys and I want to integrate it into Halo but I cant find/make a good keyhook...

[Con]

I'm using SendInput.
I made a post for you a few pages back but I guess you missed it.
http://www.modacity.net/forums/showthread.php?t=21417&p=536751&viewfull=1#post536751

You should also check the byte at 0x00622058 (1.08) as well as the current window title. If that byte is 1, then there are no menus, console, or chat boxes open. If the current window title is Halo then we're not minimized and finally input can be sent.



As for the AI, I think I'm going to make the bot use a list of tasks, each with a priority. Their priority will be updated as it plays and it will only work on the highest priority task at any time. Tasks may be things like reaching the objective, killing enemies, and getting items. As you get closer to an enemy along the path to the objective, then the kill enemy task priority will increase. Its priority could also increase as a function of health and current weapon. If its priority exceeds the reach objective task, then it will pathfind to the enemy hopefully kill it, ending the task. The next highest priority will then be reaching the objective again. The list of tasks should be remade and randomized for each life to mix things up.

[TEMPTii]

Oops, didn't see. Thanks for that (:

[Dwood]

Allow us to set "split points" where there are points where the people are able to deliberately have randomness in what it does- 1 point can split into 2+ different paths, and the bot picks the way in semi-random fashion.

[Con]

That's a good idea but it doesn't work for big maps like bloodgulch. Putting split points here and there will simply cause the pathfinding to potentially add an extra node to the path when it comes across one of these points. It wouldn't make the bot choose to walk through the caves instead of over the hills. Like I said earlier, the way to accomplish this would be adding additional information to each node that's only used during pathfinding. Each time it does pathfinding, it should mark the nodes around the path. On the next use of pathfinding, those nodes will be avoided causing the bot to choose an entirely different path. The distance of deviation depends on the scale of the cost added and the radius around the path it marks. I would simply need to add a parameter to the pathfinding that says whether or not I want a shortest distance, or a safe path and/or an alternate pat. The parameter would dictate how the costs are added up for each node, resulting in different path types.

This also easily integrates with the task priority tree for AI behaviour. Some tasks require different types of pathing; getting to the objective requires a safe and random path, while finding the path to the oddball carrier needs the fastest path since you want to minimize the time they're holding the ball.

Update (May 28)
This has grown in complexity so if I want to make things easier on myself for the future AI stuff, then I'll have to improve the modularity of my code. This will take some time since there's a lot of things I want to improve while I do this, so if you're reading this then don't expect any updates for a while.

Update (June 10)
The most apparent change is the renaming of HaloBot to GuiltySpark. GS now has an icon as well as some practical features, such as click and drag viewing of the graph (left button panning, right button angle), some some adjustment to the console commands, and revised management of threads and memory reading. Everything's falling into place for the AI.

[Con]

http://img811.imageshack.us/img811/906/1273887305225.gif

bump

I made a little video of the program in action. It shows you building and editing graphs, as well as using the pathfinding with some real server lulz. I know the quality is horrible, whatever.
I also saw texrat when I was recording. Who knew he was still around?

XkObevIwVP4

the updated UI so you can better see what I'm clicking, etc:
http://img823.imageshack.us/img823/1355/captureax.png

[Inferno]

That is awesome, you are awesome. Link a aim bot to it and see how well it does in a pubby.

[Con]

Not that easy! It's just going to waste all its ammo shooting walls and hills. I dunno what to do about that.

[Dwood]

looks like a screwed up chemical compound of some sort tbh.

[p0lar_bear]

Not that easy! It's just going to waste all its ammo shooting walls and hills. I dunno what to do about that.

I remember an autofire app made once that made the game shoot any time the reticle turned red.

[Con]

Problem is it won't be red if it's leading for ping. Moreover, it sometimes wont turn red unless you're zoomed in or much closer than typical range. There has to be some other way of doing it...

I could use the existing node graph and see if the line between player and enemy comes close to any nodes, meaning a blocked shot, but that would only work for walkable surfaces like hills blocking the view. For things like cliffs, it could interpret large areas of the graph without links as cliffs and would try to move the player for a clear line of sight. However, there are still cases where this won't work properly and it's kind of a bandaid.

Another option is copying the collision mesh from memory and performing checks on that instead. I'd need help with that.

Can anyone think of any other options? I want to avoid trying those for now :\

[IGMBiti]

I'm not sure if you'd be able to do this with you're application, but I believe there is some thing built in that you can use. In CTF, Oddball, and juggernaut-type games, if objectives are indicated on screen, the image drawn over your objective will change depending on whether or not you can see the person. For instance, when the enemy has your flag, you may not be able to see where that flag carrier is when that player cannot be seen, but when that player can be seen a red indicator may appear over their head.
This is what I mean. (http://www.xfire.com/video/2d7a15/) <- The enemy team's flag goes from a diamond to a flag when the player holding it could be seen.
Someone correct me if this is not the process used (and sorry for the low-resolution).
If I am correct, I will not judge the difficulty of working this out.

[DEElekgolo]

Name of song in vid please.

[Con]

my bad

Caribou - Odessa

[Inferno]

Why not check the distance between the player and every player in the server. And then check to see what weapons the player is carrying. And then pick a a weapon that is appropriate for the range the nearest enemy is at. Then check and see if the target enemy is rendering (IE he is not behind a wall).

[Con]

The weapons will be dealt with by the task system. The priority of picking up weapons or powerups will increase as you get closer to them. I'm thinking a random element added to that so it doesn't always choose the same weapons. The priority could also be based on what weapons you have already so it doesn't pick up two short range weapons. Their priority would be decreased to 0 when you have a shotgun for example.

Another thing I'm considering is adding a second window to the app that consists of the task tree and a task editor. The editor will let you create the task tree and define functions for the priority calculation based on any of the properties in my gameState object, which reads the game memory. This will let users tweak the bot or adapt it for unforeseen situations. Of course, you will be able to save and share these behaviours as well.

As for checking if the target enemy is rendering, that won't work because they'll usually be rendering anyway but covered up by closer rendered geometry. Use wireframe to see what I mean. I'm gonna look into Biti's idea a bit more. I'm wondering if it only works for the objective in objective games, and if so maybe I can force the objective to be located at the bot's current target? Or maybe I could use the function that the objective is using to see if it's visible, but I don't know how to do that. Skarma has offered to help me with stuff so I can see if he has any advice.

[Inferno]

You could check and see if the players bounding radius is in view. I think that is sensitive to walls...

[p0lar_bear]

You could check and see if the players bounding radius is in view. I think that is sensitive to walls...

Again, that would be visible to the bot regardless of whether they're actually in view or not.

[Donut]

i love this more every time i visit this thread con. my buddy and i are planning on each making our own lists and having our bots fight each other and betting on the winner.

[CrAsHOvErRide]

I remember an autofire app made once that made the game shoot any time the reticle turned red.

Ye I did and it sucked.

If you want to do a new type of Aimbot for Halo you would make the lead dependent on the ping. Once you get that correlation right (you don't need testing to get a reference value. you can calculate it) 99% of the time you will hit the target.

Nice work on this though.

[Con]

I think I should add taunting players to the possible tasks...

http://img806.imageshack.us/img806/662/76151065.jpg


Eh but seriously, what features would you guys like to see? Nothing too complicated, but stuff hat would make it easier to use the program. Someone suggested ingame hotkeys for graph creation and I think I'll add that. What else would you like?


update

I have an idea for letting the aimbot know if the target is visible or not before shooting. The red reticule is unreliable as Pat said, but there's something else that changes when you aim at an enemy (or teammate without names on):
http://img716.imageshack.us/img716/7959/0screenshot00.jpg
I just have to check if there's text up. The great thing is that you don't have to be aiming directly at them. It shows up while aiming in a close area around them, which should include the lead distance.

update 2
GS now handles the file association between the saved graphs and the program. Doubleclick your graphs and GS opens them up, ready to use.

update 3
I looked into the ladder problem again and I discovered that ladder climbing is really easy with a little trickery in the graph construction and a new type of link called a look-ahead link. As you know, you can tell it to look forwards while walking and use aiming to steer instead of a full combination of WASD with independent aiming. While being especially useful for vehicles, this also comes into play when traversing ladders. Since you need to aim up the ladder to ascend, I will have a look-ahead link between the top and bottom of the ladder that will override the aimbot and force your aim in the direction of the next node. Another problem I had with ladders was it would tard out when the top and bottom nodes were right above each other. By placing the top node slightly forward of the end of the ladder, the program will always try to walk into the ladder as it ascends because in a 2D sense the node is on the other side of the ladder. For those ladders in Boarding Action with access to 3 floors, you simply use dev cam to place a node slightly past the surface of the ladder but still within the node radius, then you link this one to one off to the side using a look-ahead and the bot will walk you onto the platform. Since going to different floors requires different nodes, you simply branch these options from the bottom node instead of worrying about linking them on the ladder itself.

[Inferno]

Make it so you can run multiple instances of this on 1 computer so you can run a dedi and 2 instances of halo with a bot and 1 instance of halo for you to play on. This would make it so that people could host custom maps with bots to get people to actually JOIN servers that run custom maps.

[teh lag]

Yeah, a way to have this set up to populate a server with bots would be really, really good. Even if you can only have 1 bot per computer it'd be a big help for a server that runs customs.

[Inferno]

Well, my main question is if you can make Halo run multiple instances on 1 computer. If that is possible you could just run a server with the dedicated server and then a few instances of halo with a bot attached to each.

[Con]

Multiple instances would be a bitch IMO. First of all, it doesn't really attach to the game for sending input. It simulates key pressed globally. Halo doesn't seem to accept messages, so tha'ts the only way I could do it. It might be possibly by crazy hook ninjary but that's way beyond my skill level. Secondly, running multiple instances of Halo isn't possible is it? And thirdly, if it did work up to this point, you may have problems with CPU load by running multiple instances of Halo and multiple instances of GS. GS takes up a good amount of resources because it's doing a lot of things at once--pathfinding, path following, memory reading and writing, AI, drawing the graph, and aiming, not to mention all the code making sure these things run together without a hitch and making sure the user of the program doesn't do something stupid.

I think it's gonna have to be 1 bot per computer. But like laggy said, you can still use it to attract players to a server and I'm sure half of them won't even realize they're playing against a bot. The map will get play time, so everyone's happy. For the reason I mentioned earlier, Halo needs to be the active window for the bot to play. You could just leave it running when you go AFK for a while.

[Inferno]

I see. Maybe you could try and hook this so a person could just run this in the background all the time (since I already run this computer 24/7) to idle a server with bots.

[Con]

Maybe. Biti knows about this stuff, I could ask him, but don't get your hopes up. I've got bigger fish to fry. Also, I hope you guys don't mind but the app is 1.08 only ATM. I figured a lot of people use the 1.08 exe for opensauce and use version changer like I do.

[Inferno]

If someone is willing to give me a 1.08 exe I'd be happy to use it with VC.

[Con]

http://www.halomodding.com/index.php?/files/file/4-version-changer/

[Cortexian]

iirc I had an executable from some app maker (possibly bitidork) that allowed you to run multiple instances of the game.

[leorimolo]

Con, couldn't this be easily ported to H2X since you can send inputs through network (debug), and theres even an application to play Xbox 1, with a 360 controller connected to the PC, so you could use that to create the paths.

[Dwood]

H2V is what it would be ported to if anything imho.

[Kornman00]

xbox7887 and I developed an application (.NET based) which lets you control H2X from your computer. I think that's what he's referring to.

All you would need at 15 modded xboxes and 16 instances of this app and you got yourself a lan party :downs:

[leorimolo]

xbox7887 and I developed an application (.NET based) which lets you control H2X from your computer. I think that's what he's referring to.

All you would need at 15 modded xboxes and 16 instances of this app and you got yourself a lan party :downs:
Exactly what I was referring too, could even be possible with halo 3 and a Jtag console. Also, this app uses XYZ cords from the player in the game, which can easily be read from the memory using this app, thing is I have no idea how to do it, im just sure its possible in case you ever feel like porting it.

[Con]

Maybe I can make GS run in a mode where it accepts messages from another app which feeds it game data. Korn's app would have to relay the information back and forth between h2x and GS. Another thing I could do is have it load up process names and addresses from a file on launch with a specific argument. This file's information could override the built-in Halo information and potentially allow this app to work with any FPS you wanted, provided you have the addresses.

[Inferno]

iirc I had an executable from some app maker (possibly bitidork) that allowed you to run multiple instances of the game.

Could you upload that for me. I would luv to run 15 instances of halo and joining some random guys server 15 times.

[Kornman00]

Maybe I can make GS run in a mode where it accepts messages from another app which feeds it game data. Korn's app would have to relay the information back and forth between h2x and GS. Another thing I could do is have it load up process names and addresses from a file on launch with a specific argument. This file's information could override the built-in Halo information and potentially allow this app to work with any FPS you wanted, provided you have the addresses.
You could also define an interface for doing such things which an external .NET DLL could implement, thus making it all managed and entirely object based (instead of serializing, remoting, WCF, etc).

[Cortexian]

Could you upload that for me. I would luv to run 15 instances of halo and joining some random guys server 15 times.
Bitidork contacted me, said it wasn't him that modified the executable. I'm not sure I have it anymore, I cleaned out a lot of my Halo CE stuff. If I find it I'll post it in here.

[CrAsHOvErRide]

My Halo can be run in multiple instances. I'll upload the exe because I cannot remember where I patched :S

Halo Custom Edition 1.09 Executable (Multiple Instances, CRC Removed, Dev Enabled with -console) (http://www.vivid-abstractions.net/downloads/HaloVersions/haloce_109_dev_inst.rar)

[Skarma]

http://www.modacity.net/forums/showthread.php?18223-Reverse-Engineering-References&p=463551#post463551

[Con]

Needs more 1.08 version.

[Dwood]

Needs more 1.08 version.

.

[Inferno]

Needs more 1.08 version.
.

[Con]

GS may end up compatible with both 1.08 and 1.09 anyway. We'll see.

edit: I just finished the pathfinding option that find alternate paths. It wasn't too hard to pull off and the results are pretty good so far. It just keeps a persistent cost for each node which I add 1.0 to when it's used in a path. Every time I finish pathfinding I have to reset costs for all nodes anyway, so I just subtract 0.1 from every node's persistent cost. The pathfinding avoids paths with a higher cost. If I add more than 1.0, it will take longer for that node's cost to go down so it will produce more alternative paths. I still have the pathfinding option that picks the best path.

[Con]

bumpu

http://img214.imageshack.us/img214/6914/capturegl.jpg
I set up Damnation to be walked on. 137 nodes.

Something you may have noticed is the new link type (red). This is the look-ahead link and it forces you to aim at the next node while following that link. This makes ladders easy to navigate but can be used in combination with jump links to pull off all sorts of maneuvers. A problem I had with walking along the narrow walkways in the pit of Damnation was the bot would randomly press strafe keys and fall. The look-ahead link forces the view forwards along the walkway and only uses W; no strafing.

I also added tabs to the interface. On the Artificial Intelligence tab you'll be able to load your AI text files and the program will transform this into something it can work with, telling you if there's any errors. It's kind of like a compiler. I could go on about the structure of the decision tree, but it's unimportant right now. The tab will also have options to control the "smarts level" of the AI.



Here's a video of GS walking around Damnation.

C9Ul82x1oEQ

[Con]

I just finished the AI text file loading. The text file is what defines the behaviour of the "AI" controlling the player. It doesn't actually play yet, that's still to come. What I've accomplished recently is reading the file and constructing the appropriate data structures so the AI will be able to use them in real time.

How will the program use these structures?
Users may create their own text files to define how their bot behaves. In the file, you define a tree-like structure of TaskNodes. Each TaskNode has a priority calculation expression and possible child TaskNodes. There are two types of TaskNodes; Subtasks and FunctionNodes. GuiltySpark will ask the AI to find the highest priority task every second (users may adjust this interval). It starts by checking which of your TaskNodes at the first level have the highest priority, and then for the TaskNode with the highest priority it again performs the same check its children (if it has any). A TaskNode that has no children is called a FunctionNode.

The algorithm works its way down the tree to find a FunctionNode. This node contains two numbers; a function ID (FID) and a parameter. The FID corresponds to a built-in function inside the program that the AI can use, such as walking to a specified node, jumping, or aiming at a certain angle. Any TaskNode (a Subtask or FunctionNode) may be designated "concurrent" with a special symbol. After executing a concurrent node, the AI will move on to the next highest priority node and execute that. This lets you perform multiple steps at once, for example controlling the walking and targeting at the same time.

I'm not yet sure how the repeated priority calculations will affect performance. I've included an internal buffer of ingame values so that the bot only has to calculate a shared value one per tree traversal. Creating simpler priority expressions, smaller trees, and increasing the AI update interval will all benefit performance if it's becoming problematic.

Loading the text files
http://img232.imageshack.us/img232/6223/capturefi.jpg

As you can see, the program will give you feedback on the reading of this file. Errors will stop the loading, warnings will not. The debug checkbox lets you see exactly what's going on under the hood.

File syntax example


#this is a comment
*[0.5 $1 * 1 +] SUBTASK_NAME_1
{
#another comment
*[10 5 -] FUNCTION_NAME_1 !1(0.22);
[$5] FUNCTION_NAME_2 !3(12);
}
[$9 0.1 *] SUBTASK_NAME_2
{
*[10 $11 -] FUNCTION_NAME_3 !8(17);
[$5 0.5 +] FUNCTION_NAME_4 !10(1.2);
>filename.txt
}
[$4] FUNCTION_NAME_5 !5(0.573);
Comments are preceded by a hash "#" and make the entire remaining line a comment. Don't put anything after them on the same line.

Each TaskNode has a header with an optional concurrency marker, "*", a postfix priority expression surrounded by "[]" and a name. What decides if the TaskNode is a Subtask or a Function node is what comes next. If it encounters a "{" block start, then the header is that of a Subtask (since it has children). A "!" means it's a FunctionNode since FIDs are preceded by "!". FunctionNodes must end with a semicolon ";" while Subtasks must close their block with a closing brace "}".

The final thing that stands out is the line ">filename.txt". This is like #include in C. It simply redirects the parser to that file temporarily, allowing you to build these trees out of other trees in other files. Yo dawg.

You may be wondering, "why not just make it all FunctionNodes if they can have their own priorities?". This is fine, but sectioning things into Subtasks allows you to skip potentially expensive function priority calculations with a heuristical priority for the entire group.

File rules
As for specific rules, there must be no space between the concurrency marker and the priority expression "[". The priority expression, however, requires spaces to separate the terms. If you're not familiar with postfix expressions, Google it. After the "]" is the TaskNode's name. This name must not contain any spaces and must be padded with whitespace on either side. Put no spaces in the FID and parameter area. FunctionNodes can appear on the same line but must be separated by whitespace, however this is stylistically poor. On the subject of style, your open braces "{" may appear on the same line as the Subtask header (must include a space before it though).

You'll notice that FIDs are preceded by a "!". When the program is released, I will provide a list of functions and the FIDs and valid parameters. I will also provide a list of game data sources (terms with $) and their output ranges.

Changes to make
Something I want to change before continuing with the project is allowing FunctionNode parameters to have expressions like priority expressions do.

[Skarma]

I have no real hands on experience with AI, but this stuff looks complex and crazy to me. Don't get me wrong, there is no wrong way of doing this and it's very interesting. If I were to do AI in a game I didn't have source code to, I would traverse the bsp tree of the map geometry and do ray tracing for path finding and collision detection and let the bot make it's own decisions instead of limiting the options with hard coded values. I'm sure you have a reason for all this though. It is nice to have a unique node graph for different maps. Good seeing progress on this, keep it up!

[Dwood]

bumpu

C9Ul82x1oEQ

Now all you gotta do is change the looking vector!

[Con]

As you can see in the OP, there's still a few outstanding things on the to-do list. It's getting there though. FunctionNodes now accept postfix expressions for parameters.

[Con]

A little proof of concept:

http://img109.imageshack.us/img109/2224/capturesk.jpg


The AI system is now fully functioning...it just doesn't support many functions and data sources right now. One function I've added, seen in the AI text file as "!0", prints the parameter given to it. It will print to the AI output textbox in the final version, for now it prints to debug output in VS. The number preceding the ":" is basically a tick indicator for the AI timer. The reason it's random is internal, not really important.

You can see the parameters actually contain game data sources $4 and $5 which corresponds to the players aim vector. I also have player x, y, and z as sources right now.

By looking at the debug output, you can see it prints two numbers per tick. That's because the highest priority TaskNode, PRINT_X, is concurrent (*) and so the next highest priority gets executed after. If I removed the "*" then only the task with priority [1.0] would get executed.

Basically I just need to keep adding data sources and functions now to get this really cookin'. You'll eventually set up priorities based on distance to enemies and such for deciding what method of attack the bot uses for example. Another task might be capturing the enemy flag, but the priority of this task depends on a few things (don't want to concern the bot with capturing when its in the middle of a firefight). Capturing the flag could have multiple subtasks like getting to the enemy's flag, and returning the enemy's flag to your base. The priority of these will depend on whether or not you're holding the flag.

I'll try to have another update next weekend.

[Dwood]

Make it so we can import move positions and use those :D

[Con]

http://img263.imageshack.us/img263/1047/gs1p.jpg

The aimbot is done. It's pretty good; it constantly adjusts the lead based on ping and velocity. It does get messed up when they crouch or get in a vehicle, but I'm not too concerned about making it perfect.

The aimbot is just another FID a FunctionNode (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-%28formerly-HaloBot%29&p=560366&viewfull=1#post560366) can have. It takes parameter player index, so it can always aim at one player or some function of data sources giving a player index. I've also added several more data sources and FID's for your bots to use:

FID List


PRINT = 0,
AIM_AT = 1,
GOTO = 2,
GOTO_CLOSEST = 3,
GOTO_ALT = 4,
GOTO_CLOSEST_ALT = 5,
MOUSE1 = 6,
MOUSE2 = 7,
SLEEP = 8
Data Source List


PLAYER_X = 0,
PLAYER_Y = 1,
PLAYER_Z = 2,
CAN_WALK = 3,
VIEW_ANGLE_H = 4,
VIEW_ANGLE_V = 5,
CAMERA_X = 6,
CAMERA_Y = 7,
CAMERA_Z = 8,
CLOSEST_PLAYER = 9,
LOCAL_TEAM = 10,
PLAYER_COUNT = 11,
LOCAL_PING = 12,
CLEAR_SHOT = 13,
SHIFT_KEY = 14
I added in that "SHIFT_KEY" data source to show how easily this thing can be exploited for use as an aimbot for the program's user. I wanted to have hot-keys accessible as data sources anyway, but the power of the AI system lets you make an aimbot with the following simple AI text file:



# When the shift key input ($14) is 0, doing nothing has higher priority. However, when shift is held, aim (!1) at the closest enemy ($9)
[0.5] NOTHING !99(1);
[$14] AIM !1($9);
I obviously don't want to add to Halo's aimbot problem. I need ideas from you guys on how to solve this. Should I disallow hot-keys and aiming in the same file?


The other new data sources and FID's make the bot function at a very basic level now. Here's the aptly-named new001.txt:



*[1.0] GOTO_CLOSEST_ENEMY !3($9);
[0.5] AIM !1($9);
*[$13] SHOOT_AT_THEM {
*[1.0] CLICK_DOWN !6(1);
*[0.7] SLEEP !8(30);
[0.5] CLICK_UP !6(0);
}
It always goes to the highest priority task first: GOTO_CLOSEST_ENEMY. That's self explanatory, but note that it's concurrent (*). This means that once it's done executing, it'll move on to the next highest priority TaskNode. In this case, it's either aiming at the closest enemy or clicking to fire. Clicking to fire depends upon the target being visible or not ($13) but it's also concurrent, so it always ends up aiming at the target anyway. Because AIM is not concurrent, if SHOOT_AT_THEM has a lower priority (it's either 0 or 1) then it'll never shoot.

So about all that does is runs to enemies and shoots at them if they're visible. Not a team player!

Edit:
There's a couple other things I should mention. The first is a new addition to the UI called "Use Camera". The little "you" circle in the graph view follows your player coordinates and that's what it uses to place new nodes and such. If so feel like it, you can opt to use camera coordinates instead. This can make placing nodes in difficult places easier, like just inside walls for ladders to work properly. Since it no longer relies on camera coordinates for everything, you can watch it from 3rd person in devcam now.

[Cortexian]

Should I disallow hot-keys and aiming in the same file?
Yes.

Aimbots are really easy to detect with sight-jacker and it's not hard to ban people from servers so long as an admin is online. If you're playing in a server without an admin and a botter it's easiest to just leave to another server. It's not really a problem anymore.

[Con]

no shields shotguns on damnation

http://img684.imageshack.us/img684/9622/lolzxh.jpg

Not bad :woop:

It would have won if it spammed grenades like CrazyReaper did. Maybe I'll work on that next?

Also, source code will be released when it's done.

Something that just surprised me is that the AI has hardly any overhead at all. Running through the priority calculations and pathfinding every 100 ms plus constant path following only used at most 4% CPU in task manager. Only when you have the graph view open does it go up to ~20% because it has to draw all that without GPU acceleration. Might change that later but I don't think it's a big deal.

[Limited]

Very nice indeed, I'm impressed.

[Siliconmaster]

Woah- that's pretty darned awesome.

[skywalker14]

So is this fairly close to a release?

[Con]

There are a few things I still wanna add before release:


It can't walk to ANY place, only to nodes on the graph. This isn't hard to fix as I just need to add a temp node at the end of the path it's supposed to be following and the walker will handle that as if it were real.
Support for objectives. It's kinda useless if it ignores objects in various gametypes.
Improve pathfinding and the aimbot for AI usage. Right now it aims at a target and pathfinds for every tick of the AI. The aimbot should instead be aiming at a target constantly and the AI just tells it when to change targets. Similarly for the walking.
Grenade support.
Support for aiming at nodes and not just players. Who knows how people might use this program? Could be handy for machinima or something.
Distances to walking destination and aimbot target as data sources for the AI. Enemy shield % too?
Inventory information as data sources (number of grenades, weapons being held), as well as the ability to switch weapons.
Maybe find a better way to detect if targets are visible or not. In servers with high pings ~200 it tends not to take shots because it has to lead so far ahead that the enemy's name doesn't show up and hence it doesn't know they're visible.

[skywalker14]

So just so I've got it clear. This is kinda like a program that will play Halo for u in a way( including in mp)? Also how long do think adding that stuff in would take? If I'm reading every thing correctly this is looking really nice!

[Con]

I haven't tested this at all in SP, some features I know won't work there. It's built for multiplayer only. You've got the right idea though. This started as an experiment to see if I could make a program that could navigate around a multiplayer map. It has turned into a full on automated and programmable multiplayer bot. This won't be like playing with bots in other games; it's just a player who's letting a program control the game for them, so it takes up a slot in the server.

It can't navigate just any map. Users need to design a special node graph that tells the bot where it can walk. This can take some time to setup as you need to cover the entire map densely enough. Luckily I've included a few helpful tools that make the task faster. Bloodgulch, Rat Race, and Damnation already have graphs made for them. I'm also working on Hang Em High and Wizard. I might ask some select people for help making more before release in exchange for getting to use the program before anyone else.

At the rate I work, it'll probably take me a couple months at least to add those things. Something real shitty just happened to me so I don't feel like doing much of anything right now.

[skywalker14]

Well I'm sry to hear about that shitty thing happening but I'll be watching for this one. Do you think you'll need any testers for it?

[Con]

Yeah, I'll need some testers eventually. When I get some people to help make graphs they can try and break the program while they're at it.

[Cortexian]

When you need people to make graphs for the stock maps shoot me a PM. Would be nice if this released with graphs for all the stock maps.

[=sw=warlord]

Out of curiosity.
How would the program respond to another user running the same software which would effectively have two bots running the same routines?
Would they work in unison or would they go about their business like normal A.I do?

[Con]

If two people are using this in the same server then the apps don't communicate if that's what you're wondering. It treats every other player the same way. In fact, all it's working with right now in that sense is the coordinates of other players.

[=sw=warlord]

If two people are using this in the same server then the apps don't communicate if that's what you're wondering. It treats every other player the same way. In fact, all it's working with right now in that sense is the coordinates of other players.

what I was wondering is, if for instance you have two objects next to each other and they effect each other equally wouldn't they in turn move at the same time?
for instance, you have two of your bots stood next to each other, would they run and shoot each other at the same times or would they be out of sync?

[Cortexian]

Would depend when you started them both. If you started running them side-by-side they would move together and shoot together until one killed the other. Then one would respawn somewhere and start the "loop" around the map from the nearest marker.

[Con]

^
this

If you started them at the same time right beside each other then they would probably fire in unison. However, differences in the graph where they stand would make each bot move differently. That could lead to a few missed shots.

[Dwood]

I just thought of ideas for this, and I realized that even though it's designed for MP maps, that doesn't mean it has to be designed for killing other players. Say we could have an ai (theoretically anyway) get into a hog, then wait for a player to come around and jump in. Then that ai would drive the player around depending on whatever gametype it is.

[Con]

Certainly. It's as easy as just making an AI text file with that kind of behaviour. I'd have to include a few more data sources and FIDs to get that feasible though.

[Dwood]

At the top of the file have some kind of identifier (say a word) that identifies what type of driving it's for... Offensive, Defensive- then per-gametype

in regular slayer it just drives the path. In Team slayer it waits for an ally unless an enemy is close by in which case it drives the route and attempts to circle around or something. etc etc.

[Con]

It's probably easiest to just make a separate AI text file for each gametype or driving style. Remember you will be able to use a >filename.txt line to build AI files out of other AI files so common tasks can be shared.

[Donut]

as i said before, im totally up for testing when the time comes. iv always wanted something like this for hpc.

[Dwood]

It's probably easiest to just make a separate AI text file for each gametype or driving style. Remember you will be able to use a >filename.txt line to build AI files out of other AI files so common tasks can be shared.

I haven't used the program so I don't know about the features like that... What happens when the map goes into a rotation and the gametype changes? I assume people will be using these in dedis to make their maps at the top of the lists and all... And second: What happens if a map is loaded and the ai doesn't have a file for the name of it?

[Con]

An overview of the AI file language can be found here (http://www.modacity.net/forums/showthread.php?21417-WIP-GuiltySpark-%28formerly-HaloBot%29&p=560366&viewfull=1#post560366)

Right now the user has to manually change the AI file if the gametype changes. I hadn't really considered the possibility that people might set this up to keep their dedis higher in the list. Maybe whenever a new game starts it'll check if there is an AI file which can be used for that gametype. Perhaps a special comment at the top of the file with a list of gametype names will mean that the AI file is suitable for those gametypes. I can do something similar with node graphs by filename. If there's no AI file or map available then I guess I'll have it do nothing like an afk player.

[Con]

bump!

I'm going to be holding a private beta soon. If you are interested in testing and/or making node graphs, please shoot me a PM. I'm only going to be accepting people that I know I can trust not to share it. If I don't already know you, then don't bother. The anti-aimbot measures won't be added until after testing is done. I may also put a cap on the number of people who are in the beta.

[Patssj6]

Wanted to drop by to say that this is really outstanding work.

[leorimolo]

Wanted to drop by to say that this is really outstanding work.
I agree, its very incredible. I wish I could do it for all the other halos tho, on xbox.

[Cortexian]

I'm especially liking how the aimbot doesn't snap, D:

[leorimolo]

I'm especially liking how the aimbot doesn't snap, D:
Can any of you guys make a video? I am really looking forward to this.

[Cortexian]

Can any of you guys make a video? I am really looking forward to this.

http://www.youtube.com/watch?v=thC8REcOWjI

[Pooky]

Doesn't snap, and even locks onto vehicles? You better be careful with this thing :\

[Donut]

even without the snap, this thing bots pretty viciously. i can not and never have been able to lead and shoot the way this does, and i like to consider myself a decent hce player. how difficult would it be to program in aiming error, to simulate human inability to aim?

[Con]

It has some wobble to it already. I can increase it a bit. Also, it doesn't take into account the velocity of the vehicle the target player's in, so it's pretty much useless there unless the vehicles not moving.

[skywalker14]

This is looking really awesome. Would you consider releasing the aimbot separately?

[Dwood]

This is looking really awesome. Would you consider releasing the aimbot separately?

He stated previously that he wouldn't.

[Cortexian]

This isn't about cheating. It's about making a usable "AI" to drop into games and populate servers.

[d4rfnader]

Sorry, but, I thought modacity was against aimbot usage?

[Dwood]

This isn't about cheating. It's about making a usable "AI" to drop into games and populate servers.

.

[Cortexian]

Sorry, but, I thought modacity was against aimbot usage?
Reading the entirety of a thread before posting is generally a good idea. I highly suggest you do that in this case. Maybe even just read my last post that Dwood kindly quoted for you.

[d4rfnader]

Oops, sorry about that, I misunderstood. I took "usable AI to control the player" as, aimbot. =P

[Dwood]

daerp.

[Limited]

Righto I have some free time, I'll get onto testing :)

[SniperBOT]

Im willing to do some testing PM ME

[Cortexian]

Im willing to do some testing PM ME
No.

Here's why.


I'm going to be holding a private beta soon. If you are interested in testing and/or making node graphs, please shoot me a PM. I'm only going to be accepting people that I know I can trust not to share it. If I don't already know you, then don't bother. The anti-aimbot measures won't be added until after testing is done. I may also put a cap on the number of people who are in the beta.
You have ONE post, and you signed up just to post it with a name like "SniperBOT". You sound like some kid looking for the newest bot on the block to inflate your already overinflated e-peen by pretending to be good at a VIDEO GAME.

Now that's just my opinion. You may have perfectly good reasons for signing up and wanting to test. But I can tell you right now, it's not going to happen. You make an account to make ONE post requesting to test a (currently) very sensitive piece of programming, and you ignore everything the creator specified about criteria. Does Conscars know you? No. Did you send HIM a PM? No. You came here and made a post requesting he PM YOU! *laugh*

[Con]

Im willing to do some testing PM ME
u trollan?

For everyone not in the beta, lots of progress is being made. I'm close to giving the testers the third beta build which will drastically increase the bots fighting capabilities. It's not too late to still join the beta, just don't ask like that guy ^. I need someone who will push the program to its limits by trying to break everything. Let me know if you can think outside the box and test some unusual usage cases.

[Con]

I was asked to give a presentation on GS at school, so here's a picture you might find interesting if you're into diagrams or something....

http://img189.imageshack.us/img189/1930/gs0c.png

Version 1.0.20 is available for the beta testers. It's got some pretty sweet additions that you can read about in the dev blog: http://csauve.wordpress.com/

[Hiralis]

Con, this is amazing. If this were priced, i'd pay full or even double. This is amazing, kudos to u

[Cortexian]

I'm fairly sure that would be illegal, but yes, it's an awesome little application.

[Patrickssj6]

I'm fairly sure that would be illegal, but yes, it's an awesome little application.
huh why? My buddies on other forums make money selling stuff like this :D

[Cortexian]

NVM, I was thinking of GNU Licensing.

[Con]

I haven't posted in here in a while. I just finished a major feature which is the improved target visibility checking. GuiltySpark will extract the BSP of whatever map you're playing in and perform ray casting to see if the line between two points is obstructed. It was a lot of work but definitely worth it. You can read more about it on my blog: http://csauve.wordpress.com/

Some other changes I've done:


Graph view ported to DirectX; uses less CPU now
Command history and associated features
Added a couple new graph commands
Various graph view improvements and bug fixes
Improved script error checking



As for release, there are a couple bug fixes to do first and including more AI scripts would be helpful for you guys.

[Limited]

Jizzed in my pants...

Wow, incredible work :) so does it do the BSP checking on the fly (as in during when you use the bot)? That'd make sense to it can repeatedly check if theres any walls in the way.

[Con]

Yeah, it extracts it once then does the calculations on its own copy since that's faster than reading from Halo. The default AI refresh rate is every 100ms, so that's how often it's checking.

[Siliconmaster]

Wow. Looks awesome.

[urbanyoung]

I just got told about this project and I must say, it's incredibly impressive. I've always wanted to go deeper into the mechanics of Halo. I see you posted in February that it was available for beta testers. I'm obviously interested in the source code, so I was wondering when it will be released? Is it available for beta builds, or will it only be for the final build?

[Con]

welp, I haven't posted here in a while. I started working on this project again recently. Everything I wanted to get done before release is done. There are still nagging bugs to be fixed that really hinder this app in certain cases. Coming back to my code after this time really showed me how horribly written it is. I've been working as a software engineer for the past 6 months and I've picked up a lot of good practices, but right now the goal is just to get it done, no matter how hacky it is. I will not do any refactoring of code and will likely not release future versions of the existing app. I already have a good idea of how I could rewrite this completely and make it general and extensible enough to apply to any game, but that's a story for another time. I'm hoping to get the bugs all fixed by the holidays.

For now, here's a couple videos I recorded recently:

SpogBHQXg5k

rHVixLzxVMI

[EagerYoungSpaceCadet]

Really nice, good to see it's been worked on.

What the hell happened at 0:26 though?

[Con]

In which video? If you're talking about the crazy fast spin in the first video, that's because the aimbot needed to pivot around really quickly since the target's location + lead distance was very close to the player. The bot attempts melee in close quarters now.

[JackalStomper]

Did anyone accuse the bot of botting?

Seriously though nice work, can't believe something like this was even made for halo in the first place. Are those two videos of the same encounter? It doesn't look like they are.

[Con]

It hasn't been accused yet, but that's usually because I keep it in smaller servers with easier opponents.

Here are some things that might give it away:
- Attempts to jump over unexpected obstacles rather than walk around them
- Will lock on through walls for small period while switching targets (it hasn't realized they aren't visible yet)
- Can walk quite oddly (getting stuck in corners)
- With no targets visible, it will face directly forwards to the next pathfinding node. Paths aren't always straight, so it kind of zig-zags its way to the target.
- Doesn't lead shots when targeting players in vehicles.
- Clueless about avoiding grenades or vehicles
- Runs straight at enemies even when overwhelmed
- Always backpack reloads

There are two reasons I spot botters normally. The first is that they're already targeting me the instant I show myself to them. I'll toss a few up to luck, but it's a pretty clear indicator when its repeated. I address this by having the bot aim along its movement path when the target is not visible. Also, smooth aiming and an intentional delay prevent GuiltySpark from firing on the target too early after spotting them.

The second way I spot botters is when they appear to be skilled with their weapons, but lack strategy and general halo common sense. GuiltySpark tries to be more believable by strafing, but still lacks the common sense to avoid grenades or vehicles, or to take cover. It will just run straight over the hills to the target because that is the shortest path. Having it understand strategy is an interesting problem that I would like to address in v2. It's also not a team player since it doesn't go for goals or anything.

The basic functionality is there for goals, though. Maybe people will write some more advanced scripts than mine after release. I modularized some components of the advanced bot script into separate scripts. This means that in your own scripts, you can just do something like >include_weapon_management.txt and it will select the best weapon for the target's range and the amount of ammo you have.

And the two videos are not of the same encounter. Fraps doesnt seem to want to capture my entire screen either.

[sanni]

Could you run multiple instances of GuiltySpark on one computer? I like the idea of a Tower Defense Sidewinder were 7 mindless bots per team walk on predefined (strategic) routes towards the enemy flag and kill each other in the event :o

[Con]

Could you run multiple instances of GuiltySpark on one computer? I like the idea of a Tower Defense Sidewinder were 7 mindless bots per team walk on predefined (strategic) routes towards the enemy flag and kill each other in the event :o
No, sorry. It's one instance per computer just like Halo. For that idea you would be better off making a custom Sidewinder map with actual bots in it. That's not really GuiltySpark's usage.

Speaking of usage, I need some well-rounded and experienced gentlemen to play around with the app and report any bugs they find... just some general sanity testing. There are still bugs, but they are either too hard to track down or don't affect the usability too much.

Please PM me if you are interested in testing a pre-release of GuiltySpark. Preference given to established community members.

[Pooky]

Depends what you mean by testing. I've got no programming experience whatsoever but I'm pretty knowledgeable on Halo's gameplay and mechanics.

[Con]

No programming experience needed. Testers are just looking for usability issues.

[vnlagrla]

I would love to test. If I can either PM me or send me a youtube msg at http://www.youtube.com/user/vnlagrla1 I've been waiting for the release ever since I read this thread.

[=sw=warlord]

So, Me and Pooky were testing this last night on a server on Hang em high and found a slight problem.
We found that the AI likes to walk to walls looking up and try to jump, same with platforms.
Could this possibly be a problem with the nodegraph?

[EagerYoungSpaceCadet]

2438
Spark hates me :(

[Con]

So, Me and Pooky were testing this last night on a server on Hang em high and found a slight problem.
We found that the AI likes to walk to walls looking up and try to jump, same with platforms.
Could this possibly be a problem with the nodegraph?
Yes, the Hang Em High graph is incomplete and therefore useless for pathfinding. readme.txt in the graphs directory will tell you which are incomplete.



Spark hates me :(
lolwut. Are you on 1.08ce?

[EagerYoungSpaceCadet]

Yeah, I'm on 1.08ce. Used the 1.08 exe in the download, turned off OS (although I saw some screens of PP working with Spark) and whatnot.


EDIT: Forgot to run as admin. :fail:

[EX12693]

So far Spark has been working perfectly for me. In close combat though it turns just a tad too slow...

[EagerYoungSpaceCadet]

Doesn't turn for me at all :S Just runs straight towards hogs and ghosts. Silly Spark.

[Cleaver]

Would you be able to make GuiltySpark's leading less steady and controlled? At the moment it seems to be the main thing identifying it as a bot, as leading is always so smooth, moving at exactly the same pace until the opponent is killed.

[Con]

That's a great point. It's certainly possible, everything is. I feel like this is something I should save for version 2.0, though. The current system doesn't lend itself well to that.

Speaking of 2.0, I've already started planning and blocking out the framework. I'm still trying to decide on a concurrency model though. I'm making it general enough to automate any process you want to write plugins for. I will, of course, focus on plugins around Halo.

[flamewheel06]

i would like to test this program
xfire: a2l
email: thedon5214@gmail.com

[Con]

I'm no longer looking for testers.

[TVTyrant]

And then Con was never heard from again.

[Con]

Hi.

[Cortexian]

Speaking of 2.0
.

[Con]

lol, I don't have an interest in gs2 at the moment. Maybe in the summer, maybe not. Currently programming for minecraft.

[Limited]

lol, I don't have an interest in gs2 at the moment. Maybe in the summer, maybe not. Currently programming for minecraft.Minecraft eh? Any mods?

[Ryx]

lol, I don't have an interest in gs2 at the moment. Maybe in the summer, maybe not. Currently programming for minecraft. In that case can you reupload GS source? http://www.modacity.net/forums/styles/smilies/emot-ohdear.png

[Patrickssj6]

lol, I don't have an interest in gs2 at the moment. Maybe in the summer, maybe not. Currently programming for minecraft.
heh same here. hopefully not programming the same thing...

i am working on an efficient minecraft rendering engine

[Donut]

on the topic of minecraft programming, since java and c# are really similar, and microsoft XNA is built on c#, would minecraft benefit from being ported to XNA? i feel like it would, but ive never actually used XNA, so im not sure.

[Kornman00]

The syntax for Java and C# are similar, but the architecture for Java/JVM is definitely not the same/similar as/to .NET.

[Limited]

on the topic of minecraft programming, since java and c# are really similar, and microsoft XNA is built on c#, would minecraft benefit from being ported to XNA? i feel like it would, but ive never actually used XNA, so im not sure.
Not another Minecraft port >_<. Go to the XBLA, you will see a million XNA Minecraft 'clones'. At least think outside of the box! (zing).

If your going to make a port, least made it interesting - for example WebGL.

[Patrickssj6]

on the topic of minecraft programming, since java and c# are really similar, and microsoft XNA is built on c#, would minecraft benefit from being ported to XNA? i feel like it would, but ive never actually used XNA, so im not sure.

Porting Minecraft from Java/OpenGL to C#/XNA is not the key part in making it more efficient. I facepalmed my way throgh the Minecraft mechanics and saw some obvious flaws:

Chunks
Chunks contain 16x16x128 blocks. So everything from bedrock level to the top of the sky is stored in one chunk and is loaded at once. Which is obviously inefficient because one does not care about the blocks beneath the player unless he digs down. They already changed this in some snapshot version...not the official release though I think.

Map Format
The map format partially relies on text searching to find the correct place inside a map file...compared to Bungie's map format it's a QQ

List goes on and on...
http://youtu.be/7anx9_3TYvg?t=37s
http://www.youtube.com/watch?v=oXmwLkSDQL8

The version is already a tad older and relies to much on the CPU. Right now I am working on getting some HLSL going to let the GPU do all the work.

[Limited]

By the way Notch updated the way maps are stored and also updated the chucks (he increased height by two-fold).

[Patrickssj6]

By the way Notch updated the way maps are stored and also updated the chucks (he increased height by two-fold).
Yeah I said that. Increased height to 256 and divided a chunk into 16x16x16 (or 32? can't remember).

[Limited]

Why is that inefficient? You want to decrease the amount of loading from file you need to do, as thats the killer part. What happens if player wants to place a TNT block? That has a wider range than a players dig rate.

[Patrickssj6]

Why is that inefficient? You want to decrease the amount of loading from file you need to do, as thats the killer part. What happens if player wants to place a TNT block? That has a wider range than a players dig rate.
The chunk is GZIP compressed and they did not allow any space inside the file for chunk decompression so you either IO it ouside or load it into memory (which takes a lot of time...). Second problem with that is that you surely have realized when you teleport in MC to a region which has no chunks loaded, everything from top to bottom is loaded which is stupid because the visible part should be rendered first. E.g. If you are on top of the Empire State Building you don't want every floor of the building to be loaded. You want the top floor to be loaded first.

If you are concerned about TNT you load the top floor first and then after the whole visible top floor is loaded, you can load one floor beneath.

[Limited]

The chunk is GZIP compressed and they did not allow any space inside the file for chunk decompression so you either IO it ouside or load it into memory (which takes a lot of time...). Second problem with that is that you surely have realized when you teleport in MC to a region which has no chunks loaded, everything from top to bottom is loaded which is stupid because the visible part should be rendered first. E.g. If you are on top of the Empire State Building you don't want every floor of the building to be loaded. You want the top floor to be loaded first.

If you are concerned about TNT you load the top floor first and then after the whole visible top floor is loaded, you can load one floor beneath.
Yes so you need to load a whole chunk at a time. You stated that if your at height 32 for example, why bother loading height 1 first? How does the chunk know where you are? It doesnt. It reads the chunk from start to finish. That is why you load bottom to top. If you were to reverse it, and have top height data at the start of file, you'd have the opposite problem if your in a cave (why load empire state building first when your in an underground cave).

So the whole chunk needs to be loaded. You also need to take into consideration sand/gravel blocks, which will fall if theres a space below. This is another reason why its loaded bottom to top.

[EagerYoungSpaceCadet]

I like the Minecraft discussion going on in this thread, but [WIP] GuiltySpark

[Patrickssj6]

No no...top to bottom or bottom to top doesn't matter. My point is, which they already changed as stated in an snapshot update, to divide a chunk into more pieces. Before 16x16x128 now 16x16x32. So you have 4 sub-chunks in height where before you had a whole chunk.

About the Gravel, in a voxel engine you have to save chunk states wether they are solid (in case of gravel it's not), opague etc so neighboring chunks know.

[Patrickssj6]

I like the Minecraft discussion going on in this thread, but [WIP] GuiltySpark

I just came here to ask what con is working on :-3

[Limited]

Fair enough, all I'm saying is your going to run into issues making BeautyMine :D

[Donut]

Not another Minecraft port >_<. Go to the XBLA, you will see a million XNA Minecraft 'clones'. At least think outside of the box! (zing).

If your going to make a port, least made it interesting - for example WebGL.
i wasnt suggesting they make a clone. i was suggesting an official port, like, mojang moving the game to c#/XNA for the purpose of efficiency. but pat already addressed this, so nvm.

[Con]

heh same here. hopefully not programming the same thing...

i am working on an efficient minecraft rendering engine

Na, I don't know anything about that. I'm doing a quests mod for bukkit servers.


In that case can you reupload GS source? :ohdear:

What do you mean by this? Source is still available in the release thread:
http://www.modacity.net/forums/showthread.php?24206-GuiltySpark-for-1.08-automate-your-player

[Limited]

i wasnt suggesting they make a clone. i was suggesting an official port, like, mojang moving the game to c#/XNA for the purpose of efficiency. but pat already addressed this, so nvm.
http://marketplace.xbox.com/en-US/Product/Minecraft/66acd000-77fe-1000-9115-d802584111f7

(http://marketplace.xbox.com/en-US/Product/Minecraft/66acd000-77fe-1000-9115-d802584111f7)Already being made, officially by Mojang.

Sorry for temporarily derailing thread Con :D