itch.io

 This is really cool! :O Thank you for sharing it.

This is such a charming idea! A deck contained in a deck. And it's really well made, too.

Hello! And yeah absolutely!

For starters: referring to widgets by a shorter nickname. I think you were on the right track already, but I'll explain it in more detail anyway.

One option is to create a variable which is just the full path to a widget somewhere else in the deck:

doorknock: DormitoryHall1.widgets.DoorDepr

And that should make it possible to use "doorknock" as a shortcut for the longer name.

Or a project that has many info tracking widgets on a secret storage card could just simplify part of the path:

status:secretstoragecard.widgets

And then be able to use that in your scripts like this:

if status.pickedflower.value

And while you can define these shortcuts in the specific scripts where you're using them... you could also put them in the Deck-level script if you use them a lot. Just like Widgets and Cards can have scripts, you can also define events and variables at the Deck level.

Things put in the Deck script are always visible to every widget in the project (unless overridden more locally, but that's a different subject).

You can access this script  with File > Properties > [Script...]

Or if you're already in a script editor for something else you can use File > Go to Deck to move there directly.

And this kind of nickname variable doesn't need to be in an event handler or anything, just define the variable and you're done.

Okay, now on to your real questions....

Just like a checkbox can hold 1 and 0 as true/false... other widgets are good at holding other kinds of information.

In this case I recommend a slider widget, specifically. They're very good at storing numbers within a specific range, and you can choose the minimum and maximum of that range, and how big of a step is allowed between each point on the slider.

They're my go-to widget when I'm keeping count of something!

I'd recommend setting the style of your slider to "Compact" in the properties dialog to make the number easier to read while you're testing, and then you can also set the min and max of the range of numbers you want to use.

A nice thing about using a slider for this job is that your existing script doesn't need to change much.

The current number stored in a slider is also called .value in scripts. 

And you can adjust it by doing things you already understand how to do:

yourslider.value: yourslider.value +1

If you need to reset it back to the beginning you can just assign it the number you want to start at. Assuming that's zero at the beginning of the game, just do this:

yourslider.value:0

(And, as always, make the names match your actual project)

For the other part... It's true that we can't use combined operators but you can usually get the effect you need by writing things a little differently. I'm not completely sure all the ways you were thinking about using >= so this may not fully answer your question...

But for this script example... I think things could be simplified a little with the power of "else".

(I'm not copying your full script here so I'll just leave placeholders for the different scene possibilities, okay?)

if doorknock.value =1
 # "Erm, Hello?"
else
 # "...."
end

Basically else is "If the condition wasn't true...  do this other thing instead." 

Or you could add more possible outcomes with elseif. 

The first true thing in the series of possibilities will be the one that happens, so if two things could technically be true at the same time, make sure to put the higher priority one earlier in the list:

if doorknock.value =1
 # "Erm, Hello?"
elseif doorknock.value =20
# "Please stop knocking!!"
elseif doorknock.value > 15
# "...!! >:O"
else
 # "...."
end

20 is more than 15, so the event for ">15" could have happened at value=20..... but =20 was earlier in the order of possibilities, so only that one will happen. It's kind of a silly example, but I hope it makes sense.

And while I'm thinking about it, you can also move your dd.open[] and dd.close[] lines to be before and after your branching dialog possibilities if you want. Like this:

on click do
dd.open[deck]
 if doorknock.value =1  
 dd.say["Erm, Hello?"]
 else  
 dd.say["...."] 
 end
dd.close[]
end

I've got to stop here for now but I'm happy to come back and clarify if I wrote things in a confusing way, or if I didn't answer your real question!

These are lovely! It's so nice to see these sorts of things made in Decker!

Hooray! I'm so glad!

Things are sometimes a little quieter here in the forum during August because one of the official decker jams just happened in July. But there's always enough people stopping by to make sure that questions get answered.

Feel free to reply here or leave a new comment on the thread, I'll keep an eye out for you. :)

I was rushing a bit at the end of my post so let's see....

You figured it out (correctly) that I meant "thebutton" as the name of the button. I didn't know what yours was called, but I also didn't make it clear that I was making up a name for it. Sorry about that! But something is still not right, huh...

Is it possible there's an extra space at the beginning or end of the widget name? I do that all the time... and it will technically affect what the name of the button.

If the button's name is just "GrabFlowerButton", then that's how you should be able to write it in the code.

GrabFlowerButton.locked:1

Also! Since you mentioned things that only work inside a widget's script, I'll also mention this in case it's useful: 

When you're writing a script for a widget you can always refer to that specific widget as "me"

So for the script inside the button you can write it like this:

me.locked:1

Though you'll still have to use its name whenever you're referring to it in scripts that live anywhere else in your project.

I hope one of these things can help! I'll check back again later. 🫡

Hello! This looks like a charming game already.

When you want to create a variable in decker to be referred back to later you need to store them in a widget. A temporary variable can be created within a specific script while it's running, but these temporary variables aren't stored anywhere and can't easily be edited unless you put them inside a widget.

But it's pretty easy to do exactly that!

For things where you want to track true/false (has the flower been picked?) a checkbox-style button is really useful. If you created a checkbox called "pickedflower" and gave it the value 1 like this:

pickedflower.value:1

.value means different things for different widgets, but generally it refers to the kind of information stored in them. I'll keep it simple and say that in the case of buttons (including checkboxes) they can only store a boolean 0/1 (false/true) as their value.

To check this value in your if statement you can write it like this:

if pickedflower.value
# the rest of your script here
end

But... since the checkbox is a widget that will live on a specific card, you'll need to put it somewhere. 

From what you explained about your game you want to set the variable while picking up the flower on one card... and then check the variable on another card later to give the flower to someone later, right?

So we also have to talk about how to refer to a widget that's on another card.

If the "pickedflower" checkbox lived on a card called "garden", you could refer to it this way on your scripts, when you need to refer to it's stored value from other cards:

garden.widgets.pickedflower.value

It's a little long to write it like this, but I think that's okay when you only have a couple things to check. If you have a lot of things to track, let me know and I'll come up with some suggestions for how to store them and refer to them more easily!

Also, you can set your checkbox to show:"none" and it'll be completely hidden to your player.  
Or you can store all your game state-related widgets on a card that the player never sees (I recommended this if you have a lot of them!)

Optionally, if you don't want to store a variable this way at all... there's other ways to do something similar. 

For example: you can check the current visibility of your flower canvas to see if it's been hidden or not:

if theflower.show="none"
# something that happens only if the flower's canvas is hidden
end

And you can also lock a button if you no longer want it to be clickable.

thebutton.locked:1

If you do this make sure to add unlocking it (thebutton.locked:0) to your reset button too.

I'm happy to explain more if it would be helpful. But I wanted to get an answer for you quickly so you could get started playing around with it.

This is so soft and beautiful!

A sequence of gut punches, well told. As always.

(And thank you for 10.PS)

Oh, these rock! Beautiful! I really love 10!

Stag Beetle Squishy.... it's so soft and round looking. But also this is a lovely collection of bugs.

Beautiful font, and so many things to look at with it! I really appreciated the bit of audio narration. 

This is such a cool concept! I enjoyed it a lot.

Flocon!! This rocks!! I found two of the (side quest) ... are there more? 👀

Not a stupid question! If you already have a hex file you can just drag it from your file folders onto your Decker projects and it should change your colors automatically. 

If you're on some platform where you can't drag-and-drop you can copy-paste the PalImport contraption (scroll down a little bit in this post to find the code block to copy) which should let you find and open your hex file and then apply it with the button.

Alternatively you can mess around with the colors directly in Decker with Missooni's RGB adjuster (expand the second part of this post and then copy the code block)

There's also an art section in Phinxel's Field Notes which talks about how color works in Decker, in case seeing things explained in a different way is helpful.

This is beautiful!! And so cool!

Snep! Thank you so much for playing! I'm so glad the color change worked out.

Ohh I love this! I've sometimes compared making things in decker to being a little bit like physical arts and crafts (paper dolls, shadow plays, shoebox dioramas, etc.) and this is so perfectly up my alley. Though I didn't know anything about the history of these toy theatres! I'm fascinated.

Thank you very much for this wonderful deck (And for your occasional blogging during the project -- I enjoyed following along).

This is fantastic! All the art! And somehow I picked every single wrong choice but that's fine because then I got to enjoy all of the text.

It's no joke to try to put together something like this on a short schedule and I think you did amazingly.

The art is gorgeous! 

Thank you for all of your support! Especially over the last little while. And thank you so much for playing :D

Thank you SpunkyDude! (And good luck with your project!)

I'm thinking about it! I've got something else cooking that I want to try first, but I think a longer Mystlike is going to happen sooner or later... Thank you Salty!!

Thank you very muchly, friend... I hope to showcase even more ingenuity someday...

Yay! And thank you for playing!

The technical side of the panels opening was entirely down to the ease module, which handles the math side of things for certain kinds of animation. So I have to admit I was mostly picking the effect I wanted from the already prepared options within the module.

But I am very flattered and happy that you liked it!I think about that throughline a lot too. And thank you very much for playing!

You are eloquent as always, Mind Ape. I'm nodding along with the idea of working within (and being shaped by) the medium. I haven't seen that film but I might have to since you've mentioned it. Thank you for playing!

Thank you! Yeah, time got away from me this month so I had to cut away at the scope until I was sure I could get it done.

It does definitely make me want to give this kind of game a try again sometime, without any time pressure.

I'm glad there's several paths to the answer, haha... Thank you for playing! (And for checking out the behind-the-scenes!)

:'D Thank you Millie

Thank you IJ! 

This is really nice! It's always so lovely to spend time with your characters.

Yooo! Thank you and good luck! I'm looking forward  to seeing what you've been working on!

I'm Baker 3? That seems way cooler than me, but I'll take it. 😎

This thing is so packed full of details, amazing work!

Yeah this rocks

This is super beautiful! I really like your art

i will be here with you 🥺

Sounds! So many sounds.... custom sounds....

I really love the back and forth feeling between you and missooni, it's really a "wow! two  great cakes!" situation for me. :D I'm going to continue playing with this and cinnamon!

This is not a complete answer, this is kind of just a gesture towards one. The actual complete answer will kind of depend on what's going on in your game, y'know? But I can point to a couple of things.

Here's some recent discussion of the sokoban example specifically: https://itch.io/post/16368974

And for the path module here's the card that has an example that gives a visual example of the forbidden color thing: https://beyondloom.com/decker/path.html#followeranim (click the checkbox at the bottom) 

Some of the code for this is inside the module, not the deck's scripts but I believe it uses .hist to check parts of the movement grid for a specific color, and forbids movement onto that square of the grid if it finds any.

It should be possible to do something similar with a different kind of movement system too, if the path module itself doesn't have the kind of movement you had in mind.