[Patch] Bugs and suggestions

Runes of Magic/Radiant Arcana (http://www.runesofmagic.com)
Post Reply
Message
Author
User avatar
memcpy
Posts: 30
Joined: Fri Jun 05, 2009 8:48 am

[Patch] Bugs and suggestions

#1 Post by memcpy » Thu Jun 18, 2009 6:30 pm

1. Forcing waypoints/wandering via commandline

Code: Select all

# rom/bot.lua path:foo retpath:retfoo
the svn implementation is okay. you didn't copy my code. went your own way. thats okay but generated some bugs. i fixed them.

new in my patch: if you force the bots path but did not force the return path, my script will now look for a designated returnpath xml. this has to have some prefix like "ret_". you can set the prefix by a new option in the settings.xml called RETURNPATH_PREFIX. and yes this even works for wandering. so if you enter path:wander it will look for "ret_wander.xml". this way you can even specify a retpath for your wanderspot.

i found this real handy if you bot around with like 10 different waypoints a day. easy switchable.

Code: Select all

example:
# rom/bot.lua path:bears
-> retpath not forced -> will look for ret_bears.xml in waypoint directory
problem: i don't know if there is a more perfomant way to do the filesystem check. i found io.open, it works, but there may be a more elegant way to solve this. feel free to change.

Code: Select all

@bot.lua:164
	elseif( forcedPath and io.open(getExecutionPath() .. "/waypoints/" .. settings.options.RETURNPATH_PREFIX .. forcedPath .. ".xml", "r") ) then
		-- If our Path was forced and the designated returnpath xml is in place use it
		__RPL:load(getExecutionPath() .. "/waypoints/" .. settings.options.RETURNPATH_PREFIX .. forcedPath .. ".xml");
2. to be continued...

changes where made to the svn by elverion. just grab the newest svn and you are set
Last edited by memcpy on Fri Jun 19, 2009 5:17 am, edited 1 time in total.

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

Re: [Patch] Bugs and suggestions

#2 Post by Administrator » Thu Jun 18, 2009 11:42 pm

So you are suggesting the return path prefix to automatically suggest a return path when not set? That's actually an interesting idea. Hadn't thought of that. However, I did have an idea (which obviously was not implemented at this time of this patch) of a whole different system that will be implemented in the future.

The basic idea is that all of that information will be moved into the waypoint scripts themselves. This makes for easier distribution and setup as each waypoint script will have a paired return path, so it seems kind of redundant to have to switch both of them in the profile rather than act as a pair. Simply put, the <waypoints> tag in the XML will contain the name of the return path.

This will be combined with others' idea of moving extra options into specific waypoints (ie. one user suggested setting the COMBAT_DISTANCE into the waypoint XML). This patch was very light on changes to the actual bot (as you've probably noticed) and was focused entirely around the harvesting system. The changes to the bot itself are unfinished.
elverion, if you pick up someones ideas and decide to implement them, please add some credits - thanks
Don't take it the wrong way. I'm a busy person and get sidetracked with other projects and work. I'm just now getting home at 11:30pm from working all day. I appreciate all user contribution no mater how big or small. This bot truly is a work of the community, not myself, and I realize this.


EDIT: I've committed a few of your patches to SVN, and given you credit. I have stripped the return path prefixing for the time being. I would like to hear you reasons for preferring this method other my suggestion above. The problem I see with your method is that it would break when users share waypoints. Not always, but sometimes (when one user prefers one prefix over another). Obviously, if both users do not have the same prefix set, it causes problems. In my system, they just drop both scripts into the waypoint folder, and it works reguardless.

Also, I have found a minor bug in your code. The change is on SVN already. It is near line 176.

Code: Select all

cprintf(cli.green, language[1], __RPL:getFileName());
If the return path is not set (which is not required), it will result in an error because of a nil value. This is the fix I made:

Code: Select all

	if( __RPL:getFileName() ) then
		cprintf(cli.green, language[1], __RPL:getFileName());
	end

User avatar
memcpy
Posts: 30
Joined: Fri Jun 05, 2009 8:48 am

Re: [Patch] Bugs and suggestions

#3 Post by memcpy » Fri Jun 19, 2009 5:16 am

Administrator wrote:The basic idea is that all of that information will be moved into the waypoint scripts themselves. This makes for easier distribution and setup as each waypoint script will have a paired return path, so it seems kind of redundant to have to switch both of them in the profile rather than act as a pair. Simply put, the <waypoints> tag in the XML will contain the name of the return path.
interesting. i had a similar idea while working on the prefix variant. my idea would combine both the waypoints and the returnpath waypoints in one file. so you have <waypoints>...</waypoints> and <returnpath>...</returnpath> in one xml file. but of course this would change the createpath.lua drastically and i didnt want to code such a huge change just to be rejected ;)

anyway, your idea with linking both files a la <waypoints returnpath="foo"> sounds a little bit more dynamic then mine. i think. not quiet sure yet, have to go through some scenarios in my mind.

Code: Select all

   if( __RPL:getFileName() ) then
      cprintf(cli.green, language[1], __RPL:getFileName());
   end
i actually noticed that too and changed it in my code. don't know what happened. think i screwed up the .rar bringing in an old .patch :oops:
Administrator wrote:Don't take it the wrong way. I'm a busy person and get sidetracked with other projects and work. I'm just now getting home at 11:30pm from working all day. I appreciate all user contribution no mater how big or small. This bot truly is a work of the community, not myself, and I realize this.
i don't. it's just a friendly reminder. don't get me wrong i think most people here are as busy as you are (at least i am). got job, kids, family, friends - but i like this project and like putting some effort in it in the evening hours. and it really takes you minimum time to track the names in a .txt of people who contributed.

d003232
Posts: 1252
Joined: Wed Jun 03, 2009 4:27 pm

Re: [Patch] Bugs and suggestions

#4 Post by d003232 » Fri Jun 19, 2009 5:20 am

memcpy wrote:you can set the prefix by a new option in the settings.xml called RETURNPATH_PREFIX. and yes this even works for wandering. so if you enter path:wander it will look for "ret_wander.xml". this way you can even specify a retpath for your wanderspot.


Independend from which soultion will come, I would prefere 'suffixes' instead of 'prefixes'. Simply because of the sorting of my waypoint files by names in my folder. If I use suffixes I can very fast see for which waypoint files I have return files.
The RoM Bot Online Wiki needs your help!

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

Re: [Patch] Bugs and suggestions

#5 Post by Administrator » Fri Jun 19, 2009 5:32 am

interesting. i had a similar idea while working on the prefix variant. my idea would combine both the waypoints and the returnpath waypoints in one file. so you have <waypoints>...</waypoints> and <returnpath>...</returnpath> in one xml file. but of course this would change the createpath.lua drastically and i didnt want to code such a huge change just to be rejected
True. It actually brings more problems than just that. First, it is necessary in XML to have one, and only one, outer limit tag. That means that this is not valid:

Code: Select all

<waypoints>
  <waypoint .... />
</waypoints>
<returnpath>
  <waypoint .... />
</returnpath>
It is invalid because there are two outer limit tags ('waypoints' and 'returnpath'). This means the waypoint script format would need to change drastically (resulting in compatibility issues), and it would take a lot of effort rewrite createpath.lua and the waypoint loading functions to accommodate for this.

The other problem is that it would require you to re-create your return path every time you make a new waypoint script. It would be annoying. Most people set one return path to a general area and forget about it.

I hope to, in the next 2 weeks, be making a lot of the changes that d003232 has been posting about. I'll just have to weed through what is feasible (or, more likely to not cause any potential problems with the bot). Maybe once that is done I can continue work on the waypoint system.

User avatar
memcpy
Posts: 30
Joined: Fri Jun 05, 2009 8:48 am

Re: [Patch] Bugs and suggestions

#6 Post by memcpy » Fri Jun 19, 2009 6:01 am

d003232 wrote:I would prefere 'suffixes' instead of 'prefixes'.
well thats a matter of taste imho. i would prefer having waypoint and returnpath files sorted together instead of mixed. but either way makes sense.
anyway, if - and it really looks that way - the linking variant goes live you can name it what you want.
The other problem is that it would require you to re-create your return path every time you make a new waypoint script. It would be annoying. Most people set one return path to a general area and forget about it.
good point. let's go for linking.

d003232
Posts: 1252
Joined: Wed Jun 03, 2009 4:27 pm

Re: [Patch] Bugs and suggestions

#7 Post by d003232 » Fri Jun 19, 2009 6:17 am

Administrator wrote:
The other problem is that it would require you to re-create your return path every time you make a new waypoint script. It would be annoying. Most people set one return path to a general area and forget about it.
That would be quite bad. I thought one could create a waypoint file simply like a combination of a waypoint file and some profile file options:

Code: Select all

<waypoints>
	<waypoint x="4105" z="2415" />
	<waypoint x="4242" z="2431" />
	<waypoint x="4452" z="2425" />
	<waypoint x="4294" z="2333" />
	<waypoint x="4158" z="2316" />
	<waypoint x="4104" z="2455" />
	<waypoint x="4026" z="2408" />
	<waypoint x="3913" z="2421" />
    <options>
        <option name="RETURN_PATH" value="blabla_return.xml" />
        <option name="COMBAT_DISTANCE" value="180" />
        <option name="WAYPOINT_DEVIATION" value="48" />
        <option name="CLEAR_AROUND" value="true" />
        <option name="INSTANT_LOOT_DISTANCE" value="30" />	
        <option name="WAYPOINTS_REVERSE" value="false" />	
    </options>
    <friends>
        <friend name="Borrofar" />
    </friends>
</waypoints>
The RoM Bot Online Wiki needs your help!

Zilvermoon
Posts: 104
Joined: Mon Jan 05, 2009 8:19 am

Re: [Patch] Bugs and suggestions

#8 Post by Zilvermoon » Fri Jun 19, 2009 6:53 am

d003232 wrote:
Administrator wrote:
The other problem is that it would require you to re-create your return path every time you make a new waypoint script. It would be annoying. Most people set one return path to a general area and forget about it.
That would be quite bad. I thought one could create a waypoint file simply like a combination of a waypoint file and some profile file options:

Code: Select all

<waypoints>
	<waypoint x="4105" z="2415" />
	<waypoint x="4242" z="2431" />
	<waypoint x="4452" z="2425" />
	<waypoint x="4294" z="2333" />
	<waypoint x="4158" z="2316" />
	<waypoint x="4104" z="2455" />
	<waypoint x="4026" z="2408" />
	<waypoint x="3913" z="2421" />
    <options>
        <option name="RETURN_PATH" value="blabla_return.xml" />
        <option name="COMBAT_DISTANCE" value="180" />
        <option name="WAYPOINT_DEVIATION" value="48" />
        <option name="CLEAR_AROUND" value="true" />
        <option name="INSTANT_LOOT_DISTANCE" value="30" />	
        <option name="WAYPOINTS_REVERSE" value="false" />	
    </options>
    <friends>
        <friend name="Borrofar" />
    </friends>
</waypoints>
I like this idea of being able to "overwrite" profile options with Waypoint options ... but at this point in time I haven't figured out how to do this, but it got my support.

Zilvermoon

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests