Author Topic: Reference root command in subcommand?  (Read 934 times)

Robertsmania

  • Newbie
  • *
  • Posts: 46
Reference root command in subcommand?
« on: February 23, 2022, 11:33:05 AM »
Is it possible to reference the root command that called a subcommand?

I was optimistic that {LASTSPOKENCMD} would work, but it strictly does return the last "spoken" command which is not always the case for my root command.

In my case I have root commands that are sometimes executed from the command line.  I can use {CMDACTION} inside the subcommand to verify that the root command was called as 'External' but it would be really helpful to know which command is the root.

My goal is to have a common command that I execute at the start of any command that could be called from the command line.  It checks a boolean to see if its okay to execute chat comands and aborts if not.

Here's a snip of what I tried initially.  If I verbally call a root command, and then run the same one from the command line, then LASTSPOKENCMD token resolves to the same root and it works.  But if I verbally do something else and then call something from the command line LASTSPOKENCMD still references the last verbal command.

Code: [Select]
Begin Condition : ([ChatCommandsOk] Equals False AND [~passedText1] Has Been Set)
    Write [Blue] 'ChatCommandsOK is False, aborting {LASTSPOKENCMD} sorry {TXT:~passedText1}' to log
    Say, 'Sorry {TXT:~passedText1} its not a good time for Pit Girl commands. '
    Kill command, '{LASTSPOKENCMD}' (by name)
    Exit Command
Else If Text Compare : [~passedText1] Has Been Set
    Write [Blue] '{TXT:~passedText1}' to log
    Execute command, 'B2 acknowledge viewer' - passing values (and wait until it completes)
End Condition

I've combed through the documentation, and dont find anything obvious.  But would hope there is something like ROOTCMD?

Robertsmania

  • Newbie
  • *
  • Posts: 46
Re: Reference root command in subcommand?
« Reply #1 on: February 23, 2022, 12:09:28 PM »
I figured out a way to do it.  We can pass in the "{CMD}" token as a parameter when executing the subcommand and then reference that from within.  I'm already passing in a text value for the calling user's screen name.  So ~passedText2 is the {CMD} token from the calling command.

~passedText1 is not set when I call the command verbally, so that avoids the check and executes.

Code: [Select]
Begin Condition : ([ChatCommandsOk] Equals False AND [~passedText1] Has Been Set)
    Write [Blue] 'ChatCommandsOK is False, aborting {TXT:~passedText2} sorry {TXT:~passedText1}' to log
    Say, 'Sorry {TXT:~passedText1} its not a good time for Pit Girl commands. Aborting {TXT:~passedText2} '
    Kill command, '{TXT:~passedText2}' (by name)
    Exit Command
Else If Text Compare : [~passedText1] Has Been Set
    Write [Blue] '{TXT:~passedText1} called {TXT:ROOTCMD}' to log
    Execute command, 'B2 acknowledge viewer' - passing values (and wait until it completes)
End Condition

Gary

  • Administrator
  • Hero Member
  • *****
  • Posts: 2832
Re: Reference root command in subcommand?
« Reply #2 on: February 23, 2022, 12:16:52 PM »
I was going to suggest pretty much just what you have indicated (I think mine had more to do with command shared variables)  :)

There is no root command token, as a command can be called several levels deep.  I can look at making a {CMDPARENT} token that would serve what you are trying to do - and maybe add a {CMDROOT} and/or a delimited lineage (which might need to rely on internal ids that are set by the profile author).   Just spitballing ideas ;)

Robertsmania

  • Newbie
  • *
  • Posts: 46
Re: Reference root command in subcommand?
« Reply #3 on: February 23, 2022, 12:34:03 PM »
Thanks for the prompt reply!

Passing in the {CMD} token and referencing it as a ~passedText variable does work fine for me. 

It might be convenient to have {CMDPARENT}/{CMDROOT} or something but its not really necessary and would probably introduce risk or increase complexity somewhere else...

My main goal was to be able to drop the call to the subcommand in any routine without having to do any local setup or variable maintenance in that root command.  This seems to work well.