From: Sammy (
Date: 08/18/00

From: "Patrick Dughi" <dughi@IMAXX.NET>
Sent: Thursday, August 17, 2000 2:19 PM

>         I think that a good first step would be to simply have a standard,
> open source circlemud editor.  Built in the same way circlemud was - no
> frills, but easy to expand upon.  After a while, the momentum may gather
> to include some sort of automatic configuration file.  I know I'd make my
> copy of the editor download the files directly to the mud and alter
> rooms/areas in real time, as well as upload a configuration file and
> conversion rules for areas existing pre-conversion.  Guess I'd have to
> stick a versioning system in there.  In anycase though, it doesn't matter,
> because there is no editor like that out there.
>         If anyone wants to collaborate on that sort of a project, I have
> been kicking a few ideas around.  The only thing I'm really stuck on
> though, is that we make the source as free to have as circle's.

It's 5am  and I just finished an 11-hour workday, so I'm going to keep this
short, but I while back I put a lot of thought into this.  I'll give a brief
overview and maybe write more another time...

My proposal is an editor composed of simple gui building blocks, and using a
simple scripting language to allow more powerful configuration editing by a
mud's coding staff.  The top-level config script would be zone-level and would
call the mob/room/object/shop script, which could call lower level scripts
like an extra description editor.   It wouldn't need a fancy language parser,
just something that woulld allow semi-intelligent decision making.  The gui
building blocks could stay pretty basic and probably wouldn't ever have to
change.  The idea was that with a starting stock circle script set and a short
HOWTO on modifying it to handle things like the 128-bit mod and other popular
changes, it would be very reuseable.  I had even considered writing some
scripts for stock rom/envy/etc to make it more widely useful.

p.s. Here's a really rough draft of a sample room editor script I threw
together a few months ago.  It's ugly, but demonstrates the general idea.

{file {$zone_number}.wld}
{repeat $room_data}

{define room_data filedata {
{$zone_number} {$room_bits} {$sector_type}
{repeat $exit_data}

{define exit_data filedata optional {
{$door_flag} {$key_number} {$room_linked}

{creation getextern {{$zone_number} {$zone_top} {$top_vnum}} or
{$new_roomfile_prompt} do {$create_room_0}}

{define create_room_0 action {
{new {$room_data}}
{do {$open_room_0}}}

{open do {$open_room_0}}

{define open_room_0 action {edit FIRST ROOM}}

{define new_roomfile_prompt dialog {
{{$zone_number} "Zone number"}
{{$zone_top} "Zone top"}
{{$top_vnum} "Top room in mud"}

{define zone_number extern int min 0 max {{$top_room} / 100} default 99}

{define top_vnum extern int min 0 default 32767}

{define room_vnum int min {{$zone_number} * 100} max {$zone_top} default

{define zone_top extern int min {$zone_number} max top_vnum default
{{$zone_number} * 100 + 99}}

{define room_name string min 1 max MAX_ROOM_NAME_HERE default "A New Room"}

{define room_description text min 1 max MAX_ROOM_DESC_HERE default "You are in
a new room."}

{define room_bits bitvector default 0}

{define sector_type enum}

{define direction enum}

{define exit_description text min 0 max MAX_EXIT_DESC}

{define exit_keywords string min 1 max MAX_EXIT_KEYWORD}

{define door_flag ???}

{define key_number int min 0 max {$top_vnum}}

{define room_linked int min -1 max {top_vnum}}

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

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