Re: Thoughts on PjD's Offline World Editor

From: Patrick Dughi (
Date: 12/31/00

        > pharaphrase dak: XML & http are gooooooood <

        I agree.  Matter of fact, having no real world experience with
XML, at a certain point in time, I had invested a decent amount of effort
in examining it when it started coming up as every other topic on
slashdot, as well as often enough here.

        Doesn't mean I understand it so well though :)

        The one thing that I may just not have gotten to yet is that of
interface design.  I'd be curious to see how you can write a generic, yet
useful interface for most of the common tasks in the editor.  Just taking
a few examples;

Ex 1:

        Need a way to read a static list of data and associate it with
values and a name (ie, name = Item types, with [char string,number] for
the data and value).

        Take that and present it at a certain location in a drop down list
box, where selection of a given item will result in a 'value' type for
later use (since int's are easier to deal with than random strings in most

        The ability to locate this setting in a file, and store it or load
it in a file in the correct way.

        Now, 1 & 3 I know how to do.. 2... i've not seen. But drop down
list boxes are a common control, perhaps it's there.  Lets look at example

Ex 2:

        We assume we can load/write data for zcmds, no matter what they
are.  Data is read in and written out as it appears on screen - with
translations to the proper syntax of course.  We assume the translation of
zcmd to an english string to be a trivial process, despite the fact that
the command type determines number of commands displayed and the syntax
for each cmd differs slightly in many cases.

        Data is loaded in sequential order and given a number starting at
1 for that order.  it is then placed in a standard listbox (not drop
down).  This list box though has a scroll bar on the bottom.  It also has
drag and drop capabilities - if you drag the representation of one zcmd (a
single line item) to a place above or below it's current position, it will
renumber the commands and redisplay with the moved command in the dropped
position.  Further, there is a last command which will always exist, even
if there are 0 zcmds, which reads "add a new cmd".

        When double clicking on any given entry, it allows the user to
edit it in place, as if they were adding a new one, only filling in the
correct fields

        if clicking on the 'add a new cmd', it opens a window which allows
you to enter the appropraite info.  In this case that means altering the
display based on values contained within the display (like, changing
button functionality based on command type, etc)


        I can't think of a way to describe this, and I have to imagine
that this sort of functionality just isn't built into any system.  I know
cause I had to cobble it together.  But this is just one representation.

        If your answer is that you have to make a seperate control in
visual c++ each time you want a unique, non existing control, including
even trival things like whether it should display or not, or screen
position, then that invalidates the use of XML to nothing more than data
in/out parsing.  Still valuable, but that means your interface will be
custom c code.  That means it's probably easier to leave the parsing out
and keep everything in the same langauge and format, instead of having to
translate to a C-usable form each time you want to do something.

        Again, I don't know if a translation to a C usable form is
required - or what is involved, but I'm just thinking about potential
required processes.

        The other thing is that someone would have to have is a moderate
grasp on XML to define a new DDL, and document each time they add
something even reasonably unique.  Considering that it probably already
exists in C for use in their mud, and again, all associated functions are
written, etc, might it not be easier to just cut and paste on a per-mud

        All these aside, i have been looking for an excuse to insert XML
into this project, as it's exactly what i need for the read in/out of the
files.  However, I still want to make the interface as dynamic as the
existing one, and also easy to configure by others who may know zero code
at all (like the head builder)

        Maybe someone (dak?) can answer these questions.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 04/11/01 PDT