Toril editor and the area docs -yes this belongs in gameplay

Feedback, bugs, and general gameplay related discussion.
grundar
Sojourner
Posts: 209
Joined: Sat Mar 12, 2005 5:03 am
Location: vt inn
Contact:

Toril editor and the area docs -yes this belongs in gameplay

Postby grundar » Sat Aug 30, 2008 3:54 am

Could someone maybe update the area docs, particularly the object files as there are no ATD devices present anywhere? and also while we're at it, update the toril editor so it recognizes these file types?

i'm certain there's a ton of object types i'm missing due to a lack of an accurate listing in the area docs, same goes for other types and mob races i'm sure have come in since the last update.

easier zonewriting makes for new content, new content makes for more shit to do. if you made it half as simple to build zones for toril as it was for homeland you'd have more than just the 1 odd zone per year coming in.

(i did not invite a discussion as to why this belongs in gameplay btw. if you dont understand why it does, please dont post here.)
Dugmaren
Staff Member - Areas
Posts: 554
Joined: Tue Dec 11, 2001 6:01 am
Location: Vancouver, Canada

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Dugmaren » Sat Aug 30, 2008 4:17 am

http://www.icebergdryice.com/areadocs/toc.php

Whipped that up.. incomplete, needs work, not hosted on torilmud.org yet. However - it IS better then scrolling through text.

Dug

- feel free to request updates to confusing / unformatted parts / whatever.
daggaz
Sojourner
Posts: 464
Joined: Mon Nov 01, 2004 4:17 pm
Location: Copenhagen, Denmark

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby daggaz » Fri Sep 19, 2008 4:34 pm

I just wish they had OLC. You realize Dug, that I have over 1500+ rooms of well written zoneage still sitting around on my computer? I got sick of the editor crashing every five minutes, and eventually gave up.
Zoldren
Sojourner
Posts: 1309
Joined: Mon Feb 12, 2001 6:01 am
Location: mt. vernon, il
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Zoldren » Thu Oct 02, 2008 11:52 pm

who has the te code? I know there are plenty of people who play with code that wouldn't mind updating it....to match current area restrictions/codes etc...
Marthammor
Staff Member - Areas
Posts: 834
Joined: Tue Jul 15, 2003 9:00 am
Location: On a Rocky Tor Overlooking a Storm-Ridden Landscape
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Marthammor » Fri Oct 03, 2008 5:16 pm

I had asked the same question about the code. The reply I got was that the code for it was lost a long time ago. I know there have been a few attempts to make another editor, but none seem to have been finished.
Gormal
Sojourner
Posts: 3917
Joined: Tue Feb 13, 2001 6:01 am
Location: A Whale's Vagina
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Gormal » Fri Oct 03, 2008 9:56 pm

Coming in 2.0.
User avatar
Shevarash
FORGER CODER
Posts: 2944
Joined: Fri Dec 29, 2000 6:01 am

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Shevarash » Mon Oct 06, 2008 6:39 pm

I don't have any idea where the TE code is, and I lost Ilsensine's email address a long time ago. I can try to hunt around for it a bit, but honestly, in this day and age I'm not sure that maintaining a DOS based editor would be a good use of anybody's time. Now, a .NET or Java editor, that would be slick..and possibly easier to get up and running (and maintained) than a DOS editor written in C. Anyone interested?
Shevarash -- Code Forger of TorilMUD
Raiwen
Sojourner
Posts: 430
Joined: Sun Jan 28, 2001 6:01 am
Location: Atlanta, Ga USA
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Raiwen » Mon Oct 06, 2008 7:35 pm

Actually,

I've been thinking this over the past few days of doing something in java. I don't like to run windows/dos based OS's, so java would be perfect for me - and for you windows people out there.

Initially, I was thinking of creating an xml DTD which lays out a structure for the "stuff" that's in a collection of zone/item/quest files.

Next, I'd create an import routine to suck in an existing set of files, and massage it to this xml format.

From there, i'd be easy to manipulate all that in memory, and provide a front end interface.

I was even tossing ideas around in my head about a hibernate style database backend to keep track of changes/versions/etc... even the data itself. then, you could build in data constraints to keep things sane and ensure you have records pointing to where they should be pointing, etc. Since it's hibernate with a backend of whatever you want, you could theoretically point the database to something like embedded sql, sqlLite, oracle, mysql, sybase, ms-sql, postgres - whatever - and just migrate the data without having to touch the code.

My first thought about the xml, was that it would be relatively easy to suck in a text file, read it into an xml document tree object, and then flag all the stuff that it couldn't read properly. It'd be easy to store, easy to write output programs for (xml libraries exist in almost every language), and xml is pretty strict about keeping to the DTD. So, that's sort of like another error checking function. A collection of xml "zone" files

You could even collect groups of xml files together into zip files, to ease organization of the data, ease the storage requirements, and could easily create routines to read the data in read only mode, directly from the zip file. (like a jar file, but I'm thinking more language agnostic.)
Vaprak
Staff Member - Areas
Posts: 630
Joined: Wed Feb 16, 2005 5:46 pm
Location: Midwest

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Vaprak » Mon Oct 06, 2008 10:04 pm

I think it'd be cool if the MUD could read area files that were formatted in XML. Personally, I'd write it in VB.
Vaprak, the Destroyer
-Formerly Tempus of HomelandMUD -- pre-merger
Raiwen
Sojourner
Posts: 430
Joined: Sun Jan 28, 2001 6:01 am
Location: Atlanta, Ga USA
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Raiwen » Mon Oct 06, 2008 10:27 pm

well, I was hoping a product could be developed that could be used by all members of the mud - not just you windows folks :)
Zoldren
Sojourner
Posts: 1309
Joined: Mon Feb 12, 2001 6:01 am
Location: mt. vernon, il
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Zoldren » Mon Oct 06, 2008 11:22 pm

would give afu something to do
Gizep
Sojourner
Posts: 150
Joined: Thu Mar 10, 2005 4:34 pm
Location: Menzoberranzan
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Gizep » Mon Oct 06, 2008 11:29 pm

right like they would give me a copy! hah, not happening, too bad too, inferfaces to flat files is what im good at :p you should look into include in your php manual, little formatting could read the zone files directly, at least the indexes..
As long as we live in this world we are bound to encounter problems. If, at such times, we lose hope and become discouraged, we diminish our ability to face difficulties. If, on the other hand, we remember that it is not just ourselves but everyone who has to undergo suffering, this more realistic perspective will increase our determination and capacity to overcome troubles.
-- The Dali Lama
Gizep
Sojourner
Posts: 150
Joined: Thu Mar 10, 2005 4:34 pm
Location: Menzoberranzan
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Gizep » Mon Oct 06, 2008 11:36 pm

btw, all you would need to do is include your structs.h, utils.h, utils.c, constants h and c, and any other defines that you deem important, mostly just keeping those bits and what they stand for...
As long as we live in this world we are bound to encounter problems. If, at such times, we lose hope and become discouraged, we diminish our ability to face difficulties. If, on the other hand, we remember that it is not just ourselves but everyone who has to undergo suffering, this more realistic perspective will increase our determination and capacity to overcome troubles.
-- The Dali Lama
Vaprak
Staff Member - Areas
Posts: 630
Joined: Wed Feb 16, 2005 5:46 pm
Location: Midwest

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Vaprak » Tue Oct 07, 2008 12:16 am

You don't really need any MUD code to build an area editor. The area docs are freely available.
Vaprak, the Destroyer

-Formerly Tempus of HomelandMUD -- pre-merger
shalath
Sojourner
Posts: 310
Joined: Thu Oct 30, 2003 8:46 pm

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby shalath » Tue Oct 07, 2008 5:35 pm

Raiwen wrote:Actually,

I've been thinking this over the past few days of doing something in java. I don't like to run windows/dos based OS's, so java would be perfect for me - and for you windows people out there.

Initially, I was thinking of creating an xml DTD which lays out a structure for the "stuff" that's in a collection of zone/item/quest files.

Next, I'd create an import routine to suck in an existing set of files, and massage it to this xml format.

From there, i'd be easy to manipulate all that in memory, and provide a front end interface.

I was even tossing ideas around in my head about a hibernate style database backend to keep track of changes/versions/etc... even the data itself. then, you could build in data constraints to keep things sane and ensure you have records pointing to where they should be pointing, etc. Since it's hibernate with a backend of whatever you want, you could theoretically point the database to something like embedded sql, sqlLite, oracle, mysql, sybase, ms-sql, postgres - whatever - and just migrate the data without having to touch the code.

My first thought about the xml, was that it would be relatively easy to suck in a text file, read it into an xml document tree object, and then flag all the stuff that it couldn't read properly. It'd be easy to store, easy to write output programs for (xml libraries exist in almost every language), and xml is pretty strict about keeping to the DTD. So, that's sort of like another error checking function. A collection of xml "zone" files

You could even collect groups of xml files together into zip files, to ease organization of the data, ease the storage requirements, and could easily create routines to read the data in read only mode, directly from the zip file. (like a jar file, but I'm thinking more language agnostic.)

This seems horribly over-engineered. Databases, schema validation, abstractions like JPA...why? If you want to write an editor, write an editor; then add stuff when it works if it makes sense to do so.

Apart from that, I would ask - why XML? The mud runs the zone files as they are, which means that your output has to be in that format, and not XML. Humans interact with your graphical interface, which means that you show them images and buttons and stuff, and not XML. Where is the advantage in using XML here? XML is a great border technology - for interfacing two disparate systems using a self-defining markup language which both sides can translate into their own native formats as needed. Here everything will be done inside your own program - a single system which translates the human interaction to a zone file. Consider carefully why you think you need XML.

Please note: I'm not trying to discourage you. I'm simply suggesting you try and keep it somewhat simpler than you're currently describing :-)

-simon
[Profile edited by Board Admin. If you can't be civil, we'll fix it for you. -ed]
Raiwen
Sojourner
Posts: 430
Joined: Sun Jan 28, 2001 6:01 am
Location: Atlanta, Ga USA
Contact:

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Raiwen » Wed Oct 08, 2008 5:19 am

I'm trying to formalize some requirements about this, and hopefully I could get some input before I start sketching a bunch of crap that nobody wants. Requirements begin with an asterisk (*) .

Several reasons for xml:

* Document Type Definition - You can CLEARLY define what belongs in an area file beside that which is defined in a really, really long ascii file that was created some 10 years ago. It'd be very strict, and open the door for OTHER editors or applications to manipulate the area data (maybe even the mud itself). A DTD is a clear win, no matter what. Updates to the area file format could use different versions of the DTD. Thus, no matter what XML file was read, the program (or mud) could run it against that DTD to ensure it was properly formed. Program/editors would be designed to ensure they work with certain versions of zone files. If ABC editor doesn't support XYZ types of data that was introduced in v1.5 area-xml, then it will know to alert the user that the document will be downgraded - or not open it at all.

* Generic Interface - Yes, XML could be used for bordering systems, but it can also be used to generically describe something. Such as an area file. I'm thinking different versions of toril, or even different muds all together. Who says that a zone editor has to be used for just creating and editing toril areas?

* Importer - I'm sure there is data in existing zone files that is br0ken, or just bad form. Importing to an intermediary format, then back out again, is an acceptable way to flag things that need to be adjusted. A simple import < file.zone | export > file2.zone ; diff -u file.zone file2.zone could show you what's wrong. My idea was to use "document drivers" which are basically classes that perform the import and exporting of the raw data to an internal format, and even an xml format.

* Exporter - Who cares what format the current mud uses for it's area files? Just expand it's document driver, or inherit it's methods and overload what you need to create a new raw area format.

Why databases?

* Databases - I was just throwing ideas out there. I was thinking way ahead of myself, but for years I've often wondered how different muds would be if they ran off databases instead of flat text files. Data integrity. Saved states (on crashes). Transactions!! Anyways, you're probably right about including that in a zone editor - however, if it could work - imagine the possibilities!

What other requirements?

* Revision Control - I do like the idea of revision control. You could create your own local copy of subversion or CVS, and perform the revcon youself - if you don't already do that or at least keep backups - then you should consider it. I've seen java modules that directly talk to subversion or CVS repositories. Would be neat to have that automatically handled for you.

* Open interfaces and architectures - I like to think in open architectures. Area files are soooo 1993. There is a informal text file that describes these other text files. Extra space or character, line break, etc, and the area file could be corrupted or read incorrectly. It may even appear to be correct until whatever app that's reading it reaches a point of no return - and has to crash or exit. How do you verifiy it? Easily? Accurately? To solve all these corner cases, these "exceptions to the rule", and all that fuzzy logic that text file formats require - it's just wasted effort for every programmer that wants to build an editor for these beasts.

However, to create an importer/exporter and then store the data as a clearly defined XML file that strictly adheres to a DTD (that hopefully could be blessed by the admins themselves) - well that just opens the door for lots of opportunities. Such as the mud actually using these xml files for it's zone data, to the ability of other editors (or scripts) to parse this data easily and in a defined manner.

Hell, with the right DTD and XML editor, you don't even NEED a GUI to create a zone. Lots of XML editors can take a DTD and will give you HINTS and AUTOCOMPLETE attributes for the file! Who needs area docs? (that's rhetorical.)

(yes this is long winded - almost done)

Enough Backend - what about the Frontend?

* Graphic Interface - So once the import of the data and the output of the data to either xml or raw area file is taken care of (the structure). What's left? The interface. It boils down to "how graphical do you want it?" Do you want 3D renderings of rooms based on dimensions, with 3D representations of exits with an overlayed alpha blended 2D map? that'd be sweet, but I don't really have the time for that!

* Sorted object lists - I personally would want a list of objects/rooms
room1 - Big Cave
room2 - Guarded Cave Opening
room3 - Main Gathering Cavern

I'd also want the ability to change what is displayed and sorted, such as by mob object, or by room object.

* Map Grid - I'd want a grid somewhere, so I could get an easy visual of how it looks - yet this grid needs to represent 3D , or at least handle it in a consistent way - a zone like SF could look really annoying if the map drawer was implemented incorrectly - some levels with only two rooms - spaces apart? Eww!

* Generic Objects - a list of generic objects that would be defined in the DTD in a "generic" section, so you could drag basic mobs/items.

* User defined objects - Have an easy way to create objects, maybe like a software wizard, or possibly using a template from a "generic" object.

* Drag and drop from lists/icons (not from Desktop) - Have a grid of icons for either generic objects, or user-defined items/mobs, and be able to drag them to a room/item/object. Drag "connection" lines to link rooms together - for teleport rooms, etc.

* Fast manual room creation - the ability to define a template for a room, and use the curser keys to quickly "key out" a basic area layout.

* Fast automatic room creation - the ability to define a "grid" using something like a software wizard.

* Easy ANSI color - highlight text, select color(s) - DONE. Mud ansi codes automatically exported to raw zone file. Could even use a "color map" in the XML and internal format, so the raw text would be readable, and the color could be applied when needed (toggled).

Raw: This is raw text.
Map: 11f2 e2 3e4 5e550
Out: This is raw text.

* Human Editable Properties - click on something/anything, right click, select properties, and get a window where you can edit the attributes of that object (room,mob,item).
shalath
Sojourner
Posts: 310
Joined: Thu Oct 30, 2003 8:46 pm

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby shalath » Wed Oct 08, 2008 8:28 am

Good luck to you :-)
[Profile edited by Board Admin. If you can't be civil, we'll fix it for you. -ed]
Vaprak
Staff Member - Areas
Posts: 630
Joined: Wed Feb 16, 2005 5:46 pm
Location: Midwest

Re: Toril editor and the area docs -yes this belongs in gameplay

Postby Vaprak » Wed Oct 08, 2008 11:57 am

Need the ability to "dig" zones out similar to homeland OLC and I think the toril editor.

A simple map would be cool, especially if you could click on a room and pull up that specific room.

Lists are good. You'd need a pane where you could see the entire room list, object list, mob list, quest list, shop list, etc.
Vaprak, the Destroyer

-Formerly Tempus of HomelandMUD -- pre-merger

Return to “T2 Gameplay Discussion Archive”

Who is online

Users browsing this forum: No registered users and 30 guests