12 Oct, 2009, Scandum wrote in the 1st comment:
Votes: 0
Being not much of an LP person I'm having issue trying to figure out how to categorize LPMuds.

I created a basic tree of LPMuds by driver a while ago: http://www.mudpedia.org/wiki/LPMud_famil... - I assume that tree is more or less correct. Also, is an alike tree like structure possible for mudlibs?

I also wonder, what exactly is the difference between LPC and an LP driver? If they are separate entities, what is the difference?
12 Oct, 2009, David Haley wrote in the 2nd comment:
Votes: 0
LPC is a language, the driver is the virtual machine (and maybe some support/auxiliary libraries). LPC is to an LP driver what Java is to the JVM.
12 Oct, 2009, bbailey wrote in the 3rd comment:
Votes: 0
David Haley said:
LPC is a language, the driver is the virtual machine (and maybe some support/auxiliary libraries). LPC is to an LP driver what Java is to the JVM.


Additionally, each driver implements a mostly-compatible but not quite exactly alike language specification. Different drivers have varying syntax, language features, and differing levels of responsibility insofar as what concepts are implemented in the driver and what is pushed off onto the mudlib.
12 Oct, 2009, Cratylus wrote in the 4th comment:
Votes: 0
DGD should have a dotted line, and "CDlib" should probably be "CD", because it looks like
you're establishing a driver hierarchy, not a lib hierarchy.

A lib tree is possible, indeed I'd thought Tyche had posted one
on TMC a while back.

-Crat
http://lpmuds.net
12 Oct, 2009, Scandum wrote in the 5th comment:
Votes: 0
Okay, so if I get this right LPC isn't an actual implementation, just the name for the programming language definition. Was the original LPMud a driver only, or did it also contain a noteworthy mudlib?

Additionally, are LPMuds primarily grouped by driver or by mudlib?

edit: Thanks for the info so far guys.
12 Oct, 2009, Cratylus wrote in the 6th comment:
Votes: 0
Scandum said:
Okay, so if I get this right LPC isn't an actual implementation, just the name for the programming language definition.


I wouldn't go that far either actually. It's more a term for a family of definitions.

Scandum said:
Additionally, are LPMuds primarily grouped by driver or by mudlib?


The lib tends to imply the driver, as it is rare for a lib to be ported to an unrelated driver.
You don't lose very much precision if you group lpmuds by lib.

-Crat
http://lpmuds.net
12 Oct, 2009, bbailey wrote in the 7th comment:
Votes: 0
Scandum said:
Was the original LPMud a driver only, or did it also contain a noteworthy mudlib?.
Both.
12 Oct, 2009, Scandum wrote in the 8th comment:
Votes: 0
I see, how do the libs typically relate to each other? Are they derivatives, or fully independent creations? I'll have a look at Tyche's tree and see if I can use it.
12 Oct, 2009, bbailey wrote in the 9th comment:
Votes: 0
Scandum said:
I see, how do the libs typically relate to each other? Are they derivatives, or fully independent creations? I'll have a look at Tyche's tree and see if I can use it.


Mudlib derivation is roughly equivalent to the normal server derivation you see in the Diku tree. A lot of them have common roots, similar frameworks for game logic, taking snippets from one and adapting it to another, etc. There are entirely independent mudlibs that are created now and then, but a lot of them are derivatives with a fairly rich history.
12 Oct, 2009, Cratylus wrote in the 10th comment:
Votes: 0
Scandum said:
I see, how do the libs typically relate to each other? Are they derivatives, or fully independent creations? I'll have a look at Tyche's tree and see if I can use it.


Hard to answer this with a "usually". For example, DGD libs tend to be independent
from one another, but the latest (and most significant, IMO) DGD lib project builds
on a pre-existing lib.

MudOS/FluffOS libs generally are based on some version of Nightmare, Discworld, or TMI.
Lima mudlib is about as old as those others, but is generally not used as a base for a
new lib due to its eccentric design philosophies and ambiguous-but-harsh-sounding license.

I imagine some folks might have indeed built a lib from scratch, but none come to
mind. It's really a very labor intensive proposition.

So the answer is "depends".

-Crat
http://lpmuds.net
12 Oct, 2009, Scandum wrote in the 11th comment:
Votes: 0
Thanks again for the info. Based on badly sourced Wikipedia articles I came up with the following, is this more or less correct?

LPLib (For lack of a better name)
|
+——> CDLib (Genesis LPMud)
|
+——> Heaven7 (LDMud)
|
+——> TMI (The Mud Institute)
|
+—–> TMI-2
| |
| +—-> Lima
| |
| +—-> TMI-3
|
+—–> Nightmare –> Dead Souls 1 –> Dead Souls 2
|
+—–> Discworld
12 Oct, 2009, Cratylus wrote in the 12th comment:
Votes: 0
Yeah, I think that's right, off the top of my head. There's a few things
missing, of course, but yer on the right track. The biggest thing I'd change
are the addition of two independent Discworld derivatives, Skylib and Final Realms.

You might want to add Merentha as an independent Nightmare deriv, and
Foundation I & II as TMI (not TMI-2) derivs.

There's also a supposedly from-scratch lib (I never got around to verifying it,
but I believe the developers) called LPUni, with a derivative called Sapidlib.

Other than that you seem to have got the MudOS "usual suspects".

I'm not as familiar with DGD libs tbh, but Aidil is, I think.

-Crat
http://lpmuds.net
12 Oct, 2009, Tyche wrote in the 13th comment:
Votes: 0
Your driver tree is more or less correct except there's some other little used branches. I could never find an/the LPMud 3.0 driver though.

The lib tree is too, for what libs you charted, except Heaven7 originated on LPMud 3.2 Amylaar, although I believe it does work on LDMud. You are right that the mudlib release with LPMud never had a name. It's just called the LP 2.4.5 mudlib. Many of the libs were indeed built off that.

DGD has several mudlibs that only run on it, Melville, Gurbalib, Phantasmal, and LPMOO (a MOO implementation)

There are dozens of mudlibs, of which the origin and driver they run on I know little about.
But here's a list of some you are missing my best guess at what driver and origin…

UNILib runs on MudOS originated from scratch
KobraMud
IceLib
Dragon
ColonyLib
CoreDump
LandLib
StarLib
Skylib (MudOS?)
ZombieLib
DarkeLib
EverLib
RotM (LDMud?)
Merentha
TubMud (Amylaar?)
Morgengrauen
NewMoon
Wildfire
Slimewarp
Centolib
Suffeli
Passion
Starfire

Many of the above may not have been released.
12 Oct, 2009, Scandum wrote in the 14th comment:
Votes: 0
I assume UNILib is the same as the LPUniversity Mudlib? The latter indicates being TMI-2 derived on Wikipedia. And according to lpmuds.net Foundation is nightmare derived. I think what I got below will do as something for more knowledgeable people to work with.
LPMud
|
+——> CDLib (Genesis LPMud) (4 muds)
|
+——> Heaven7 (LDMud) (1 mud)
|
+——> TMI (The Mud Institute)
|
+—–> TMI-2
| |
| +—-> Lima (6 muds)
| |
| +—-> LPUniversity Mudlib (1 mud)
|
+—–> Nightmare
| |
| +—-> Dead Souls 1 –> Dead Souls 2
| |
| +—-> Marantha (0 muds)
| |
| +—-> Foundation (0 muds)
|
+—–> Discworld
|
+—-> Skylib (1 mud)
|
+—-> Final Realms (1 mud)
13 Oct, 2009, Tyche wrote in the 15th comment:
Votes: 0
Scandum said:
I assume UNILib is the same as the LPUniversity Mudlib? The latter indicates being TMI-2 derived on Wikipedia. And according to lpmuds.net Foundation is nightmare derived. I think what I got below will do as something for more knowledgeable people to work with.


Yes, my error. It is indeed descended from TMI-2.

Here's a few more things…

LPMud
|
+——> CDLib (Genesis LPMud) (4 muds)
|
+——> Morgengrauen (Genesis LPMud)
|
+——> NannyLib (LPMud 2.4.5)
|
+——> NewMoon (LPMud 2.4.5)
|
+——> Heaven7 (Amylaar LPMud 3.2.x or LDMud) (1 mud)
|
+——> Tublib (LDMud) (1 mud)
|
+——> TMI (The Mud Institute - MudOS)
|
+—–> Basis (The Mud Institute - MudOS)
|
+—–> TMI-2
| |
| +—-> Lima (6 muds)
| |
| +—-> LPUniversity Mudlib (1 mud)
|
+—–> Nightmare III
| |
| +—-> Dead Souls 1 –> Dead Souls 2
| |
| +—-> Merantha (0 muds)
| |
| +—-> Foundation (0 muds)
| |
| +—–> Nightmare IV
|
+—–> Discworld (MudOS + FluffOS)
|
+—-> Skylib (1 mud)
|
+—-> Final Realms (1 mud)

DGD
|
+——> Melville
|
+——> LPMOO
|
+——> Gurbalib
|
+——> Phantasmal
13 Oct, 2009, Silenus wrote in the 16th comment:
Votes: 0
Lima is a from the ground up rewrite and though it post dates TMI-2 is perhaps more of a spiritual successor (if that) than a TMI-2 derivative since it shares no code with the former. I believe lpuni is also a ground up rewrite.
13 Oct, 2009, Cratylus wrote in the 17th comment:
Votes: 0
Silenus said:
I believe lpuni is also a ground up rewrite.


Yep.

Also Dead Souls isn't based on NM3, it's based on NMIV.

And it's "Merentha" not "Merantha"

-Crat
http://lpmuds.net
13 Oct, 2009, Scandum wrote in the 18th comment:
Votes: 0
Not sure if it looks alright on resolutions below 1600.

Is this more or less correct? I omitted a couple of libs that seemed private / obscure.

http://www.mudpedia.org/wiki/LPMudlib_fa...
13 Oct, 2009, Cratylus wrote in the 19th comment:
Votes: 0
Scandum said:
Not sure if it looks alright on resolutions below 1600.

Is this more or less correct? I omitted a couple of libs that seemed private / obscure.

http://www.mudpedia.org/wiki/LPMudlib_fa...


Looks nice. Sapidlib is a bit obscure but I suggest adding it as a deriv of lpuni anyway.
It's one of the few distlibs still under active dev and maintainership, making it at least
as relevant as some of the ones on there nobody's touched for a decade.

-Crat
http://lpmuds.net
13 Oct, 2009, Silenus wrote in the 20th comment:
Votes: 0
I am not sure what the dotted lines mean. Also the NM tree isn't quite right. NMIV follows NMII and shares some code. The Foundation I and Foundation II libraries are stripped down versions of NM3 and NMIV respectively. Also NM before it closed down ran on the NMV lib (which was never released to the public). I think Crat has refurbished a lot of these old libraries and they are downloadable from lpmuds.net download page.

One suggestion would be for Lima and lpuni would be to have them off the some root branch (or make the thing a forest) and have the x axis denote some sort of time line. I think it's a bit problematic that the driver information isn't there (perhaps a separate tree which one can cross reference against the library tree to see the driver relationships?).
0.0/99