03 Oct, 2008, Igabod wrote in the 21st comment:
Votes: 0
i'd like to see a description editor that was more friendly to the various mud clients. all the description editors i've seen have it so that .l .h .c .s and all those do the functions like save, clear line, etc. the problem with this is that zmud uses the . to start paths. there are others out there that make use of the / symbol and some that use the # but these are symbols used by other mud clients. i would like to see some other method of formatting and saving and line editing. i'm sure there are other versions of OLC that i havent seen that do exactly what i'm talking about but i would like to see it on rom as well.
03 Oct, 2008, Vassi wrote in the 22nd comment:
Votes: 0
Fizban said:
Line by line entry? I can't think any possible alternative that's mud-client compatible…


I'm not sure i follow that one. I've been using key\flag based "OLC" editors for years. I've actually never seen any alternative as I started on MUDs by building\staffing and then running Darkness Falls and Darkness Falls Crusade (commercial MUDs by Mythic).

I.E. if I had a sword I would do: e o sword name="sharpened blood-steel sword" nam=sword dam=30 etc.

I looked at one of these OLCs for a MUD in the repository here, I confess I don't remember which one, and it looked like it prompted you for each setting one by one, that would totally drive me nuts. Is there a reason it *has* to be that way? Is there a draconic character limit on standard clients I don't know about?

Edit: Also, Chris, if the point is to gear it to NEW Rom users, wouldn't that be a good reason to make a 'drastic' change? Unless by 'familiar' you mean in relation to what other MUDs are doing. Also, I don't know it makes a difference, but the Tempest codebases for DF\DFC were template based so you'd create a mob in a 'slot', for instance, and then assign that index to a gen-table which would then pop them out like cookies. If you changed the slot, it would generate differently everywhere it was referenced, etc.


V
03 Oct, 2008, quixadhal wrote in the 23rd comment:
Votes: 0
Vassi said:
Fizban said:
Line by line entry? I can't think any possible alternative that's mud-client compatible…


I'm not sure i follow that one. I've been using key\flag based "OLC" editors for years. I've actually never seen any alternative as I started on MUDs by building\staffing and then running Darkness Falls and Darkness Falls Crusade (commercial MUDs by Mythic).


He's referring to the fact that although telnet supports switching to character-at-a-time mode, most mud clients do not, and most muds don't fully implement the telnet protocol.

So, you can have editors that accept text or commands when you hit enter, but if you wanted a full-screen editor with arrow keys and such, you'd have to accept that half the clients out there will break.

Personally, I think it's a good idea to implement a full screen editor, and even a menu system that can use cursor keys, but not as the default, and not until all the bugfixing/streamlining is well underway. :)
03 Oct, 2008, quixadhal wrote in the 24th comment:
Votes: 0
Igabod said:
i'd like to see a description editor that was more friendly to the various mud clients. all the description editors i've seen have it so that .l .h .c .s and all those do the functions like save, clear line, etc. the problem with this is that zmud uses the . to start paths. there are others out there that make use of the / symbol and some that use the # but these are symbols used by other mud clients. i would like to see some other method of formatting and saving and line editing. i'm sure there are other versions of OLC that i havent seen that do exactly what i'm talking about but i would like to see it on rom as well.


I'm not exactly sure most people would call it "friendly", but I'd be all for porting my old friend ed as an editor. It's well know and standardized in the unix world (see the man page), the LpMUD people would already know it, and even vi people like me wouldn't grumble too much, since ed is basically the "colon mode" of vi.

I'd be willing to bet there's a version of ed out there that's already set up for embedding, and maybe even BSD licensed.
03 Oct, 2008, Igabod wrote in the 25th comment:
Votes: 0
quixadhal said:
I'm not exactly sure most people would call it "friendly", but I'd be all for porting my old friend ed as an editor. It's well know and standardized in the unix world (see the man page), the LpMUD people would already know it, and even vi people like me wouldn't grumble too much, since ed is basically the "colon mode" of vi.

I'd be willing to bet there's a version of ed out there that's already set up for embedding, and maybe even BSD licensed.

i'm not familiar with the way ed works, but i'm up for anything thats even a minute improvement on the current editor.
03 Oct, 2008, quixadhal wrote in the 26th comment:
Votes: 0
This is interesting…

Quote
A number of different packages were created to add online creation capabilities, the first of these was Armageddon for DikuMUD by Dan Brumleve, Nasri Hajj, and Santiago Zorzopulos, which allowed builders to create zones, rooms, exits, objects, and mobiles interactively through a VT100 menu, or command line driven, interface.[8] Their online creation system was added to the DikuMUD derived SillyMUD codebase, released in 1993.


I think we have a copy of SillyMUD somewhere, don't we? It was on ftp.game.org ages ago. Might be worth a peek to see how it worked. I'm curious if it was just vt100 cursor movement to draw a menu, or if it actually accepted single-character input so you could use the cursor keys.
03 Oct, 2008, quixadhal wrote in the 27th comment:
Votes: 0
Ok, well… back on topic. It's probably time for me to get a few hours of sleep.

What are we using as our baseline? Stock 2.4b6? The cleaned up version? The cleaned up g++ version? Some other variation that everyone likes? I hear QuickMUD is pretty nice and doesn't have too many bells and whistles added, but haven't looked at it yet.

That's probably step 1… deciding where we're starting from, so we can poke around and see what all needs changing. I'd hate to put time into developing OLC or a new editor if we start from a branch that has one already.
03 Oct, 2008, Sandi wrote in the 28th comment:
Votes: 0
I guess what I'm trying to ask you guys that use Ivan's is, "How bad is it? Should it be scrapped?"

As as coder…. IMHO it was written by three students, one of whom got more credit for nice comments than working code. :wink:
03 Oct, 2008, Vassi wrote in the 29th comment:
Votes: 0
quixadhal said:
He's referring to the fact that although telnet supports switching to character-at-a-time mode, most mud clients do not, and most muds don't fully implement the telnet protocol.

So, you can have editors that accept text or commands when you hit enter, but if you wanted a full-screen editor with arrow keys and such, you'd have to accept that half the clients out there will break.


Ok, I follow now. Still, that seems a little excessive - cool mind you - but a little excessive. The only thing I could think of to require that much control would be when editing descriptions, but even then you're more than likely better off copying and pasting from a word processor.

quixadhal said:
Personally, I think it's a good idea to implement a full screen editor, and even a menu system that can use cursor keys, but not as the default, and not until all the bugfixing/streamlining is well underway. :)


That would be pretty neat. We actually use a Telnet console interface here at work for some stuff (Bank) but again, the client support just isn't there. You could bite the bullet and pick one client then require immortals\staff to use it. I have no problems requiring things from my admins :evil: easier, and more fair, than doing it for players.
03 Oct, 2008, Fizban wrote in the 30th comment:
Votes: 0
You might not mind requiring it from your admin, but requiring it from all admin of a specific codebase instead of simply a specific MUD is a rather large leap in my eyes.
03 Oct, 2008, David Haley wrote in the 31st comment:
Votes: 0
Character-by-character mode and some support for clearing the current line would be absolutely wonderful (and incidentally essential) for implementing shell-like behavior in a MUD, e.g. letting you use 'tab' to autocomplete the current command, vnum, etc.
03 Oct, 2008, Davion wrote in the 32nd comment:
Votes: 0
quixadhal said:
What are we using as our baseline? Stock 2.4b6? The cleaned up version? The cleaned up g++ version? Some other variation that everyone likes? I hear QuickMUD is pretty nice and doesn't have too many bells and whistles added, but haven't looked at it yet.

That's probably step 1… deciding where we're starting from, so we can poke around and see what all needs changing. I'd hate to put time into developing OLC or a new editor if we start from a branch that has one already.


I think this is exactly where we should start. I also think it's a fairly simple answer. The g++ clean up of ROM. We are setting up to be a ROM derived codebase. Picking something like Quickmud, 1stMUD or any of the other attempts at ROM would mean we're not directly derived from ROM. The reason I say the g++ clean up, is because what we're attempting to do is modernize the codebase. Now, I'm not saying here that we should full on implement C++ into the codebase, but instead, allow the option for developers to do so if they please, without having to jump through the hoops of getting it to compile under g++. Once we decide on the codebase, we can move on from there and apply all the bug fixes and clean up of the code.

On to the systems. The OLC will definitely be a big step. But seeing as we're trying to keep the feel of ROM I think Ivan's OLC is probably our best bet (1.81 if I may suggest a version.) The system is mostly clean, and very few bugs (with the exception of the progs… I'll get to that later.) It's also very familiar to the builders and programmers a like. There's also a bunch of guides, and general information about it all over the community. Now, for additions to the OLC, I think we can't ignore the plea for a class and race editor. It's totally possible with the existing system. That said, you can't really just stop there. With those, you should also include an editor for the skill/spell table, as well as the groups, so one can easy modify the inner workings of the games without having to dig through the code. Also, for additions to the OLC, we could add ones for generic tables as well (like the bits, and pretty much everything in tables.c.) Along with that, we can remove most of the constants (like the OBJ_VNUM_*, MOB_VNUM_*, ROOM_VNUM_*, MAX_*) and put an online editor for those as well. Now for the progs. I think we can all agree that we'd need to move to something a little closer to an actually scripting system. The PROGs are buggy as -hell-. I spent a good year and a half debugging those pesky things and still didn't come out with a perfectly clean system. For that we have many options, we can write or own, or not reinvent the wheel, and use something like python, javascript or lua. I'm a huge fan of python, and Boost::Python allows for easy integration, and you aren't even required to write wrapper functions for anything really. You can expose already written functions and structs with ease. I know I'm getting a little ahead, but it's something we should atleast start thinking about.

Colour. Colour is a huge part of a MUD. Since we're releasing this as a codebase for the masses and not our own personal game, we should consider an easy way to customize the game appearance. I've used Lopes in the past, and moved on to write my own. I've also looked at a few custom systems, and one of the best was one that used keys for customization. The colour codes looked something like {[say_name], {[say_text], {[score_brackets], etc. It made it so you could totally customize everything, and not just at the implementor level, but all players could make the game the way they want. I've even gone so far as to implement the QSF templating system into the MUD so you could edit score, who, whatever, from a website and view the changes without even having to reboot.

That leads me to the database. Flatfiles verses and actual DB. Very hard to decide this one, as not everyone has the access to a db of any kind. But using a db gives us the ability to have a great deal of integration with a website without very much work. We are attempting to modernize though, so maybe it isn't such a bad thing. -Every- game has to have a website… it's just the standard now, so we should consider at least some level of integration for websites.

Now for the copyover. I think we should offer a little sugar on this one, and implement a seamless copyover that is barely detectable by players. I've gotten pretty close to this, to the point where there's almost no lag. You can view it in the MudConV codebase on this site. Just check acnt_cmd.c and comm.c for the meat of it. This comes -really- close to seamless, it only misses because it doesn't save mobs, combat, etc (mostly because the codebase lacks all these.) But I think it's a nice feature.

Infinite bits. This is a tricky one. I happen to very much enjoy Runter's bitmask code, for implementing infinite bits (also available somewhere on this site.) However, most implmentations of infinite bits introduce some sort of data structure or array to the mix. The problem here, is with the object values, as they use an array of ints to set many default bits. We'll have to tackle that one once it's infront of us, and decide which way to go.

Annnyways, that's my rant. I've obviously though a lot about this subject over the last few years (and have evne made a few attemps)
03 Oct, 2008, David Haley wrote in the 33rd comment:
Votes: 0
Updating it to have it compile under the most recent version of g++ is essential IMO. It's not that hard if you know what you're doing w.r.t. common problems, I've done it for several codebases already.

Player-customizable color is also a must-have for me… I think that being able to color code information the way you want it means that you can maximize your ability to see the information you want.

I would recommend against any kind of database that involves a separate server. A database stored in a flat file would be ok, although I'm not sure it's necessary. A sane file format is obviously a must.

Personally I would refuse to use anything that doesn't have decent support for arbitrarily sized bitvectors. I don't believe that you need bitvectors that can grow at runtime, however, you should be able to create them with an arbitrary number of bits. This is an excellent place to use C++, incidentally, even if you don't encapsulate the whole codebase.
03 Oct, 2008, Fizban wrote in the 34th comment:
Votes: 0
g++? I'd agree gcc is essential but g++ hardly seems so. (Yes, I am aware g++ will compile C code as well, but I see no purpose of sticking to its guidelines when it's not what most people will use and not even intended for the language the codebase is written in.)
03 Oct, 2008, David Haley wrote in the 35th comment:
Votes: 0
g++'s stricter guidelines promote better coding standards, which is pretty much always a good thing. It also allows use of C++ features when you want them – and frankly using nice encapsulation would do MUD code a world of good. Finally, I'm not exactly sure what you mean when you say that it's not "intended" for C.
03 Oct, 2008, Fizban wrote in the 36th comment:
Votes: 0
Simple that if g++'s intended use was compiling C code there wouldn't be gcc, there would only be g++.
03 Oct, 2008, Davion wrote in the 37th comment:
Votes: 0
Fizban said:
Simple that if g++'s intended use was compiling C code there wouldn't be gcc, there would only be g++.


Well, technically, g++ is gcc, but with the -x default option set to c++.
03 Oct, 2008, David Haley wrote in the 38th comment:
Votes: 0
You don't think that backwards compatibility has anything to do with that decision? Anyhow, I'm not sure I see the point, given that better adherence to proper standards is almost indisputably a good thing, other than the problem of having to clean up your act. (general you)
03 Oct, 2008, Pedlar wrote in the 39th comment:
Votes: 0
using g++ can very much so be useful in the long run, as a MUD progress and a coder sees more views into inheritence, methods, and other nifty C++ features, it will be readily avalibe.

And like DH said (Oh my god im actually gonna ggree with DH…SHOOT ME) the stricter guidlines promote better coding standards.
03 Oct, 2008, Fizban wrote in the 40th comment:
Votes: 0
Pedlar said:
using g++ can very much so be useful in the long run, as a MUD progress and a coder sees more views into inheritence, methods, and other nifty C++ features, it will be readily avalibe.

And like DH said (Oh my god im actually gonna ggree with DH…SHOOT ME) the stricter guidlines promote better coding standards.


It's not so much that they promote them, they do. The problem to some extent is that they enforce them. A good coder likely attempts to adhere to them anyway, but most coders that use DIKU derivatives instead of going from scratch are relative newbies. Losing backwards compatibility and harming said newbies just doesn't necessarily seem like a fantastic idea.
20.0/181