[Release] RebornBuddy Version 1.0.461

[mastahg]

Is this with cb version too?
"Additions:
You can now change jobs without having to restart the bot(Pausing it first is recommended)" we need that funtion and new fix.
Another question is my job is bard , How to solve the obstacle behind the target can not attack the problem? Whether to increase the range of options or conversion away from the target time?

Yes it is also for the CN version. I'm not sure what your asking for the second part.

 

[Wheredidigo]

You should probably either update the text on the Updater for RB or just remove the text entirely. When you go to update the bot, the text still shows the details from when we were updating to version 174.

 

[kinmen]

Yes it is also for the CN version. I'm not sure what your asking for the second part.

My play job is Bard(Archer) , when the target behide big rock or tree then bot won't attack with the range and trapped there a while with shake. (then any other player will know that is BOT and it is trapped then tell GM and i m GG...)
So i think maybe there have a option for user to setting attack range nometter they use melee or ranged job. Or another option to setting how long (sec) when bot can't attack target then change to next one.

 

[kaihaider]

My play job is Bard(Archer) , when the target behide big rock or tree then bot won't attack with the range and trapped there a while with shake. (then any other player will know that is BOT and it is trapped then tell GM and i m GG...)
So i think maybe there have a option for user to setting attack range nometter they use melee or ranged job. Or another option to setting how long (sec) when bot can't attack target then change to next one.

we would need a log to know what's going on but from the word shake I would assume it was spamming path generations?

if that's the case then your cr is trying to move to the target while the bot base is also trying to move towards the target. This results in a shaking motion because of the movestop before the move call.

About the change target, you would have to blacklist a target in the cr. As long as fatebot checks the blacklist, it should work.

I'm actually not sure how the pull range setting works, even after I had it set to melee range, it would still call the pullbehavior while really far away :S

 

[mastahg]

we would need a log to know what's going on but from the word shake I would assume it was spamming path generations?

if that's the case then your cr is trying to move to the target while the bot base is also trying to move towards the target. This results in a shaking motion because of the movestop before the move call.

About the change target, you would have to blacklist a target in the cr. As long as fatebot checks the blacklist, it should work.

I'm actually not sure how the pull range setting works, even after I had it set to melee range, it would still call the pullbehavior while really far away :S

new Decorator(ret => (Poi.Current.Unit.Distance() > (RoutineManager.Current.PullRange + Poi.Current.Unit.CombatReach) || !Poi.Current.Unit.InLineOfSight()) && !Core.Player.IsCasting, CommonBehaviors.MoveAndStop(ret => Poi.Current.Unit.Location,r=>(RoutineManager.Current.PullRange + Poi.Current.Unit.CombatReach),true, "Kill Target")),

new HookExecutor("PreCombatLogic"),
new Decorator(
ret => Core.Me.PrimaryTargetPtr != IntPtr.Zero,
new PrioritySelector(
new Decorator(r => Core.Player.IsMounted, new Action(r => Actionmanager.Dismount())),
new Decorator(ret => !Core.Me.InCombat, new HookExecutor("Pull", "Run when pulling a mob to kill.", RoutineManager.Current.PullBehavior)),





From the main logic tree that fatebot and orderbot use.

 

[mastahg]

Maybe ill modify the line above the executor, make it so it only runs when not in combat.

 

[kaihaider]

that makes sense - a los check, thanks XD

but why do you even have the moveto command instead of just calling pull behavior? :S
would make my life so much easier >_>

I guess it's for cr's that use core.me.currenttarget instead of core.target for pull but it would make cr movement so much more flexible

Or maybe you can set up a way to turn off that moveto call from a cr? Even if you don't set up a new check for precombatbuffs...

pretty pretty pretty please XD

btw, thanks for the code because I was worried about getting los pull stucks so I had some weird code. Now I can match it to yours

I guess I don't need pull movement now, or I can use this XD

if (!Core.Me.IsCasting 
     && o.InLineOfSight() && Core.Me.Distance(o.Location) <= RoutineManager.Current.PullRange+o.CombatReach)
     await Coroutine.ExternalTask(Task.Run(() => Movement.MoveToTarget(o)));

j/k

public static bool IsPoiTarget(GameObject u)
{
   if (u == null) return false;
   return Poi.Current.Unit!=null && u.ObjectId == Poi.Current.Unit.ObjectId || Poi.Current.BattleCharacter!=null && u.ObjectId == Poi.Current.BattleCharacter.ObjectId;
}

should I only be handling on pull when Core.target == null and Core.Me.CurrentTarget!=null?
Or if poi is empty does it get filled with CurrentTarget, so I would need to check poi?
While we're on the topic, do you have any comments about CombatTargeting.Instance? Is the first unit Core.Me.CurrentTarget or poi or how is it used?

:S

still, really really wish I could control pull with my own movement/targeting XD or at least targeting during combat

 

[Thecamel]

Im not sure why, but im getting A shit load of game crashes since this release,

here is a recent log if you wish to have a look.

View attachment 25512 2014-11-06 09.33.txt

Servers are down so I guess I will look later tonight.

 

[Thecamel]

Ive got a update for .197 ?

Updated for latest version of ff14.

Orderbot:
Tweak poi clear logic
Tweak combat target weighting logic
Add new tag attribute PostCombatDelay, this attribute can be used with any tag and will sleep x seconds after leaving combat.
Ex: <Grind grindRef="BattleoftheBottomfeeders" PostCombatDelay="5" while="GetQuestStep(66864) == 1" />
Sleep 5 seconds after combat.
Path precision increased from 1.25 to .8
Will now handle cutscene dialog's and chat.
Gathertag:
Will now try and get closer to nodes.
Tweaked spell logic slightly
Will now better respect the mount settings
Won't try and sprint directly after mounting
Teleport tag:
You can now force the bot to teleport by setting Force="true", this will make it teleport even if its on the same map as long as the aethereyte is not in range of the objectmanager.
TalkTo tag:
If you don't pass in a quest and step id the behavior will exit when the conversation is done.


Fatebot:
Weights have been drastically changed, will now favor nearby fates.
Should no longer spam poi changes.
-Going to try exposing the weights via the config file next version atleast.

Api:
Added WorldManager.SubZoneId (Can use in profiles via IsOnSubMap(subid))
Added GetQuestById(questId), this can be used to access the large plethora of quest variables.(Having a simple gui coming soon to make working on quest profiles easier.)
Added TappedByOther to battlecharacter



Bug Fixes:
Always set attributes and elements to their default values first in XML engine.
Fix rare issue with lua engine returning wrong value due to insufficient padding.


But Im still getting a version error on login ? was this update something I missed before the patch or after patch and just has the wrong offsets ?

 

[exaccuss]

Ive got a update for .197 ?

Updated for latest version of ff14.

Orderbot:
Tweak poi clear logic
Tweak combat target weighting logic
Add new tag attribute PostCombatDelay, this attribute can be used with any tag and will sleep x seconds after leaving combat.
Ex: <Grind grindRef="BattleoftheBottomfeeders" PostCombatDelay="5" while="GetQuestStep(66864) == 1" />
Sleep 5 seconds after combat.
Path precision increased from 1.25 to .8
Will now handle cutscene dialog's and chat.
Gathertag:
Will now try and get closer to nodes.
Tweaked spell logic slightly
Will now better respect the mount settings
Won't try and sprint directly after mounting
Teleport tag:
You can now force the bot to teleport by setting Force="true", this will make it teleport even if its on the same map as long as the aethereyte is not in range of the objectmanager.
TalkTo tag:
If you don't pass in a quest and step id the behavior will exit when the conversation is done.


Fatebot:
Weights have been drastically changed, will now favor nearby fates.
Should no longer spam poi changes.
-Going to try exposing the weights via the config file next version atleast.

Api:
Added WorldManager.SubZoneId (Can use in profiles via IsOnSubMap(subid))
Added GetQuestById(questId), this can be used to access the large plethora of quest variables.(Having a simple gui coming soon to make working on quest profiles easier.)
Added TappedByOther to battlecharacter



Bug Fixes:
Always set attributes and elements to their default values first in XML engine.
Fix rare issue with lua engine returning wrong value due to insufficient padding.


But Im still getting a version error on login ? was this update something I missed before the patch or after patch and just has the wrong offsets ?

It's probably some minor thing he just added which he does from time to time.

 

[kinmen]

new Decorator(ret => (Poi.Current.Unit.Distance()
From the main logic tree that fatebot and orderbot use.

Thanks a professional answer, but I'm just an ordinary user, so totally do not understand programming language.
maybe i show you a picture , hope you understand my problem.

Attachments is im use profile and screenshot.

 

[kaihaider]

Thanks a professional answer, but I'm just an ordinary user, so totally do not understand programming language.
maybe i show you a picture , hope you understand my problem.

Attachments is im use profile and screenshot.

Profile doesn't matter, we need a log. Are you using a custom kupo? It should say so in the log but sometimes people don't rename.

I'm 99% that the problem is what mastahg or I were talking about.

Were you in combat?
If so, it's what mastahg suggested.
If not, it's a conflict with the pull and your cr needs to be edited to not move towards your poi.target during pull.

rant: still really really wish botbase would just move to set target and then let cr handle targeting/movement until pull/combat behaviors are no longer being called T_T

 

[mastahg]

that makes sense - a los check, thanks XD

but why do you even have the moveto command instead of just calling pull behavior? :S
would make my life so much easier >_>

I guess it's for cr's that use core.me.currenttarget instead of core.target for pull but it would make cr movement so much more flexible

Or maybe you can set up a way to turn off that moveto call from a cr? Even if you don't set up a new check for precombatbuffs...

pretty pretty pretty please XD

btw, thanks for the code because I was worried about getting los pull stucks so I had some weird code. Now I can match it to yours

I guess I don't need pull movement now, or I can use this XD

if (!Core.Me.IsCasting 
     && o.InLineOfSight() && Core.Me.Distance(o.Location) <= RoutineManager.Current.PullRange+o.CombatReach)
     await Coroutine.ExternalTask(Task.Run(() => Movement.MoveToTarget(o)));

j/k

public static bool IsPoiTarget(GameObject u)
{
   if (u == null) return false;
   return Poi.Current.Unit!=null && u.ObjectId == Poi.Current.Unit.ObjectId || Poi.Current.BattleCharacter!=null && u.ObjectId == Poi.Current.BattleCharacter.ObjectId;
}

should I only be handling on pull when Core.target == null and Core.Me.CurrentTarget!=null?
Or if poi is empty does it get filled with CurrentTarget, so I would need to check poi?
While we're on the topic, do you have any comments about CombatTargeting.Instance? Is the first unit Core.Me.CurrentTarget or poi or how is it used?

:S

still, really really wish I could control pull with my own movement/targeting XD or at least targeting during combat

Pull is called when all the following is true:
1)You have a target
2)You are not currently in combat

 

[kaihaider]

Pull is called when all the following is true:
1)You have a target
2)You are not currently in combat

i'm not sure you understood what I was saying. After you get close enough to set the game target with the poi, there is no need for you to handle movement/targeting while we have a viable target. Let the cr handle it.

all it does is make advanced cr logic for add handling impossible...

 

[kinmen]

i'm not sure you understood what I was saying. After you get close enough to set the game target with the poi, there is no need for you to handle movement/targeting while we have a viable target. Let the cr handle it.

all it does is make advanced cr logic for add handling impossible...

Yes, that's what I'm talking about, make a option let user set attack range if possible. Just like the range of ride chocobo.
By the way, that screenshot already in combat use Kupper.

 

[mastahg]

Version 198

Fixed issue with teleporting to corethas
Fixed issue with turnning in quests that have rewards
Orderbot/Fatebot will no longer call movement code once they begin targeting an enemy and calling the pull behavior.

 

[kaihaider]

Version 198

Fixed issue with teleporting to corethas
Fixed issue with turnning in quests that have rewards
Orderbot/Fatebot will no longer call movement code once they begin targeting an enemy and calling the pull behavior.

omfg i love you

will be a while before I try anything fancy but it' so much cleaner ^_^

 

[mastahg]

Version 199

Updated kupo:
Forgot to include the updated kupo when the ability to switch classes was added

 

[kaihaider]

Version 198

Fixed issue with teleporting to corethas
Fixed issue with turnning in quests that have rewards
Orderbot/Fatebot will no longer call movement code once they begin targeting an enemy and calling the pull behavior.

Movement is awesome but can you also let us keep targeting control XD

 

[mastahg]

Use combat assist XD