13 Oct, 2010, JohnnyStarr wrote in the 1st comment:
Votes: 0
I was thinking about creating an OLC server. Sounds kind of funky I know, but hear me out:
Say you have a project running and an extra port, you could host the OLC builder there. The
fancy thing about this idea is that the data could be exported to ROM, RaM, SMAUG, or something
completely custom. It would support multiple connections so that you could have several builders
on at a time, collaborating without having to worry about actual players coming in and out.
All of the raw data would be stored in a database which as said earlier could export into any
format. Also, configuration files would dictate how these objects are serialized to begin with.

Say I was running QuickMud and so my .are files are being output in the traditional style, but I
wanted to convert the code to output into a "Key" style like SmaugFUSS? Well, this would just be
a matter of either adding a new configuration file, or changing the "Rom" format file.

The downside to area editors is that if you add new fields or objects, you need the source to do
this. Not with this idea, you would have the freedom of customizing objects, fields, or adding new
objects and how they are formatted all without having to write any code. (unless one considers YAML to be code)

I have been wanting to write this for a long time, mainly just to contribute something useful.

So, I'll ask the community, would this be cool to you?
13 Oct, 2010, Kline wrote in the 2nd comment:
Votes: 0
I wrote a small CLI conversion utility to help transfer some older areas into my base with the hopes it would pick up more widespread use and lead to more interoperability of areas. I also planned to add some more formats to it but just haven't found the free time :(.

[link=file]2725[/link]
13 Oct, 2010, JohnnyStarr wrote in the 3rd comment:
Votes: 0
I see, interesting.

BTW, Xenogears RULES!
13 Oct, 2010, Rudha wrote in the 4th comment:
Votes: 0
In response to the original post: It would be useful and if it existed for NakedMud I'd probably use it, but I at the same time wouldn't consider it so useful that I would implement itself.

Having building being done on a second copy of the MUD is a common practice; this often also extends to code testing as well. I would find a separate server for only building useful as it would provide a safe "sandbox" for new builders to learn and experiment, without risking pulling the MUD down by writing broken code or something.
13 Oct, 2010, chrisd wrote in the 5th comment:
Votes: 0
I don't think such a thing would be that useful. If you want a dedicated building port, why wouldn't you just run another instance of your game on that port and lock it so only builders can access it?

Rather than having each and every person run their own copy of this server, why not have a central one that builders from any MUD can connect to. They build an area on this server and once they're done, they export it to whatever format they require and have the server e-mail it to their chosen address. I don't think I would use such a service, but it sounds neat.
13 Oct, 2010, Rudha wrote in the 6th comment:
Votes: 0
Quote
Rather than having each and every person run their own copy of this server, why not have a central one that builders from any MUD can connect to. They build an area on this server and once they're done, they export it to whatever format they require and have the server e-mail it to their chosen address. I don't think I would use such a service, but it sounds neat.


That sounds much more obtuse a method to me than what Johnny's suggesting, honestly. Why should I have to email myself my own rooms to implement them?

Maya/Rudha
13 Oct, 2010, chrisd wrote in the 7th comment:
Votes: 0
Rudha said:
That sounds much more obtuse a method to me than what Johnny's suggesting, honestly. Why should I have to email myself my own rooms to implement them?

Maya/Rudha


It could be useful in cases where you want to let builders send you areas without giving them access to privileged commands on your game. Furthermore, if you've only got one port available to you you can't run an extra server dedicated to OLC. If you've got multiple ports, well… as I said before, why not just run an extra instance of your game? Point being, I can't really see a situation where you'd need to run one of these universal OLC servers, but I can see a situation where you might want to use one.
13 Oct, 2010, Rudha wrote in the 8th comment:
Votes: 0
chrisd said:
as I said before, why not just run an extra instance of your game?


I believe I answered this previously, but in case it was unclear: the reason I would not want to just run a second version of the full game server is that it's overhead that I wouldn't need to "just" build. It really depends on your requirements I suppose.

One advantage I could see to a "universal" server: say I have people interested in building for Elvenblade, but they are experienced in building for DikuMud, or one of it's derivatives. I could spend the time retraining them to use Elvenblade's OLC system. It takes a bit and there's always "gotchas" as I call them. But if I had a "universal" server (or even just some sort of universal OLC) then I would not have to spend the time retraining them, or it would, at least be mitigated.

That said, as I said in my opening reply, it would be useful and I would use it were it written, and probably be pretty pleased with it, but I don't consider it so useful that I would write it myself.

Maya/Rudha
14 Oct, 2010, Runter wrote in the 9th comment:
Votes: 0
Not useful unless it provides superior tools to the native codebase. Like a better interface for generating the layout. Click and drag to connect rooms. Maybe a more simple way to keep up with vnums. But honestly, you're really o ly targeting a single family of muds.
14 Oct, 2010, David Haley wrote in the 10th comment:
Votes: 0
I have to admit that I don't really see the point either; I'm with Runter on this one. Unless you have very tight integration with the native codebase, what are you providing? I also think it's somewhat utopic to believe that a single OLC server can realistically serve several different servers with potentially dramatically different underlying models.
14 Oct, 2010, ATT_Turan wrote in the 11th comment:
Votes: 0
I would be more interested in a downloadable area editor with a GUI that could use configuration files to save areas made inside of it into different formats. I have seen a few that look nifty, but they're all specialized for a specific codebase - and, of course, if you modify your area format at all within your codebase, it still breaks compatibility.
14 Oct, 2010, jurdendurden wrote in the 12th comment:
Votes: 0
Nick Gammon's GUI area editor is open source and quite modifiable, have you checked this out ATT_Turan?
14 Oct, 2010, ATT_Turan wrote in the 13th comment:
Votes: 0
I believe I have, but in order to make his editor work with different file formats you'd have to download the source code and change it in there, which is somewhat different from my thought of one editor that could make an area and save it into different area formats via choosing a configuration as you save. That's not say it might not be a solid starting point to make such an editor, just that it wasn't useful for me because the time spent to do that would more usefully be spent on improving my game's OLC.
14 Oct, 2010, Kline wrote in the 14th comment:
Votes: 0
ATT_Turan said:
I would be more interested in a downloadable area editor with a GUI that could use configuration files to save areas made inside of it into different formats. I have seen a few that look nifty, but they're all specialized for a specific codebase - and, of course, if you modify your area format at all within your codebase, it still breaks compatibility.


I try to hype AVAE at every chance I get; and this seems like a good one! While AVAE is geared for Ack based games, the bulk of the area format is customizable via XML template files. So for games with a slightly off flag set, or new fields, it's not hard to make it compatible. It also has a MUD-preview mode where it dumps you into a live copy of your zone you can fully walk around in and explore, or build in similar to logging into a real buildport. You can also use the GUI to click/point/edit and build that way, instead. I'm not a Java person at all but would love to see AVAE resurrected and carried on into a new era of greatness :)
15 Oct, 2010, ATT_Turan wrote in the 15th comment:
Votes: 0
How slightly off? Can the XML's be configured to save it in a drastically different format? I'll have to check it out.
15 Oct, 2010, Kline wrote in the 16th comment:
Votes: 0
ATT_Turan said:
How slightly off? Can the XML's be configured to save it in a drastically different format? I'll have to check it out.


Last I used it I remembered it was good for re-ordering how a file was saved (since nothing was in a key'd format) and maybe adding one or two additional fields. Definitely check it out though!
15 Oct, 2010, Quarlash wrote in the 17th comment:
Votes: 0
Not to invert the intent of the topic, but why not a central repository of areas broken down to key sections (or fields) with a standard open format and an accessible API? And a web tool to build areas easily into that format? And a compatibility-assistant for importing(or exporting) non-standardized areas from stock muds? Possibly user-based accounts which allow you to privatize and or share the areas (or information) that you upload.

I don't see a project like that being impossible if a couple people lent a hand, and this could provide an exceptional value to the community. I think I might start planning a little more on this tonight…
15 Oct, 2010, JohnnyStarr wrote in the 18th comment:
Votes: 0
Good comments all.

I'll have to think about it for a bit. I imagine I'll just focus on making a more flexible OLC for ROM.
I will probably finish my Lua OLC for ROM.

The whole purpose is so that new users that want to add fields and objects to their ROM OLCs can do this
easily.
16 Oct, 2010, jurdendurden wrote in the 19th comment:
Votes: 0
ATT_Turan said:
I believe I have, but in order to make his editor work with different file formats you'd have to download the source code and change it in there, which is somewhat different from my thought of one editor that could make an area and save it into different area formats via choosing a configuration as you save. That's not say it might not be a solid starting point to make such an editor, just that it wasn't useful for me because the time spent to do that would more usefully be spent on improving my game's OLC.


You're right. One of my builders has pointed this utility out to me, and requested that I modify it to work with our game, but the extent to which I have changed the OLC already would make this a pretty heavy task to be honest. I've been slowly working on it, but yeah, it's definately a 'side' project.
16 Oct, 2010, Ludwig wrote in the 20th comment:
Votes: 0
Quote
why not a central repository of areas broken down to key sections (or fields) with a standard open format


I expect 95% of all uploaded rooms would be missing descriptions. :lol:
0.0/25