I think if you wanted to reference something off another object you'd need to do it in a card-agnostic manner, something like card1.widgets.dialoguewindow.size, if that helps
Millie Squilly
Creator of
Recent community posts
Normally the way I set up a style to reference in multiple places I'll just put it in the deck level script. Then it's in scope for wherever I'm referencing it in code. Depending on what you're doing, it could make more sense for the card level script, it's up to you
As an example, here's something I grabbed from an old project - this is just in the top level deck script, not inside any "on such and such do" events.
ddstyle:() ddstyle.fcolor:colors.black ddstyle.bcolor:colors.white ddstyle.speed:3 ddstyle.border:deck.contraptions.border ddstyle.next:image["%%IMG2AAgABwACAQYAAQEBJAUBAiQGAQIkBgECJAYBAiQFAQEAAQEGAAI="] ddstyle.nextd:20
And then I can just call like dd.open[deck ddstyle] from anywhere.
I'm guessing the grid isn't working for you is because it's passing in like a string containing the text "deck.contraptions.bracket" instead of a reference to the actual bracket contraption.
In order to put text on your card, you'll need to add a Field widget.
Switch to widget mode with Tool->Widgets
Then create a field with Widgets->New Field
The field widget will appear and you can position and resize it as needed
To type text in it, double-click it and type into the Text section of the properties box. Alternatively, if you switch back to Interact mode (Tool->Interact) you can just click in it and type.
(As a final tip, if you're looking at releasing a deck for others to use, you may want to "lock" the field to stop the text from being editable in interact mode. You can do this by selecting Widgets->Locked from widget mode with the field selected)
I hope this makes sense, let me know if anything doesn't though!
So, short version is that if there's anything you need to store outside an individual function call in Decker, the intended solution is to store it in a widget, on a card. Values of variables otherwise don't persist outside the specific piece of code that you're running at the time.
Let's say if you need to store a string named "mystring", you'll probably want to make a field widget to store it in, let's say it's called field1. Then in your code you can just store it like this
field1.text:mystring
And you can then access field1 from any other bit of code on the same card and retrieve the string from field1.text. And if you don't want the user messing with it at runtime, you can "lock" the widget or set its view attribute to "none" to hide it.
If your widget is on a different card, that's no problem either. I find it can work to have an inaccessible "utility" type card for holding onto variables. Let's say if I have field1 on a card named "myvars" for example, I can refer to it like this
myvars.widgets.field1.text
If you're storing values other than strings, in theory pretty much every Decker datatype can be serialised into a string but it might make more sense to use other methods for different data, depending on what you want to do. There's a bit of information in Phinxel's Field Notes, in the Lil section on the "Storing Information" page that might come in handy here.
It sounds like you've tried something like this but run into some issues, maybe you could go into details? In theory even if you're doing something "wrong" Decker shouldn't be hard-crashing so if you've got some examples of that then that could be handy in case there's a bug.
If you want to have a global constant though, that's a bit of an easier matter. You can at the top of a widget script, or a card script or the deck script, predefine the values of variables to essentially use them like global constants. Something like this
magicnum:1234 mystring:"Hello, World!"
I hope this makes sense but let me know if you need more explanation.
It has AGAIN been a fair gap but I am still making these. zine of Millie CE issue 2 is out now! https://zine.milliesquilly.com/ce/ce2.html

I managed another janky instrument (kinda smooshed the previous two together haha). Janky Samplemin.
I've already made a couple of janky musical instruments for this jam, Janky Theremin and Janky Sampler.
I'd originally made a custom module for Janky Sampler to handle resampling the audio to be faster or slower, but with Decker 1.69 there's built-in native functionality to do that and it sounds nicer and runs much faster, so this evening I updated Janky Sampler to use that instead!
I'd originally thought I might make some sort of narrative point and click or visual novel type thing for this jam but it kinda ain't happening, so maybe I'll give that another try at a time of year when there's more sunlight in these parts haha































