Printable View
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.
If someone is willing to give me a 1.08 exe I'd be happy to use it with VC.
iirc I had an executable from some app maker (possibly bitidork) that allowed you to run multiple instances of the game.
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.
H2V is what it would be ported to if anything imho.
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.Quote:
Originally Posted by 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.
Could you upload that for me. I would luv to run 15 instances of halo and joining some random guys server 15 times.Quote:
Originally Posted by Freelancer
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).Quote:
Originally Posted by Con
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.Quote:
Originally Posted by Inferno
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)
Needs more 1.08 version.
.Quote:
Originally Posted by Con
.Quote:
Originally Posted by 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.
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.
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
Comments are preceded by a hash "#" and make the entire remaining line a comment. Don't put anything after them on the same line.Code:#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);
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.
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!
Now all you gotta do is change the looking vector!Quote:
Originally Posted by 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.
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.
Make it so we can import move positions and use those :D
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 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
Data Source ListCode:PRINT = 0,
AIM_AT = 1,
GOTO = 2,
GOTO_CLOSEST = 3,
GOTO_ALT = 4,
GOTO_CLOSEST_ALT = 5,
MOUSE1 = 6,
MOUSE2 = 7,
SLEEP = 8
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:Code: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 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?Code:# 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);
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:
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.Code:*[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);
}
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.
Yes.Quote:
Originally Posted by Con
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.
no shields shotguns on damnation
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.
Very nice indeed, I'm impressed.
Woah- that's pretty darned awesome.
So is this fairly close to a release?
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.
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!
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.
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?
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.
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.
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?
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?Quote:
Originally Posted by Con
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?
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.
^
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.
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.
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.
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.
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.
as i said before, im totally up for testing when the time comes. iv always wanted something like this for hpc.
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?Quote:
Originally Posted by Con
An overview of the AI file language can be found here
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.
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.
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.Quote:
Originally Posted by Patssj6
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.Quote:
Originally Posted by Freelancer
http://www.youtube.com/watch?v=thC8REcOWjIQuote:
Originally Posted by leorimolo
Doesn't snap, and even locks onto vehicles? You better be careful with this thing :\
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?
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.
This is looking really awesome. Would you consider releasing the aimbot separately?
He stated previously that he wouldn't.Quote:
Originally Posted by skywalker14
This isn't about cheating. It's about making a usable "AI" to drop into games and populate servers.
Sorry, but, I thought modacity was against aimbot usage?
.Quote:
Originally Posted by Freelancer
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.Quote:
Originally Posted by d4rfnader
Oops, sorry about that, I misunderstood. I took "usable AI to control the player" as, aimbot. =P
daerp.
Righto I have some free time, I'll get onto testing :)
Im willing to do some testing PM ME
No.Quote:
Originally Posted by SniperBOT
Here's why.
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.Quote:
Originally Posted by Conscars
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*
u trollan?Quote:
Originally Posted by SniperBOT
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.
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....
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/
Con, this is amazing. If this were priced, i'd pay full or even double. This is amazing, kudos to u
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 :DQuote:
Originally Posted by Freelancer
NVM, I was thinking of GNU Licensing.
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.
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.
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.
Wow. Looks awesome.
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?
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:
Really nice, good to see it's been worked on.
What the hell happened at 0:26 though?
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.
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.
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.
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.Quote:
Originally Posted by sanni
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.
Depends what you mean by testing. I've got no programming experience whatsoever but I'm pretty knowledgeable on Halo's gameplay and mechanics.
No programming experience needed. Testers are just looking for usability issues.
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.
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?
Attachment 2438
Spark hates me :(
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.Quote:
Originally Posted by =sw=warlord
lolwut. Are you on 1.08ce?Quote:
Originally Posted by 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:
So far Spark has been working perfectly for me. In close combat though it turns just a tad too slow...
Doesn't turn for me at all :S Just runs straight towards hogs and ghosts. Silly Spark.
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.
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.
i would like to test this program
xfire: a2l
email: thedon5214@gmail.com
I'm no longer looking for testers.
