Taking requests from developers who want certain API functions that aren't currently implemented.  Trying to make a public API library that adds onto the wrobot base API.

 

Don't request wrappers for other profiles

So I was playing around the other day doing a plugin for savage blood farming, you can just probably do a single profile but you are not able to move to the next target once the target has been trapped (You can detect the debuff in ur fightclass and stop atacking and such, but you will remain there until the mob dissapears).. so basiaclly my aproach was to make a simple grinder profile with only coords no targets, and code the target lookup on the plugin and other validations like the trap debuff and such... is there any way we could tell wrobot to continue with its pathing profile and next target somehow? or a temporal blacklist of a target (Not sure if possible cause I think they still share the same GUID).. but something like BlackListAndContinue(Guid) which would ignore the trapped mob and continue with the current profile..  I was able to detect the trapped debuff and move to the next target but i had to manually pause and resume the grinder product in order for my algorithm to work ... doing it from inside the plugin wouldn't work because once you pause or stop any product then the ticks stop and ur not able to resume the product from within the plugin... 

Not sure if anything makee sense, I perhaps havent played around enough with the API, and perhaps im asking for functionality rather than API changes but oh well..

Maybe if you could add a debuff validation on the grinding profiles that'd be awesome, like add the target id and also a validation like you do in the fightclass, Debuff, Distance, Health, w.e, in order to attack that given mob or just continue the normal loop.

2 hours ago, Fer said:

So I was playing around the other day doing a plugin for savage blood farming, you can just probably do a single profile but you are not able to move to the next target once the target has been trapped (You can detect the debuff in ur fightclass and stop atacking and such, but you will remain there until the mob dissapears).. so basiaclly my aproach was to make a simple grinder profile with only coords no targets, and code the target lookup on the plugin and other validations like the trap debuff and such... is there any way we could tell wrobot to continue with its pathing profile and next target somehow? or a temporal blacklist of a target (Not sure if possible cause I think they still share the same GUID).. but something like BlackListAndContinue(Guid) which would ignore the trapped mob and continue with the current profile..  I was able to detect the trapped debuff and move to the next target but i had to manually pause and resume the grinder product in order for my algorithm to work ... doing it from inside the plugin wouldn't work because once you pause or stop any product then the ticks stop and ur not able to resume the product from within the plugin... 

Not sure if anything makee sense, I perhaps havent played around enough with the API, and perhaps im asking for functionality rather than API changes but oh well..

Maybe if you could add a debuff validation on the grinding profiles that'd be awesome, like add the target id and also a validation like you do in the fightclass, Debuff, Distance, Health, w.e, in order to attack that given mob or just continue the normal loop.

I actually requested a bot functionality change that would solve your problem, (changing blacklist from static on load to dynamic).  I could make my own blacklist class, however I am hoping droidz will update the bot to allow for blacklists to be dynamic.  I'll look into more when I get home, if wRobot allows for mob skipping based on memory location, and has a move on function(I may write this myself, since it will be very useful in general) I could easily write a temp blacklist class that would solve your problem. May be more work than it's worth since droidz will hopefully update the current blacklist class to allow for dynamic additions.  However, I will look into it and get back to you.

29 minutes ago, Brian said:

I actually requested a bot functionality change that would solve your problem, (changing blacklist from static on load to dynamic).  I could make my own blacklist class, however I am hoping droidz will update the bot to allow for blacklists to be dynamic.  I'll look into more when I get home, if wRobot allows for mob skipping based on memory location, and has a move on function(I may write this myself, since it will be very useful in general) I could easily write a temp blacklist class that would solve your problem. May be more work than it's worth since droidz will hopefully update the current blacklist class to allow for dynamic additions.  However, I will look into it and get back to you.

he will because anything that improves bot is worth making update for but right now he's busy with the relogger program. I'd say ETA before getting updates to API etc is couple weeks to 1 month

7 hours ago, Brian said:

I actually requested a bot functionality change that would solve your problem, (changing blacklist from static on load to dynamic).  I could make my own blacklist class, however I am hoping droidz will update the bot to allow for blacklists to be dynamic.  I'll look into more when I get home, if wRobot allows for mob skipping based on memory location, and has a move on function(I may write this myself, since it will be very useful in general) I could easily write a temp blacklist class that would solve your problem. May be more work than it's worth since droidz will hopefully update the current blacklist class to allow for dynamic additions.  However, I will look into it and get back to you.

Sounds great, thanks for the reply, hopefully I get an update on this at some point.