Recovery period detection?
- Thread starter eccentric
- Start date
Reason why I ask is that I check to make sure a spell isn't casting before telling a new one to cast, and during recovery time no spell is casting but Ability.Use doesn't make the cast; therefore I inadventently find myself spamming Ability.Use several times during the recovery until the recovery finishes. I don't know if this means several duplicate calls are being made to the server; I don't want to put up any red flags on that end.
From what I can gather, the LavishScript counterpart (EQ2Bot.iss) doesn't seem to express awareness of the .5 second or so recovery period, but instead uses small waits (wait 2, wait 3, etc) in loops that partially overlap the period on the final iteration.
What I would recommend/request at this point is a Me.IsRecovering to complement Me.CastingSpell. I'd like to avoid arbitrary waits as much as humanly possible, especially in code deeply embedded within a frame lock.
What I would recommend/request at this point is a Me.IsRecovering to complement Me.CastingSpell. I'd like to avoid arbitrary waits as much as humanly possible, especially in code deeply embedded within a frame lock.
Acually, eq2bot does not think about recovery period, it queues spells one after another. If it wants to cast the same spell more than once in a row, it waits until it is 'ready' again.
The waits are to deal with server/client communication issues. The EQ2 client is poorly coded in some instances and the client actually updates before the server does (ie, when you click to cast a spell.) In other words, the client thinks that you're casting (or whatever) when the server doesn't know that you're casting yet. The only way to deal with that is to place in small waits to give the server time to catch up.
This all goes back to why I feel that .NET will never be the best thing to use with games and applications such as innerspace. There are just too many variables and too many things which I cannot control. I mean, if I had the EQ2 source code, it might be different ...but this is not exactly "easy". We have to make do with what I can figure out ...and, honestly, using a non-compiled scripting language (whatever it might be) is the best thing to do.
It is for this reason, more than anything else, that lavishscript has continued to be used with isxeq2. It's just "easier" to deal with the unknown variables and things that just can't be easily determined through reverse engineering.
The waits are to deal with server/client communication issues. The EQ2 client is poorly coded in some instances and the client actually updates before the server does (ie, when you click to cast a spell.) In other words, the client thinks that you're casting (or whatever) when the server doesn't know that you're casting yet. The only way to deal with that is to place in small waits to give the server time to catch up.
This all goes back to why I feel that .NET will never be the best thing to use with games and applications such as innerspace. There are just too many variables and too many things which I cannot control. I mean, if I had the EQ2 source code, it might be different ...but this is not exactly "easy". We have to make do with what I can figure out ...and, honestly, using a non-compiled scripting language (whatever it might be) is the best thing to do.
It is for this reason, more than anything else, that lavishscript has continued to be used with isxeq2. It's just "easier" to deal with the unknown variables and things that just can't be easily determined through reverse engineering.
I'm not gonna lie, I'm pleasantly surprised that C# performs as well as it does in these circumstances. The added beauty of it is that I have been able to attach the Visual Studio debugger to the client and step through my code line by line. It has some quirks but in emergencies it saves my ass. I wouldn't throw in the towel on .NET botting just yet, there's vast potential here. You've come a long way.
I'm not trying to bust balls when I go into detail, I'm just trying to get information if you happen to have it. Right now this is the most entertaining software dev hobby project I've had in years and I'm rushing to get enough completed so I can start 6-boxing zones with it. Then I'll put the code out there so everyone can laugh and scratch their chins about the approach I took.
I'm not trying to bust balls when I go into detail, I'm just trying to get information if you happen to have it. Right now this is the most entertaining software dev hobby project I've had in years and I'm rushing to get enough completed so I can start 6-boxing zones with it. Then I'll put the code out there so everyone can laugh and scratch their chins about the approach I took.
though your questions are sometimes annoying and seem to grate on raw nerves here and there, I'm hoping you can pull it all together and make something amazing.
I probably won't use it, but having an open source example that actually does something useful would be a huge benefit to the .net world of eq2
I probably won't use it, but having an open source example that actually does something useful would be a huge benefit to the .net world of eq2
Pygar
EQ2Bot Specialist
I've been keeping quiet on this, but I'm fairly confident it would be faster to overcome your learning curve on lavishscript and correct whatever it is that has your panties wadded than trying to get this working in .Net.
You've got all the basic implementation issues to work out, and once you finally get some code running, your going to start running into the same issues we've alread had to address one by one in addition to the c# specific proglems. There are hundreds of odd quirky behaviors we've had to just code around due to latency, lag, inaccurate server/ client data, etc, etc.
I can assure the man hours required to resolve all these issues will be greatly higher than just jumping into script and echoing it out till you find whatever it is you don't like to change it around.
I dunno what the issue is, but you may very well find, there are some things a script just will never handle better within the boundaries of the data we are working with.
My point isn't to discourage you from this path, however, while others might try to step you thru each of these dozens if not 100's of quirky problems like recovery periods, I'm simply not going to try to re-hash that out again for you when working examples exist in current scripts. Nor am I going to take the time to explain why we chose solution E cause of the inherent problems found in solutions A thru D.
Good Luck
You've got all the basic implementation issues to work out, and once you finally get some code running, your going to start running into the same issues we've alread had to address one by one in addition to the c# specific proglems. There are hundreds of odd quirky behaviors we've had to just code around due to latency, lag, inaccurate server/ client data, etc, etc.
I can assure the man hours required to resolve all these issues will be greatly higher than just jumping into script and echoing it out till you find whatever it is you don't like to change it around.
I dunno what the issue is, but you may very well find, there are some things a script just will never handle better within the boundaries of the data we are working with.
My point isn't to discourage you from this path, however, while others might try to step you thru each of these dozens if not 100's of quirky problems like recovery periods, I'm simply not going to try to re-hash that out again for you when working examples exist in current scripts. Nor am I going to take the time to explain why we chose solution E cause of the inherent problems found in solutions A thru D.
Good Luck
No offense, but there is a definite reason I and a friend discontinued using eq2bot and it wasn't because it was written in LavishScript. It just wasn't suited to our style of boxing, which consisted of a lead character (usually MT) with casters on autofollow. And we had countless issues with healers refusing to heal, casters refusing to participate at non-melee ranges, and on and on that we couldn't seem to configure ourselves out of. When a second friend started to have these issues, I knew it was time to take my own path.
My bot always assumes there is a live player who is controlling the lead character; I'm not looking to copy eq2bot's total automation features. Casters don't care about melee positioning and won't waste precious time on it; they care about pristine spell order. If melee is important, the lead character can pull the casters into position with autofollow and that's that. This major design principle has made a world of difference in dps and survivability. If you're looking to bot scouts or fighters (with the eventual exception of troubador), this is not the bot for you.
To enter offensive combat it doesn't try to detect combat but waits for an "assist me" chat line, the kind many raid guilds have used with real players for years. The beauty of this is that you can start combat at will. And you can train through zones. Actually it isn't just beauty, it's a necessity. I'm also working on a "stay here" configurable chat line that briefly turns off autofollow to keep them at range and at that coordinate. If chat is too dangerous, I'll move to network commands/keyboard hotkeys/voice commands down the road.
There is no UI but I don't need one either, they get in my way anyway. It uses INI files, and prebuilds one per character if none exists. Right now I key off a subtle chat substring to reload it but down the road I'll just create a thread that monitors the directory for changes.
Two mage classes and a mystic are already raid-functional and have been thoroughly tested and debugged in T7 zones and VP. There is a TODO list before I'm ready to publish what I've got so far but I am 150% assured this path is the right one. It is a tremendous help to draw on past .NET experience and be able to bring in any old .NET code as needed.
The one missing thing that would make this absolutely killer is to know the max health of the mob being fought, because you don't use the same casting orders on trash that you do with named. Hell, not even all trash is created equal. I know the EQ2 client gives a percentage instead of a flat value (or at least I assume at this point), so the long-term idea I had was to create a hitpoint database using a .NET interface to MS-SQL CE and cache ACT-estimated values in the bot per mob/zone.
As far as recovery time, my provisional plan is to wait out the time provided by the Ability class, unless an error message (too far, etc) pops up before it ends. This should be very helpful in cutting down the Ability.Use spam I cause when Me.CastingSpell is false but Ability.IsReady is true. Or something to that effect, I don't have the code with me right now.
Even if I'm the only one who ever uses this, I'm getting my time's worth out of it regardless. Good Luck to you too sir.
My bot always assumes there is a live player who is controlling the lead character; I'm not looking to copy eq2bot's total automation features. Casters don't care about melee positioning and won't waste precious time on it; they care about pristine spell order. If melee is important, the lead character can pull the casters into position with autofollow and that's that. This major design principle has made a world of difference in dps and survivability. If you're looking to bot scouts or fighters (with the eventual exception of troubador), this is not the bot for you.
To enter offensive combat it doesn't try to detect combat but waits for an "assist me" chat line, the kind many raid guilds have used with real players for years. The beauty of this is that you can start combat at will. And you can train through zones. Actually it isn't just beauty, it's a necessity. I'm also working on a "stay here" configurable chat line that briefly turns off autofollow to keep them at range and at that coordinate. If chat is too dangerous, I'll move to network commands/keyboard hotkeys/voice commands down the road.
There is no UI but I don't need one either, they get in my way anyway. It uses INI files, and prebuilds one per character if none exists. Right now I key off a subtle chat substring to reload it but down the road I'll just create a thread that monitors the directory for changes.
Two mage classes and a mystic are already raid-functional and have been thoroughly tested and debugged in T7 zones and VP. There is a TODO list before I'm ready to publish what I've got so far but I am 150% assured this path is the right one. It is a tremendous help to draw on past .NET experience and be able to bring in any old .NET code as needed.
The one missing thing that would make this absolutely killer is to know the max health of the mob being fought, because you don't use the same casting orders on trash that you do with named. Hell, not even all trash is created equal. I know the EQ2 client gives a percentage instead of a flat value (or at least I assume at this point), so the long-term idea I had was to create a hitpoint database using a .NET interface to MS-SQL CE and cache ACT-estimated values in the bot per mob/zone.
As far as recovery time, my provisional plan is to wait out the time provided by the Ability class, unless an error message (too far, etc) pops up before it ends. This should be very helpful in cutting down the Ability.Use spam I cause when Me.CastingSpell is false but Ability.IsReady is true. Or something to that effect, I don't have the code with me right now.
Even if I'm the only one who ever uses this, I'm getting my time's worth out of it regardless. Good Luck to you too sir.
Last edited:
eccentric is using C# because a lot of us love the language and there is a .NET wrapper available. If it doesn't work, then it doesn't...if it does then it's one more tool available. I couldn't get .NET for ISXVG to do anything productive, just spit out basic info for me, but that was a while back...I'm actually very excited that someone's doing something for EQ2 in C#!
I have this professor that said the only time he gets excited about a project is when someone stands up and says, "who would want that" or "just do it the regular way"...like in the late 70's working on a SGI system when he programmed an accounting program for his boss to make quarterly reporting simple for their firm. His boss looked at it and said, "You wasted your time. Nobody will need this, I only use this every couple months so I'll keep doing it my way!" Then not long after VisiCalc came out(first desktop spreadsheet program)...followed by the likes of Lotus and Excel. He moved onto other projects and places and has since patented some rally interesting ones in the medical imaging field.
You know you are onto something when someone asks why.
Keep up the good work, and the questions eccentric!
gf
EDIT: Must have hit reply just before you finished your message eccentric!
I have this professor that said the only time he gets excited about a project is when someone stands up and says, "who would want that" or "just do it the regular way"...like in the late 70's working on a SGI system when he programmed an accounting program for his boss to make quarterly reporting simple for their firm. His boss looked at it and said, "You wasted your time. Nobody will need this, I only use this every couple months so I'll keep doing it my way!" Then not long after VisiCalc came out(first desktop spreadsheet program)...followed by the likes of Lotus and Excel. He moved onto other projects and places and has since patented some rally interesting ones in the medical imaging field.
You know you are onto something when someone asks why.
Keep up the good work, and the questions eccentric!
gf
EDIT: Must have hit reply just before you finished your message eccentric!
Last edited:
Pygar
EQ2Bot Specialist
As stated many times, this is how the majority of eq2bot users utilize the bot, and we all manage to do it everyday without issue. You've simply failed at understanding how to configure things. I'd wager Amadeus and I log 300+ hours / month using eq2bot in exactly this same fashion.
What you're going to eventually discover about recovery time, and the ability class in general is they don't update fast enough to reflect the actual data or conditions the server is going to bind you're spell casting by. Now, if you're not worrying about enchanters or melee classes for now, you'll maybe get by with the method your approaching it with.
In reality, gear proc, spell proc, group/raid buffs change cast and recovery time much more rapidly than the ability class updates, hell I don't think the client is always updated much less the class. This is why castspell has been tweaked the way it is. There is a minimum casting time that anything under that just falls into a static delay before next cast as trusting anything from the class or client in under around .5s cast times is just too problematic.
For caster's it's much simpler to start a cast, evaluate the next spell in the chain and queue it, then just manage your queued states and queue another when the current one fires. This way recovery time becomes irrelevant and you don't spam abilities cause you halt your order while things are 'queued'. Recovery time really only becomes important for melee CA timing. I have not scripted these though cause Ama hasn't provided me the real-time delay data on weapons, which without, I can not effectively time CA's. We had something working, but it would get off on its timers fairly quickly as haste proc's fired and weapon delay data did not update. The only other effective way to approach ca timing was to create an isxact extension or using lax's log parsing extension to compile a scripted 'ca ding' like already exists for players via ACT.
CastingSpell also can not be trusted 100% due to client/server latency it doesn't update immediately when casting starts and stops and without some padding around evaluating it you're going to reach a point where it isn't returning true. I'm sure you've found it doesn't start returning true when the cast starts, more like .1-.2s after it starts and it returns true up to the 99% progress bar but at 100% it returns false. Under normal circumstances thats fine, but on server lag you can end up interrupting yourself cause you trusted CastingSpell to be 100% accurate without any padding on it.
Last edited: