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
file.
> 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:
>
> http://www.imaxx.net/~dughi/other/cbreak/sc1.jpg
>
> 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.
Sam
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT