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 lol.
What? I don't even. CanCast now returns true if you can queue a spell instead of only if you can directly cast it.
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.
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.
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.
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, } }
Post a log??? Rogue=29, Ninja=30, Just do a typecast until I get a new build out. Code: (ClassJobType)29;
Is release after death not working? I died while fate botting and it just sat there. Also using a real ghetto Rogue script, not sure if that's related. View attachment 7924 2014-10-28 23.02.txt
I recall someone else also posted about release when dead not working. I'm sure it will be fixed soon.
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!
