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.