The js_decker_html variable should be defined in c/resources.h which should be automatically built when it needs to be.

If you rm c/resources.h and then make V=1 c/resources.h do you get any error message?

So this might help a bit, but basically there's two ways of setting the colour/pattern of text in a field. It sounds like what you're doing is using the "select a bunch of text and change it with the text menu" option, which yeah does seem to not affect newly added text. But you can also select the field in widget mode, go into the properties (double-click or widget -> properties) and then there's a "pattern" button. If you set the pattern or colour there, that becomes the default for that field, so when you're writing into it in interact mode it'll come up as the colour you want. Hopefully this helps / makes sense.

With the selection still active, you can choose "Edit -> Resize to Original" or "Edit -> Resize to Card" from the menu to preserve the original dimensions of the image or snap it to the dimensions of the card, respectively.

Hi! I'll do my best to answer your questions, but please let me know if anything doesn't make sense to you, and I will try to explain more clearly.

1:

When you're doing the style settings in Dialogizer, there's two key attributes to get it to animate with sound. The first is "tsound" which specifies a sound to play for each word, and the second is "speed" which specifies how fast or slow the text will appear.

For example, if you have a script in a field and a sound:

o:()
o.tsound:"sound1"
o.speed:3
dd.open[deck o]
dd.say[field1.value]
dd.close[]

2:

When you play a sound using the "play" command you can specify that you want it to loop. When you do this then it will loop continuously including over other cards, until a command is used to stop it.

To start a sound:

play["sound1" "loop"]

and to stop it:

play[0 "loop"]

3:

One way to make it easier to keep animation frames consistent and lined up is to use the grid functionality. When you're in drawing mode, in the View menu there is an option to "Show Grid Overlay" which will add a grid to the screen that you can use to line everything up. And if you click "Grid and Scale..." then you can change the size of the grid if you need to.

4:

Yes! As part of the setup for Puppeteer, you will have added an "on animate do" function - this is what Dialogizer uses to work at the same time as Puppeteer and other scripts. So if you add the zazz commands here then they will run as well.

For example, in a current project I have this in a card-level script to make the zazz animations work.

on view do
 zazzanimations[]
 go[card]
end
on zazzanimations do
 zazz.flipbook[coffee coffeeframes 0.0015]
end
on animate do
 zazzanimations[]
 pt.animate[deck]
end

I've put the zazz command in its own function so that I only have to change it in one place.

5:

So basically you will need to create a separate card with checkboxes on it, to store the values. E.g. make a card called "flags". Then you add a checkbox on this card named "gotkey"

You can in your code refer to the value of this card like so:

#to get the value
flags.widgets.gotkey.value
#or to set the value
flags.widgets.gotkey.value:1

You can reset it by having some code that runs at the start to reset the value to 0, or if you set the checkbox as "volatile" then it will automatically reset when the deck opens.

I hope this all makes sense. If you have more questions I'm sure people here would be happy to help out.

And I think it is absolutely OK to share projects that aren't in English. I know there have been a few Decker projects that are in languages other than English. People may not be able to understand it but you shouldn't let that stop you!

For your first question, a canvas gets the click event on mouse-down, and the release event on mouse-up, so you can make the canvas change colour while the button is held down:

on click pos do
 me.pattern:colors.red
 me.rect[0,0 me.lsize]
end

on release pos do
 me.pattern:colors.white
 me.rect[0,0 me.lsize]
end

(obviously you can do fancier painting than that if you want)

The release event also gives you the position of the pointer at the time the button was released, relative to the top-left corner of the canvas. If the position is below and to the right of the top-left corner, and above and to the left of the bottom-right corner, then it’s within the canvas, and you can do whatever the canvas-button is supposed to do:

if min (pos>0,0),(pos<me.lsize)
 alert["whatever I'm supposed to do"]
end

For your second question, I can’t easily spot an error (though I’m pretty sure you don’t need set); in this situation I’d wrap show[] around different parts of the code to double-check that the values being calculated were the ones I expected. show[] takes a sequence of expressions, logs them to the Listener, and returns the first one, so you can wrap it around expressions without changing how your code runs. So, this code will run exactly the same as the example above:

if min show[(pos>0,0) "<-- to the bottom right"],show[(pos<me.lsize) "<-- to the top left"]
 alert["whatever I'm supposed to do"]
end

…but produces this output in the Listener:

(1,1) "<-- to the bottom right"
(0,1) "<-- to the top left"

For your third question, the floor operator drops the fractional part of a number:

 floor 1.0,1.4,1.5,1.6,2.0
(1,1,1,1,2)

If you want round-to-nearest rather than always-round-down, you can add 0.5 before hand:

 floor 0.5+(1.0,1.4,1.5,1.6,2.0)
(1,1,2,2,2)

You can set the .widths property of a grid widget to a list of column widths in pixels. Any columns thus set to 0px wide will be completely hidden from view and skipped over when navigating by cell. Grids will also automatically hide any rightmost columns that don't fit within the width of the widget, so making leftward columns a bit wider can scrunch the secret columns out of view. (Columns have resize handles in between column labels while in Interact mode!)

I might be wrong but I think you're using an older version of Decker. Possibly 1.54 or earlier. 

The reason I think that is because Decker 1.55 introduced some changes to Lil. The description box under the preview is showing a "0" which suggests that your version of Decker is from before "nil" was introduced.

Could you update to a more recent version and let us know if that fixed it?

As a concrete example, assuming the default palette, if you wanted to set animated pattern 28 to red and black alternating as fast as possible you could use The Listener to issue the following Lil snippet:

patterns[28]:35,47

To halve the speed you could double up each pattern index, e.g.:

patterns[28]:35,35,47,47

There are more examples of this sort of thing in All About Color.

Is that clear?

The "rows" primitive turns a table into a list of dictionary, with each dictionary representing a row.

You can thus iterate over the rows of the table stored in a grid something like:

each row in rows mygrid.value
 # ...
end

More broadly, though, what are you trying to do? There might be better alternatives depending on the application.

Grid widgets, like this example named "items":

contain tables. You can read or write the table of a grid widget via the .value attribute of the grid. Tables can be indexed numerically (looking up rows) or by strings (looking up columns):

items.value
# +--------------+-------+--------+
# | fruit        | price | amount |
# +--------------+-------+--------+
# | "apple"      | 1     | 1      |
# | "cherry"     | 0.35  | 15     |
# | "banana"     | 0.75  | 2      |
# | "durian"     | 2.99  | 5      |
# | "elderberry" | 0.92  | 1      |
# +--------------+-------+--------+
items.value[3]
# {"fruit":"durian","price":2.99,"amount":5}
items.value.fruit
# ("apple","cherry","banana","durian","elderberry")

In the simplest case of populating another grid with a specific column of a source grid, assigning a list to the destination grid's .value attribute will implicitly cast it to a table:

dest.value:items.value.fruit

For more complex transformations of data, there's Lil's query language:

select fruit price where amount>2 from items.value
# +----------+-------+
# | fruit    | price |
# +----------+-------+
# | "cherry" | 0.35  |
# | "durian" | 2.99  |
# +----------+-------+

A query never modifies tables in-place; it returns a new table. Just like before, we can take the source grid's .value, query it, and assign the result to another grid's .value attribute:

dest.value:select fruit amount where fruit in "cherry","banana" from items.value

There are many examples of using queries on tables in the Lil reference manual section Lil, The Query Language. If you aren't using it already, Decker's Listeneris very helpful for trying queries interactively or generally testing out snippets of code.

Does any of that point you in a useful direction? I can try to furnish more specific examples of how to formulate queries for your project if you provide additional detail about how your data is organized.

Possibly a silly question, but did you make sure to add the "zazz" module to your other deck?

Not a silly question!

The short answer is you can use ctrl+v (or Edit > Paste Widget in the menu) while you're looking at a card.

The slightly longer answer is this:

Decker's image data, widgets (including contraptions) and even whole cards can be copied and pasted between decks very easily.

As an example: if you copy a plain button widget and then paste it somewhere else... you get a matching button.
But if you paste it into a text editor like notepad you get something that looks a little bit like the code blocks in the contraption bazaar:

%%WGT0{"w":[{"name":"button1","type":"button","size":[60,20],"pos":[230,164]}],"d":{}}

That's because this is what widgets look like when they're stored in your system's clipboard. They start with %%WGT and contain all the information about their size and scripts and data, etc.

So Decker will know that if there's a  %%WGT at the start of a string that you're pasting (that you copied from the bazaar) that means you're pasting a widget!

Just like it would recognize %%IMG as image data or %%CRD as being a whole card.

We're using the forums as a place to pass this easy kind of copy-and-paste clipboard data to each other in order to share our inventions and tools. Because it just works. :)

So, yeah, when you copy a contraption from the bazaar you can just paste it directly onto a card!

Have fun, and good luck with your finals!

The easiest way is to cut them. Use [ Card > Cut Card ] from the menu bar, and then just don't ever paste them back in.

(This gives you a small window to get your card back before it's gone for good.)

Is there ANY way to resize an internal canvas(es) on a contraption resize?

If you make your prototype “resizable” (when you’re editing a prototype, from the “Prototype” menu make sure the last item “Resizable” is ticked), then you should be able to resize the contraption when you add it to a card. If you also tick “Show Margins” in the Prototype menu, you’ll also get four little handles you can use to mark the left, right, top and bottom margins of the prototype: any part of a widget that is between the edge of the prototype and the margins will stay at that fixed distance from the edge, any part of a widget that is in the middle will be proportionally resized as the contraption is resized.

%%WGT0{"w":[{"name":"prototype11","type":"contraption","size":[98,91],"pos":[86,66],"def":"prototype1","widgets":{"canvas1":{"size":[81,41]}}}],"d":{"prototype1":{"name":"prototype1","size":[100,100],"resizable":1,"margin":[0,25,0,0],"widgets":{"canvas1":{"type":"canvas","size":[83,46],"pos":[8,9]}}}}}

If you paste the above widget definition into a card, you’ll get a contraption with a canvas in the top half of it. The top edge of the canvas is between the top edge of the prototype and the top margin, so it stays at a fixed distance from the top of the contraption as it is resized. The bottom edge of the canvas is between the top and bottom margins, so it moves proportionally as the contraption is resized.

If you are trying to write code to reposition widgets in a deck, that should work, but it may be overidden by the “built in” resizing behaviour described above? I’m not sure, I haven’t tried it.

But, then that raises another question, I am uncertain where to initialize long term state on a card or contraption.

The best place to put long-term state on a card or contraption is in a widget. Widgets don’t have to be in the centre “white” part of a prototype, you can stash them in the dark-grey border area - but make sure they’re locked so the user can’t accidentally interact with them. For most data types (numbers, strings, lists, dicts, tables) you can just use a regular field, and read and write its .data property. If you want to store a bunch of images (such as sprites), the best way is to use a rich-text field; you can paste the images in, and access them from code by reading the .images property.

Also, is there a working example of get_ and set_ for prototypes?

If you edit a prototype and choose “Script…” from the Prototype menu, you can enter a handler like this:

on get_foo do
 "here's a foo"
end

Then, let’s say you make a contraption from this prototype, called mycontraption. If you say mycontraption.foo, that will evaluate to the string "here's a foo". Here’s a pasteable example of that in action:

%%WGT0{"w":[{"name":"mycontraption","type":"contraption","size":[100,100],"pos":[86,66],"def":"prototype1","widgets":{}},{"name":"button1","type":"button","size":[84,20],"pos":[93,40],"script":"on click do\n alert[mycontraption.foo]\nend","text":"Gimme a foo"}],"d":{"prototype1":{"name":"prototype1","size":[100,100],"margin":[0,0,0,0],"script":"on get_foo do\n \"here's a foo\"\nend","widgets":{}}}}

Setting works the same way: define on set_foo val do ... end and it will be called when code does mycontraption.foo:somevalue.

If you want to be able to get and set values interactively, rather than just through code, you can also use “attributes”, but that’s an optional, additional layer on top of get_foo and set_foo that you don’t have to worry about otherwise.

I have another question. How can I limit the number of action steps for followers in Path? To align with and advance the plot development, I don't want players to run around on the map. At the same time, I want followers to trigger events when their steps are exhausted or at specific locations. Sorry for asking so many questions, but I really want to make this game well.

How long does it pause for?

Yeah! If I'm doing art stuff I usually have Decker fullscreen on my display tablet. 

What OS are you using? And can you describe any problems you're having currently?

Your audio duration should be fine! 

After experimenting with a deck where I have a similar audio looping setup I think my best guess is that the script is expecting to find a Field that has the name "loopcounter" on the same card you're on and it's not finding it so it can't correctly loop through your clips. 
(Because nothing is loopcount-ing, y'know?)

It could be that it doesn't exist, or it has a typo in the name or it does exist by that name but it's on another card... something like that. 

You’re almost there, but unfortunately Decker doesn’t allow you to add a pressed attribute to a button like that. If you want to keep track of a flag like “treasure taken”, the easiest thing would be to make a button in the puzzle-room called treasuretaken, configure it to be a checkbox, and “Show None”. Then the button that takes the treasure can do:

on click do
 treasuretaken.value:1
end

(note that you have to say 1, not true: Decker’s scripting language Lil does not recognise true and false specially, and treats them both as undefined variables)

…and the button that checks for taken treasures can do:

on click do
if puzzleroom1.treasuretaken.value & puzzleroom2.treasuretaken.value
 dd.open[deck]
 dd.say["You successfully stolen all treasures!"]
 dd.close[]
 go["end"]
else
 alert["You must collect all treasures to leave!"]
end
end

(note that the way to say “both these things must be true” is & not and - Lil does not recognise and either)

You could write a script to record the position of all the canvases automatically (rather than recording every coordinate by hand), stash those positions in a field somewhere, and then have another script re-apply them when appropriate.

Let's say you have widgets something like this:

The "remember" script looks like:

on click do
 p:select key value..pos where value..type="canvas" from card.widgets
 positions.data:raze p
end

And the "restore" script looks like:

on click do
 each pos name in positions.data
  card.widgets[name].pos:pos
 end
end

In practice, this field and buttons will probably be hidden (set to "show none"). If you ever want to record the current state of the canvases without un-hiding the buttons you can simulate a click via the listener:

remember.event.click

Does that make sense?

The keyboard shortcuts that I know (In native Decker) for swapping between modes are F1 for Interact Mode, F2 for Widget Mode (And F3 - F12 are for the drawing tools). I hope this helps!

From the reference manual's description of the Prototype Interface,

when a definition is updated, the name, pos, show, locked, animated, volatile, font, pattern, and script attributes of Contraptions will be preserved, as well the value, scroll, row, col, and image content of the widgets they contain (as applicable) if they have been modified from their original values in the prototype, but everything else will be regenerated from the definition. The state of contraptions is kept, and the behavior and appearance is changed.

Any other state that you wish to survive prototype modification should be stashed in internal widgets; I recommend refreshing these settings (alongside applying settings from the enclosing contraption instance like .font and .locked, where appropriate) in the view[] event handler in the prototype script.

The Canvas is the only widget that has both click and release events, and the Button is the only widget that responds to keyboard presses, so you can’t make something that starts when you hold a key and stops when you release.

However, you can make the button send a click, then wait a while, then send a release, which is probably as close as you’re going to get:

on click do
 canvas1.event["click" 0,0]
 sleep[15] # in 60ths of a second
 canvas1.event["release" 0,0]
end

That can look a little weird, since Decker disables all interactive widgets (drawing them greyed out) until the sleep time is complete, but it prevents the player from doing more things while the previous things are still going on.

If you don’t want to freeze things like that, you can build something a little more complex that lets Decker keep doing things while you wait. Create a field to hold the timer countdown, and change the button click handler to:

on click do
 canvas1.event["click"]
 field1.data:15
 field1.animated:1
end

So when the button is clicked, it sends the click event to the Canvas, it loads 15 into the field, and sets the field to be animated (so Decker sends it view events 60 times a second). The field’s view handler looks like this:

on view do
 me.data:me.data - 1
 if me.data = 0
  canvas1.event["release" 0,0]
  me.animated:0
 end
end

So every time view is called (that is, 60 times a second), it subtracts 1 from the value it stores. When it reaches 0, it sends the release event to the canvas, and turns off animation again. As a result, when the button is clicked, the canvas is “clicked”, then things keep happening as usual while the timer ticks down, and when it does the canvas is “released”.

The field can be made “Show None” if you don’t want the player to see it; if you make the button “Show None” then it won’t react to the keyboard. However, you can make the button use the “Invisible” style to hide it, and “Show Transparent” to make it invisible even when clicked. You can also just move it off-screen.

I realise it's not exactly a solution, but have you tried recording sound separately (in like Audacity for example) and then importing into Decker? I've found even when the audio editor is working I get better results this way since I can adjust the levels and such in Audacity before converting down into Decker's format

Decker and Dialogizer should always work with each other, unless there's of a very old copy of one of them and a very new copy of the other. So let's check that. The current version of Dialogizer is 1.7 and the current version of Decker is 1.63, for reference.

You can see the current version of your module (and update to a newer one if needed) in the same popup where you transferred it into your project from the Dialogizer example deck [File > Resources]. 

You can see the current version of Decker by using the menu [Decker > About].

If the version numbers seem fine then the other thing to check is whether you have dd.open[deck] before you dd.say[] anything. Like this:

on click do
 dd.open[deck]
 dd.say["hi"]
 dd.close[]
end

Hopefully one of these two things will be the answer, but if not please let me know.

Yeah, there's a way to do it! We'll be using the font editor in examples/fonts.deck to modify the menu font.

The one slightly fussy element is that "menu" is not a font that can be transferred between decks through the DA/Font mover... but after making the change you can save the editor deck as a new file and empty it out to use it as a starting point for future projects.

(There might be other ways to move the font around, but I'm less sure about how....)

If that sounds okay to you then this is how I'd do it: We're going to copy the glyphs of an existing font and apply them to the menu font.

Step one would be to open examples/fonts.deck and hit the button for the Font Editor. Look through the list to find a font you like. A lot of them tend towards whimsical or deliberately handwritten but perhaps there's something in there that would work for you. 

There's also the option of using something from this font pack which has some very nice ones but you'd probably want to edit them to have less empty space above the glyphs. (I can explain more if you find one that you prefer in there)

I'm going to use 'ahmCasual' from fonts.deck for my example here. The existing 'menu' font is 16 by 13 pixels, and ahmCasual is 16 by 16. The difference in width might cause a letter to get cut of in some places where 'menu' is currently used but... it's probably okay? It's close enough.

At the top right of this card you'll find a couple of sliders labeled 'font properties' and a button labeled 'set grid overlay to font dimensions' -- the button may be grayed out if the grid overlay already matches the font dimensions listed.

We want to set the grid overlay to match the dimensions of the font we're taking our new glyphs from. So after you find a font you like you should click that button (if it isn't gray already).

Now click the Sheet button at the bottom of the card. 

Go into Widgets mode and use the View menu to turn on 'Snap to Grid'. (You can also turn on 'Show Grid Overlay' if you'd like to see what's going on.) 

With 'Snap to Grid' active the positions and sizes of widgets will snap to the dots on the grid overlay whenever we move or resize them.

And because we're in Widgets mode you'll also be see the hidden widget that marks the area where the glyphs are drawn on the card. (the widget is named 'workzone')

(an image of the workzone widget as I found it..... not at all aligned with my new grid overlay dimensions but that's fine)

Drag 'workzone' around once to make the top left corner snap to a point on the grid near the top left of the card. Then resize 'workzone' once so the widget  is moderately large on the card and the other dimensions will snap to the grid too. You don't need to be too specific about the size or position. 

If it's not big enough during the next step you can resize it and try again. It's also okay if there are still unrelated glyphs on the card -- they'll be erased automatically in a moment.

Go back to Interact mode on this same card and click the 'Load' button. The glyphs of the font you selected should now be shown on the card inside the space marked by the 'workzone' widget.

Click the Font button at the bottom of this card to go back to the card with the font list and select 'menu' towards the top of the list.

Use the arrows on the 'font properties' sliders to match the grid overlay dimensions of the other font we're using (in the case of my example, ahmCasual, that's 16 by 16). The 'set grid overlay to font dimensions' button (which we're not clicking now) should become gray/locked automatically when your selected dimensions in the sliders match the current grid overlay.

And now we go back to the Sheet editor card one last time and click the Apply button.

The glyphs that were on the card in the 'workzone' should be applied to the menu font. :) 

Save this deck as a new file and enjoy?

In Lil, dot-indexing with an identifier and bracket-indexing with a string are equivalent:

card.parent.event.moving
card.parent.event["moving"]
card.parent["event"]["moving"]
card["parent"]["event"]["moving"]

This is a very convenient shorthand when functions take a single string as their argument, but I can see how it might leave you puzzled about passing extra arguments to the "event" method of deck-parts. You're looking for something like:

card.parent.event["moving" which.text]

Make sense?

Puppeteer includes a simple screenshake effect. If you're using that library already, you can just include the !shake command in your dialog scripts like in the example. Here's a simplified version of how that works internally that could be used elsewhere- adjusting "shake_mag" and the duration of the transition (here 15) can tune how the effect looks:

go[card on shake_trans c a b t do
  local shake_mag:30,30
  local m:shake_mag*1-t
  c.pattern:1
  c.rect[0,0 c.size]
  c.paste[a (random@2*m)-m]
end 15]

Unfortunately, supporting non-Latin-alphabet languages in Decker is not straightforward. Phinxel has a few suggestions for workarounds, but any way you slice it a great deal of work would be involved.

To hide Decker's main menu, you'll need to lock the deck. (The following page describes how you can save a "protected" copy of the current deck.) Whether you're exporting a protected copy of a deck or using the ordinary save menu, all you need to do to create a web-playable version of a deck is save with an ".html" extension.

When you create your project page on Itch.io, upload the .html file you saved, and mark it as "played in browser". It'll look something like this:

There are also additional settings to configure how your game will be embedded in the web page:

The defaults are mostly fine, but I recommend enabling the "fullscreen button" for most projects.

A field widget stores some text, a slider widget stores a number, a canvas widget stores a picture, that’s about all there is to it.

If you see a canvas widget’s content changing between different frames of animation, then either the canvas is being redrawn by code (as in the Canvases card in the built-in tutorial deck), or there’s some other card or canvas somewhere that has all the different frames, which are being copied into the canvas to create animation.

Decker comes with an example deck called Puppeteer, which includes a module you can include in your own decks to do this kind of animation.

You're off about canvases, unfortunately... they're so much more basic that you're currently thinking. 

(Though there is something else that you an look inside... I'll come back to that)

A Canvas doesn't really store any data except for the image that is currently displayed on it.

But canvases are very flexible and convenient as the display component of anything interactive or animated that uses images. 

This might be a weird metaphor but if we were trying to play a film in Decker.... a canvas is like a projection screen. 
It's not the projector (that's probably the script, wherever it lives) or the film (your stored images).

---

Okay! So! In Phinxel's Field Notes almost all of the extra images are stored in separate canvases on a card named 'storage'.

This card can't be navigated to while flipping through the book in interact mode because I prevented that... but you can find it by arrow key navigating around in widget mode or by opening up [ File > Cards ] to see the full list of cards and navigate to it that way("storage" is near the very bottom of the list)  if you want to see all the stuff in there.

Inside of the script for the cookie slider example you mentioned there's a snippet that looks like this:

 plate.paste[ storage.widgets[x].copy[] ]

What this does is copy an image from a canvas on my storage card onto the canvas on the same card that we're on now... the relevant canvas on this slider example card is named 'plate'. 

storage.widgets[] is telling Decker to look at the widgets on my "storage" card and 'x' is a temporary variable combining the naming pattern I used for my stored canvases and the current number that the slider is set to. Don't worry about that part... I think I was trying to make my own example a little more compact.

If I was going to rewrite it to copy from a single specific named canvas it might look like this:

 plate.paste[ storage.widgets["cookie3"].copy[] ] 
     # or, alternatively #
 plate.paste[ storage.widgets.cookie3.copy[] ] 
     # or if I was copying from a canvas on the same card as the one I'm pasting on...#
 plate.paste[ cookie3.copy[] ]

So... we have to store our extra image data somewhere else that isn't just on the 'projector screen' and there's a few options:

Canvases

Storing images in other canvases is totally fine! Depending on how many images you're storing it might not be ideal but it works. Canvases are built for displaying images and they have easy to use .copy[] and .paste[] functions to move those images around.

Fields

When you make a new field it'll be set to "rich text" by default, which is exactly what we need for it to be able to store images. If we put some images into a field we can use the .images attribute to refer to them in scripts.

You can see some examples of this on one of the pages about Fields in Phinxel's Field Notes (here's a direct link to the page) but it probably warrants more discussion here on the forums because it's very handy! This is a particularly good method for storing lots of animation frames in one place.

Other Places ....

Images can be stored in grid widgets as text (image data correctly stored this way would begin with %%IMG) or maybe also as pasted images if the grid column format is set to support rich text (this is not the default for grids).

(I've never really used grids for storing images for animations, honestly. I just know that it should technically be possible....)

You can also store images directly on a card and refer to the card.image or even use a widget as a marker for a smaller area on the card that you'd like to use. Someone can probably explain more about this if it sounds appealing.

But I personally tend to use canvases and fields for most things.

---

The other thing I wanted to mention is Contraptions, which do actually have an "Inside". Contraptions are custom widgets made of the 5 basic types of widgets + scripts (see the contraption bazaar thread to tour some of the community contributed contraptions).

Going back to the idea of a projector...  a contraption could be made of a canvas to play your sequence of images and a field to store the full collection of frames. And you'd definitely also need a script to tell the widgets how to relate to each other.

This could absolutely just be built directly on a card (or split across a display card and a storage card...) without getting contraptions involved but sometimes it's handy to package these combinations of widgets together. And this is the concept that exists in Decker where a widget does actually have a secret "inside" area so I wanted to mention it. :) It's a much bigger topic though so I'll stop here.

Hopefully this made a little sense.

I think of canvas widgets as being sort of like <canvas> elements on web pages: a drawing surface that contains one image at any given time and which can be manipulated with scripts.

Building on what Ahm said, it's certainly possible to create contraptions that bundle together a canvas and storage for a sequence of animation frames, with logic for playing those sequences back. The WigglyKit deck comes with a contraption along these lines called wigglyPlayer.

Here's a little demo video of using a WigglyPlayer to create looping animated "sprites" on top of a drawing, with no custom scripting required:

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.