From the lil reference manual:

If join is applied to non-table arguments, it produces a list by pairing adjacent elements from x and y. If either argument is a number, it is considered "range" of that argument, and otherwise it is interpreted as a list. For example, "ABC" join 3 gives (("A",0),("B",1),("C",2)).

As you can see, it has a preference for preserving the length of the left argument if they don't match. Some functional languages call this operation on lists "zip()". Applying "join" to tables performs a natural join.

If you simply want to concatenate lists and atoms, use the comma operator (,):

 a1,a2
# ("aa","bb","cc","dd","x")

(Lil doesn't have list literals per se, just atom literals and the comma operator.)

Does that make sense?

Hmm. Could be tricky to make this fast in Lil.

In general, using queries is much more efficient than loops. You can slightly simplify

where (on f x do "r" in x end)@value

as

where value like "*r*"

and you could hoist that "in" out of the loop, since it accepts a list as a left argument. Together, these ideas can make the query much more concise:

on strip x do "" fuse "r" drop x end
still:select word:value wod:strip@value
 where (strip@value) in words
 where value like "*r*"
 from words

...but probably not much faster.

You can also avoid stripping the r's twice by using a "subquery"

still:select where wod in words from
 select word:value wod:strip@value
 where value like "*r*"
 from words

You could use a conditional to compute the extracted column (this is evaluated once per group):

extract if count value first value else () end where 1<count index by value from str

Or you could use the "gindex" column to make the filter retain at most one element per group:

extract where (!gindex)&1<count index by value from str

How's that?

You could define a function which "wraps" the default play[] in the deck-level script, preventing the original from being called unless your flag is set:

on play x y do
  if options.widgets.soundsandmusic.value=1
    send play[x y]
  end
end

The "send" statement is specifically designed to make it easier to set up these kinds of overrides for existing functions. (Overriding go[] has some interesting potential!)

If you think there are some situations where you may want to call play[] normally, a less invasive approach would be to give your wrapper a different name instead of shadowing the built-in function, and to change e.g. all the instances of play["foo"] within your own scripts to sfx["foo"]:

on sfx x do
  if options.widgets.soundsandmusic.value=1
    play[x]
  end
end

Keep in mind that scripts within modules and contraptions don't "see" deck-level definitions, since they're supposed to be reusable from deck to deck. If you're setting up sound effects for dialogizer text, for example, you'll need to perform the same flag-check. This can also be done in a centralized place with deck-level functions.

Does that make sense?

Hello, welcome! I have a simple script for you. Where to put it is going to vary a little bit based on what you're doing.

If you're changing the number inside the slider by having the user click on it, you could put something like this in the slider's script:

on change val do
 if slider1.value > 69 
  button1.locked:0
 end
end

Or, explaining what that means: "Whenever my value is changed (by the user clicking on me), check if my value is above 69. If yes, unlock the button. End (for the if statement). End (for the on change val do event)."

This only unlocks the button -- it doesn't re-lock it if the number goes back down. I'm not sure if that's even something you want, but you could have it re-lock below 70 with an added "else":

on change val do  
 if slider1.value > 69    
  button1.locked:0
  else   
  button1.locked:1  
 end
end

I'm locking and unlocking the button in this example but you can use nearly the same snippet to change the button's visibility instead. 

Rather than using .toggle here I'd prefer to use .show just to feel like I had complete control over it:

on change val do
 if slider1.value > 69 
  button1.show:"solid"  
  else  
  button1.show:"none"  
 end
end

If you end up hiding the button you'll probably want to use .show:"none" rather than .style:"invisible"  in the script.

The difference between them is that even though "None" buttons are effectively locked AND hidden from view... Invisible buttons can still be clicked. This is useful for users who are drawing scenes and want to use buttons as containers for their clickable areas without the standard appearance of a button.

The above scripts are assuming that the slider's value was changed by the user clicking on it and that the script is inside the slider.

But if the slider's value is going up because of something happening in a script somewhere else you could add the "check if >70, unlock or show button" snippet to the end of that other script instead.

For example, a script inside a button which adds +10 to the value of the slider, and also unlocks a button if the new number is more than 70... could look like this:

on click do
 slider1.value: slider1.value+10
  if slider1.value>69
  button1.locked:0
  end
end

I hope this points you in the right direction! If this isn't what you needed, then I'm happy to try again.

I'm pretty sure the Style menu option is only available in drawing mode.

That said... I'm very curious what you're up to with tracing mode, if you're inclined to share.

I often make a timer in a basic widget when I need one.

A simple example:

If you make a field and set it to be "animated" (select the widget, then in the menu select Widgets > Animated) it will experience 60 view events per second.

Since this example is using a field we can also ask it to store a number to keep count of how many view events have happened. And when it reaches a certain number (60 view events multiplied by the number of seconds -- for 60 seconds this is 3600) tell it to do something special.

on view do
me.text:me.text+1
if me.text=3600
#the stuff you want to happen#
 end
end

(When you're writing a script inside a widget, you can refer to that widget as 'me', which is what I'm doing in the script here.)

This may not be needed but you can also make a custom event handler pretty easily:

on view do
me.text:me.text+1
if me.text=3600
my_event[]
 end
end

I'm using the example name "my_event" but you can name it something more specific and then define what happens during this event inside of the same widget's script that uses it (or on a higher level like the card or deck-level scripts) by writing it out like any other event handler:

on my_event do
# the stuff you want to happen #
end

Also there was a recent thread about making timers for someone else's game that has some more discussion, if it's of any use to you: (link here)

Yes, by sending events. A script on CardA can call function "foo" with the argument "bar" on CardB like so:

CardB.event["foo" bar]

This expression returns the result of the function call. In this way you can design cards that act as "APIs" to be called by scripts elsewhere in the deck.

You can likewise call .event[] on widgets. This "synthetic" event is indistinguishable to the target (thatButton) from an event generated by Decker itself:

thatButton.event["click"]

When an event is sent, all the deck parts and other magic variables will be in scope from the perspective of the target: widgets will "see" other widgets on the same card, "me" will be bound to the target, etc.

Yes! A widget's order placement can be modified with .index

For example:

on click do
 me.index:999
end

index:0 places a widget at the bottom of the order, index:999, or any other sufficiently large number, places a widget at the top.

You can put this snippet into an "on drag do" event handler as well.

If you refer to the Decker Reference Manual, grid widgets have a ".rowvalue" property that can be used to obtain the data in the selected row; this will be a dictionary. The "first" of such a dictionary will obtain the value for the first column:

on click do
 f.text:first g.rowvalue
end

In this particular example it would be equivalent to ask for the "key" entry of the dictionary, as that is the name of the first column:

on click do
 f.text:g.rowvalue.key
end

As for adding rows, it looks like you were consulting a very old example from before the "insert" syntax was overhauled. Given a grid "i" with a single column "name", I think you want something closer to:

i.value:insert name with "sworde" into i.value

The Lil Reference Manual has detailed explanations and many examples of the "insert" query form.

Does that make sense?

You may be looking for the "floor" primitive? There's no corresponding "ceiling" primitive but you can take the negation of the floor of the negation:

 select value down:(floor value) up:(-floor-value) from .1*range 21
 
+-------+------+----+
| value | down | up |
+-------+------+----+
| 0     | 0    | 0  |
| 0.1   | 0    | 1  |
| 0.2   | 0    | 1  |
| 0.3   | 0    | 1  |
| 0.4   | 0    | 1  |
| 0.5   | 0    | 1  |
| 0.6   | 0    | 1  |
| 0.7   | 0    | 1  |
| 0.8   | 0    | 1  |
| 0.9   | 0    | 1  |
| 1     | 1    | 1  |
| 1.1   | 1    | 2  |
| 1.2   | 1    | 2  |
| 1.3   | 1    | 2  |
| 1.4   | 1    | 2  |
| 1.5   | 1    | 2  |
| 1.6   | 1    | 2  |
| 1.7   | 1    | 2  |
| 1.8   | 1    | 2  |
| 1.9   | 1    | 2  |
| 2     | 2    | 2  |
+-------+------+----+

You can just say something like:

field1.text:alert["What's your name?" "string"]

Here’s an Ask button that asks the question, and sticks the response into a field:

%%WGT0{"w":[{"name":"field1","type":"field","size":[100,20],"pos":[154,108],"value":"blorp"},{"name":"button1","type":"button","size":[60,20],"pos":[174,74],"script":"on click do\n  field1.text:alert[\"What's your name?\" \"string\"]\nend","text":"Ask"}],"d":{}}

As a follow up, I’ve tried creating variables too, but it didn’t work either.

I’m trying to make an invisible counter tracking the amount of time a player visited a card (and could be reset), so like a numerical variable…

EDIT AGAIN: Counters. That’s how it works. then add +1 to the text. Got it.