Genbot.mac 12.38 -- Updated 6/4/2004

[Fuergrissa]

genbot.mac

Code: Select all

|genbot.mac 
|Generic bot macro for any class. 
|Version 12.34 
|Date:05/22/2004
| 
||** 
[genbot] 
version=12.34
**|| 
| 

#include botcore.inc 
#include botspell.inc 
#include botcombat.inc 
#include bothealer.inc 
[color=red]#include shortcuts.inc[/color] 
#include personal.inc 
#include advpath.inc 
#turbo 40 

 

should that not read

Code: Select all

 [color=red]#include botshortcuts.inc[/color]

[Vexix]

Ayup. Fixed up above.

--Vexix

[fez_ajer]

Vex: Just an FYI, SitAfterCast was being set to 19hours to prevent a previous sit timer from expiring during the cast and interrupting it. SpellSub was supposed to reset the timer to the proper value afterwards, but that sit logic was moved out to calling routines in case a bot Do-command wanted to cast say 3 spells without sitting between them.

[Mortedamour]

*Beats Vexix for making him redo his 147 shortcuts AGAIN!* =P

[oddball]

I made some fixes to the code...
For this event sub, in botspell.inc

Change this:

Code: Select all

Sub Event_ImmuneSlow 
   /varset SpellFail 1 
   /call ChatOut 3 ${MasterName} "Can't Root or Snare this Target!" 
   /varset CTimer 0 
/return 

To:

Code: Select all

Sub Event_ImmuneSlow 
   /varset SpellFail 1 
   /call ChatOut 3 ${MasterName} "Cannot Slow this Target (Immune)!" 
   /varset CTimer 0 
/return 

If you want to detect root immunity, add the following event to the list near the top of botspell.inc

Code: Select all

#event ImmuneRoot "Your target is immune to changes in its run speed."

And somewhere near the other event subs, add the following.

Code: Select all

Sub Event_ImmuneRoot
   /varset SpellFail 1 
   /call ChatOut 3 ${MasterName} "Can't Root or Snare this Target!" 
   /varset CTimer 0 
/return 

Hope this helps.
This macro has been a godsend when trying to 4 box...

[Vexix]

Fez -- Thanks for the clarification on the SitTimer 19h thing. As I'm working through the code, it certainly helps to hear some history of why things were done in a certain way.

Mort -- Sorry about the rework! Hopefully the increased flexibility of these shortcuts will be worth it.

--Vexix

[Spanky_Monkey]

So on inc, I have a hotkey /g inc %t;/t bot assist

He will assist but like just decides halfway through the fight to not bother fighting or taunting or inciting anymore. Any ideas?

Spanky

[Rassilon]

Anyone know of a way to have the bot stop looking UP when a mob is dead? I have to use my Home key after each mob death so I can see where its going.

Thanks

[Omiime]

Anyone know of a way to have the bot stop looking UP when a mob is dead? I have to use my Home key after each mob death so I can see where its going.

Thanks

look for /face fast and put

/face nolook fast

[Vexix]

Fez or Lord Giddeon,

Can either of you guys let me know what the thinking behind the SupportStatus variable is? Had a run in today. My tank got caught by an AggroCheck bug (fixed in next update), and ran out into a bunch of mobs. He called an evac, and my evacer considered moving towards him, a la Do-Moveto, but then remembered he was on "support status," stayed where he was, and safely evaced. My tank on the other hand, didn't fair as well.

Anyone know where to put that nolook into /face that Omiime mentioned?

Spanky -- No clue. Was your bot rooted or something? Was he aggroed? Need more details. Is anyone else seeing this?

Anyone have a good way to check if you're rooted? Rangesub is eating a lot of time if you can't move at all.

--Vexix

[Omiime]

Code: Select all

    /if (${Me.Sitting}) /stand
      /face fast
      /if (${Target.Distance}<${FastMin}) /Keypress BACK hold 

anywhere you see /face fast
change it to /face nolook fast

if you don't want char to look way up

[Vexix]

Actually, the /face without the nolook has it's use. The reason Rassilon is looking up after his mobs is probably because he's fighting tall mobs, like giants. If you're fighting little things, afterwards you'll be looking at the ground.

I kinda like looking at what I'm fighting, so what I'll try to do is just add a /keypress Home after the battle is done. Seeing if I can put that in now.

--Vexix

[Mortedamour]

Mort -- Sorry about the rework! Hopefully the increased flexibility of these shortcuts will be worth it.

--Vexix

Eh. its nice. And dont take this as a complaint, because the new flexibility is awesome. but I miss LG's simple shortcuts.


soe=Spirit of Eagle

"soe" assumes it needs to assist
"soe target" assumes it is given a target

[blueninja]

One small annoyance with this that I found is that most stuff that checks if you are standing really only checks if you are sitting when you could also be feigned. For example Do-Stand only checks ${Me.Sitting} and won't stand up when you are feigned.

There are quite a few places where this should be fixed, I searched the files for /stand and found a few. I fixed a few of these in my files but since they are small simple fixes spread out all over the place I figure it's probably not much help if I post mine.

Thanks for keeping this great macro going..

[fez_ajer]

Vex: Combatstatus and Supportstatus...

They're both pretty much the same thing as far as letting the group know what the current enemy is. The only real difference is whether you should be swinging or not. I believe the idea is to have the puller do a single 'assist' call, SA and other melee's set Combatstatus and dive in. Necros, Wizzies and the like set Supportstatus and know that if you call for a nuke it's headed for the target.

Part of the problem is that when the switchover to MQ2Data happened, things weren't always working correctly. Some routines implemented ${Me.Combat} checks instead of using Combatstatus. In particular, something odd happens with clerics who swing. I can't find out why exactly, but if certain commands are called while the cleric is in his heal loop, when he goes to reset the target to the mob, he instead remembers the last person healed and merrily tries to beat on them a while.

Part of the problem (I believe) is that in ChkGroupHealth the Breakout tests will bail out without resetting the SaveCombatID value, although when I fixed that with /goto's it STILL happened /sigh...

In the time LG was away, my code has diverged quite a bit from the core Genbot. I've fixed some things, broken some others. I did find some problems that still live in Genbot, which are probably easier to describe rather than post fixes for. One big one that causes all kinds of oddities is that SpellSub can be called from events as well as from the main loop. That means that if you call /doevents from inside SpellSub (like we do) another command can call SpellSub, which does some wierd things for sure. I've tried to fix this here by two things:

1) When an event is triggered, add a command to a FIFO queue (mine actually has priorities) then next time through the Main Loop, pop the highest priority event and do it. This can't really work in genbot as it is because some events/routines can take ALOT of time to exit.

2) Since I tried to move all casting into the Main Loop, I had to put ALOT of delay timeouts into the code to prevent bad routines from hogging time from the Main Loop.

Another option is to do what spellcast.inc does and only call the /doevents that you need for casting spells to work (ie: Just call /doevents for the fizzle and spellcast checks)

Does all this stuff need to happen in Genbot? Prolly not. I did some really odd stuff just to make it work here. In alot of cases, what I tried was a truly horrendous idea :)

The above info *IS* useful though, because when you start to think about how individual events can affect the Main Loop, and visa versa, you can start to debug alot of the wierder things that can happen with your bots.

Sorry this is long, I've got about a fifth of bourbon in me... Memorial day and all!