Rez v1.8.0 — An Open-Source tool for creating choice based games/IF

Technical Development Development Systems
,
21

Technically, yes, but I would recommend pushing the element ids instead.

22

Do I need to store their IDs as text attributes matching their declared element names for that purpose, or is there a built in syntax to fetch an element’s id anytime I need it?

(also, let me know if it would be appropriate to keep pestering you with questions, perhaps in DMs. I would gladly jump the REZ wagon totest it, but I can’t get the basic mechanics to work so far)

23

In the first case I am happy for you to ask questions. Either here, or I created a Discord. I’m also a little humbled that your experience has been so problematic, hopefully you’ll stick with so I can fix the problems.

On to your question: Every element you define has an id (the @game element is automatically assigned the id #game other IDs you assign yourself).

Every element in the .rez source files gets translated into JS object by the compiler (using classes RezObject, RezCard, RezGame and so on) with an id property that gives you back that id. So your definition:

@location gym_ring {
  $global: true
}

Will end up creating a RezObjectJS object whose id property is "gym_ring".

If you look at the end of dist/assets/js/runtime.js you will see the objects being created and how the id & attributes are assigned to it.

In the runtime you can go from id string to an object using the $ function, e.g. $(“gym_ring”). $ is a shorthand for the method getGameObject() on the singleton RezGame object.

If its an object you want to be able to refer to frequently you can set $global: true and the runtime defines a constant value $gym_ring with the reference (i.e. the id becomes the variable name).

So in the above example:

$gym_ring == $("gym_ring")
$gym_ring.id == $("gym_ring").id == "gym_ring"

Does that help?

24

Yesterday I released Rez v1.9.2 which contains the following changes:

  • Updated built-in Bulma CSS to v1.0.4
  • Updated built-in Alpine.JS to v3.15.2
  • @list can use includes: to pull in values from another @list
  • Detect invalidly closed user components (e.g. <.pb>….<./pb>)
  • Extensions to the @pragma API
  • The blocks: attribute is changed from a list to a binding list so you can name the binding
  • Switched from breadth-first to depth-first initialisation of runtime objects
  • Adds +#{:foo :bar :baz} to merge new elements into set values defined in defaults
  • Compiler error if you try to $(…) include a file twice
  • Template variables are automatically converted into a template function that calls the rendering engine with the object bound.
  • Several dozen bug fixes
1 Like
25

Thanks, it makes perfect sense.

I’m not discouraged easily :slight_smile: Switching to discord then.

1 Like
26

Today I am releasing Rez v1.9.4 which contains the following changes:

  • Rationalised event handling and naming
  • @plotplot now supports subscribers (which can be other @plots)
  • Added support for displaying & cancelling flash messages to the base template
  • Add support for event, card, interlude,scene, and resume for <button> tags
  • Can use <a event='event-name'>…</a>syntax for creating event firing links
  • Template expressions can use indexed accessors ${a[0]} or $foreach(x: card.values[0])
  • Fixes auto-referencing parent binding
  • Event transformations are now tied to the rez-evented CSS class which can be applied anywhere that you need dynamic links/buttons to work.
  • The addCopy() API now supports passing an id for the copy.
  • Browser & form events now fall back to event-bubbling if no handler is present in the current card
  • Improved template compiler error messages
  • Fixes ptable attribute encoding
  • Binding list attribute can include keyword values
  • Major revisions to API docs
  • Numerous bug fixes

I want to extend my thanks to @BlackTrifle for pointing out the many errors & inconsistencies that they have come across. This release is easily the best tested so far.

2 Likes