A few questions if anyone knows!

[deckarep]

1. Before some commands like TEXT(11118, "the Nickel News door") or SAY(11099, "....") what do these numbers mean and how are they determined?
2. There is a script in PostOffice.dinky for starting the postalWorkerWorking thread animation. I noticed that this loop was defined as a while YES but I changed it to a do loop and it still works. Is there any difference in the two approaches or when you'd use one vs the other?
3. I'm not 100% but I suspect there is a way to hot-reload/refresh code changes? If I edit the script text files is there a way to force the engine to reload the script without exiting and starting the game over entirely?

Just a curious question on dinky as a language. I understand it's based on Squirrel? Is it a modified version of Squirrel or entirely homegrown? What is it about Dinky that Squirrel was lacking to motivate the creation of Dinky?

I love learning about this engine and how it was created. Thanks for sharing!

[deckarep]

Ah, first question is localization! The mapping is in the Data/Translations_{language}.tsv files

[grumpygamer]

while(1) { } is the same things as do { }. At some point there might have been an expression in the while loop that was removed and replaced with YES. Typically we don't do while(YES) { }.

Dinky is a completely from scratch engine. I moved on from Squirrel due to wanting to add new commands. It also can't do const expressions, meaning if you have v = 1+1 it will generate an add opcode. where DInky realizes they are const and emits v=2

[deckarep]

Anyone willing to give insight on how: imagePushPopFrozen works? I see that it controls a frozen property on images which seems to perhaps overlap with touchable state?

My best guess on observation of the game: when you invoke imagePushPopFrozen(YES) any images that are buttons already on the screen will have their frozen property set to true. If it is set to true, these images won't receive button dispatch events. More image buttons can be added, and therefore more calls would continue to add those image/buttons to a stack. This would allow for a layering effect of enabled/disabled buttons. Invoking with NO would cause the stack to unwind and the reverse behavior.

It would be great if anyone can confirm this behavior...and a bonus if @grumpygamer chimes in :)

[grumpygamer]

Yes, that is true. Frozen will also stop them from animating. and they are all pushed on a stack so you can freeze all the current ones and then add new ones. This is how the Options screen works.

[deckarep]

@grumpygamer - thank you again for the insights but just to clarify: frozen is just about things animating or not or is it also about preventing button dispatch events or both?

[grumpygamer]

Frozen also makes it untouchable and won't respond to events but is still visible.

[deckarep]

A humble thanks @grumpygamer for your replies! Cheers.

[deckarep]

@grumpygamer - I'm trying to understand the conceptual nature of why all the breakwhile* (ie, breakwhileyacking, breakwhileanimating, etc) even exist in the first place.

Let me take a crack at understanding the nature of these functions. They seem to be called after an animation or yack is kicked off which I think implies that said animations or yacks run in their own "coop-thread". Then the calling code hits one of these breakwhile* commands and perhaps tells the engine that for any animations, yacks, sounds, walking basically ensure that we periodically "yield" back to the engine allowing other threads the chance to run.

If this above is true, why even have these functions needed in the first place? Why not just say that for any running thread kicked off from an animation, yack, sound, etc just ensure that we yield periodically by design?

Another way to ask: what is the advantage of having to opt into these functions? If I don't call them then those threads don't yield and everything else (other threads) won't run until the current thread completes.

I'm just failing to understand the semantics and not trying to be critical of your design choices.

For transparency, I'm trying to reimplement the entire engine in Lua and Love2D and I actually have quite a bit working at this point. I read your fair usage post about DeloresDev (not making a professional game) so please tell me if you're not thrilled to hear about this. All of this is just a learning thing for me as I'm not a traditional game dev but a backend engineer by trade.

[deckarep]

Dang it, did I shoot myself in the foot? 😊…give me a thumbs down on here and I’ll stop bugging.

[grumpygamer]

breakwhileyacking() waits for the current yack file to be done and then continues running the calling script. We often want to wait until the conversation is over before continuing with the game code.

[deckarep]

Ohhhhhhh, that’s what I’m missing! I knew there had to be something to it I was missing. Basically it means yield until breakwhile whatever that something runs to completion …I think.

Thank you Ron for taking the time to write your responses. One of your blog posts mentioned that you would go into technical detail about your scripting language Dinky. I hope to see that article one day.

A humble thanks for your time!

[deckarep]

@grumpygamer - for the engine methods that are like: imageMoveFromtTo, imageAlphaFromTo, image<?>FromTo I'm pretty sure these are asynchronous fire and forget functions.

But other than doing something like: breaktime is there a way to have the calling script wait until these operations run to completion? Similar to the breakwhile* functions for yacking, animating, etc?

[grumpygamer]

They are fire and forget, but they last X seconds, so we will do

imageMoveFromTo(image, EASE_OUT, time, start_pos, end_pos)
breaktime(time)