Re: Offline editor.

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

> > >
> > >         But the winner is; windows ini style.
> > >
> > >         Why? Because windows already has the library to easily parse
> > > ini-type files. I'm lazy.
> >
> > One thing to consider, can you use the library and still keep it gpl?
> It's not a library, is part of the Win32 API.
        Er, yes, badly phrased on my part, it's part of the API :)

        As I sit and consider how to best make a scripting language or two
to define the input, dispay, and output of files data, I find it - as I
did last time - a boggling task.

        I think, perhaps, that it is something of a large enough scope to
not be worth my time.  What I can accomplish in code so very easily would
take a script language of immense complexity to achieve the same
versitility and abilities.  If you've seen the editor, imagine the
difficulty involved to make it easy to describe how the zedit page works
(the one with the list box which you can auto-sort, and auto-renumbers
it's contents, etc), or how you'd deal with different object values
meaning associated with different types.

        No. It's too much effort to do this in a configuration file, which
would only provide poor representation of the data.  1/10 of the effort on
my part, and 1/10 on the person who has to configure the system if it's
just done directly in code.

        I think I'll spend the time generating more generic classes -
like the 'query<type>', where type is 'string' or 'int', or even 'spell'
or 'object type', and cleaning up code.

        That way, I can make it simple to alter or append to these generic
classes, and derived classes can be easily made.  Perhaps for now, only
constant-type data will be held external to the program, for ease of
modification, and any additional types will simply have to be included
later in a specific-mud-branch version. (that you make, not me)


   | FAQ: |
   | Archives: |

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