From: Sammy (
Date: 08/18/00

From: "Patrick Dughi" <dughi@IMAXX.NET>
Sent: Friday, August 18, 2000 12:00 PM

>         >snipped script<
>         That looks pretty good, though some of the repeats (like exits)
> should also follow the min/max restrictions.  Also, how to deal with what
> would otherwise be hardcoded 'constants' - like sector type defines &
> names, or room flag names and values...Otherwise, that looks decent.
> Really, it wouldn't be a big issue to write these 'gui' building blocks as
> activex controls, and then the biggest issue will simply be usability...

That was a pretty rough sample I wrote on the fly without much forethought.  I
think the constants would probably be in seperate files.  I was thinking the
flags and types constants could be generated by a source-parsing utility and
might be included in a "builder builder" that might visually set up the look
and feel.

As for the gui, I was planning a java version for portability (and because
I've been slightly more successful with java gui than with ms-windows.  Java
might open the possibility to set up a mud's web page with a gui editor
builders could use from wherever they find themselves with some free time and
a web connection ;)

>         That is, it's easy to make them pop up, but it makes things look
> poor.  At the same time, it's hard to integrate them into the app so
> they'll be coherent.  I think the best thing to do, perhaps, is to expand
> some on the dialog structure in your script - for example,
> exits/descriptions/etc should probably be in a single dialog box with a
> listbox containing all extra descriptions, aside from just the exdesc
> keywords and text.  Same, perhaps, for the exits.

I agree.  My idea was to define a certain width, then just throw one thing
after another below each other and include the capability for some popups.  It
wouldn't be pretty, but would make for a simpler script.  Unless there's a
"builder builder" I'd hate to have to define the look and feel in a script

>         An aside, I dug up an old project I was working on for a specific
> mud which I never had the time to finish - an editor of all things.  If I
> were to remove the non-stock options and do a little fix-er-uper work
> (like getting that stupid map to finally work!), would anyone be willing
> to do a bit of work on the scripting?

I'll have to admit I have zero experience with scripting, and have had a hard
time getting even simple lex/yacc projects to work correctly, but I may be
able to help out.  Maybe we can work out a design doc and then various people
could work out the interface with C/C++ and Java.

>         What I've got right now is just the following:
>         That's just one form out of, well 3 right now, that were supposed
> to fit into a tabbed box - which I also haven't done yet, only wrote up
> the child frames and some of their functionality (most of it is
> vaporware).
>         Think that's a decent look & feel for stock-type editor, or no?

I like that very much.  I'm thinking that may be hard to define in a text
script.  Any ideas?

>         I would just post out the code now, but that was way back when I
> was trying to make the jump from windows3.11 API-type coding to windows 95
> with MFC.  I will give out the code, resources, etc, when it actually has
> something usable though - no doubt :) Sides, as I indicated, most of it
> right now is vaporware.

MFC and I don't get along very well, and the API isn't much better, so I'd be
more interested in a Java version, but I don't see any reason why we couldn't
do both.  Most of the real work is designing the script interpreter.  Maybe we
can get some dgscripts expertsto do the actual editor-script writing.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

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