Post by Internet Janitor in Lil Programming Questions

Viewing post in Lil Programming Questions

In Decker, persistent state lives in widgets. If you want to remember anything beyond the scope of an event handler, it should be stored in a widget. For example:

Type of Data to Store	Appropriate Representations
String	Field text
Ranged Number	Slider value
Arbitrary Number	Field text
Boolean (true or false)	Button value, any Widget's visibility
Image	Canvas, Rich Text Field (encoded as inline image)
Table	Grid value, Field text (encoded as CSV)
Dictionary or List	Field text (encoded as JSON)
Position or Size	any Widget's bounding box

If you want to remember something without showing it to a user, you could use invisible widgets, or widgets on a hidden card.

The walkthrough and examples in this thread might be helpful to you.

I recommend checking out The Listener as a way of interactively trying short snippets of code. You can use the Listener to poke and prod at the contents of a deck or card and verify behaviors before you write a script.

The print[] and show[] Built-In Functions can be used to log information (formatted text or arbitrary Lil values, respectively) to the Listener for debugging. The alert[] function can sometimes be handy for debugging because it pauses the current script and displays text to the user. The panic[] function stops scripts completely, but can likewise be a tool for peering into the workings of complex scripts.

Does any of that help?

yeehaw308 days ago(+1)

yes that is really helpful! thank you for the functions and guidance about the listener- i'll keep tinkering with it! and thank you for making decker- super cool project, and it's really nice how you always answer questions

yeehaw308 days ago(+1)

hello- i'm so sorry to do this, but i've just spent the last 4 hours trying to figure out how to put a string variable in a field (i.e. player types in their character's name -> that name appears in text when the game or NPCs address the player's character) and i just can't? figure it out?? thank you so much for your response, i did manage to grok that you can just use the field itself as the variable (using the listener to figure that out!!) but actually taking that text and putting it in a sentence in a field is just beyond me.. i've read the reference manuals, looked at examples, gone thru the community threads and have now decided to swallow my pride and ask how you would 'embed' a string variable in a different field? like "hi [playerName], it's nice to meet you" or something like that?

sorry, i am very aware that i've been asking a lot of questions.. this is the most ambitious thing i want to do, so i don't imagine i'll be asking too many more!

Internet Janitor308 days ago

No worries. Asking "obvious" questions in a public forum like this helps future users and lets me know about potential documentation/usability problems so I can continue to improve Decker.

There are a few different ways we could approach using the value of one field to update another. For starters, let's take a look at string formatting.

The Lil "format" operator takes a formatting string on the left and one or more parameters on the right. Let's see a few examples in the listener:

"Hello, %s. How's it hanging?" format "Alice"
"Hello, Alice. How's it hanging?"
"%s missed your call; they were busy %s." format ("Phil","gardening")
"Phil missed your call; they were busy gardening."

Each "%s" in the formatting string is replaced with a string on the right, in order of appearance. There are lots of other formatting codes and features available for dealing with numbers, zero-padding, case conversion, etc, but for the moment we can ignore them.

Now, let's say we have two fields on the same card: "name" and "reply":

There are a few ways we could approach updating "reply" when "name" is changed. One way would be to add a script to "name" and use the "on change" event:

on change do
 reply.text:"Hi, %s. I hope this example makes sense!" format name.text
end

It would also be possible to do the same thing when a button is clicked, etc. If "reply" was on another card, we might have to specify the "path" to it:

on change do
 otherCard.widgets.reply.text:"Hi, %s- how's it going?" format name.text
end

Both of these approaches are "push"-based: something explicitly happens to the name field and our script reaches out to other fields in response. A different way to think about it would be "pull"-based: logic on individual cards which reach out to other widgets and update themselves. For example, we could have an "on view" script on our "other card" which updates reply whenever a user travels to that card:

on view do
 reply.text:"Hi, %s- how's it going?" format firstCard.widgets.name.text
end

Either way works.

Does that get you "unstuck"?

yeehaw307 days ago(+1)

this is incredibly helpful! it did get me unstuck- thank you so much, i really appreciate it !!

itch.io

Viewing post in Lil Programming Questions