Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Issue with Contraptions and the `card` field

A topic by Capital Ex created Dec 20, 2023 Views: 126 Replies: 5
Viewing posts 1 to 5
(+1)

I'm working on some ideas in Decker. I thought to use a prototype to organize a scene that was getting quite busy. The documentation states that `card` should point to the prototype or contraption a widget belongs to (if it belongs to one). However, this is only true for direct interactions. I was wonder if this was intended design since it wasn't documented?

Example deck of what I'm trying to do: https://gist.github.com/Capital-EX/4bf59ab2e61bb2f6ab2606a87384971e

The bottom slider sets the value of the top slider. This works as expected. 

The incerment button retrieves the slider from the contraption, then increases it by 1. In this situation, the bottom slider can no longer see the top slider.

Developer (1 edit)

Your example appears to have a typo; line 16 should be:

s.event["change" s.value + 1]

That said, there seems to be a subtle problem with scoping for event dispatch; investigating.

Developer

I believe I have resolved the problem; it will be patched in the next release, and modulo the typo correction I noted your example should work as intended.

As a general design note, I do not recommend directly exposing internal widgets of contraptions and banging on them from the outside; this is very brittle and makes it difficult to revise the design of the contraption or maintain internal constraints. Instead of exposing a slider via an attribute:

on get_slider do
 slider1
end

And then both updating the slider value and firing an event from the outside:

on click do
  s: prototype11.slider
  s.value: s.value + 1
  s.event["change" s.value + 1]
end

You could instead expose a function for incrementing the slider's value (and all the necessary consequences) on the contraption:

on get_inc do
  on inc do
   slider1.value:slider1.value + 1
   slider1.event["change" slider1.value + 1]
  end
end

And call it from the outside like so:

on click do
  prototype11.inc[]
end

Or, alternatively, you could expose both "get_"  and "set_" attributes on the contraption which likewise hide any side effects that are needed:

on get_v1 do
  slider1.value
end
on set_v1 x do
  slider1.value:x
  slider1.event["change" x]
end

And then from the outside it looks exactly like the read/write attributes of a primitive widget:

on click do
  prototype11.v1:prototype11.v1 + 1
end
(+1)

Hi! Thank you for looking into it. I ended up quite late trying to figure out if it was me of Decker having issues. Went through just about every design pattern I could think of. 

Developer

Sorry for the trouble; I know these sorts of problems can be extremely frustrating and derailing when you're trying to focus on a creative project. I do appreciate you taking the time to raise the issue, and having a clear reproduction case was a big help.

Developer

Patch for this issue (and some clarification of the intended semantics) is in Decker 1.36