15 May, 2011, Rojan QDel wrote in the 1st comment:
Votes: 0
Has anyone found success in converting a Smaug-type MUD to use a standard file format such as YAML or XML or even JSON rather than its bizarre home-brew file format (that's different for each type of file…)?

Also, has anyone experimented with file versioning much aside from using source control such as Git or HG?
16 May, 2011, Tyche wrote in the 2nd comment:
Votes: 0
Rojan QDel said:
Has anyone found success in converting a Smaug-type MUD to use a standard file format such as YAML or XML or even JSON rather than its bizarre home-brew file format (that's different for each type of file…)?


Yes. I wrote a convertor that converts TinyMud, Diku, Merc, Rom, Smaug and PennMush files to YAML format for TeensyMud. That's probably not what you're asking since TeensyMud isn't a Smaug mud, although it can use converted Smaug area files. Maybe you mean a Smaug snippet?

Anyway the stock Smaug format I use ends up looking like this:

- !ruby/object:Room
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: |
You float in a formless void, detached from all sensation of physical
matter, surrounded by swirling glowing light which fades into the
relative darkness around you without any trace of edge or shadow.

:owner: 0
:triggers: {}

:location:
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: Limbo
:exits:
- 1206
:msgfail: ""
:id: 1207
:contents:
- 1155
- 1189
- !ruby/object:GameObject
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: A mystical spring flows majestically from a glowing circle of blue.
:owner: 0
:triggers: {}

:location: 1207
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: a mystical spring
:msgfail: ""
:id: 1155
:contents: []

- !ruby/object:Exit
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: ""
:owner: 0
:triggers: {}

:location: 1794
:to_room: 1798
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: south
:msgfail: ""
:id: 1792
:contents: []


Everything is all in one big file. I didn't bother with mobiles.

Rojan QDel said:
Also, has anyone experimented with file versioning much aside from using source control such as Git or HG?


Depends on what you mean. For my own mud, object versioning seems to be more useful. It may be as simple as adding a version property to an object and a mechanism for utilizing it.
16 May, 2011, Rojan QDel wrote in the 3rd comment:
Votes: 0
Interesting that you made a converter. I wasn't really asking about a snippet, but more if someone had been successful in implementing a conversion on SMAUG.

Speaking of TeensyMUD, any plans to make it work with Ruby 1.9?

As far as file versioning, I meant using a more advanced versioning system or versioning file system like git (http://libgit2.github.com/) or any of these http://en.wikipedia.org/wiki/Versioning_... - I know that most muds have a simple version number in files, but I was thinking of actually being able to revert to any saved version of a player file, area, etc.
16 May, 2011, Runter wrote in the 4th comment:
Votes: 0
Sounds like you're wanting a migrations system of some kind.
16 May, 2011, David Haley wrote in the 5th comment:
Votes: 0
The format you store the file in is easy. You'd have to rewrite the loading routines obviously but in most cases it would simplify things because you wouldn't depend on the funky ordering anymore and instead just pull fields out of a data structure returned by the file parser. This would be easier in C++ than in C, and even easier in Python/Lua/Ruby/etc.

As for versioning, just rename the file according to some versioning scheme when you save it. E.g.,
player.data
player.data.1
player.data.2
etc.

when you save a new version, you get
player.data <– new version
player.data.1
player.data.2
player.data.3 <– what used to be player.data
20 May, 2011, Tyche wrote in the 6th comment:
Votes: 0
Rojan QDel said:
Speaking of TeensyMUD, any plans to make it work with Ruby 1.9?

A few people have told me they are running it with Ruby 1.9

Quote
As far as file versioning, I meant using a more advanced versioning system or versioning file system like git (http://libgit2.github.com/) or any of these http://en.wikipedia.org/wiki/Versioning_... - I know that most muds have a simple version number in files, but I was thinking of actually being able to revert to any saved version of a player file, area, etc.


I think it would be pretty easy to add git or subversion commands from existing or new mud olc commands. For example, from your player_save routine you issue an add/commit or commit after closing the file; and an administrator command to list and revert player files.

I think the problem is that version often serves another purpose… to synchronize data and code changes. So that's why I would version each object and write code to handle the different versions.
30 May, 2011, Noplex wrote in the 7th comment:
Votes: 0
Assuming that you're compiling with G++ you can always build a schema for the configuration file, and use XSD to build C++ serialization objects. Works quite well.
31 May, 2011, Chris Bailey wrote in the 8th comment:
Votes: 0
Tyche said:
Rojan QDel said:

Speaking of TeensyMUD, any plans to make it work with Ruby 1.9?

A few people have told me they are running it with Ruby 1.9


Oops, I was going to send you a compatible version and forgot. I need to sort it out from the rest of the changes and get it to you. I'll try to find time this week. =)
01 Jun, 2011, Nathan wrote in the 9th comment:
Votes: 0
I think XML and the like should be avoided, if at all possible, in favor of a standardized plain-text system. Not that it's bad, but all the tags seem to clog up visibility of what is being stored. That and they have to be parsed out, which seems harder than separating on single characters. The ruby example above looks ok, but the date strings should be one string and not use the same separators as the elements, unless you only check for the first, say, ':'. At least I think so. That and any mud that uses it ought to be able to ignore missing fields and leave them empty or fill the in with default values. So, required fields, and optional ones are necessary. A room without a number would be problematic for instance. Versioning is interesting too, is it reasonable to just use a version attribute, or is it easier to use a number after the whole filename?
01 Jun, 2011, Runter wrote in the 10th comment:
Votes: 0
Nathan said:
I think XML and the like should be avoided, if at all possible, in favor of a standardized plain-text system. Not that it's bad, but all the tags seem to clog up visibility of what is being stored. That and they have to be parsed out, which seems harder than separating on single characters. The ruby example above looks ok, but the date strings should be one string and not use the same separators as the elements, unless you only check for the first, say, ':'. At least I think so. That and any mud that uses it ought to be able to ignore missing fields and leave them empty or fill the in with default values. So, required fields, and optional ones are necessary. A room without a number would be problematic for instance. Versioning is interesting too, is it reasonable to just use a version attribute, or is it easier to use a number after the whole filename?


It's not ruby, it's YAML. (Which is closely related to JSON). It's precisely a "standardized plain-text system."
01 Jun, 2011, Tyche wrote in the 11th comment:
Votes: 0
Quote
The ruby example above looks ok, but the date strings should be one string and not use the same separators as the elements, unless you only check for the first, say, ':'. At least I think so. That and any mud that uses it ought to be able to ignore missing fields and leave them empty or fill the in with default values. So, required fields, and optional ones are necessary. A room without a number would be problematic for instance. Versioning is interesting too, is it reasonable to just use a version attribute, or is it easier to use a number after the whole filename?


You can enter date-time fields in about a dozen formats, they just happen to be output in a consistent way. You don't parse or write the file directly, a yaml library does. The only field that's required, in my case, is :id. You can have any number of fields in any order even for the same 'class' of object. How c/c++ would handle that depends on the yaml library they use.

* My conversion programs create a table of Diku-style vnums to ids, and substitute the id for the vnums.
08 Apr, 2013, SelfCoded wrote in the 12th comment:
Votes: 0
Do you still have that converter lying around? If so, mind letting me use it? There are a ton of areas that I'm trying to move to Evennia. While this wouldn't be a direct conversion, YAML would be a lot easier to manipulate than the current format I'm dealing with.

Tyche said:
Rojan QDel said:
Has anyone found success in converting a Smaug-type MUD to use a standard file format such as YAML or XML or even JSON rather than its bizarre home-brew file format (that's different for each type of file…)?


Yes. I wrote a convertor that converts TinyMud, Diku, Merc, Rom, Smaug and PennMush files to YAML format for TeensyMud. That's probably not what you're asking since TeensyMud isn't a Smaug mud, although it can use converted Smaug area files. Maybe you mean a Smaug snippet?

Anyway the stock Smaug format I use ends up looking like this:

- !ruby/object:Room
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: |
You float in a formless void, detached from all sensation of physical
matter, surrounded by swirling glowing light which fades into the
relative darkness around you without any trace of edge or shadow.

:owner: 0
:triggers: {}

:location:
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: Limbo
:exits:
- 1206
:msgfail: ""
:id: 1207
:contents:
- 1155
- 1189
- !ruby/object:GameObject
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: A mystical spring flows majestically from a glowing circle of blue.
:owner: 0
:triggers: {}

:location: 1207
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: a mystical spring
:msgfail: ""
:id: 1155
:contents: []

- !ruby/object:Exit
props:
:msgsucc: ""
:created_on: 2006-06-28 18:56:33.563894 -04:00
:desc: ""
:owner: 0
:triggers: {}

:location: 1794
:to_room: 1798
:updated_on: 2006-06-28 18:56:33.563894 -04:00
:name: south
:msgfail: ""
:id: 1792
:contents: []


Everything is all in one big file. I didn't bother with mobiles.

Rojan QDel said:
Also, has anyone experimented with file versioning much aside from using source control such as Git or HG?


Depends on what you mean. For my own mud, object versioning seems to be more useful. It may be as simple as adding a version property to an object and a mechanism for utilizing it.
08 Apr, 2013, quixadhal wrote in the 13th comment:
Votes: 0
Actually, it would be a worthy project to take such a converter script and then also make the appropriate YAML loader code for each supported Dikurivative codebase. Being able to freely trade areas back and forth between several different MUD types seems like a good thing. Most people have modified their codebases, so it wouldn't be a 100% fix for everybody, but if you started from Smaug or SmaugFUSS, having YAML load/save code for that gives you a pretty close place to start from.
08 Apr, 2013, Kline wrote in the 14th comment:
Votes: 0
I had started writing a small C++ program to do just this a year or two ago, mostly to convert things for my own game. Looking back at it I'm almost ashamed, but it's functional and might make a good starting point for anyone who cared to take it further. I just lost motivation to decipher the formats from other games.

[link=file]2725[/link]
09 Apr, 2013, SelfCoded wrote in the 15th comment:
Votes: 0
Kline said:
I had started writing a small C++ program to do just this a year or two ago, mostly to convert things for my own game. Looking back at it I'm almost ashamed, but it's functional and might make a good starting point for anyone who cared to take it further. I just lost motivation to decipher the formats from other games.

[link=file]2725[/link]


I tried downloading it a couple of times. I'm getting a message about it being corrupt. Sounds interesting though :thinking:
09 Apr, 2013, Kline wrote in the 16th comment:
Votes: 0
SelfCoded said:
I tried downloading it a couple of times. I'm getting a message about it being corrupt. Sounds interesting though :thinking:

Tyche (?) mentioned this being an issue with files here when downloaded in certain browsers I believe. Something about the server gzipping the file on download rather than only gzipping the php page for display. Here is the GitHub for you: https://github.com/Kline-/areaconvert
0.0/16