Incoming Chat Handling

[Gnits]

I would like to request something that combines the #Chat command with the event command

How hard would it be to have mq2 react to an event like this:

#event tell CurewRGC "#1# tells you, 'Cure#*#'"

such that the event only triggered if that cam in through a tell?

This could make event processing so much more precise.

Again, I do not know how hard it is to do.

But for backwards compatibility you could choose a new compiler directive and do...

#chatevent tell CurewRGC "#1# tells you, 'Cure#*#'"

So that macro developers could migrate to this and not have it break every script out there doing it. I assume as text is coming in that you know what source it is coming from since there is the '#Chat' command.

[Kroak]

Typical macro...

Code: Select all

#chat tell

Sub main
  Do some stuff
/return

Sub Event_chat(MsgType,MsgFrom,MsgText)
  /if (${MsgType.Equal[tell]}) /dosomeotherstuff
/return

That what you're looking for? Actually... To be any other chat, you would have to add #chat chat or #chat group to the top...

See the wiki at http://www.macroquest2.com/wiki/index.p ... d_Commands

[Gnits]

Typical macro...

Code: Select all

#chat tell

Sub main
  Do some stuff
/return

Sub Event_chat(MsgType,MsgFrom,MsgText)
  /if (${MsgType.Equal[tell]}) /dosomeotherstuff
/return

That what you're looking for? Actually... To be any other chat, you would have to add #chat chat or #chat group to the top...

See the wiki at http://www.macroquest2.com/wiki/index.p ... d_Commands

Yes that does work, but it's not as refined as i am talking about. what if you want to react to tells, group say, specific channels, etc. With an improved chat event handler the abilties go up and the simplification of the scripts to their purpose becomes apparent.

Very few of us use little tiny scripts. Most of us use some form of continuously running script of some sort that has grown over time to suit our own play style. So limiting it to one doesnt help.

[jacensolo]

Um... If you have something like your theoretical code:

Code: Select all

#event tell CurewRGC "#1# tells you, 'Cure#*#'" 

This is (my best guess at) what happens:
1. You get a message.
2. It checks the channel and text to find a match.
3. If one matches, it calls that Event.

Here is one way to do the code now:

Code: Select all

#chat tell
#chat ooc

Sub Event_Chat(type,sender,line)
 /if (${type.Equal[tell]} && ${line.Find[blahblahblah]}) {
  /dothis
 } else /if (${type.Equal[ooc]} && ${line.Find[thisstuff]}) {
  /dothat
 }
/return

This way does this:
1. You get a message.
2. It checks the channel and text to find a match.
3. If found, it runs the commands.

Another current way:

Code: Select all

#event GotTell "#1# tells you, 'blahblahblah'"
#event GotOOC "#1# says out of character, 'WTB Sword of Uber!!!'"

Sub Event_GotTell
 /dostuff
/return

Sub Event_GotOOC
 /dootherstuff
/return

This code checks directly for matching text, so more streamlined, but less accuracy. (Personally, I hate using any events that start with a param or #*#, because it offers the possibility of faked notifications.

As you can see, the first built in method offers equal accuracy with equal efficiency to your version, while the 2nd offers more efficiency, with a loss of precision.

[Gnits]

From the documentation...

Code: Select all

#chat channelname
Defines which channel chat events will be queued from.

Valid channels are: auc, chat, guild, group, ooc, say, shout, and tell.

Only one channel may be used.

So that wouldnt work, because only one type can be used.

[fearless]

Code: Select all

#chat auc 
#chat chat 
#chat guild 
#chat group 
#chat ooc 
#chat say 
#chat shout 
#chat tell

Sub Main
:foreverloop

/delay 2
/doevents

/goto :foreverloop
/return
/end

|type,sender,line = string
Sub Event_Chat(type,sender,line)

/echo ${type}
/echo ${sender}
/echo ${line}

/if (${type.Equal[tell]}) {
  /echo ${sender} sent me a tell and it said ${line}
  /if (${line.Find[give me some buffs bitchaz!]}) {
    /target ${sender}
    /cast "some buff of holy fucking shit"
  }
}
/return

No, there are not any other macros that use Event_Chat. At all. None. Ever.

[Gnits]

(didnt look before i posted) I forgot this was a macro request forum... what i really meant to ask was an additional type of event type.

Event_Chat is great but the problem i have is when dealing with distributed (IE compartmentalized into include files) macros where one tries to keep things organized into those include files for debugging.

Nearly every bot type tries to do this and so does krust.

so while event_chat definately could do it if all responses were centrally managed in that one event, that is not always very convenient when looking at over all macros where there are mutltiple files.

So i guess i am not looking for is not so much a macro (snippet), so much as a change to the source to allow for a specific event to be triggered, if the text matches FROM a specific source, not to jump to some central clearing house and from there branch off to what ever subroutine is needed.

If i were to rebuild the macros i used from scratch it is feasible to do this.

To me this seems like a refinement of the incoming text management already in the base source code. (this is a n00bs point of view as i have very little knowlege of C coding at this level).

I can tell you that this type of function when working is worth some decent paypal money from me when its up and running, and i can see it benefiting others, too.

Gnits

[dewey2461]

The way I've seen it done is something like this: (Taken from Sym's MCS code)

The nice thing here is you can toggle which channels you want to respond to on the fly. This also has code to redirect tells / chat coming from others into a channel / irc so you can see whats going on from another toon if you wish.

Code: Select all

#chat group
#chat tell
#chat raid 

#event DoTell "#1# tells you, '#2#'"
#event DoTell "#1# told you, '#2#'"
#event DoGroup "#1# tells the group, '#2#'"
#event DoIRC "<#1#> #2#"
#event DoIRC "[#1#(msg)] #2#"
#event DoRaid "#1# tells the raid,  '#2#'" 
#event DoRaid "#1# tells the raid, '#2#'"
#event DoGuild "#1# tells the guild, '#2#'"

// stuff 

Sub Event_DoGroup(string line, string Requestor, string Request)
    |/echo Line -${line}-
    |/echo Requestor -${Requestor}-
    |/echo Request -${Request}-

    /declare isTrusted int

    | First check if allowed to command MCS
    /call isValidUser "${Requestor}"
    /varset isTrusted ${Macro.Return}

    | If they are not a Master then check if we should resend thier tells to channel
    /if (${ResendGroup} && !${isTrusted}) {
        /call chatty "${Requestor}" "the group," "${Request}"
        /return
    }

    | Added to stop above from not catching ! Trusted
    /if ( !${isTrusted} ) /return

    | They are Master lets check to see if it is a command
    /if (${UseGroupChat}) /call ProcessRequest "${Requestor}" "${Request}"

/return


Sub Event_DoIRC(string line, string Requestor, string Request)
    |/echo Line -${line}-
    |/echo Requestor -${Requestor}-
    |/echo Request -${Request}-
    /declare isTrusted int 1

    | If they are not a Master then check if we should resend thier tells to channel
    /if (${ResendIRC} && !${isTrusted}) {
        /call chatty "${Requestor}" "irc," "${Request}"
        /return
    }

    | Added to stop above from not catching ! Trusted
    /if ( !${isTrusted} ) /return

    | They are Master lets check to see if it is a command
    /if (${UseIRCChat}) /call ProcessRequest "${Requestor}" "${Request}"

/return

Sub Event_DoRaid(string line, string Requestor, string Request)
    /echo Line -${line}-
    /echo Requestor -${Requestor}-
    /echo Request -${Request}-

    /declare isTrusted int

    | First check if allowed to command MCS
    /call isValidUser "${Requestor}"
    /varset isTrusted ${Macro.Return}

    /if (${ResendRaid} && !${isTrusted}) {
        /call chatty "${Requestor}" "the raid," "${Request}"
        /return
    }

    | Added to stop above from not catching ! Trusted
    /if ( !${isTrusted} ) /return

    /if (${UseRaidChat}) /call ProcessRequest "${Requestor}" "${Request}"
/return


sub ProcessRequest(Requestor, Request)

// Big ass set of if statements that parses the requests and does what ever the command is.


/return 

[dont_know_at_all]

If you have these:

Code: Select all

#event DoTell "#1# tells you, '#2#'"
#event DoGroup "#1# tells the group, '#2#'"
#event DoGuild "#1# tells the guild, '#2#'" 

You don't need:

Code: Select all

#chat group
#chat tell
#chat raid

[fearless]

(didnt look before i posted) I forgot this was a macro request forum... what i really meant to ask was an additional type of event type.

Event_Chat is great but the problem i have is when dealing with distributed (IE compartmentalized into include files) macros where one tries to keep things organized into those include files for debugging.

Nearly every bot type tries to do this and so does krust.

so while event_chat definately could do it if all responses were centrally managed in that one event, that is not always very convenient when looking at over all macros where there are mutltiple files.

The reason the large macros are split into separate files is because of the forum software. Each post can only have so many lines. To reduce copy / paste errors, it was easier to split the macro into post length files. Beyond that it is personal preference to have separate functions split into separate files, though it is not my preference and certainly not others.

So i guess i am not looking for is not so much a macro (snippet), so much as a change to the source to allow for a specific event to be triggered, if the text matches FROM a specific source, not to jump to some central clearing house and from there branch off to what ever subroutine is needed.

What? From what source? From a tell? From a certain character? From your group?

Aside from your lack of specificity, there's about 17 different ways to handle chat. If you could be more specific, perhaps even give examples of what type of chat events you want to handle and in what way, we could give you a better answer.

[Gnits]

Ok, Fearless, that was a very helpful response. At least it told me where to be more specific. So here goes...

The reason the large macros are split into separate files is because of the forum software. Each post can only have so many lines. To reduce copy / paste errors, it was easier to split the macro into post length files. Beyond that it is personal preference to have separate functions split into separate files, though it is not my preference and certainly not others.

Ok, I had not realized that but it makes perfect sense. But it also makes it easier to troubleshoot smaller sections. (At least it does for me)

The idea behind this was to have a specific event only trigger if the text matched one of the 'named' sources. I thought that if the command were implemented into the main source for chat handling (is that what detour does?) that the handling would be faster.

Basically it defines a new event type like chat or event but it is specific to the source of the text involved.

But it needs to be generic enough to be useful enough in the main sourcecode. IE some new # command that defines an event but only applies the matching to the text if it comes in from a specific major named general source (ooc, tell, raid, channel, auc, etc. not name specific like a person, that would have to be handled by where it came from like tell or guild)

To be implemented something like this...

Code: Select all

#ChatEvent CurePerson tell "Cure me"

Sub ChatEvent (sSource as string, sFrom as string, sLine, (then the #1# type items like normal events)

So that "Soandso tells you, 'Cure me'"
triggers that event because Cure me is in the tell

So yes there are lots of ways to do this and of course macros can do this, too. I really feel this is valuable to more than just me as this provides a decentralized way of handling incoming chat.

[dont_know_at_all]

No. Filter the sender in the chat handler. You don't gain anything by prefiltering.

[TehWraith]

Lets look at this, you want...

A way of telling where a event came from... (#event CurePerson "#1# tells you, '#*##2##*#'")(assuming I remember my MQ2 right)

A faster way of handling said events... (still have to wait for /doevents)

And a decentralized way of doing incoming chat... (because we need people asking what is better)

On top of all of that, the extra code work involved to the source, vs the code work to make proper events from your macro.

In the end, you want more cross bot communication get ISXEQ and learn about relays, or implement, bug test, and do all the support for this yourself, because from my standpoint you are reinventing the wheel for some syntax sugar.

[xyilla]

люби

[xyilla]

242