ClassJobType bitwise operators

[kaihaider]

Any chance we can get ClassJobType enums flagged so I can use bitwise with them?

On a separate note, it would be awesome if you could make doaction return values more accurate

 

[mastahg]

Any chance we can get ClassJobType enums flagged so I can use bitwise with them?

No? You can't just appy flag to anything. Their values are important.

On a separate note, it would be awesome if you could make doaction return values more accurate

We return Exactly what the game function returns, it would be impossible to make it anymore accurate.

 

[kaihaider]

No? You can't just appy flag to anything. Their values are important.

I thought you defined the enums and could edit the values to allow bitwise | between class and job (which would be awesome for multiple behaviors with priority levels) I'm sure i can jerry rig something else.
Good to know, just would have been nice.

We return Exactly what the game function returns, it would be impossible to make it anymore accurate.

That's too bad, I had assumed you used your own check.

Thanks for enlightening me about both of those issues. It's nice to know.

btw, any chance I can get a response on whether that Spell In Queue check would be possible? I wasn't sure what you meant regarding the check it's self when you said cancast no longer queues spells. Since the api description says it checks if a spell is in queue, I assumed you meant the call exists privately but was removed from cancast due to other reasons. Would be a real comfort to know if that one's not gonna happen. While it's a possibility, I can't help but consider approaches for my cr which require it to be executed properly. Which causes me to anxiously await a response from you :S

 

[mastahg]

I thought you defined the enums and could edit the values to allow bitwise | between class and job (which would be awesome for multiple behaviors with priority levels) I'm sure i can jerry rig something else.
Good to know, just would have been nice.


That's too bad, I had assumed you used your own check.

Thanks for enlightening me about both of those issues. It's nice to know.

btw, any chance I can get a response on whether that Spell In Queue check would be possible? I wasn't sure what you meant regarding the check it's self when you said cancast no longer queues spells. Since the api description says it checks if a spell is in queue, I assumed you meant the call exists privately but was removed from cancast due to other reasons. Would be a real comfort to know if that one's not gonna happen. While it's a possibility, I can't help but consider approaches for my cr which require it to be executed properly. Which causes me to anxiously await a response from you :S

Sorry that documentation needs to be redone. Cancast has nothing todo with the queue anymore. If cancast is true you can cast the spell, if its not then you cant. Not going to take time to reverse stuff that isnt really needed when there are high priority targets atm.

 

[kaihaider]

Sorry that documentation needs to be redone. Cancast has nothing todo with the queue anymore. If cancast is true you can cast the spell, if its not then you cant. Not going to take time to reverse stuff that isnt really needed when there are high priority targets atm.

You say anymore, so I was hoping you had a spell in queue check which use to be used and you could make that check public.

That's the only reason I mentioned cancast.

I'm not asking for a change to can cast, just wanted to know if you had the check for spell queue already written and just left it private.

Would really like a response regarding spell queue specifically please. You keep responding about cancast so I'm really not sure what you mean regarding spell in queue in general.

If spell in queue check is not written already and not a priority, I can live with that. I just wanted to check because it sounds like you're misunderstanding what I'm asking.

 

[mastahg]

To be clear: We have 0 code that does anything about queues. The cancast documentation was never updated when I reverted the changes to cancast + cast

 

[Endus]

To be clear, this is what mastahg is referring to with CanCast:

https://www.thebuddyforum.com/rebor...rnbuddy-version-1-0-207-a-59.html#post1657094

Version 179

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

Ignore my ignorant posts that follow. I was just starting out.

 

[mastahg]

These changes were 10000000000000% reverted the next version.