Legacy LD5

Here here!

I've been talking and working with...well, I'm lazy..."advising" Ragora on what should be in the new muck software. He has an insane amount of energy for this project, combined with an insane amount of talent...and his love for scaly toes is insane, too, so "how could we stand in the light of discovery, and not act?"

We're not just going to up and abandon the old one overnight. First there will be a lot of testing and development just in a "sandbox" world, then when that seems stable enough, Ragora will get the current 'world' converted over, and we'll have a few users test that out, and then eventually go live with the new one. I think to keep security intact, the database conversion will randomize everyone's passwords, and then users can just email me to reset it to whatever they want when they try to log in again.

But like Ragora said, I've tried to "upgrade" Faibanx MUCK two times in the past, and both times were disasters. The muck would run a short while and then crash. As far as I'm concerned as an administrator, Fuzzball MUCK is unsupported and un-upgradeable, and although I was mostly content to keep Faibanx "time-locked" forever, all the other points Ragora brings about no one being able to develop for it anymore because it's so ancient and clunky...well, Faibanx won't ever evolve and get cool new features.

It's a zero-risk endeavor. We can always use the time- and feature-locked software we have now. As long as it's not tinkered with, it runs forever. But people want to tinker.

This sounds awesome! It's great that you care enough about the MUCK to do something like this, Ragora.

I remember tring to build rooms and the odd puppet or two back when I first joined and <minorgripe>was under the impression that peope actually used Faibanx for roleplaying...</minorgripe> If your new software makes it easier to build the world, that would be a big advantage and might even help keep it fresh!

I don't want to knock you out of this enthusiasm, but I do need to say a few things you probably aren't going to want to hear.
The commands are going to have to be the same. No one is going to want to relearn a muck's commands when they've already been previously established.
An end user's experience should be identical on both versions, no matter how archaic or strangely syntaxed you believe it is. This is to smooth the transition from one to the other in the best possible way.
The only people who are going to appreciate this is going to be someone actively making programs and such for the muck itself.
It's good that you are moving the muck software out of 1990 or so when it was first created, so that it's written in a language that still exists, but there's no point in doing so other than that.

Oh, you guys.

I can certainly see some valid points here. I've talked with Ragora lately regarding the new muck code. Personally I'd been looking at trying to build an improved inroom system, and as the original code and design for the current system is unavailable to me, I'd been starting from scratch.

MUF, though, has been a stumbling block for me. Work doesn't always afford me much time to work on other things. Despite my attempts at keeping the code streamlined and well documented, I still have trouble going through and making changes after a few weeks or more of being away from the code. Although I would have to learn Python with the new server code, from the examples that I have looked at, the code looks a lot more readable to me. Granted, I learned programing on and am most familiar with C style languages.

As far as the commands go, I personally think that they should remain the same only where it makes sense to do so. If a new system to do something, such as room building, actually makes the task more streamlined and/or easier to do, it shouldn't be discounted just because it isn't using the exact same commands as the current one.

I certainly don't see the issue with old people and new people way being implemented at the same time either, but there should be a pretty high up line drawn for that. The end-user commands themselves yes, but if anyone's thinking of making some kind of MUF interpreter inside ScalyMUCK, I think they should go stare at that brick wall over there. I think about as deep as the new software should go is allowing similar "look traps" or "morph" commands, stuff that a power user would use, but not a MUF programmer. I think MUF programmers should be re-Neducated if they want to actually implement commands in the new system.

I understand almost none of this. However, there are some things I do understand.

1. New.
Not old. Not as buggy. Hopefully not blocked by my antivirus.

2. Simplified
A help menu that will actually how to do things I want to do would be nice. It would also be nice if I could use one command to do one kind of thing instead of multiple commands for very similar actions.

Hopefully this whole thing will also spark a new interest in the Muck. I haven't been active there much because A) college keeps one busy B) very few people are there and those few aren't very active much of the time and C) my antivirus for some reason will not let me download the program, so I can only access it through a web browser, which is incredibly inconvenient and annoying.

Nice to have some really enthusiastic people to do cool stuff like this. ^.=.^

Ah. Well I'm sure there's an easy way around it, but I just haven't bothered with it. I'll look into it within the next couple of weeks though.

Actually, considering there's a lack of a nice free open source muck client, I was gonna think about using work time to shit one out using some kinda RAD environment...I mean, how hard can it be? It's such a simple app, all the "lego pieces" in some RAD system out there must be just ready to go, just need to plop 'em down. Don't need much in a muck client, myself...

I don't mind another software behind it all, and I would definitely love a MUCK software that realizes when someone has long lost connection.
But it will have to support all the things that the MUCK has. The only way I see for that is for the new software to handle all that old code bits people gradually wrote over the ages on top of the new, or to cross-compile all that old code into the new. So under the new code the new people 'won't have to bother' with MUF, but you will.
As for the new interface example, that looks good and neat and tidy. Better than the old 'editroom'. It lacks a lot of functionality though, like the smell of a room, room flags, look traps, parent room, change the owner of the room, ... delete the room, ...

Just saying.

...some people did >..>

Actually, by that time, most people on it did.

How about paw cookies?

Sounds like I'll be able to set up a playaround VM for people to check out on Memorial Day.

That sounds like a great way to celebrate the holiday.