Author Topic: Dialogue Interface  (Read 8238 times)

0 Members and 2 Guests are viewing this topic.

Offline Kawa

Re: Dialogue Interface
« Reply #15 on: January 22, 2021, 08:05:34 PM »
No. The #button thing is just a number that Print recognizes. It has no inherent meaning of "place a button control", that's just how Print reacts to it.

I'd rather make my own dialog box, put whatever control I want in it, like custom buttons. Think of the save/restore window, for example.

Offline scott_furphies

Re: Dialogue Interface
« Reply #16 on: January 24, 2021, 03:07:40 AM »
Y'know, I've stared at my janky button interface for so long that I've learned to love it.

I may change my mind if I can ever get my head around customising buttons.

Offline lskovlun

Re: Dialogue Interface
« Reply #17 on: January 29, 2021, 07:38:10 AM »
If you want something like the inventory code, why not use the inventory code?

Offline scott_furphies

Re: Dialogue Interface
« Reply #18 on: January 29, 2021, 08:34:06 PM »
I like the look of the inventory when you're selecting items, with only the highlighted option getting a border. Also, I expect having some more generalized code to handle this would be less of a headache, if I could get it to work.

I'm pretty new to coding, and I've spent a lot of time trying to pick apart the inventory to no success. I might come back to this later. At the moment I'm enjoying writing fun dialogue trees - so I'm satisfied with my shitty looking buttons for now.

The dialogue tree is definitely the way to go over parser based conversation, dialogue being kind of an in-game hint system, the story has better momentum.

Offline Kawa

Re: Dialogue Interface
« Reply #19 on: January 30, 2021, 05:25:19 PM »
Studying the SCI0 inventory window, it seems the item labels are DText objects. How interesting then that they act not unlike buttons.

Looking at the original LSL3 code, there's a description for DText: "A non-editable, generally non-selectable text field." Emphasis mine. And indeed, when the invDialog generates the list of DText elements representing your current inventory, it sets their state to (| csENABLED csEXIT), or (| dActive dExit) as Sierra liked to call it. You can't normally click on a text label because they don't have those state bits set. Now, DText don't do anything to draw themselves, leaving that to their super, DItem. Checking the SCI11 code, text controls are first drawn as usual, then if the control has the "selected" state and is not a field, list, or icon, it's framed. That's a match.

So that's the basic jist behind the inventory window's "buttons without borders". The exact same trickery applies to SCI11's "get items" debug cheat window.

Now, when a Dialog's doit is called, it'll return the value property of the selected control, which in this case is either a pointer to an inventory item or 0 (the "OK" button's implied default value). And since invDialog is itself a subclass of Dialog, it can provide its own doit, which doesn't actually close the window until "OK" is chosen.

What I'd do for the sake of having a "general use" window in this sort of style, is to copy the whole definition for invD/invDialog, give it a data property, and instead of having it iterate gInv/gInventory, you have it iterate whatever List or Set that data property points to. Remove the "OK" button and the whole repeat block -- just memorize what the super's doit returned, dispose of yourself, and return what you memorized.

Offline scott_furphies

Re: Dialogue Interface
« Reply #20 on: January 31, 2021, 04:23:41 PM »
Thanks, Kawa!
I'll have a look into this next time I have a block of free time, and I'll let you know how I get on!

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.041 seconds with 23 queries.