Toril editor and the area docs -yes this belongs in gameplay
Toril editor and the area docs -yes this belongs in gameplay
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.)
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.)
-
- 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
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.
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.
Re: Toril editor and the area docs -yes this belongs in gameplay
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.
Re: Toril editor and the area docs -yes this belongs in gameplay
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...
-
- 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
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.
Re: Toril editor and the area docs -yes this belongs in gameplay
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
Re: Toril editor and the area docs -yes this belongs in gameplay
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.)
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.)
Re: Toril editor and the area docs -yes this belongs in gameplay
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
-Formerly Tempus of HomelandMUD -- pre-merger
Re: Toril editor and the area docs -yes this belongs in gameplay
well, I was hoping a product could be developed that could be used by all members of the mud - not just you windows folks :)
Re: Toril editor and the area docs -yes this belongs in gameplay
would give afu something to do
Re: Toril editor and the area docs -yes this belongs in gameplay
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
Re: Toril editor and the area docs -yes this belongs in gameplay
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
Re: Toril editor and the area docs -yes this belongs in gameplay
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
-Formerly Tempus of HomelandMUD -- pre-merger
Re: Toril editor and the area docs -yes this belongs in gameplay
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]
Re: Toril editor and the area docs -yes this belongs in gameplay
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).
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).
Re: Toril editor and the area docs -yes this belongs in gameplay
Good luck to you :-)
[Profile edited by Board Admin. If you can't be civil, we'll fix it for you. -ed]
Re: Toril editor and the area docs -yes this belongs in gameplay
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.
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
-Formerly Tempus of HomelandMUD -- pre-merger
Return to “T2 Gameplay Discussion Archive”
Who is online
Users browsing this forum: No registered users and 66 guests