What's new
By:
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal
RebornBuddy Forums

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

[Release] RebornBuddy Version 1.0.461

Version 179
Code: 
Updated for latest version of ff14.

Changes:
Logic behind Actionmanager.CanCast has drastically changed. 
Previously we ignored the ability to queue spells in order make development of CR's easier but now we are reaching a point where that advanced functionality is required.
Now spells will use ff14's internal queue system.
Psuedo code for new cancast:

if (!spellqueued)
 if (!groundtargeting)
  if (spelltype = ability,weaponskill,spell)
   if (spell.cooldown < 500 ms)
     return true

return false;

What this means is that we will queue spells up up to 500ms before the spells cooldown ends. A good example to test this logic with is a low level arcanist. You can start casting ruin and almost immeditaly after that cancast("aetherflow") and it will now return true allowing you to queue up aetherflow to be cast directly after ruin is done casting.

This does have a sideffect of making groundtargeting spells less likely to be cast as they cannot be queued. To counter this  I have implemented Actionmanager.CanCastLocation which should be used now for ground targeting spells. This version of cancast has very loose checks inorder to provide a chance for groundtargeting spells to be selected.


useitem and useobject tags now have shortcircuit logic in their waits  making the bot appear more human.

Fixes:
Fix issue where some spellcastinfo information wasn't being fetched properly.
Throw an exception if teleport tag requests a aetheryte that we do not currently have
pvpbot dispose of connection handler on stop
 
I'm confused.

First, I thought that RebornBuddy and all the CR's automatically used the next spell as soon as possible (basically queuing it anyway)?

Second, if not, why not just implement that globally rather than just in .CanCast (so that the next spell in the rotation is always queued)? Is there ever a time when queuing spells is a bad thing? Even if so, CR's could just throw in "IF .IsCasting return true" or something to cancel it out when needed, right?

Third, if we MUST use .CanCast to queue spells, what's the proper format? I've always used .CanCast as a conditional like "IF .CanCast Spell1 Cast Spell2". How would I use it to queue a spell?

Lastly, if I queued EVERY spell in a rotation, wouldn't the .CanCast conditionals all break? I see the tooltip says "returns true if we are in light of sight, if there is no error code, if there is no spell queued, if the spell has less than 500ms on its cooldown, and if the spell is not a ground targeting spell" meaning if I queued everything that all .CanCasts would be False, right?

Sorry for the dumb questions. Still new to this :rolleyes: lol.
 
Last edited:
Endus said:
I'm confused.

First, I thought that RebornBuddy and all the CR's automatically used the next spell as soon as possible (basically queuing it anyway)?

Second, if not, why not just implement that globally rather than just in .CanCast (so that the next spell in the rotation is always queued)? Is there ever a time when queuing spells is a bad thing? Even if so, CR's could just throw in "IF .IsCasting return true" or something to cancel it out when needed, right?

Third, if we MUST use .CanCast to queue spells, what's the proper format? I've always used .CanCast as a conditional like "IF .CanCast Spell1 Cast Spell2". How would I use it to queue a spell?

Lastly, if I queued EVERY spell in a rotation, wouldn't the .CanCast conditionals all break? I see the tooltip says "returns true if we are in light of sight, if there is no error code, if there is no spell queued, if the spell has less than 500ms on its cooldown, and if the spell is not a ground targeting spell" meaning if I queued everything that all .CanCasts would be False, right?

Sorry for the dumb questions. Still new to this :rolleyes: lol.
Click to expand...
What? I don't even. CanCast now returns true if you can queue a spell instead of only if you can directly cast it.
 
mastahg said:
What? I don't even. CanCast now returns true if you can queue a spell instead of only if you can directly cast it.
Click to expand...

Oh... well that makes a lot more sense. No wonder I was confused lol.

That may have actually fixed an issue I've been having in that case. :D
 
Version 181
Code: 
Added missing items to the database
Orderbot xml attribute names are now case insensitive
Revert changes to actionmanager.cancast until I can get a monk/bard to test rotations.
 
Version 182
Code: 
6 new functions added for orderbot:

HuntRankCompleted(ClassJobType job, int rank)
HuntEntryCompleted(ClassJobType job, int item)
HuntSubEntryCompleted(ClassJobType job, int item,int subitem)


HuntGCRankCompleted(int rank)
HuntGCEntryCompleted(int item)
HuntGCSubEntryCompleted(int item, int subitem)


Sample XML
   <If Condition="not HuntRankCompleted(ClassJobType.Gladiator,0)">
   
      <If Condition="not HuntEntryCompleted(ClassJobType.Gladiator,0)">
         <Grind grindRef="Gladiator_0_0" PostCombatDelay="5" while="not HuntSubEntryCompleted(ClassJobType.Gladiator,0,0)" />
		 <Grind grindRef="Gladiator_0_1" PostCombatDelay="5" while="not HuntSubEntryCompleted(ClassJobType.Gladiator,0,1)" />
      </If>
   </If> 


Bug fixes:
Fixed issue with huntbehavior tags throwing an error when passing only one XYZ and radius.

Changes:
Added noncombat logic for BlacklistAfter for huntbehaviors
Added virtual _revision property to JsonSettings
-With this you can now change the default values for settings.
-Increment the property when you want to change the existing default values
        [UpdateDefaultValue(60.0f,30.0f)]
        [DefaultValue(30.0f)]
        public float HealPet { get; set; }
If you increment revision, and the value of HealPet was the old default of 60 it will be set to the new value of 30.
 
Version 187
Code: 
Bug fixes:
Adjusted gathertag movement code and interact distance.

Changes:
PostCombatDelay now uses a wait instead of a sleep so if you get incombat early it will break out of it.

Api changes:
You can now check the condition and spirit bond progress of items equipped/in your inventory.
MoveTo tag now exits when you change zones.
 
Just curious, but this support the new pvp zone? or still just the wolves den?
 
Evz said:
Just curious, but this support the new pvp zone? or still just the wolves den?
Click to expand...

As of now it only supports the Wolves' Den. Frontlines is slated to be worked on, but I believe there are other things Mastahg is working on first.
 
kagamihiiragi17 said:
As of now it only supports the Wolves' Den. Frontlines is slated to be worked on, but I believe there are other things Mastahg is working on first.
Click to expand...

Oh okay thank you for the quick reply. I am looking forward to Frontlines working!
 
Version 190
Code: 
Initial release for the new version of ff14.
 
I could be wrong, but it doesn't look like Version 190 supports Rogue/Ninja (I'm sure it'll be out soon and v190 is just to get the bot working again for now).

Just a heads up for those making CRs. Don't bash your head up against the wall for hours wondering why it's not working ;) lol.

Code: 
namespace ff14bot.Enums
{
    public enum ClassJobType
    {
        Adventurer = 0,
        Gladiator = 1,
        Pugilist = 2,
        Marauder = 3,
        Lancer = 4,
        Archer = 5,
        Conjurer = 6,
        Thaumaturge = 7,
        Carpenter = 8,
        Blacksmith = 9,
        Armorer = 10,
        Goldsmith = 11,
        Leatherworker = 12,
        Weaver = 13,
        Alchemist = 14,
        Culinarian = 15,
        Miner = 16,
        Botanist = 17,
        Fisher = 18,
        Paladin = 19,
        Monk = 20,
        Warrior = 21,
        Dragoon = 22,
        Bard = 23,
        WhiteMage = 24,
        BlackMage = 25,
        Arcanist = 26,
        Summoner = 27,
        Scholar = 28,
    }
}
 
Endus said:
I could be wrong, but it doesn't look like Version 190 supports Rogue/Ninja (I'm sure it'll be out soon and v190 is just to get the bot working again for now).

Just a heads up for those making CRs. Don't bash your head up against the wall for hours wondering why it's not working ;) lol.

Code: 
namespace ff14bot.Enums
{
    public enum ClassJobType
    {
        Adventurer = 0,
        Gladiator = 1,
        Pugilist = 2,
        Marauder = 3,
        Lancer = 4,
        Archer = 5,
        Conjurer = 6,
        Thaumaturge = 7,
        Carpenter = 8,
        Blacksmith = 9,
        Armorer = 10,
        Goldsmith = 11,
        Leatherworker = 12,
        Weaver = 13,
        Alchemist = 14,
        Culinarian = 15,
        Miner = 16,
        Botanist = 17,
        Fisher = 18,
        Paladin = 19,
        Monk = 20,
        Warrior = 21,
        Dragoon = 22,
        Bard = 23,
        WhiteMage = 24,
        BlackMage = 25,
        Arcanist = 26,
        Summoner = 27,
        Scholar = 28,
    }
}
Click to expand...

Ah, i was wondering my routine kept throwing me errors lol. Hopefully Mastahg will support it soon.
 
Version 191
Code: 
Rogue and ninja added to class enum
Fishing fixed
 
I can confirm that the release after death does not work properly anymore. This is most likely due to the change in the options after death now included with the "wait" function. Please fix this as soon as you can, thanks!
 
You must log in or register to reply here.
Back
Top