Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits) (+1)

I have been using this in a bunch of places in my current deck, and I have somehow managed to break it?

It suddenly fails to update the text when you click the buttons. If I switch modes, from interact to widgets and back, then it updates to the correct value, so the value property is clearly still working, it's just the display part that isn't.

I tried repasting in the widget from the post, in case I'd some how munged it while skimming the prototype code for ideas, but it's still not working. I had something like this happen once before and it was only temporary, I think I fixed it by just quitting without save and reloading the deck, but whatever i did was enough saves and commits back as to make no difference now.

EDIT: Figured it out. The internal slider in 'enum' has no default script, but if you go opening its script, Decker helpfully adds an empty "change" event from the default template for sliders ... for reasons I don't entirely think I understand, this breaks the prototype. Manually deleting that "change" script fixes it again. 🤷🏼‍♀️

(+2)

I'd just like to say that I really appreciate you leaving your original comments and following up when you're able to resolve problems on your own; it provides very valuable information for other users who are reading along.

If a widget defines no event handler for an event, the event "bubbles up" to the container card or contraption, and in the case of a card it can further "bubble up" to the deck-level script. Events which "bubble" still further are handled by default event handlers, if any exist. I take advantage of this in many of my contraptions because there is often only a single widget that can produce e.g. a "drag" or "change" event and putting all the logic in the contraption-level script where i can see it at once is slightly more convenient.

An existent but empty event hander "swallows" the event and does not give higher-level definitions a chance to do their work. I recognize that event handler "templates" can be a bit of a footgun in this case, but there isn't any way Decker can automatically distinguish "as-of-yet unfilled" handlers from intentionally empty event handlers meant to suppress bubbling.

I'd also like to note that re-pasting a contraption definition into a deck where the original has been modified will not update existing contraption instances unless the new definition has a higher version number.

Does that help clarify?

(+2)

Yeah, that makes sense, and also explains something I noticed while working with canvas widgets: they also stop working once you open their script, because it stubs empty handlers that then replace the default drawing behavior. 

The insurance policy I put in for 'enum' was to replace the empty handler with a comment instead, as once a script is populated that suppresses the template filling behavior, but in the future now that I understand what causes it, I'll at least know where to look.

And for sure! I think its very important for people to be able to bungle on main, 'cause everyone else gets to learn. Glad its been helpful. ^^