GW2 bot goals & ideas

http://www.guildwars2.com
Message
Author
User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

GW2 bot goals & ideas

#1 Post by Administrator » Tue Jul 24, 2012 2:35 pm

Here, we discuss various things we plan to do with the MM script that will be set up for GW2.



After learning a lot from the RoM project, there is a great number of problems that I would like to see resolved and many other things I want to see improved upon for GW2. I expect these changes to make coding quicker and easier, make the code easier to follow and expand upon, and improve the general flow of code as to avoid having to make hackish fixes all the time. Not all of these changes may make it into the bot; this is just a list of hopes and dreams.


  • State management - The bot will use a system of states (see below for more information) that describe sets of behavior/AI instead of a mess of nested loops and functions. This will allow us to much more easily define a set of goals (for example: move to this location, target enemy, fight it, then loot it) rather than just a procedural set of functions to call. Each state will have a main update function (which does not block like the functions in RoM bot did!) that will process information then push/pop other queued states.
  • Remove blocking functions - This means getting rid of functions that have while loops in them designed to take a long time to process, such as waiting for aggressive enemies or resting. These actions will still be possible, but will be done through states, not blocking functions. The purpose of this is to avoid situations where certain functions are preventing other, more important code from getting any processing time. This could potentially allow for networked botting, among other things, but will also just generally improve execution flow.
  • Better object-orientation - This one is self-explanatory, really. We're just going to move more into object relations and management than a list of functions to run.
  • Lower CPU & memory usage - This should tie in with removing blocking functions, I hope. Any unnecessary processing will be done away with. Anything that isn't currently needed in memory will also be deleted with its paired state.[/b]
  • Function hooking - Still undecided about this one. But, potentially, we could hook some functions of the game for various reasons. This would allow us to, say, ignore all rendering while botting (No need for any strain on the GPU if the player isn't actually playing) except for maybe a screen update every second. We could also better control certain actions (any kind of movement on input) directly instead of faking keyboard input to do it. Who knows what else it can bring up.
  • Minimal configuration - With the skill system that GW2 uses, the player should not be required to configure any skill settings. Just having them hotkeyed should be enough; the bot will attempt to figure out how to use the players' skills automatically.

States:
A state will be a class/table designed in a specific way that will contain logic for handling the character for that specific state. In example, one state might be designed to tell the player to combat enemies. On that state's update, the bot will attempt to use skills, re-position the player if necessary, evade attacks, heal, and whatever else. If it seems doubtful that the player can win, it will pop the combat state then push a new state into the queue: escape. On the next logic cycle, the player will now instead attempt to run away from all aggressive enemies. If the player is instead successful, it will pop the combat state and push a loot state. Once the loot state is completed, it will be popped and return to standard movement.

By pushing a chain of states, you can set up a chain of commands. For example:

Code: Select all

-- Notice these are in reverse order;
-- This is because the state at the top of the queue will be the one that executes first.
pushState(FilterInventoryState());
pushState(LootState());
pushState(AggroWaitState());
pushState(CombatState(target.GUID));

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#2 Post by BillDoorNZ » Tue Jul 24, 2012 3:44 pm

nice idea :) I've been looking at the Rom stuff and thinking along similar lines and had VERY simple partial implementation going for controlling the characters.

My idealised version would work something like:

* General routines for
- controlling the player (moving, turning, interacting etc)
- interacting with the environment ((in)visible pawns
- inventory loading, using items etc

* Pluggable modules for things like:
- combat
- inventory management
- pet management
- auction house manager

* Controller module for 'driving' the bot (i.e. decision making)
- this would also have pluggable/loadable modules similar to the existing waypoints. Each module would specify
+ its purpose (Collect / LevelCharacter / BuffCharacter )
+ its purpose specifier ( Collect: Gold/Tokens/Resources/Honor , LevelCharacter: XP/SkillRank, BuffCharacter: ???)
+ its frequency ( Daily/Weekly/Hourly... )
+ its requirements ( OtherQuest / EnoughDailies / RequiredLevel / EnoughTokens / SpecificTime etc)
+ a function to determine if the current Character can use it
+ a start location
+ expected duration
+ state ( none/started/complete/finished/idle)
+ events ( onCreate/onLoad/onUnload/onStarted/onComplete/onFinished) to allow users to add customisations for their character)
- the Controller would either be customised by users or have different strategies/goals ( get characters to level cap, then gear them, then farm xyz tokens...)
- a Queue of current objectives would then be maintained based upon the decisions of the controller.

e.g. Controller starts up, and has its goals set at:
1) Farm some Tokens (50 Water elements for current event)
2) Get to level 55
3) Farm some Tokens (e.g. Phirius Shells)
4) Get to level 65
5) Make 5 mil gold
6) Level pet to level 30
7) Make gold

The Controller would:
1) Check to see if it is currently doing stuff. And assuming it isnt, proceed to next step.
2) Take the first goal.
3) Find all modules that are purpose: Collect and purpose specifier: Water Element
4) Select one of the modules and add it to its queue (maybe it would go run the Water Element event by the res point in Varanas that runs at 20 minutes past)
5) Eventually the queued action is executed and completed (onFinished was fired so it ends up getting back to step 3 where it rechecks the modules and the one it just ran is not repeatable and therefore isn't selected as an option)
6) After a while the character has 50 Water elements so it moves on to the next goal (Get to level 55)
7) Find all modules that are purpose: Level and purpose specifier: XP
8) Select one to queue
....

Obviously theres a lot more to it than that gross simplification, but I don't see any reasons why it wouldn't work. It was quite difficult to implement in RomBot due to the way WaypointLists are laoded and used and required a lot of customisation :( I also couldn't solve interupts easily (where the player is attacked by a mob unexpectedly while in the middle of something), but with a more event-based approach that would be much easier to handle.

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#3 Post by lisa » Tue Jul 24, 2012 8:42 pm

Sounds good

*sits in the corner nodding and waits for instructions on what to do, blank smile on face like I knew what Admin was talking about.

Sounds like I have more learning to do ;)
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#4 Post by Administrator » Thu Jul 26, 2012 2:45 pm

Here's an example of how the states would work. Note that I still need to fix a bug with the classes lib, so the code I'm working on won't function without error for you guys.

main.lua

Code: Select all

include("classes/statemanager.lua");
include("classes/states/teststate.lua");

function main()
	stateman = StateManager();
	stateman:pushState(Teststate());
	print("Current state: ", stateman:getState().name);

	while(true) do
		stateman:run();
		yrest(1);
	end
end
startMacro(main, true);
classes/states/teststate.lua:

Code: Select all

--[[
	Child of State class.
]]

include("../state.lua");

Teststate = class(State);

function Teststate:constructor()
	self.name = "Loot state";
end

function Teststate:update()
	-- Check if there is lootable bodies in range, if so, loot them.

	-- If not, locate a nearby body and move to it

	-- If neither of the above, pop the state.
end

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#5 Post by BillDoorNZ » Thu Jul 26, 2012 3:31 pm

so, presumably you will need to implement a State class that makes the decisions for what other states to push onto the queue ?

i.e.:

Code: Select all

function main()
   stateman = StateManager();
   stateman:pushState(stateKillNearbyMobs());
   stateman:pushState(stateDetermineWhatToDoNext());
   print("Current state: ", stateman:getState().name);

   while(true) do
      stateman:run();
      yrest(1);
   end
end
where the stateDetermineWhatToDoNext class would contain the 'brains' for working out what the bot will do once it runs out of things to kill nearby?

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#6 Post by Administrator » Thu Jul 26, 2012 3:42 pm

If the state queue is empty, it will default to moving around waypoints (another state). Within that state, if it finds an enemy to fight, it will push the combat state onto the queue then return from the update() function, hence starting the combat state's update instead.

It would look like this:

Code: Select all

function WaypointState:update()
    if( enemyInRange(someRange) ) then
        enemy = closestEnemy();
        stateman:pushState( CombatState(enemy) );
        return;
    end
end

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#7 Post by BillDoorNZ » Thu Jul 26, 2012 5:42 pm

k, sounds reasonable...what happens when I (for example) want the bot to run a waypoint, and then depending on some stuff like player level, class, hp, xp, DailyCount etc I want it to start running a new waypoint?

Will I need to create a specific stateclass for doing all that. or will I need to edit a waypoint type file with lua type scripting?

the danger of this is that the main waypoint needs to remove itself from the queue (easy enough if it has a "I'm finished function") and push another one on. This is where the main complexity / issue will be, the interaction of waypoints and the state queue and resulting issues.

e.g. What happens when an unsuspecting user pushes a new waypoint onto the queue that sells a heap of gear and is attacked mid-sell and they haven't added code to handle that??? or would you envisage a master state that is monitoring for such things? if so, how do you tell it to ignore being attacked for a critical function?

and also, getting stuck :)

I guess it'll have to be a 'lets try this out and see and handle any issues as we go deal :)'

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#8 Post by lisa » Thu Jul 26, 2012 6:29 pm

I am starting to get an idea of how you want it to work now =)

When you get the errors worked out with the MM files can you post the working code, I don't see why we can't get the functionality sorted out before release, we could simply use RoM as the game. Just add in the required addresses for coords, hp and such which can easily be changed once they are found in GW2.
Atleast doing that we should have the building blocks of the GW2 bot ready for game release.
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#9 Post by Administrator » Thu Jul 26, 2012 6:38 pm

Different waypoints can be loaded in a similar way to how it is done with the RoM bot. They will not need to create or push a new waypoint state, as the waypoint state should always be running and keeping track of its progress.

The state queue is in place so that different, temporary states can be stacked and dealt with in order. So, if you need to run a new state to run to town, repair armor, sell garbage, and return, all of those things could be run as different state levels, only popping themselves as they finish. This means that any interruption could be handled in a next level state and then you immediately return where you left off.

As for your example of being attacked while selling junk, the event would be caught and processed and then push a new combat state. The combat state would continue until the threat is dealt with, then pop. This would return you back to the selling state to resume what you were doing. Of course, you may have to handle re-opening the vendor window during these types of interruptions, but I figure that should be fairly easy to handle in the sell state.



I've attached the state manager section of the code I've made. It is, of course, bare-bones and needs more work, but it will at least let you guys experiment with it and find any faults with it. You will need to have the latest copy of MicroMacro (1.02) and make the following change to micromacro/lib/mods/classes.lua

Original:

Code: Select all

	c.is_a = function(self, _basetype)
  		local mt = global.getmetatable(self);

		while( mt ) do
			if( mt == _basetype ) then
				return true;
			end;

			mt = mt.parent;
		end

		return false;
	end;
Change to:

Code: Select all

	c.is_a = function(self, _basetype)
		local tmp = self;
		while(true) do
			if( tmp == _basetype ) then
				return true;
			end

			if( tmp.parent == nil ) then
				return false;
			end

			tmp = tmp.parent;
		end
	end;
Attachments
gw2.zip
(1.84 KiB) Downloaded 338 times

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#10 Post by lisa » Thu Jul 26, 2012 7:57 pm

ok did up a little file for usage with RoM.

Add the file to the same folder with main.lua and add this line to main.lua
include("romcode.lua");

usage

Code: Select all

updatecoords()

playerX
playerZ
playerY
playerDirection
playerDirection should be 0 to 2Pi, 0 being west. I think.

Code: Select all

updatehp()

playerhp
playermaxhp
So have values for coords and hp now.

Also added in
memoryReadRepeat(_type, proc, address, offset)
distance(x1, z1, y1, x2, z2, y2)
Attachments
romcode.lua
V 1.2
(3.44 KiB) Downloaded 371 times
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#11 Post by BillDoorNZ » Thu Jul 26, 2012 8:14 pm

hmmm...will have a look at that when I can...thats gonna take a LOT of work :)

tho, can steal a lot of existing stuff.

The way I'd see it working is that all REQUIRED updates happen before any states are told to update etc. And the states wouldnt do any updates of the main stuff.

REQUIRED stuff would be:

player
nearby pawns

hmm....dunno....I can see 2 options there.

Thinking
The bot updates player etc every loop. And then calls a update() / think() method on the current state to pass processing off to that method.

The think method would never block, but rather quickly check anything that needs checking (e.g. for a movement state that was moving from point a to b, it would run the calcs for distance / variance / facing etc and adjust and then make the adjustment and finish, then next loop it would do the same). Same thing for combat (tho it would need to be a very fast loop for that...which could be a deal breaker).

The main advantage of this is that you could interrupt states easily (I'm being attacked, just ignore everything else and call the combat state)...

Trusting
This is more along the lines of what I think admin is talking about. The bot doesn't drive the states with its own loop, but rather loops, finds it has an active state and passes control to it...hmm...actually, no, thats not what admin meant :) I would assume that in this scenario, the bot main state would recognise a character is under attack and push the combat state which would deal with the combat...once it was done it would remove itself...tho, it would have to be getting updates for things like player position, hp etc too...

were you thinking the combatState would manually ask for these Admin? i.e.:

combatState:
1) update player object
2) update target/enemy object(s)
3) move to target
4) use skill xyz
5) is it dead? pop state
or

combatState:
1) move to target (target and player were updated 'asyncronously' elsewhere...)
2) use skill xyz
3) is it dead? pop state

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#12 Post by lisa » Thu Jul 26, 2012 8:30 pm

well for now I don't have the pawn info, didn't get that far in my memory searching so it would be better to assume we don't have it for now. If you build code around having that info and it takes a week/month to get then that code is useless for that week/month.

I think admin is looking at something like this.

for agument sake lets say you have code in lines, it starts at 1 and goes in order.
The numbers are just to represent a flow, not actual lines of code.

so we do

Code: Select all

1
2
3
4
5 at 5 it says oi your in combat, go do code at 55
55
56
57
58
59 ok out of combat go back to what ever you were doing before
5
6
7
8
9 need repairs go to 71
71
72
73
74
75 ok finished repairing, back to what you were doing
9
10 in combat go to 55
55
56
57
58 your dead, go to 89 to resurect
89
90
91 ok we are back on our feet, back to what you were doing
10 need repairs now go to 71
72
73
74 ok finished repair back to where you were
10
11
12
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#13 Post by BillDoorNZ » Thu Jul 26, 2012 9:31 pm

yep, I get how that is theoretically supposed to work, I was thinking more implementation :)

for example:

Code: Select all

function StateManager:run()
	if( #self.stateQueue > 0 ) then
		self.stateQueue[#self.stateQueue].update();
	end
end
to me, this is saying that the update method on the last queued item is called. In admins example, this would be the TEststate class:

Code: Select all

function Teststate:update()
	-- Check if there is lootable bodies in range, if so, loot them.

	-- If not, locate a nearby body and move to it

	-- If neither of the above, pop the state.
end
which is all well an good, until you think about what you are going to need to be doing.

if I have a GoRepairMyEquipmentState:

Code: Select all

function GoRepairMyEquipmentState:update()
  Build a path to a repairer
  run there
  repair the equipment
  done
end
Now, in order for that to be interrupted we have to either:

(A)
in my GoRepairMyEquipmentState:update function, I need to check for combat etc which is severly limiting - what if I dont' check for debuffs I need to remove while I'm running and the bot dies!!?

Code: Select all

function GoRepairMyEquipmentState:update()
  Build a path to a repairer
  if (I'm in combat) then 
    StateManager:push(CombatState);
    return;
  end;
  run there
    --while running, check for combat
  repair the equipment
   --check for combat
  done
end
or (B)
make the states stateful (unfortunate names).

Code: Select all

function GoRepairMyEquipmentState:update()
  if (I'm at the repairer) then
    if (I am not selling yet) then
      OpenDialogAndStartSelling()
    else
      FinishSelling();
      set my state to COMPLETE and remove me from the state Q please!!!
    end
  elseIf (I Am Not On The Path Previously Built) then
    Build a path to a repairer
    save path;
    FaceDirectionOfNextWaypoint;
    StartRunningForward
  else
    CheckProgress
    FaceDirectionOfNextWaypoint;
    StartRunningForward
  end;
end
So we'd end up creating a heap of state machines (presumably thats why they're called state classes?).

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#14 Post by Administrator » Fri Jul 27, 2012 1:19 pm

Well, how about we add another function to states, to handle events? The base function could check for the event that you have been attacked and start a combat state for you. On states that you obviously don't want this for (ie, a combat state; no need to create an infinite number of them every battle), you would, of course, disable this.


In your example for repairing, it would make much more sense to use multiple states that each handle their own section. One to go where it needs to, one to handle the dialog options and repair, and one to run back. The movement isn't going to be too problematic for interruptions. Just walk back to the last waypoint after leaving a combat state, much like how the RoM bot handles this. The actual repairing would just mean you need to restart from the beginning by opening dialog with the vendor. Again, I don't expect this would be too hard.

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#15 Post by lisa » Sat Jul 28, 2012 6:16 pm

Ok I think I have my head around this now.
Basically it uses a table to tell the bot what it should be doing and it always performs the last entry in the table, which is the last to be inserted so the most recent. Once that task is done it removes that entry and then does the now last entry in the table.

So this is how I see it working, at this stage.

In the update() you would need to monitor absolutely everything and it will decide if the current state needs to change.

Easiest way I see of doing this is to have an argument for the update function which tells it what state it is in and in the function to have things that can be overwritten. If you are in combat state you don't want to just start going to repair your gear mid fight.

So in every single state there needs to be a call for the update function, I was thinking that combat wouldn't need this as you only want to leave the combat state early under extreme circumstances but if the update checks for only specific things depending on the current state then it will be fine.

So as I see it each state will end up having to be it's own loop anyway to keep it in that state until that task is complete, either that or it runs through the state function once and then runs update() which may or may not run that state again, so no loops at all.

If I have my head around this correctly then it really needs to be well organised before being written. Need to decide when to change states and when not to, also need to decide if to remove states because you don't want to return to that state.
If in combat and decide you can't win the fight and want to run away, need to remove the combat state from the queue and then run away. If you try to run away and are successful it will then go into the combat state again which you presumably are out of combat.
I guess the update function could check if in combat and if not then remove the combat state, so the update() should be the only part of bot to actually remove the states from queue, that way things won't get messed up.
Could have a second arg in the update that says to remove current state from the queue but it wouldn't be the usual way to check for removing.


So am I close to what you were thinking?

--=== Added ===--
I guess instead of using an arg to say current state/previous state you could just check the last state in the table, I just figured passing an arg would be less PC usage then checking the table but stateQueue[#self.stateQueue] would do the same and not require an argument.


Did you want addresses in same format as in RoM?
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#16 Post by lisa » Sat Jul 28, 2012 9:48 pm

For the update this is the kind of flow that I see working.

Code: Select all

Check if in loading screen, if so then wait until not loading screen.
Check HP%, this state will decide to heal or not, this state will have code for run away or not
Check if in combat, this state will fight back since not running away.
Check objectives: 
1. Kill; not in combat so look for mob and check repair status, is there a level objective?
2. Event; do we need to travel to the event location or just wait for specified time?
3. Travel to loc; I am prefering to use a set of coords (roads) for each map and calculate best route as opposed to waypoint files.
4. Inventory status; do we need to go sell items to empty bag space, maybe just post them on auction

--=== Check HP% (heal or not), this code has run away or not in it ===--
Local of time used and cool down
Check HP% and decide to use heal or not
Check HP% compared to target HP%, run or not?
Call update ()

--=== Check if in combat, fight back since not running away ===--
Local with auto attack in use or not, hopefully find an address early after release
Locals with each skill cool down and last time used, populate table with skills available
Use skills in that table, can’t remember if there is a global cooldown or not
Call update ()

That sort of thing anyway.

--=== Added ===--

As I sit here writing this I find myself wondering if the states are needed for this type of code, so I must have the wrong idea of what you are after lol
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#17 Post by lisa » Sat Jul 28, 2012 11:16 pm

yeah I am trying to work out how states are better.

Example.
Currently farming mobs.

Just went into loot state and on the way to looting you get attacked by a mob, so need to go to combat state.
Easy enough but there has to be something somewhere that is monitoring if you are in combat or not, otherwise every single state would have to have code for constantly monitoring everything anyway.
So there has to be a function somewhere which is constantly monitoring everything and it decides to add another state or not and then when it adds states it has to tell bot to change what it's doing


--=== Added ===--
If the idea is to be able to keep track of what you were doing to be able to go back to doing it you still can by using the table the same way.

-- we are not in combat
if objectives[#objectives].name == "combat" then
table.remove(objectives,#objectives)
else
-- do what ever objectives[#objectives].name says to do
end

--we are in combat so fight back
if objectives[#objectives].name ~= "combat" then
table.insert(objectives, name = "combat")
-- start fight
else
-- keep fighting
end


Maybe I just need to understand the states more.
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#18 Post by BillDoorNZ » Sun Jul 29, 2012 5:07 am

My understanding of Admins thoughts are that the bot would be able to inject/add new states in reaction to events as they occur. The point of having the state remove itself is an OO tennet, in that the state knows only about itself and is responsible for itself - i.e. only the state knows when it is finished - otherwise the bot has to know how to determine if a state is finished in which case, it has to know about EVERY state...which is means it is tightly-coupled and a PITA to maintain.

The 'table' is just a LIFO Queue (Last In First Out). You push a state on, and its the only state that is updated. Once it is removed, the next remaining state is the only one that is updated and so on.

What will need to happen is that the bot has to control the updating of things like the player, pawns etc and use that to driive events and the like. You don't want any of the other states updating it due to speed issues. When i think of the number of times that the CObjectList is created in the rombot it makes me cringe. Ideally it should get updated once per loop and everything should work all fine and dandy and efficient like :)

That way the bot can monitor for things like the player being attacked / aggro'd etc and add states as necessary.

The combat state shouldn't be any different, it should just be fast. Check what it needs, decide what to do and start doing it, then check its interal state each time its update() is called until its done. So, short and simple and called as many times per second as the bot can handle :)

In the case where you want to run away, that state will be added by the combat state after the combat state removes itself...the runaway state man re-add the combat state if it cant run away :)

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#19 Post by Administrator » Sun Jul 29, 2012 2:33 pm

Lisa, I think you are just overthinking it. But, to be fair, I only gave limited information on what should have been a pretty vast topic. I don't blame you for getting confused. I've added some code and made it a bit more of a real-world example. Still lacks a lot, of course, but should help you to understand how this could work.

I added an event queue to the statemanager. The statemanager will attempt to pass off events to the current state. If they state doesn't consume the event, the statemanager will have a chance at using it. Any unused events will be flushed each loop.

So, if you are in the waypoint state and you are under attack (this will be handled in the main loop or something; you will not have to do this in each state), a combat event will get pushed into the event queue. The statemanager will then pass that event to the waypoint state to handle. The waypoint state gladly accepts it as a valid event and pushes a combat state. Now, the combat state will take over processing until it is finished and then pop itself. Since the combat state does not respond to combat events, it will not push new combat states on top of itself.

See the attached example. Pressing C will fake a combat event, and Q send a quit event. You will need to use the attached copy of MicroMacro as I've added another C function to improve the efficiency of input.
Attachments
gw2.zip
GW2 example
(2.91 KiB) Downloaded 340 times
micromacro.zip
MicroMacro 1.02b4
(674.13 KiB) Downloaded 349 times

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: GW2 bot goals & ideas

#20 Post by lisa » Sun Jul 29, 2012 5:53 pm

k I'll have a look but I think what got me the most was you said you didn't want any loops anymore, but the states themselves seem to be actual loops.
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests