Marking dialog options as read/ unread.

[thezombiecow]

I'm using game.read_dialog_option_color, but sometimes it'd be nice to re-classify a previously-chosen dialog option as unread, so the player knows there's potentially new stuff by clicking it...

Is there a way to flip dialog options as read/ unread that I'm missing? A search brought up talk of it round 2.72... was it ever implemented?

[RickJ]

I don't think this possible.  From the manual there dialog options are either "ON" (visible) or off (not visible).


eOptionOff
  The option is disabled - the player will not see it
eOptionOn
  The option is enabled - the player can now see and use it
eOptionOffForever
  The option is permanently disabled - no other command can ever turn
  it back on again.

[Ghost]

ZombieCow meant the (seldom used) feature of having dialog lines that were chosen once displayed in a different colour. That's not the same as turning lines on of off.  

IIRC "Nelly Cotaloot" had that feature, plus an option to turn it on/off- that would mean there *is* a way to tinker around with the feature, though probably not what you need. Maybe Ali can shed some light here...

[edit]
Also, with AGS's new ability to render dialog lines totally customized, one could script up something?

[RickJ]

ZombieCow meant the (seldom used) feature of having dialog lines that were chosen once displayed in a different colour. That's not the same as turning lines on of off.  Wink

I understood what he wanted and since his question had no replies I replied that the manual only makes mention of turning dialog option on or off.  I was not aware of the latest ability to change colors so I appologize for being a bit out of date.

[Ghost]

Sorry then, I didn't want to play the smartarse 

[RickJ]

No problem Ghost, I didn't take offense; just wanted to clarify my comments ZombieCow and the others.   

[GuyAwesome]

Nice to see an online community with an actual sense of community, not just snark and backbiting.

WARNING! Long post ahead hope it makes sense.

[edit]
Also, with AGS's new ability to render dialog lines totally customized, one could script up something?

Yeah, I think that's how you'd have to do it, unless there's a custom dialog system out there you could adapt. There's two stages, as I see it, colouring the options differntly if they've been read (pretty easy), and KNOWING if they've been read or not (not so).

Firstly copy all the custom dialog rendering functions from the manual, and change the colour/size/position/etc settings to suit. Then change a few lines in dialog_options_render

Code: ags

      if (info.ActiveOptionID == i) info.Surface.DrawingColor = 13;
      else info.Surface.DrawingColor = 4;

to

Code: ags

      if (info.ActiveOptionID == i) info.Surface.DrawingColor = 13;
      else if (info.DialogToRender.HasOptionBeenChosen(i)) info.Surface.DrawingColor = game.read_dialog_option_color ;
      else info.Surface.DrawingColor = 4;

(Or the colours you actually want.)

HasOptionBeenChosen looks to be read only, so you'd need someway to get AND set the state.

Code: ags

bool OptRead[50000]; // Random number, based on 500 Dialogs (maximum) @ 100 topics each. Probably overkill.

bool SetUnread(this Dialog*, int Option) {
  int optAbs = this.ID*100 + Option;
  OptRead[optAbs] = false;
}

bool IsRead(this Dialog*, int Option) {
  int optAbs = this.ID*100 + Option;
  return OptRead[optAbs];
}

Then you call dTest.IsRead(1) instead of dTest.HasOptionBeenChosen(1), and dTest.SetUnread(1) to refresh it. The downside is keeping track of when options are clicked...
According to the manual the custom dialog rendering stuff is advanced scripting, so this probly doesn't belong here, but: How does AGS determine which option was actually clicked on? dialog_options_get_active shows where the mouse is but not if it's been clicked, and dialog_options_mouse_click seems to only deal with clicks NOT on any option (which sounds wrong for its name).

If you knew this, it'd be easy enough to automate setting whether an option is read or not. Without it, you might have to MANUALLY set each option to read in dialog script.

[edit]:
Thinking about it, you're probly not going to want to refresh ALL the topics in the game, are you? So manually setting refreshed topics back to read shouldn't be as much work as

manually setting EVERY topic to read, every time.
So what if you had three states, for unread/read/refreshed, instead of just read/unread. Make OptRead an int and setUnread/IsRead into functions (SetUnread will also need to set the option AS read, or make another function for that) and it should be possible. Maybe set up an enum to make it easier to tell what the values mean. Then you add a check to the dialog rendering functions that sets the option as read if HasOptionBeenChosen is true, and it's not marked unread.

Code: ags

  if (info.DialogToRender.HasOptionBeenChosen(i) && info.DialogToRender.IsRead(i) != eOptMarkUnread) info.DialogToRender.SetUnread(i, eOptRead);

Check IsRead when you're setting the colours of the options. You'll also need to call SetUnread in the refreshed option's dialog script to mark it as read again.

[Ali]

For the record, I'm afraid Nelly Cootalot wasn't able to 'refresh' read dialogue options, because I never worked out a way to do it! It was just possible to switch the shadowing on and off. GuyAwesome's suggestion sounds very interesting though, and somewhat awesome.

[Vince Twelve]

Would it not be possible to just have multiple dialog options that are the same, but one of them containing more info?  Then you turn off the one with more info until appropriate (and turn off the other one).

When you turn the option with expanded dialog on and the original off, it would have the same effect as marking it as unread.  The only downside is that you'd have to potentially copy/paste a lot of dialog if it's repeated between them for each version of the option.

[GuyAwesome]

The only downside is that you'd have to potentially copy/paste a lot of dialog if it's repeated between them for each version of the option.

Couldn't you use scripting to link them all to the same function, to save copy/pasting, that is have the 'dialog' once in the global script and just call it as needed? The actual downside, as I see it, is all the redundant options you'd have to create but otherwise, yeah, that might be the easier way to do it. Shame, as I think I've gotten my code working. I'm just too lazy to create a bunch of dialogs to test it with...

[Vince Twelve]

D'oh.  Totally right, GuyAwesome.  I don't use AGS dialog system in my game, so I forgot how you no longer need to use the old dialog_request mumbo jumbo.

[GuyAwesome]

Well I reckon dialog_request would've worked too, but allowing 'proper' commands just makes it a bit easier and neater looking IMO.

Another downside to the multiple topics idea is if you're going to have new information available more than once (multiple refreshes), you'll need to track which dummy options have been used so you know what to turn on/off, especially if the updates can occur in any order. Depends how - and how often - it's going to be made use of, I suppose. Zombiecow, you still out there?

[JpSoft]

One member of our team just worked in a dialogs module; she included an option to disable the options already were selected, even when the player still can see it (i guess it could be usefull for this case too)

I will post the code as soon as i have it

Jp