In case I forget: Before this whole worldtest stuff, I had planned to compile dlgedit on Windows, so that Andrew (and possibly others) could use it. Shouldn't be too difficult compared to compiling the engine itself. However, that also reminded me that there are two unfinished parts in the recent version (see http://adonthell.berlios.de/doc/index.php/Tasks:Dlgedit).
The first item requires an update to the part that generates the final python script, so it will play nicely with the changed character and quest implementation. It's no big deal, but it involves parsing and replacing parts of strings, something that's awkward at best with C++. Which is the main reason why this is still open ;-). The other task (being able to modularize dialogues) is mostly open because of design issues. And that is where I had an inspiration this week which I wanted to share. There are two design issues still open. One is regarding the dialogue compiler: should the resulting python scripts be modular as well, or is it okay to compile everything into one script? The downside of latter is that changes to a dialogue module will result in having to recompile all dialogues that use it. But I'd be willing to go with that for the beginning, since at best it doesn't require any change to the compiler at all. The other issue (and I am sorry that it took me so long to get to the point) is the user interface aspect of modular dialogues, i.e. how the connections between the different levels of a dialogue will work. Right now, each dialogue module appears as a simple box to the outside world. There is no obvious way to make a connection between an outside node and a node inside the module. You would have to select the source node, drill down into the module and select the target node to complete the connection. That would require some changes to the internal data model of the editor, as we'd have two different connections: the visible one between a node and the module box and an invisible one between the two actual nodes. If, however, we would harvest all start- and end nodes from the module (i.e. nodes with no predecessor and nodes with no followers) and display them around the module box, connections could be made directly to those nodes (and only those). That would simplify both the GUI design and the internal data model with one drawback: one could not make connections to arbitrary nodes inside the module. While this sounds like a restriction in theory, I believe that in reality it won't make a big difference. Moreover, you'll get modules whose interface is clearly visible once they are added to a dialogue (provided start and end nodes can be distinguished). Um ... not sure if all that makes a terrible lot of sense to anyone, but feel free to comment. I should perhaps add some sketches to illustrate what I mean and how it would work ... Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel