Let's say I have a grid widget like this:

The .value attribute of a grid widget is a table value.

Tables can be indexed by a string (a column name) to retrieve a column as a list, or by a number (a row number) to retrieve a row as a dictionary:

somegrid.value[1]
# {"fruit":"cherry","price":0.35,"amount":15}
somegrid.value.price
# (1,0.35,0.75,2.99,0.92)

Thus, if you want a specific cell, you can index by row and then column, or column and then row, whichever way you find convenient:

somegrid.value[1].price  # 0.35
somegrid.value.price[1]  # 0.35

Any questions?

Currently native-decker doesn't include a "stretch-to-fit" fullscreen mode.

Don't worry! Open up your file in a basic text editor (notepad or whatever you've got).

You'll see stuff at the top that looks kinda like this:

Change that line to say locked: 0 and you should be good.

If you haven't already read it, I recommend checking out All About Sound.

In a simple linear script, like part of a cutscene, playing sounds in sequence is straightforward with sleep["play"]:

play["sound1"]
# do anything else you want while the sound is playing...
# ...
sleep["play"] # wait for all playing sounds (sound1) to finish
play["sound2"]

In more elaborate cases, with sounds playing while a deck remains interactive, you may want to rely upon the loop[] event or keep track of your own timer to trigger subsequent sound effects.

Does this help point you in the right direction?

Since you're overriding this behavior on many cards, it's easiest to define an overload for the link[] event at the deck level; see Deck -> Properies... -> Script... via the menu. I'll assume for the sake of this example that cards are named with a "group_cardname" convention, so we can use the portion of the name preceding the underscore to determine whether two cards belong to the same group:

on link x do
 on groupname x do
  first "_" split x
 end
 if groupname[deck.card.name]~groupname[x]
  send link[x]
 else
  go[x "BoxIn"]
 end
end

Make sense?

You may have a different method of distinguishing groups, like invisible metadata fields on cards; I'd be happy to clarify how to adapt this approach to your deck, if needed.

Alright. So first up, you don't know how to code YET! You may yet learn to code. I think what you want to do is doable, if you are prepared to start dabbling in a bit of code. And as you get more comfortable you can try out more stuff

If you make a button and hit the "Script..." button, you'll see this pop up

on click do
end

In between is where we can put code that we want to run!

on click do
 app.save[]
end

With some more advanced coding, there are some other ways of saving out stuff but we'll start simple for now. But if you want a more complicated example, my game The Wayward Mage uses a custom save format that basically saves out the game state in a custom file.

If you set up a button to go to a card with a transition, and then open its script up you will see something like this.

on click do
  go["card1" "SlideLeft"]
end

It might be easier, with lots of cards, to basically use this but change the names of the cards manually in the code, like if you know you want to go to a card named "branch2a" you can just write that into the code.

If you're doing visual novel stuff, it could be easier to do things without needing a separate card for each screen. If you use the dialogizer and puppeteer modules that come in the Decker examples folder, they basically let you write and run a whole visual novel script with sprites and a background and text and such. So you're not using a whole card for just one screen of text - you basically just have a card for a background, and some cards to store your character sprites. And then a hidden field somewhere to stash your script. It's again a bit of simple coding, if you look in the dialog.deck and puppeteer.deck files in the Examples folder they'll have documentation.

Finally, if you haven't checked it out definitely take a look at Phinxel's Field Notes, it's a very thorough Decker tutorial that'll teach you some simple coding things among many other Decker tricks, and it doesn't assume any existing coding knowledge. Another thing I've found helpful is pulling apart other people's decks to find out how they did things.

Dialogizer runs in a "blocking" manner; Decker won't process click[] events or other interactions with ordinary widgets while Dialogizer is active, so you wouldn't be able to furnish that kind of functionality with ordinary buttons on a card.

You could, however, use the animate[] event that Dialogizer continuously emits while dialog boxes are open, in combination with the Pointer interface- which provides live-updating access to the state of the user's pointing device- to explicitly detect clicks on extra buttons.

If pointer.start and pointer.pos are within a given rectangle and pointer.up is truthy, you'll know the "button" corresponding to that rectangle was clicked. You could even physically have buttons with click event handlers on the card if you want. Presuming a button called "menu", you might have an animate[] script something like:

on within pos rect do
 min(pos>rect.pos)&(pos<rect.pos+rect.size)
end
on animate do
 if within[pointer.start menu]&within[pointer.pos menu]&pointer.up
  menu.event.click
 end
end

Make sense?

Note that this technique works best when a dd.ask[] dialog is open; ordinary dd.say[] dialogs will automatically advance for any pointer click irrespective of what else happens in animate[]. If you really want fine-grained control here you might need to make minor alterations to the dialogizer module itself. I'll ponder this kind of use-case and possibly make some enhancements to the module in the future.

You'll need to set the contraption instance itself to "Show Transparent".

You can do this manually, via the menu ("Widgets -> Show Transparent") or programmatically, by giving the contraption an internal script which initializes this attribute in response to the view[] event:

on view do
 card.show:"transparent"
end

I don’t believe so, no. Even though it looks a bit like Lua or Python, Lil’s functional-language heritage means there’s no shortcuts, no return or break or continue. This can make some things more difficult, but once you get used to thinking in that style you’re writing much more vectorisation-friendly code, and Lil’s vector operations are much more efficient than regular loops.

Lil doesn't have a keyword for performing an early return from a function, or otherwise an equivalent of break/continue for each/while loops or a throw/catch exception mechanism. All control flow is strictly structured and local.

For some situations where you might want to guard a clause, you can take advantage of the fact that if ... elseif ... else ... end structures, like all control structures in Lil, are expressions which return their result:

C:

int foo(){
 if(cond1){return a;}
 if(cond2){foo();return b;}
 bar();quux();return c;
}

Lil:

on foo do
 if cond1 a
 elseif cond2 foo[] b
 else bar[] quux[] c
 end
end

I encourage breaking functions down into fairly short definitions. You can nest function declarations within one another if you need "helper" functions that are only used in one place, and those nested functions will close over the lexical scope of their "parent" function.

Hi there! Welcome!

I'm going to start with two existing resources which do similar things along these lines so check them both out let me know if either of them do the thing you want.

An option that can make text appear word-by-word in a dialog box: the Dialogizer module (specifically this page's demo which shows the text showing up word-by-word)

An option that can make text appear letter-by-letter in a text field: the Typetext module. (Demo on the main page)

Are either of these similar to what you're looking for? I can write out instructions for how to use either of them.

Decker Sokoban uses the general strategy I described above. Level elements are aligned to a 32x32 tile grid, and every tile of the card background of a level that contains any pixels of pattern 20 (that diagonal slashed pattern) are treated as "solid"; note how I always use a layer of this pattern when drawing level boundaries:

Most of the work happens in the script of the card named "game". Paraphrasing,

CELL:32 # grid size
on isTile pos tile do
 (card.image.copy[pos CELL,CELL].hist[tile])>0
end
on isWall pos do
 isTile[pos 20]
end

The "isTile[]" function is also used to identify "goals", where blocks are supposed to end up on each level, identified with a different pattern.

Collision and movement animation/physics in games is a very deep and complex realm, but here's a simple demo for you to play with as a starting point: an animated canvas that moves around in response to arrow keys using the gamepad interface, and cannot move past pattern 36 (pink).

on view do
 each in range 3
  if !card.image.copy[me.pos+gamepad.dir me.size].hist[36]
   me.pos:me.pos+gamepad.dir
  end
 end
end

As a paste-able example:

%%CRD0{"c":{"name":"home","image":"%%IMG3AgABVgZAgHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAMKHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOAGQIJGzp5KdO30KLQKU59CjRY8iBap0aFGjTXsmjRM0qsGncKZaJYi1TdetXLWq+Qp2oFg0ZMsKPHuGrVqAac24ffsvLpm5dP3hDbM3776+XwD7xWdXjODB9w5vUUzpKVPElwqDYSzJsWTIjShf0QzJ8mXMij5zEW3JM2fQgE5TUd2YNWo+rqPErjz79Z3aTnB3fmw7M+8yuh+R7p36913jp4ITf6P8Z3NGw5fDRj7mOXTq0gVZRxKdU/fst7EbFj9qO/jjVdGaR/Rdiun35M+3z7KeffzV8PPPh1z/SH9D+xmh34CmnTdEgJvdFwqCOhHooGcG/iegggtS6F9++EGYHYNWSAighQfCt5hlG4LohYeFRPfeeCaWxWGHLXrnGHcYopeebSgSFWOCItrxYIFt7djUizDeWN2DPv4oZJFQoUYkk8Ap2SQdSLLxpE1XVrGdlCTW0SNVS/qU44VGjghkEhrGMiZJWWZYJhYrPtElLGuK1KabXcQp24x0hnnTnXia+SKgu73pIqFT4DYnnHVq56dMi4JpqHttIurbpEqlOcdshFq6SKMXnbmpa3zyBWofp04kKpVhlsoipqKkCtGqXrb6n6eH4KoRrbUuqWuIj9IG60ya4oHgr0Qg6+iwMUVqLKnBJhqtcNOC5Goezu7J7GSyJrltS8pqeS1+zFXrm5jdOheuqeYa6FW6aK575Lfu7gEvmfcySm+9z7Y7Wrb2+cuvXPkCW7C+Uw5cnMAIy0vwvgrL4TATxToyccSBhnfxwwljbC+8vFp8sMc6MiztuMJ2TLLGEHMbciQjryzEqTVGFvPKF3+JycYyU2yyui+31nLP6v1MI8A734yz0fgqbSPResiLsoxMQ32yyjZivQnPVjdt5dQL7+g0yXUiPV3FS3Dd9YRDC2r2qPrlNjbZVQP9thtKpq322iVrnYaecC+KdoN7822w338DXi7AUhrOctRgFy2Yg39USVzMd7+6b9zYclk3SzcPPu/Qivfq+dyzOp35v5/jfXrQh7b9tYSFa7464bVjhDrukpd2+9G7K7T7rcFrq2juFQ3fX/FyRi5u6yEFXx/ybsuuN/QfSf8z9fQ53z32HWlvfRPM+6wr9w6JjziP43fuIfoMwY+v5oXmKL/w4EMZ2P2Ull1+XahrjvcIMcDRvYV/MzNXAZeVv8MdsIH9W1/zEAiFvVGwIAvMSrQyGLb25el/eoHd4iR4PRA2jYSJg6BFuOS68f2ugygciwpX6Lk1QMuEbBvZBa/CwhSW7oT182DWEJO3IL1uh+RDIBJV9UL2HRFmAZwhSprIpBqmjIExzAsVP8i5SShPiFHhoDC+CMYhLfFSWZQYDiVyxtAUb41slGInmNdGGspxa3eM4MDgyMBc8fEhdfxQGW2YxykW0neHrGAiS/JHVIGwkelbJBQfCcn4SZJaOKzkQjTpLTBuUX/uCqQfntRFA/KLk2rc4ICidMnotdKPx1slK9PoF1QmkUCK1E1afmXLg/QSeEW0Gy2Bmcph0uWXfTvilD7ptWKe8pWsU6Yso8mqQWYKmt8TXQ6nSc3APdOaLBPj4USYMUkZ84HgrCYzt5lO3nmzXpUk58faqUd4YjOX4nxc4M4ZO36G854lNJ096UlIUSarW8g0C0DNR9B3NXSC/uRIQ+Fo0Pm9E1LbWyjQvCirhGpjPQatKDHNSZPpadSiQntoQIlltEyeNIIRBWWzWkrJl9azhTHNyPJsmkCVFtOnySwp02qa01FKjaft2ClQXVZUo6JIpOhQ6lJPhNSrNZWhWKra/zza07px9aNa5elXcfdQqEY1rDYdK1npadaz+rR8al2rAvM5EtqJ9aoE1Kbc9Aour8YVjd4LZlb9OlViSPOHNbFrVZNz2MXO432OZezrrALZyEpWZ8esbGEdR4un/pWzjlwqXUF7DGWNlrTG4CVfUeuM88mTtcvwFFZOC9tgmOcrtE3Za2uLz3Tu8rPj5CZvG4ZXt+Q2EVYcbjatOZd1Bux0yiVuTiWzWkx+BrPR7a0Hr7vb526uutllp68Og1jAuum4sAVvMlFYXje6UL3hDS5M04hd98bUubwVIXzFW1Fdore2T1xud/UZTbySFroFttw8r9rWMAqWqj8KbXGBCxPhZq1m7gNng+NrYdMZmMKsxZzANhzfkWb4wyA+8CU7lWLOwm9Lli3xSiE34hY77r/7ayeJZXzQg93WxobDb44NbDAe2wzH2RyikRFpQZpudsky3O+QZwnlpEm5m6a8XpWRO2BBzdJvO45ue/fauC93TMhb/qnYlMmxDqcZlipqLJF7XMo3X0fOZTbzle3sVATD1Iho5jONH2xVQaeWcm4ztDzCrGiqzbnRzWA0pDMB5EmnqNKWHgSmMx2ITXO6cp7+tIRFnY5Qk3rQpz6HpFNtXVaXw9SuFmisxQHrWTvT1uCoNa5HuOtv6LrXs3s0sHPx62H70NjbKDayObbsbCi72VmGNjWeLW2mVrsa1L42F4WtbVdku9taQDK4ZbHnceOivuYeY4TTDYx1s7vdbn53L8Ys73rb+974zre+983vfvv73wAPuMAHTvCCG/zgCE+4whfO8IY7/OEQj7jEJ07xilv84hjPuMY3zvGOe/zjIA+5yEdO8pKb/OQoT7nKV87ylrv85awOAg==","widgets":{"bug":{"type":"canvas","size":[21,17],"pos":[89,204],"locked":1,"animated":1,"script":"on view do\n each in range 3\n  if !card.image.copy[me.pos+gamepad.dir me.size].hist[36]\n   me.pos:me.pos+gamepad.dir\n  end\n end\nend","border":0,"image":"%%IMG3ABUAEQZAgHBILAaOxSQAuQyAngHl0Ak6Pq9VKbWKxUaT2233Oz2az+Kvucumqtlw6DsOJ7u9cTuenhWGq2JjU3yCRIFXd2SGaIxRioZGflJTkZNB","scale":1}}},"d":{}}

(There's a lot more this would need to make it feel good to play, like giving the bug animation, a sense of velocity and weight, allowing it to "slide" past walls while touching them, a smaller bounding box, etc.)

Is it possible you've named a card "sleep" or defined a function in the deck-level script that likewise shadows the built-in sleep[] function?

Normally if you type "sleep" in the Listener and evaluate it with shift+enter you should see a response like

on native x do ... end

If it's being shadowed by a card you might instead see "<card>", for example.

Here's a somewhat more compact approach that is roughly equivalent to your script:

dirs.face_north:compass_n
dirs.face_east :compass_e
dirs.face_west :compass_w
dirs.face_south:compass_s
 
each canvas name in dirs
 canvas.toggle["transparent" deck.cards.f.widgets[name].value]
end
 
compass_neutral.toggle["transparent" (!sum "transparent"=(range dirs)..show)]

If you want your contraption to update in response to a change in state elsewhere in the deck, you will need to somehow notify the contraption of that change. There are a number of ways to accomplish this. For example, if you wrapped the script you describe in an "on view do ... end" event handler defintion, you could also expose a way for code outside the contraption to fire that view event:

on get_update do
 view
end

And then fire it from the outside when appropriate:

mapArrowContraption.update[]

You could alternatively make a widget inside the contraption "animated" and use the view[] event that fires at 60hz to poll for changes to player direction on each frame, but this type of polling approach should be used sparingly; if lots of contraptions work this way it can add up to your game doing quite a bit of redundant work every frame!

You might also find this thread relevant.

Does any of that help point you in the right direction?

One way to set an entire column of a table to a numeric value is to perform an assignment like this:

grid1.value.done:0

This expression produces a new, updated table. If we want the change to be reflected in the grid, we need to assign the result to the grid's .value attribute, so our whole "clear tasks" button script might be

on click do
 grid1.value:grid1.value.done:0
end