That is awesome, you are awesome. Link a aim bot to it and see how well it does in a pubby.
Printable View
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.
I remember an autofire app made once that made the game shoot any time the reticle turned red.Quote:
Originally Posted by 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 :\
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.