From one chooser to another

[DomReardon]

I'm trying to launch one chooser from another, but can't seem to get it working.
I've set up a chooser for some conversation with another character and I have 2 clickable text items at the bottom for responses from the player, each of these text items should launch a different chooser for different responses. I've set up the choosers in interface.xml and I'm dealing with the clickable text items in the game.js. It really seems like it should be working but it's not. I can launch a map change, a story page, all sorts of things, the one thing that I can't do is launch another chooser. Am I missing something here? If anyone has any ideas about this it would be very helpful.

[ggadwa]

I got this on my list and I'll be looking at it ASAP.  It sounds like a problem in my code.  What I should probably add is the ability to jump from chooser to chooser in the XML itself, so you don't have to script something basic like that (but the scripting should work, too.)

[>] Brian

[DomReardon]

Thanks. The ability to jump from chooser to chooser in the XML itself would be really nice for doing conversations.

[Oddity(007)]

While we're at it, the ability to load a custom chooser in a script by say,

Code: [Select]

iface.chooser.new(xmlstring) //Return id
iface.chooser.remove(id)

Would make choosers a lot less awful.

[⑨]

The choosers as they are right now are a very complicated and ugly way to do this. They hardly offer any controll and if you have a lot of choosers in your game, the xml tends to get very, very cluttered.
Maybe a completely different system could be added instead or in addition? Something that would allow a lot more controll over custom interface designs and interactions.

[ggadwa]

The real difference between the XML and doing it in scripting is it's much easier to edit in the XML -- and much harder to keep track of in the scripting.  There needs to be a more in-between solution where you can get the best of both worlds.  Tracking a ton of text and layout information in the scripts is a mess, but having everything static in the XML doesn't give you a lot of control.

[>] Brian

[⑨]

Then maybe we could define prototypes or templates in the XML (like a chooser for quests, a yes/no chooser, etc.) and then call them by script, supplying the information for the texts, image sources, options, etc.?

[ggadwa]

Then maybe we could define prototypes or templates in the XML (like a chooser for quests, a yes/no chooser, etc.) and then call them by script, supplying the information for the texts, image sources, options, etc.?

Ha, you read my mind!  That's what I was working on.  I was thinking something like:

Code: [Select]

<Choosers>

<Chooser name="TheChooser">
<Frame on="true" title="Choose a Map" x="50" y="80" width="900" height="620" />
<Key ok_id="100" cancel_id="103" />
<Texts>
<Text id="1000" data="Some Text" x="90" y="450" size="30" just="left" clickable="false" />
<Text id="1001" data="More Text" x="90" y="530" size="20" just="left" clickable="true" />
<Text id="1002" data="More Text" x="90" y="580" size="20" just="left" clickable="false" />
</Texts>
<Items>
                                 ..................................
</Items>
<Buttons>
<Button id="100" name="Next" .................  goto="NextChooser" />
</Buttons>
</Chooser>

<Chooser name="NextChooser" template="TheChooser">
<Texts>
<Text id="1000" data="New Text" />
</Texts>
</Chooser>

</Choosers>

Basically, setup a chooser, and that chooser can be used as a template further down the line.  Anything in the chooser using a template can just fill in the values they want substituted, in this case, a single piece of text.  As long as the IDs match, everything else will be the same.

Also, any clickable element (buttons or items) can have a goto attribute that will automatically jump to a new chooser.

[>] Brian

[⑨]

Actually I was thinking that the data would be provided by the script that calls the chooser, not the XML.
Same problem as before. Though the amount of code is reduced, when you want 50+ choosers, things will get messy, right?
If it's in the script, the data will all be linked to where it appears in the game.
Right now, if I have a switch that activates a chooser, but I forgot which one it was, I have to go into the script for the switch, look it up, then go back to the XML and change it.
Not really a nice way to do it.
If the data was all in the script, I'd just change it right there and be done.

[ggadwa]

Actually I was thinking that the data would be provided by the script that calls the chooser, not the XML.
Same problem as before. Though the amount of code is reduced, when you want 50+ choosers, things will get messy, right?
If it's in the script, the data will all be linked to where it appears in the game.
Right now, if I have a switch that activates a chooser, but I forgot which one it was, I have to go into the script for the switch, look it up, then go back to the XML and change it.
Not really a nice way to do it.
If the data was all in the script, I'd just change it right there and be done.

You can do substitutions now when you open a chooser (i.e., put something like {0}, {1} etc in the text, and put in strings when you call the chooser, like ('choosername",'subs0','subs1')

[>] Brian

[⑨]

Actually I was thinking that the data would be provided by the script that calls the chooser, not the XML.
Same problem as before. Though the amount of code is reduced, when you want 50+ choosers, things will get messy, right?
If it's in the script, the data will all be linked to where it appears in the game.
Right now, if I have a switch that activates a chooser, but I forgot which one it was, I have to go into the script for the switch, look it up, then go back to the XML and change it.
Not really a nice way to do it.
If the data was all in the script, I'd just change it right there and be done.

You can do substitutions now when you open a chooser (i.e., put something like {0}, {1} etc in the text, and put in strings when you call the chooser, like ('choosername",'subs0','subs1')

[>] Brian

Sounds good.