Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

When you use go[] with a transition, the transition animation needs two Images to animate between, so it sends the view[] event to the target card to see what it’s going to look like. Then, when the transition is complete and the new card is visible, it gets another “view” event like normal.

So no, you’re not doing something wrong, that’s just how Decker works.

If you’re struggling to get the solutions in that other thread working, here’s another alternative: by default, a transition takes 30 frames (half a second), so if view gets called twice within the same second, it’s probably because of a transition, and we can ignore the second one.

If you put a field named lastview on your card, you can use it to keep track of the last time view was called, like this:

on view do
 # If the current frame is more than
 # 60 frames (one second) since
 # the last time view[] was called,
 # call realview[].
 if sys.frame > lastview.data + 60
  realview[]
 end

 # Log that view[] was called
 show["viewed" card.name]

 # Update our records for next time
 lastview.data:sys.frame
end

on realview do
 show["real view"]
end

You should make the lastview field invisible and locked so that players don’t accidentally mess with it.

If you go to this card without a transition, in the Listener you should see the log messages:

"real view"
"viewed" card1

If you go to this card with a transition, you should see the log messages:

"real view"
"viewed" card1
"viewed" card1

realview[] was called for the first view, but the second view happened so soon afterwards, that it skipped calling realview[] the second time.

(+2)

There are many reasons a card can be sent a view[] event, including exiting editing tools, (re)opening a deck, or closing a dialog box. It should not be understood as an event that is fired when a card is visited at all, but rather a request to update the contents of a card. I do not recommend attempting to use timing as a method to disambiguate the origin of a view[] event; such methods are inherently brittle and error-prone.

To address may's problem, I would recommend altering the script on the originating card to send a new event- one not generated by Decker itself- to the destination card after the transition. Let's call the new event "visited":

on click do
 go["Next" "SlideDown"]
 deck.card.event["visited"]
end

(Note that after go[] has completed, "deck.card" will refer to the card we just navigated to.)

The destination card can then fire the dialog in response to this "synthetic" event:

on visited do
 dd.open[deck a]
 dd.say["Kindling Village"]
 dd.close[]
end
(+1)

Thank you both so much, I will definitely try this out!

(+2)

This solved my problem! Thank you so much! :D