Dialog bug

[Kelandon]

I'm not sure if this is old news, but I think I've found yet another bug in BoA, namely this: if you set up a dialog with only a first and third dialog option, the third dialog option returns the number 2 instead of the number 3 when one uses run_dialog().

 

This is what I mean:

 

Code:

     reset_dialog();     add_dialog_str(0,"1, 2, or 3?",0);     add_dialog_choice(0,"1");     add_dialog_choice(1,"2");     add_dialog_choice(2,"3");     print_num(run_dialog(1)); 

Choose dialog option 3, and it prints the number 3. However:

Code:

     reset_dialog();     add_dialog_str(0,"1, 2, or 3?",0);     add_dialog_choice(0,"1");     add_dialog_choice(2,"3");     print_num(run_dialog(1));  

Choose dialog option 3, and it prints the number 2.

 

This seems like a particularly malicious bug because one could have a dialog option that may or may not be available depending on a flag, and the resulting run_dialog would return an unexpected number.

 

The workaround, of course, would look something like this:

Code:

     reset_dialog();     add_dialog_str(0,"1, 2, or 3?",0);     add_dialog_choice(0,"1");     if (get_flag(5,25))          add_dialog_choice(1,"2");     add_dialog_choice(2,"3");     if (get_flag(5,25))          print_num(run_dialog(1));     else          if (run_dialog(1) == 1)               print_num(1);          else               print_num(2);  

But this seems excessive to me.

[Lilith]

EDIT: Ah, I see what the problem is now.

 

I suppose one workaround is to make sure that whenever possible, dialog options that are only available conditionally are the last one on the list, so they don't affect the order of the others.