Genbot v13.3.2 [Updated 08/08/2004] Slim trim code rewrite!

[gus]

Vexix, sorry, I missed your reply on the .ini settings.

I mean unsightly only in the sense it's not consistent within the ini file. I'm a consistency freak when it comes to things like coding style, bad habit of mine.

While genbot might not care about case, my sed scripts sure do. So I've got no choice (well I do, but cure worse than disease). And whenever I upgrade to a new genbot, I always create a brand new template .ini (/macro Genbot master, /end), so I've got to match against whatever you use there.

You're maintaining genbot, do what ya want. :)

Enough posting for today, I got a day off, time to play EQ!

--gus

[Charisa]

These may or may not be actual bugs, but they are things I found when playing with the latest version of things today or suggestions I ran across while thinking.

1) Resisted debuffs don't seem to be automatically recasted. Is this by design? Can we maybe make an ini setting to toggle it and have it be an option?

2) Stopforheals if enabled will spam the group about stopping the current buff over and over and over and never do a thing. i finally turned it off

3) Change sitaftercast to be disabled if you have yaulup turned on. If you do yaulp and then sit you loose the yaulup buff so why have it enabled. Just seemed like a good idea

4) When i did an evac command it came back saying it was creating an anchor at the current spot before it cast, is this by design? That could be a bad thing.

Charisa

[gus]

Addendum to a few posts back... updated the IRC event subs to unify them with standard chat processing. With this change, just need to use ListenChan as 'IRC'. In particular this change allows Bot only commands to be broadcast in IRC without duplicating the logic of Event_Chat.

Code: Select all

Sub Event_IRCMSG(string IRCText,string IRCSender,string Command)
   /call Event_Chat IRC "${IRCSender}" "${Command}"
/return

Code: Select all

Sub Event_IRCSAY(string IRCText,string IRCSender,string Command)
   /call Event_Chat IRC "${IRCSender}" "${Command}"
/return

Now, folks might not like IRC being treated as ListenChan. If not, we could lie and send them as GROUP/TELL events. Or, we could modify Event_Chat to specifically deal with IRC chat type as "always" on.

--gus

[Vexix]

Using names instead of IDs for PCs was intentional. PCs hang around, zone, come back, follow you, etc, but the ID could change. I'd have to check, but I think that switching to IDs for PCs would mess up the buffing routines if you zoned, and the PC ID changed.

I've thought about the issue with Bob and Bobo a bit, and here's how I'd like to handle it. Under the PC section of RefineTarget, put in a SpawnCount[pcnamvarwhatever]. If it comes up with more than one match, then use the exact name match code from snippets: http://macroquest2.com/phpBB2/viewtopic.php?t=8641

That should take care of little bob and bobo, without loosing their auto-buff on zoning.

--Vexix

[gus]

Update: Jeez, didn't see Vexix's reply above. Good point, about the ID changing, I totally missed that we needed a canonical cross-zone name for buffing to work. Duh. True exact name match is the way to go.

---

Ok, had time to think over the Refining target thing. The original thing I tried failed with name only targeting (no qualifier like: id, pc, etc).

The following will still get a valid typed target. Instead of turning an ID of a PC into just a Name, it now turns a Name into a typed name and an ID, and an ID into a typed Name and the same ID.

Code: Select all

Sub RefineTarget(string RFTarget)
   /if (${RFTarget.Equal[assist-]}) /return assist-
   /declare RFTargetID int local ${NearestSpawn[pc ${RFTarget} radius ${MaxTargetRange}].ID}
   /if (${RFTargetID}) {
      /varset RFTarget pc ${Spawn[${RFTargetID}].Name} id ${Spawn[${RFTargetID}].ID}
   } else {
      /varset RFTarget ${NearestSpawn[${RFTarget}].Type} id ${NearestSpawn[${RFTarget}].ID}
   }
/return ${RFTarget}

Both this version and current version in Genbot fail for pets. For example, in the case of calling a 'buff on %t' where we have a pet targeted, it fails because the target name is "Player`s warder" when the spawn has a name of "Player`s_warder00". Might be able to handle that case by doing a secondary pet spawn search after replacing the spaces with an underscore? I'd try it out, but I'm not seeing a "replace" function on String in the manual. Coding a replace via a macro would be uber inefficient.

--gus

[Vexix]

Gus? Did you look at the exact name matching snippet I linked to above? That's what you're looking for. Take a read over my post above again about using SpawnCount. That's the way we want to head.

Not sure about the pets thing. I thought that was working ok at the moment since I haven't heard much issues with it.

I already have a StringReplaceAll sub and a ListReplacebyArg sub in botcore.inc. Less efficient than having a datavar for it, but it works until someone codes them up and puts them into the MQ2 base.

--Vexix

[gus]

I was in the middle of finishing that message when you posted (took me a couple hours, went out for dinner). Hence the update at the top after I noticed your post. I don't feel it is proper to delete a message once I write it.

I agree, a uniquness check followed by a name scan will work.

I'm certain buffing on pet's isn't working for me (at least 3rd party buffs, no idea if pet owner can buff). I'll make sure I revert to old RefineTarget, but since pet's aren't pc don't see it making any difference (only tweaking pc part of sub). My wizzy won't nuke a necro pet as well.

Unfortunately, my spare time for the weekend is over, back to work. Won't be able to work on anything else until next weekend.

--gus

[Vexix]

Understood re: your post.

Lol. Pets are a PITA. If you want more fun, look at how I've tried to accommodate defend and combat target to allow you to attack pets of NPCs.

There have been a couple of ways that attempt to deal with pets. I think I'll take a look at it. I think it was Nosaj a while ago who suggested a MasterName-pet type syntax for buffing them. This might be one way to make it work. Store by mastername and then specify pet of that master, so genbot will use ${Spawn[pc mastername].Pet.ID} to find the pet. Would also help for zoning now that pets can do that too.

I'm at work too, which is why I'm not testing or replying to your. . . er, wait. I am replying. Nevermind!

--Vexix

[dman]

Just an event I've added to make life easier if I can't send a normal tell, ie if I happen to be on FV.

Code: Select all

#Event AltTell "#1# told you, '#2#"
#Event AltTell "#1# tells you,#*#, '#2#"

Sub Event_AltTell(string line, string sender, string text)
|  /echo AltTell ${sender}    ${text.Left[-1]}
  /call Event_Chat TELL "${sender}" "${text.Left[-1]}"
/return

This grabs tells in alternate languages, and tells from ;tell

[Bahumut]

first, the puller toggle doesnt seem to do ANYTHING. Secondly, when i try to turn on guard for a character, it gives me /varset DoGuard not recognised or something, throws 4 or 5 lines of debug, then toggles itself off. about to head to work so i cant get exact message, but will post when i return. ugh, note to self....dont down quad shot mochas when you gotta work in the morning.

[Vexix]

dman -- Nice work on the other forms of tells. I'll use that to make a version that works for tell windows as well.

Bahamut -- The role of the puller toggle is kinda subtle. Basically, it's to be used with the anchor command. The puller toggle enables the bot to leave the anchor point until he gets hit by some mob, at which point he goes running back to the anchor point, and turns the puller toggle off. You have to set it again next time you want him to pull. It's not automated yet, in that you have to send the bot to somewhere that a mob will whack on him, so he will pull it back to the anchor point. I'll work on this some more when I start working on the pulling routines.

Give me the errors for the DoGuard bit, and I'll take a look at it.

Charisa -- Looked back at your message on stopforheals. Did you add in the /return statement a few posts back? If so, and it still spammed you, then I'll take another look at it.

--Vexix

[Bahumut]

tried turning the guard toggle on, and get this...
/varset failed, variable 'DoGuard' not found
botcombat.inc@166 (Toggle-guard): /varset DoGuard 1
botmain.inc@228 (SetToggle(string Name,string newValue)): /call Toggle-${Name} ${newValue}
botcore.inc@771(ExecCommand(string CommandText)): /call SetToggle ${CurrCommand.Lower} ${CommandParam}
botcore.inc@1132 (Event_SelfEcho(string EchoText)): /call ExecCommand "${EchoText}"
botmain.inc@66 (Main): :MainLoop

*Edit* i tinkered the hell out of this, and i have no idea how to fix it, i tried changing the toggle name, the name on 166, and a few more things, and nothing worked....hope you can make more sense of it than i can. worst part is, i used to be a coder....but i lost my touch, and i cant even figure out something simple like this

[gus]

Shot in the dark, try this:

Code: Select all

Sub Toggle-guard
   /if (${CommandParam.Equal[${Int[${CommandParam}]}]}) {
      /varset Toggle-guard 1
      /varset GuardRadius ${CommandParam}
   }
   /if (${Toggle-guard}) {
      /if (!${IsAnchored}) /call ExecCommand anchor
   }
/return

The old DoXXX toggles were removed recently. I'm guessing that's one reference that got missed. Just replace DoGuard with Toggle-guard which appears to be the new toggle varible syntax.

Blah, blah, untested, blah blah, use at your own risk, blah blah.

--gus

[Charisa]

Nope I missed the correction on the return. I'll fix that tonight and try it. What about the other stuff (especially recasts on resist), I know there was a fix at one point posted on one of the old copies, is that still the same fix? And is there any chance of maybe getting an .ini toggle to turn it on and off instead?

[zigzags]

just a quick observation, it seems as though when I am grouped with a genbotted cleric, he casts a double cheal on my pet very often (almost always), but when I am ungrouped and am having the cleric do a /watchtarget jobober there doesn't seem to be an issue with double cheals...

Is there an extra cheal being queued somewhere by mistake, or is the lag any different whether grouped or ungrouped?

I'd a newbie at this mq2 coding, so I don't know what other kind of info i'd need to post to help fix it....just lemme know and I'll do what I can.