NightDev Community Forums

$(twitch) when part of another variable

#1

I’m having some trouble using $(twitch) in urlfetch when it’s part of something else like eval or querystring

Works:

$(urlfetch something/?twitch=$(twitch $(query) “{{name}}”))

Does not work:

$(urlfetch something/?twitch=$(querystring $(twitch $(query) “{{name}}”)))
$(eval data=$(urlfetch json something?twitch=$(twitch $(query) “{{name}}”)))

In the former case I get the data I want to send to the remote service (i.e. the user name referenced) while in both of the two other cases, the remote service receives “Unknown Twitch Channel”.

Is this a bug or am I doing something wrong? I’m effectively using this to lowercase the username, so I’m also open to other suggestions to achieve that result.

(Note I had to edit the urls to make the forum spam filter happy; Of course I am actually querying proper URLs)

0 Likes

#2

Upon further inspection it seems that nightbot does not parse variables deeply enough. Something like:

$(urlfetch something/twitch=$(querystring $(querystring $(query)))) results in the remote service receiving “$(query)” (albeit urlencoded twice of course).

0 Likes

#3

@squidcharger

You are correct. Nightbot currently only allows for 2 levels of variable nesting, and beyond that, variables don’t resolve properly. For example, in your command setups, the $(twitch) variable will attempt to search up the channel name of a Twitch account literally called “$(query)” which will result in the $(twitch) variable resolving to “Unknown Twitch Channel”.

Also, in case you are wondering, this is not a bug of any sort. It’s an intentional restriction.

0 Likes

#4

Argh, thanks. I understand the need to limit this, but as demonstrated both by myself and the thread you reference, 2 layers is exactly one layer too shallow. At least I can’t think of a way to change the data in variables passed to $(urlfetch) without this type of nesting.

0 Likes

#5

You could work around it with command aliases, where you have commands passing input to other commands. This could eliminate the need to have variable nesting further than 2 levels.


Take the command responses you gave in your first post:

Let this response be for a command called !cmd1

$(urlfetch ...?twitch=$(querystring $(twitch $(query) "{{name}}")))

Let this response be for a command called !cmd2

$(eval data=$(urlfetch json ...?twitch=$(twitch $(query) "{{name}}")))

We can change !cmd1 into a working command setup by splitting it into two commands, !cmd1 and _cmd1, with !cmd1 aliased to (and therefore passing input to) _cmd1

!addcom -cd=5 !cmd1 -a=_cmd1 $(querystring $(twitch $(query) "{{name}}"))
!addcom -cd=5 _cmd1 $(urlfetch ...?twitch=$(query))

!cmd1 looks up the name given in the user’s input, URLencodes the name, and passes it to _cmd1 which performs a $(urlfetch) with the passed result.

We can do something similar with !cmd2 by splitting it into two commands, !cmd2 and _cmd2, with !cmd2 aliased to _cmd2

!addcom -cd=5 !cmd2 -a=_cmd2 $(urlfetch json ...?twitch=$(twitch $(query) "{{name}}"))
!addcom -cd=5 _cmd2 $(eval data = $(query); //some other code here, presumably)

!cmd2 looks up the name given in the user’s input, performs a $(urlfetch) with the name, and passes the $(urlfetch) result to _cmd2 which will probably run some JS script to manipulate the information in the passed result.

1 Like

#6

Oh clever, I’ll try that. Thank you.

0 Likes

closed #7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

0 Likes