[WIP] GuiltySpark

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

[Skarma]

http://www.modacity.net/forums/showt...551#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


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.

[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


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.