GW2 bot goals & ideas

http://www.guildwars2.com
Message
Author
BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: GW2 bot goals & ideas

#21 Post by BillDoorNZ » Sun Jul 29, 2012 6:21 pm

hehe...indeed :)

tho, the states themselves technically arent loops...they a run, or a sequence...its just that they happen to be called repeatedly from a loop ;) all very droll, but it is in fact an important point of differences as it means the states are short running and only handle the stuff they should - they don't get bogged down with looping etc.

This will cause problems of course, in that sometimes you will want a state to loop / block / wait until an event occurs. But thats just a paradigm shift:

e.g.

old style

Code: Select all

function SellingState:update()  --player is already at the merchant and needs to sell stuff
  while (sellDialogNoOpen) do
   player:target(merchant);
   player:attack();
  end;
end;
possible new style:

Code: Select all

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

SellingState = class(State);

SELLSTATE_STARTED = 0;
SELLSTATE_OPENING_DIALOG = SELLSTATE_STARTED+1;
SELLSTATE_DIALOG_OPENED = SELLSTATE_OPENING_DIALOG+1;
SELLSTATE_COMPLETE = SELLSTATE_DIALOG_OPENED+1;

function SellingState:constructor()
	self.name = "Combat state";
	self.lasttime = os.time(); -- We're going to just fake combat with time.
	self.dialogIsOpen = false;
	self.state = SELLSTATE_STARTED;
end

function SellingState:update()
	if (self.State == SELLSTATE_STARTED) then
		if (merchant is close enough) then
			self.State = SELL_OPENING_DIALOG;
		else
			stateman.pushState(moveToMerchant);
		end;
	elseif (self.State == SELL_OPENING_DIALOG) then
		player:target(merchant);
		player:attack();
		
		if (dialogIsOpen) then
			self.State = SELLSTATE_DIALOG_OPENED;
		end;
	elseif (self.State == SELLSTATE_DIALOG_OPENED) then
		if (player:sellMyLootz()) then
			self.State = SELLSTATE_COMPLETE;
			stateman.popState();
		end;
		
	elseif (self.State == SELLSTATE_COMPLETE) then
		stateman.popState();
	end;
end

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

Re: GW2 bot goals & ideas

#22 Post by Administrator » Sun Jul 29, 2012 6:49 pm

lisa wrote: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.
Well, there is the main loop, but other than that, no. If the states themselves contained loops, it makes it difficult to execute overhead code. Instead, we hacked things into place with RoM. As BillDoorNZ pointed out, things like parsing the object list were a complete mess and was sometimes called multiple times within what should have been one update cycle.

Now, we aren't necessarily eliminating loops entirely, just not long-running ones. So, a for loop would definitely be acceptable. A short while loop (as in, one that executes in less than a second) would be fine, too. But throwing the whole combat sequence in one loop would just make it a big mess again.

I understand that if you are not familiar with object-oriented code, it can be a bit confusing at first, but you'll catch on quick and I think find it to be much cleaner and easier to manage.

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

Re: GW2 bot goals & ideas

#23 Post by lisa » Sun Jul 29, 2012 7:31 pm

Ok So main() basically keeps calling the current state, main() is a loop, each state has the code required to do their job and once their job is done it removes itself from the queue so when main() calls the current state on the next loop it will be something else. The states themselves arn't trapped in long loops but rely on main() to call them again if needed on the next main() loop.


So in main will be a few checks, like "in combat" as that will need to change regardless of what state is the current state (except in combat or running away).
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: 5176
Joined: Sat Jan 05, 2008 4:21 pm

Re: GW2 bot goals & ideas

#24 Post by Administrator » Sun Jul 29, 2012 7:37 pm

Yeah, that's pretty much the idea. We'll try to keep the main function as clean as possible and use events to pass information around, but all those fine details will be worked out when the time comes.

Let me know if there is something you didn't understand in the example I provided.

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

Re: GW2 bot goals & ideas

#25 Post by lisa » Sun Jul 29, 2012 11:00 pm

I added this

Code: Select all

function StateManager:handleEvent(event)
	if( event == "quit" ) then
		self.running = false;
		return true;
	end
	if( event == "combat" ) then
		printf("Switching to combat.\n");
		stateman:pushState(CombatState());
		return true;
	end
	if( event == "loot" ) then
		printf("Switching to loot.\n");
		stateman:pushState(LootState());
		return true;
	end
	if( event == "repair" ) then
		printf("Switching to repair.\n");
		stateman:pushState(RepairState());
		return true;
	end	
end

Code: Select all

Current state:  Waypoint state
Waypoints advanced to #2
Waypoints advanced to #3
Waypoints advanced to #4
Switching to combat.
1
2
3
4
Ending combat.
Switching to loot.
1
2
3
4
Finished looting.
Switching to repair.
1
2
3
4
Finished repairing.
Waypoints advanced to #5
Waypoints advanced to #6
Waypoints advanced to #7
Waypoints advanced to #8
Stopping execution.
Keypress C initiated the combat, at the end of combat it initiated loot(popped combat), at the end of loot it initiated repair(popped loot), at the end of repair it popped it and went back to waypoints.
Attachments
gw2 V4.zip
4 seconds in each state once combat is initiated.
(3.99 KiB) Downloaded 230 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

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

Re: GW2 bot goals & ideas

#26 Post by Administrator » Sun Jul 29, 2012 11:55 pm

No. Inheritance means you would really only need it in one place. I didn't include that in the example as it would have just confused you.

I've also considered setting and unsetting callbacks. Still not perfect. Either way, there's still no way around describing exactly which events are handled by different states.

Edit: Just so this doesn't seem out of place, this post was directed at a question which has since been edited out.

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

Re: GW2 bot goals & ideas

#27 Post by lisa » Mon Jul 30, 2012 12:56 am

yeah I pretty much answered my own question, eventually lol
As I have it now all the pushes are done by the state manager handleevent, function StateManager:handleEvent(event), so basically anytime there is a push event it uses that pushed state, which is how I figure it is meant to work.

Ok so
state:constructor() is called when the state is first run.
state:update() is repeated until the state is changed, as in it is repeatedly called.
statemanager:handleEvents() will execute StateManager:handleEvent(event) when pushevent is called with a new state, so that code is only done once,
State:handleEvent(event) will do code in the current state when an event is pushed, pushevent() not sure if it aswell as the statemanager or if it overrides the statemanager, i'll do tests.

--=== test results ===--
It "should" do the statehandleevent and if no state handleevent then it does the staemanager handleevent but there might be an issue with this.

I have tested with this.

Code: Select all

		stateman:pushEvent("repair");
		self.first = true
		stateman:popState();
So it does the pushEvent but it doesn't do the code in the state handleevent, but if I remove the popstate it does do it, so there is an issue there with timing I guess. It does the state handleevent in what ever the current state is, not loot anymore.

without the popstate it looks like this

Code: Select all

4
Finished looting.
loot code
1
2
3
4
Finished repairing.
back at looting
probably not an issue really as you wouldn't need to call code int he handleevent of the current state as you could just do the code without it.

Hmm needs more thought, I'll get back to you on it.

This kind of reminds me of how addons in RoM are handled.
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

#28 Post by lisa » Mon Jul 30, 2012 1:55 am

I found this interesting so thought I'd post it

Code: Select all

	if timepassed > 3  then
		-- End Loot.
		if self.add == 0 then 
			printf("Finished looting.\n");
			stateman:pushEvent("repair");
			self.first = true
			self.add = 1
		else
			-- done after repair is popped
			stateman:popState();
		end
	end
end

-- Handle events
function LootState:handleEvent(event)
	if event == "repair"  then
		printf("loot code\n");
		stateman:pushState(RepairState());
		return true;
	end
end
So when it gets to timepassed > 3 it does the pushevent for "repair" which is in the same state as being to pushstate repair, once repair is popped it comes back to the loot state and does the code here
-- done after repair is popped.
So you could do code thats is ONLY done after it comes back from another state, something I will keep in mind 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

#29 Post by lisa » Mon Jul 30, 2012 2:21 am

V5
Ok added more descriptive prints so you can see more easily how it is working.
keypress C to initiate Combat
keypress R to initiate Repair

end of Combat (popped) initiates Loot
end of Loot (popped) initiates Repair
end of Repair just pops

So prints look like this.

Code: Select all

Waypoints advanced to #2
Waypoints advanced to #3
Waypoints advanced to #4
Keypressed C
Switching to combat.
combat timer: 1
combat timer: 2
Keypressed R
Switching to repair.
repair timer: 1
repair timer: 2
repair timer: 3
repair timer: 4
Finished repairing.
combat timer: 6
Ending combat, popping and pushing Loot.
Switching to loot.
loot timer: 1
loot timer: 2
loot timer: 3
loot timer: 4
Finished looting, popping and pushing Repair.
Switching to repair.
repair timer: 1
repair timer: 2
repair timer: 3
repair timer: 4
Finished repairing.
Waypoints advanced to #5
Waypoints advanced to #6
Stopping execution.
So yeah basically I think I have it worked out now lol
Atleast part of it anyway ;)
Attachments
gw2 V5.zip
(4.12 KiB) Downloaded 219 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

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

Re: GW2 bot goals & ideas

#30 Post by Administrator » Mon Jul 30, 2012 2:41 am

Now that you understand it better, don't you think it will be much easier to work with?

Tomorrow I'll try to take a look at your example and see if there's any problems or improvements to be made.

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

Re: GW2 bot goals & ideas

#31 Post by lisa » Mon Jul 30, 2012 2:53 am

yup on a roll now.

I added a random number it combat to proc a heal state, simulating needing heals.
In the heal state I put a handleevent to ignore combat.

Code: Select all

-- Handle events
function HealState:handleEvent(event)
	if event == "combat"  then
		printf("Ignoring combat event, healing.\n");
		return true;
	end
end
I think it would be best if you make a googlecode for this, atleast then you have the admin rights over it =)

I added a counter of how many times the state is called and I am amazed at the amount of times per second.

Code: Select all

combat timer: 1
combat timer: 2
combat timer: 3
combat timer: 4
combat timer: 5
combat timer: 6
combat timer: 7
combat timer: 8
combat timer: 9
combat timer: 10
combat timer: 11
combat timer: 12
combat timer: 13
healing, did combat code 837 times.
Obviously not much for it to be doing to slow it down but still, 837 times in 13 seconds.
Attachments
gw2 V6.zip
(4.68 KiB) Downloaded 211 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

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

Re: GW2 bot goals & ideas

#32 Post by Administrator » Mon Jul 30, 2012 3:06 am

I think it would be best if you make a googlecode for this, atleast then you have the admin rights over it =)
I will when it comes to actually writing code for the bot. For the time being, we can only discuss ideas and weed out any potential problems in preparation for August 25th.

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

Re: GW2 bot goals & ideas

#33 Post by lisa » Mon Jul 30, 2012 4:01 am

ok so next part, how are we going to do things like decide what to do?

a waypoint file system or a list of commands to push states?

I personally like the idea of being able to tell it to go to ## coords and kill mobs there until lvl # but monitor time for going to do a nearby event and after the event return to killing those mobs.

Maybe a system that loads states and it of course starts with the last state loaded.

Code: Select all

somerandoname = {
{type = "travel",X=45,Z=2022},
{type = "kill", end = "lvl", value="12"},
{type = "kill", end = "time", value ="30"},
{type = "travel",X=909,Z=45},
{type = "event", time ="4:30",name="apple event"},
}
5. go to X Z
4. kill mobs until lvl 12
3. kill mobs for 30 minutes
2. go to X Z
1. do the apple event at 4:30(so monitors time and pushes event at 4:30)

So starts at the
1. add monitor in background for time.
2. once at those coords
3. kill mobs for 30 mins.

Maybe even just a console adition

Code: Select all

gw2/main type:kill end:lvl value: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

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

Re: GW2 bot goals & ideas

#34 Post by Administrator » Mon Jul 30, 2012 11:56 am

I'm not really sure. That is actually an interesting question. I think, perhaps we should just start with simple waypoints, but then can easily just insert another state that would serve the purpose of deciding whether or not it should move to a different location, complete a nearby event, run for repairs, or whatever else.

Speaking of events, I think we should maybe change the events passed around in the code to tables. This way you could include more specific information, such as include the name of the waypoint script to load when pushing a waypoint event.

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

Re: GW2 bot goals & ideas

#35 Post by BillDoorNZ » Mon Jul 30, 2012 2:19 pm

Yup, start simple, see how it goes, then work up to a big refactoring / restructure to handle things better once ya know all of the gotcha's etc.

You also need a lot of info from the bot for some of those decisions (which isn't there as yet anyway as its still very early days in discovering the mem locations etc).

You'd need a large set of established and tested map nodes before you could do any generic movement stuff anyway. For me some of the issues are going to be things like:

When in a movement state, we get combat interrupted so we push a combat state on, which, in dealing with the mob, moves the bot around a lot. How does the bot then get back on track - especialy given the vaguaries of terrain / objects in the way etc. Poping the combat state back off the stack will just leave the bot with a movement waypoint that it can't get back to.

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

Re: GW2 bot goals & ideas

#36 Post by lisa » Mon Jul 30, 2012 6:23 pm

Administrator wrote: think we should maybe change the events passed around in the code to tables
I like this idea.
BillDoorNZ wrote:Poping the combat state back off the stack will just leave the bot with a movement waypoint that it can't get back to
I still like the idea of making up map sets of coords, no need to waypoints, it will take time and effort to make these though but once they are done they don't need doing again. We didn't actually fully complete that project though, so would need to finish it before even doing the maps.

If we went this way then it's not an issue as the moving code will recognise it was inturupted by combat and then remap it's route to the same coords it was going to previously.

If we are using a waypoint system then it can recognise it was in combat the same way and look for a closer waypoint to use. It will only be a pain if you dropped down a cliff edge as you can't get back up.
BillDoorNZ wrote:You also need a lot of info from the bot for some of those decisions (which isn't there as yet anyway as its still very early days in discovering the mem locations etc).
From what I saw in Beta the events were on a timer, so just need the time the event starts and the rest is like a waypoint, go kill this or go click that.
The addresses also seemed easy to find compared to other games I have worked on previously, less pointers. I had already found working code for hp, maxhp, X, Z, Y, if target, "F" indicator, 2 player direction indicators, 2 camera direction indicators.
I have a better knowledge of CE now and I am finding it easier to find addresses, only thing I still can have issues with is the static address + offset to be reliable.

I even noticed the other day that the NPC choices in rom are in static addresses when the NPC window is open. I didn't bother to loot into it further as we don't need any more addresses in RoM to find every patch and that info is gotten from in game functions anyway ;)
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

#37 Post by lisa » Mon Jul 30, 2012 7:09 pm

Next thing to concider.
What states do we want and what do they do.

basic easy states, do a job and once done pop themselves:
npc interaction (once at the npc location)
travel, moving from 1 place to another (waypoint usage)

Reactive states, pushed from an update loop:
combat
healing, or part of combat?
object interaction "F", includes looting

More complex controller states, that push other states as needed:
kill: looks for mobs and pushes combat state targeting mob, only pops itself after specific time or lvl has been reached. Also monitors repair and vendor and pushes them as required.
repair, pushes travel and NPC interaction
vendor, pushes travel and NPC interaction(sell junk in bags)
questing, pushes travel and kill states when required

events (To Be Determined)

Any thoughts ?


After creating all the state files I decided it was a pain to add all the names to main.lua so I did this.

Code: Select all

local subdir = getDirectory(getExecutionPath() .. "/classes/states/");
for i,v in pairs(subdir) do
	include("classes/states/"..v);
end
just adds any files in there, I could probably do a string.find for .lua to make sure no dummy.txt files are added, prob not needed though.

Ok next bit, the calling of pushing a state, not overly happy with it atm.

Code: Select all

	if( event == "repair" ) then
		printf("Switching to repair.\n");
		stateman:pushState(RepairState());
		return true;
	end
So for every event we need to add in code like this, I am trying to work out a way to do it so the event does it without having to repeat the code for each state.
A table comes to mind as the easiest way I can think of, obviously the event data is still added but when it comes to actually doing the code it will be much simpler.

Code: Select all

function StateManager:handleEvent(event)
	for k,events in pairs(events) do
		if( event == events.name and self.stateQueue[#self.stateQueue].name ~= event ) then
			print("Switching to "..event);
			stateman:pushState(events.function);
			return true;
		end
	end	
end
I am sure there is probably a better way though.

Have this atm,

Code: Select all

function StateManager:handleEvent(event)
	if( event == "Quit" ) then
		self.running = false;
		return true;
	end
	for k,events in pairs(events) do
		if( event == events.name ) then
			print("Switching to "..event);
			stateman:pushState(events.func);
			return true;
		end
	end  
end
each state has this at the bottom, name differs for each state of course.

Code: Select all

table.insert(events,{name = "Vendor", func = VendorState()})
trouble is that it does the constructor code when MM starts the script, so onload as such. probably not ideal.

events table looks like this when main.lua starts.

Code: Select all

table: 006E5970
1:      table: 00714CC8
        name:   Combat
        func:   table: 00714D18
                lasttime:       1343698066
                name:   Combat state
                prevtime:       0
                count2: 0
                count:  0
                newbattle:      false
2:      table: 006E43F8
        name:   Events
        func:   table: 006E4448
                prevtime:       0
                lasttime:       1343698066
                name:   Event state
3:      table: 006E3AA0
        name:   Heal
        func:   table: 006E3AF0
                prevtime:       0
                lasttime:       1343698066
                name:   Heal state
4:      table: 007194C8
        name:   Kill
        func:   table: 00719518
                prevtime:       0
                lasttime:       1343698066
                name:   Kill state
5:      table: 006E32C8
        name:   Loot
        func:   table: 006E3318
                prevtime:       0
                lasttime:       1343698066
                name:   Loot state
6:      table: 006E4380
        name:   Npc
        func:   table: 006E43D0
                prevtime:       0
                lasttime:       1343698066
                name:   Npc state
7:      table: 007197C0
        name:   Object
        func:   table: 007198D8
                prevtime:       0
                lasttime:       1343698066
                name:   Object state
8:      table: 006E3A28
        name:   Quest
        func:   table: 006E3A78
                prevtime:       0
                lasttime:       1343698066
                name:   Quest state
9:      table: 006E4718
        name:   Repair
        func:   table: 006E4858
                prevtime:       0
                lasttime:       1343698066
                name:   Repair state
10:     table: 006A37B8
        name:   Travel
        func:   table: 006A3B28
                prevtime:       0
                lasttime:       1343698066
                name:   Travel state
11:     table: 00719AB8
        name:   Vendor
        func:   table: 00719B08
                prevtime:       0
                lasttime:       1343698066
                name:   Vendor state
12:     table: 006E31B0
        name:   Waypoint
        func:   table: 006E3200
                name:   Waypoint state
                lasttime:       1343698066
                index:  1
                waypoints:      table: 006E54C0
                        1:      1
                        2:      2
                        3:      3
                        4:      4
                        5:      5
                        6:      6
                        7:      7
                        8:      8
It still does the code fine but the constructors are all done at startup, maybe not so bad after all after more thought.

Code: Select all

Current state:  Waypoint state
Waypoints advanced to #2
Waypoints advanced to #3
Waypoints advanced to #4
Keypressed N
Switching to Npc
Npc timer: 6
Waypoints advanced to #5
Waypoints advanced to #6
Keypressed N
Switching to Npc
back at Npcing
Npc timer: 1
Npc timer: 2
Npc timer: 3
Npc timer: 4
Waypoints advanced to #7
Waypoints advanced to #8
Waypoints advanced to #1
Keypressed N
Switching to Npc
back at Npcing
Npc timer: 1
Npc timer: 2
Npc timer: 3
Npc timer: 4
Waypoints advanced to #2
Waypoints advanced to #3
Waypoints advanced to #4
Waypoints advanced to #5
Waypoints advanced to #6
gw2 V8.zip
(9.46 KiB) Downloaded 220 times
V 8
keypresses
C,T,N,V
(Combat,Travel,Npc,Vendor)
combat will randomly push heal and combat does max 10 seconds of actual combat not including healing time.
Also in main.lua if you uncomment --update() it has real usage for RoM, just make sure 1 RoM client is running. It will monitor HP and in combat flag.
If hp drops below 70% it will push heal state, if in combat it will push combat state, combat state will still randomly push heal state aswell.



could do this I guess which will refresh the constructor when the state is pushed

Code: Select all

			stateman:pushState(events.func);
			self.stateQueue[#self.stateQueue]:constructor();
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

#38 Post by lisa » Tue Jul 31, 2012 1:15 am

This version is ONLY for use with RoM, just 1 client.
It will monitor combat and healing and pop/push states accordingly.

It took me a bit of fidling to get the 2 states working properly, mainly because I used pusheevnt instead of pushstate and created an infinite loop that drove me nuts trying to find lol

But it is a real working example of the state usage, it just does some prints to MM.
Best tested with a healer type with 2 sets of gear, switching gear will get your HP % to drop, then can just heal up.

That's about me for a bit, I'll wait to hear your opinions on the things I posted =)
Attachments
gw2 V8 rom.zip
(9.32 KiB) Downloaded 209 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

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

Re: GW2 bot goals & ideas

#39 Post by Administrator » Tue Jul 31, 2012 2:28 am

All looks pretty reasonable, Lisa. Good work. You're really getting the hang of this.

Here's something I was thinking of. You can put most generic event checks in State:handleEvent(). Then, in the children (combat, loot, waypoint, etc.), do this:

Code: Select all

self.parent.handleEvent(self, event);
This will cause the child state, such as combat, to call State's handleEvent function, but on itself.

So, we can just expand the hierarchy. Have one tree for fighting type states that will inherit event handlers for healing and stuff like that while capturing and ignoring combat events. The other tree would properly respond to combat events and the like.

So, something like:
Combat types: combat, heal
Non-combat types: travel, vendor/NPC, rest

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

Re: GW2 bot goals & ideas

#40 Post by lisa » Tue Jul 31, 2012 3:29 am

I'll have to play around with it to see what you really mean but I do like how it works atm, if the current state has code to handle the event then that code is done, otherwise the statemanagers code gets done.

To me this means that if I am in combat state and we get a call to repair I can stop the pushstate for repair until out of combat and then do it.
otherwise you will get an overflow effect of pushing states.
example.
In combat, items need repairing
pushes repair state but still in combat pushes combat, this would get repeated until out of combat. So you could have in the state queue
repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/
repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/repair/combat/
It will go repair and then pop the next combat and then think about repairing and repeat, deffinately not desired. I actually had this in part of my testing. But with the handle event code in the current state you can stop the state from being pushed and just keep fighting.
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 1 guest