Final Realms

[quixadhal]

HELLO out there...there...there.....

I was just going through some OLD archives on my hard drive to see what I should keep and what I should pack away, and I stumbled upon an old copy of the Final Realms mudlib.

In fact, three of them.  frmudlib-2.1b4.tgz, frmudlib-3.2b3.tgz, and frmudlib-4.0b1.tgz.

A brief google search only shows that version 3.4 was apparently the last real release of this old game, and unfortunately that isn't in my collection.  Since I had a world converter about 3/4 of the way done for my old Diku, I was considering trying to dig this guy out and see if it could be made to run under FluffOS.

Does anyone have a copy?  fr.imaginary.com is long gone I'm afraid, and that seems to be the only place the actual files were kept.

If anyone would like the older versions I do have, I could probaby find a way to let Crat grab them and then do whatever poking and prodding he feels needs to be done before releasing them (IE: try to find the author, make sure they actually compile, etc).

[quixadhal]

Talking to myself again.

I found an archive of an old mirror at the new site for the OLD archive of aragorn's FTP site.

ftp://ftp.kolbu.com/pub/mirrors/fr.imaginary.com/download

I'm going to take a wild guess and believe that the 4.0 beta I had was probably abandoned and the 3.5 beta on that mirror is probably the last release the FR team did.

Anyways... if anyone knows how much pain is involved in going from MudOS v21 to FluffOS, feel free to post hints, warnings, or condolences!

[cratylus]

if anyone knows how much pain is involved in going from MudOS v21 to FluffOS, feel free to post hints, warnings, or condolences!

You have my condolences.

I have to check my email, but IIRC, I did indeed secure permission from the FR author to
update/bundle the lib and offer it for download here.

What I discovered is that the FR lib relies heavily on the behavior of an old variety
of MudOS. I found myself involved in large amounts of mass-file modification, and
at some point decided to knock off and get back to it another time.

I yet may.

However, for now, it's backburnered, because it's a lot tedious gruntwork getting
FR to work on the latest MudOS, and I imagine it's about the same for getting it
to work on FluffOS 2.7.

This is long enough ago that I don't recall exactly what it was I was running
into, so I can't offer you help or advice. Just a hearty "cheers, mate!" and
pat on the rump.

-Crat

[quixadhal]

*grin*

Well, that's ok.  I need a few good solid walls to beat my head against every so often.

I guess the big question will be do I try to get the old v21.7b21 driver to compile and try to walk the changes forward (fr used the discworld driver mods), or try to get fluffOS to use the old local options and walk backwards.

It'll be a while, but I'll let you know if I get a pulse.

[quixadhal]

*cough* *cough*

Lots of dust in here!

Ok, so I started at the beginning and managed to get the old version of FR I had worked on back in 1996 to compile and boot.  This was MudOS 0.9.20 with the Aurora extensions.  I'm not sure I can actually find a pristine copy of that to provide my diffs against, but in case anyone else is foolish enough to walk along behind me....

The two big show stoppers in compiling things for 2007, are that varargs.h has gone the way of the dinosaurs and must be replaced with stdarg.h.  A small handful of declarations need to be changed, and anywhere va_start took one argument, it now has to take two.  Not hard, just scary like an old crank telephone connected to a vonage box.

When I say must be replaced, I mean must.  The GNU folks aren't kidding!  Take a peek at /usr/lib/gcc/i486-linux-gnu/4.1.2/include/varargs.h:

Code: [Select]

#ifndef _VARARGS_H
#define _VARARGS_H

#error "GCC no longer implements <varargs.h>."
#error "Revise your code to use <stdarg.h>."

#endif
Number two was the need to comment out a few spots where errno was declared and make sure errno.h was included.  That's ALSO depreciated, but the compiler will still let you use it.

So, this isn't really all that much progress... but it's a step towards something useful.  Now we'll see if the last released version can be made to work before looking to the present.

[silbago]

Maybe I should release the current 2013-version of FR-Lib, anyone interested ?

I have an almost finished release-script that can produce a tarball, with some heavy modifications and fixes it could be possible. At the moment I dont have time to finish up the release-script and really get the release stable. Just need to ask permission from Baldrick to release first.

Since our 3.5 release, we have done many rewrites and yes, we still develop organic. The lib is probably quite difficult to understand for outsiders, me including.

[quixadhal]

Sounds good.  FWIW, I think the only big criteria for an actual "release" of a mudlib/driver is that it stand a good chance of being able to boot and let you log in, and that you remember to put an admin character and password somewhere in the readme.

One idea for the future, to make life simpler for you doing more frequent releases...

You have a mudlib directory.  It has some amount of stuff you want kept private, but some of that might be an "essential" part of making the release mudlib work.  What you can do is copy the whitelisted stuff from your main mudlib to a "release" directory, then build a bit of boiler-plate that will only live in the release lib, to take the place of those few places where things will explode if stuff is missing.

The idea there is, rather than having something spew out a zillion errors when you try to use it (because stuff it wants to import isnt' there, etc), it would just print "Not implemented in release".

Remember, you aren't selling it... so it doesn't have to be perfect.  Release what you have now, and push updates every month or three.  I keep trying to get people to put things on github, because then, not only can you just push single updates as you do them, but other people can submit fixes back to you easily.

Of course, you want to make sure you put the release candidate on github, not your live mudlib.