[WIP] GuiltySpark

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.



Videos







Left to do:

• Overhaul link implementation
• Saving and opening networks
• Pathfinding (A*)
• Allow the program to move the biped
• Allow the program to drive vehicles
• Upgrade pathfinding and following
• AI file definition & loading
• Create an AI to control the player
• Integrated aimbot (program-use only, with error)
• Create more functions and data sources for the AI to use
• Create some node graphs and AI files, fix bugs, add final touches
• pre-release testing

It's done, download here:
http://www.modacity.net/forums/showt...te-your-player

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. :(

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

Or did I read this wrong?

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:

Quote:

---

Originally Posted by 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?

---

Eventually, yes.

Quote:

---

Originally Posted by 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:

---

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?

Quote:

---

Originally Posted by Con

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.

Best way to AFK

Quote:

---

Originally Posted by Con

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

Quote:

---

Originally Posted by Limited

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.

Quote:

---

Originally Posted by TEMPTii

It would work in conjunction with solstice cam

---

ah, good idea.

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

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

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

:-3

Drawing the lines?

They like the teal.

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".

Quote:

---

Originally Posted by Inferno

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

---

Trolling opportunity

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

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.

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

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.

Ohh Ok.

finished revamping links

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

this should be much clearer with big arrows

Can you lay down path nodes or anything?

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.

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

Quote:

---

Originally Posted by 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.

---

We already established that it controls the WASD key, thus the only way to control a biped is to bump posses it.

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

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.

Assuming you could make fake clients, it might sync.

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

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.

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

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.

Quote:

---

Originally Posted by 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.

---

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

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

Gave up. :S

Good news, I found the solution. Limited suggested I use SendInput instead.
you'll need these

Code:

---

        #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);

---

Code:

---

                    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.


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.

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!

Quote:

---

Originally Posted by Freelancer

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 "wwwwwwwwwwwwwwwwwwwwwwwwwwsssssssssddddddddaaaaaa aaa"?

Quote:

---

Originally Posted by Pooky

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 "wwwwwwwwwwwwwwwwwwwwwwwwwwsssssssssddddddddaaaaaa aaa"?

---

Yea, aimbot.

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.

Quote:

---

Originally Posted by Pooky

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

---

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.

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.

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.

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.

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

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

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.



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.

Quote:

---

Originally Posted by Inferno

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:

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

Quote:

---

Originally Posted by Kornman00

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

---

Do it.

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.

Quote:

---

Originally Posted by Freelancer

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 <_<

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 :)

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/showt...l=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.

Quote:

---

Originally Posted by Con

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.

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).

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.

Quote:

---

Originally Posted by Con

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

Quote:

---

Originally Posted by 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.

---

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.

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 :|

Quote:

---

Originally Posted by 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?

---

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.

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).

You should make a video of the bot ingame (:

And release it publicly. (:

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

It will be released publicly when it's completed.

Quote:

---

Originally Posted by Con

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

It will be released publicly when it's completed.

---

And it will be completed when?

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

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.

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.

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.

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.

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.

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...

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/showt...l=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.

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

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.

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.

http://img811.imageshack.us/img811/9...3887305225.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?



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

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

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

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

Quote:

---

Originally Posted by Con

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.

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 :\

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. <- 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.

Name of song in vid please.

my bad

Caribou - Odessa

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).

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.

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

Quote:

---

Originally Posted by Inferno

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.

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.

Quote:

---

Originally Posted by p0lar_bear

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.

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




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/7...reenshot00.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.

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.

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.

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.

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.

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.