-
lisa
- Posts: 8332
- Joined: Tue Nov 09, 2010 11:46 pm
- Location: Australia
#21
Post
by lisa » Wed Mar 14, 2012 10:40 am
yes the developers are a bunch of idiots with the blade of grass obstruction.
silinky wrote:can i somehow program this to take a step back when the obstacle message appears on screen?
That would involve monitoring system msges and you would need to check for new messages every second, major load on PC resources.
If you only checked for messages every 5 seconds then you would still be there slapping away with melee attacks for 5 seconds anyway, no improvement.
-
silinky
- Posts: 213
- Joined: Mon Nov 23, 2009 5:07 am
#22
Post
by silinky » Wed Mar 14, 2012 10:54 am
true, frog is doing everything to make it harder for the players.
well we should not let them win

i at least won't give up finding a decent solution to this and if i succeed, i will share it with you guys.
-
rock5
- Posts: 12173
- Joined: Tue Jan 05, 2010 3:30 am
- Location: Australia
#23
Post
by rock5 » Wed Mar 14, 2012 10:25 pm
lisa wrote:Or did you simply clear the table after killing a mob successfully, which would of course still try to attack the last ignored mob anyway.
Actually I like this idea. There would still be some repetition when there are mobs behind walls, eg. it puts some mobs behind walls in the ignore list then attacks a mob and tries to attack the mobs behind the wall again but if a user can't be bothered setting the MAXCOMBAT_DIST, at least it wont get stuck. But it would work and in the case I said with the blade of grass, it would still kill the first mob.
- Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
- I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
- How to: copy and paste in micromacro
________________________
Quote:
- “They say hard work never hurt anybody, but I figure, why take the chance.”
-
lisa
- Posts: 8332
- Joined: Tue Nov 09, 2010 11:46 pm
- Location: Australia
#24
Post
by lisa » Wed Mar 14, 2012 11:39 pm
I really don't have a solution for this yet. The other issue with storing addresses in a table is addresses change, happens regularly, so in that case it would be better to use the GUID for the mob instead of the address.
Current code works with address because it only thinks of the last mob, so literally less then 1 second before looking for another mob to kill, chances of the address having changed is slim in that exact time.
Anyway to the issue at hand.
Trouble is even is we determine that the client is posting the obstruction error it won't help determine how to deal with the issue. It doesn't tell us if it's a wall or a blade of grass. If it's a wall we need to totally ignore mob, if it's a blade of grass it may be as simple as moving closer to mob to kill it.
A possible solution would be to try to move closer to the coords of the mob, since mobs move around we would need to only take into concideration the coords when first targeted otherwise it won't work.
So try to move closer, if it's a wall then we will get to a point we can't actually get closer, so distance will remain unchanged or only a little changed.
If it's just a blade of grass then you can move to melee range easily.
Is that a good solution though?
Would be fine if you don't mind being in melee range of a mob but let's face it the ONLY classes that get the obstruction issue are the ranged classes which don't like being in melee range.
Ok so if we decided to do that it would mean less ignored mobs as the only mobs ignored will be ones behind walls, if there are 2 mobs behind the same wall though you will still be stuck there forever with current code.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest