Fatal error: What does it mean and how do I fix it...
Scott
I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
give me a break, I am new to this :) Now, I have the executable file but,
when I attempt to run it I get: 'fatal error changing to data directory: No
such file or directory'
HELP!! I am trying to run this under Windows 95. Any help I can get would
be most appreciated. Thank in advance...
Dargen Teristen
Scott (free...@eznet.com) wrote:
: I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
Well thats your problem.. its windows :)
Greg Munt
On 30 Jun 1997, Dargen Teristen wrote:
> Scott (free...@eznet.com) wrote:
> : I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
> : give me a break, I am new to this :) Now, I have the executable file but,
> : when I attempt to run it I get: 'fatal error changing to data directory: No
> : such file or directory'
It means (surprise, surprise) that your data directory doesnt exist. This
means you have to create it.
Although, the question remains, why are you trying to compile a mud if
you know nothing about programming? (I can hear George readying the chili
as we speak;)
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
Never settle with words what you can accomplish with a flame-thrower.
Joshua J. Cantrell
In article <01bc856c$b342e880$df201ace@scott> "Scott" <free...@eznet.com> writes:
> I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
> give me a break, I am new to this :) Now, I have the executable file but,
> when I attempt to run it I get: 'fatal error changing to data directory: No
> such file or directory'
You should probably grep the source code for part of that message. This
way you find out where in the code it failed to work correctly.
> HELP!! I am trying to run this under Windows 95. Any help I can get would
> be most appreciated. Thank in advance...
I think Win95 has a Find... program under the Start menu that can search
for strings in files. I'd suggest you try to find the point where it
failed in the code. I can't help you more than that because I don't have
MSVC++ and I don't like Circle code.
Joshua Cantrell
j...@cory.berkeley.edu
Jon A. Lambert
Greg Munt <gr...@uni-corn.demon.co.uk> wrote in article <Pine.LNX.3.91.97063...@uni-corn.demon.co.uk>...> > : I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
> > : give me a break, I am new to this :) Now, I have the executable file but,
> > : when I attempt to run it I get: 'fatal error changing to data directory: No
> > : such file or directory'
You really should read the Circle Win FAQ before posting here. And reread
it again and again. I'm certain this is covered. :)
>
> It means (surprise, surprise) that your data directory doesnt exist. This
> means you have to create it.
>
> Although, the question remains, why are you trying to compile a mud if
> you know nothing about programming? (I can hear George readying the chili
> as we speak;)
Nobody should feel obligated to answer such a question.
JL
TheAce
In article <s38afk7...@carina.EECS.Berkeley.EDU>,
j...@carina.EECS.Berkeley.EDU (Joshua J. Cantrell) wrote:
>In article <01bc856c$b342e880$df201ace@scott> "Scott" <free...@eznet.com>
writes:
>
>> give me a break, I am new to this :) Now, I have the executable file but,
>> when I attempt to run it I get: 'fatal error changing to data directory:
No
>> such file or directory'
>
>way you find out where in the code it failed to work correctly.
>
>> HELP!! I am trying to run this under Windows 95. Any help I can get would
>> be most appreciated. Thank in advance...
>
>I think Win95 has a Find... program under the Start menu that can search
>for strings in files. I'd suggest you try to find the point where it
>failed in the code. I can't help you more than that because I don't have
>MSVC++ and I don't like Circle code.
>
>
>Joshua Cantrell
>j...@cory.berkeley.edu
Hmmm.....I know what to do......(if you havent done it yet......)....you have
to move circle.exe from the circle30bpl11/src directory to circle30bpl11/ so
that it can read the data directory......
//TheAce\\
..
In the beginning the universe was created.
This has made a lot of people angry and
has been widely regarded as a bad move.
- Douglas Adams
Keiko Krahnke
Dargen Teristen <dar...@dragon.clemson.edu> wrote:
: Scott (free...@eznet.com) wrote:
: : I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
: : give me a break, I am new to this :) Now, I have the executable file but,
: : when I attempt to run it I get: 'fatal error changing to data directory: No
: : such file or directory'
: : HELP!! I am trying to run this under Windows 95. Any help I can get would
: : be most appreciated. Thank in advance...
: Well thats your problem.. its windows :)
:-)
well...i dont know for certain about windows as i run on linux, but here is how
i perceive it:
in lunx when you run circle you are in the base directory and type bin/circle
that way the executable can change to ./lib in order to read in and output the information that it needs....I would suggest trying this:
open a dos windows and cd to circle(or wherever you have the mud)
in this directory you should be able to dir and see the src lib log...directories
then type bin/circle and i guess you can genuflect toward the idol of your
choice and see if you can actually do ANYTHING cool with microslop
let me know if you need anymore help, but DO NOT mail to this address...i will
never get it, instead mail to:
pep...@grfn.org
--Pepito
Deidril
Dargen Teristen wrote:
> Scott (free...@eznet.com) wrote:
> : I have *finally* been able to compile Circle under MSVC++ ver. 5.0.
> (Hey,
> : give me a break, I am new to this :) Now, I have the executable file
> but,
> : when I attempt to run it I get: 'fatal error changing to data
> directory: No
> : such file or directory'
>
> : HELP!! I am trying to run this under Windows 95. Any help I can get
> would
> : be most appreciated. Thank in advance...
>
> Well thats your problem.. its windows :)
Roll on the floor . You don't run the executable from the good
directory.
go to the directory of your mud, where you should list the <LIB> and
<SRC>
directory.You must run the executable from THIS DIRECTORY, and not
by using the RUN Menu of MSV.
There is nothing to check with WIN95. The same thing occurs under unix
if you run the executable from the wrong directory.
Deidril
M.C. Lewis
> when I attempt to run it I get: 'fatal error changing to data directory: No
> such file or directory'
You have to run the MUD from the main directory. The command would
be bin/circle. Don't go to the bin directory first, because it
looks for lib/, not ../lib.
To reiterate, in the Circle30bpl11 (I assume) directory, there are the
subdirectories lib, doc, src, bin, etc. You must be in this directory
when you run it.
Hal Bonnin
Scott <free...@eznet.com> wrote in article
<01bc856c$b342e880$df201ace@scott>...
> I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
> give me a break, I am new to this :) Now, I have the executable file but,
> when I attempt to run it I get: 'fatal error changing to data directory:
No
> such file or directory'
>
> HELP!! I am trying to run this under Windows 95. Any help I can get would
> be most appreciated. Thank in advance...
>
>
you need to not be in the src dir..
you need to run it with src\circle.exe in order for it to locate the
directorys
or you can copy the exe from the src dir.
or you could improve the dir searching rountine.. <experienced coders only>
no big problem realy..
Andy Hassall
Scott () scrawled in rec.games.mud.admin:
>I have *finally* been able to compile Circle under MSVC++ ver. 5.0. (Hey,
>give me a break, I am new to this :) Now, I have the executable file but,
>when I attempt to run it I get: 'fatal error changing to data directory: No
>such file or directory'
>
>HELP!! I am trying to run this under Windows 95. Any help I can get would
>be most appreciated. Thank in advance...
>
It compiles and runs fine if you read the instructions properly... try
it sometime :P
____ __ __ __ ____
/ __ \____ ____/ /_ __ / / / /___ _______________ _/ / /
/ /_/ / __ \/ __ / / / / / /_/ / __ `/ ___/ ___/ __ `/ / /
/ __ / / / / /_/ / /_/ / / __ / /_/ (__ |__ ) /_/ / / /
/_/ /_/_/ /_/\__,_/\__, / /_/ /_/\__,_/____/____/\__,_/_/_/
/____/ andyh...@innotts.co.uk
Greg Munt
On 5 Jul 1997, Scott wrote:
> Ok, I fixed the error. I don't know if I fixed it *correctly*, but it
> compiles and runs. I made the 'lib' directory a subdirctory of 'src' and lo
> and behold, it works. Now, why am I compiling a mud if I know nothing about
> programming? Let me ask you a question first: When you first started, did
> you know all there was to know about programming? Were you an expert?
Of course not - but I didn't attempt to put up a mud at that stage,
either. In all probability, my attitude is derived from innate disgust at
the code-illiterate setting up a mud, and, by implication, disgust at the
state of this newsgroup right now; also, it may be due to the fact that
my first attempt at serious programming (read: my first attempt at my own
mud) was not to download someone else's code (and declaring it as 'extensively
modified') and bolt-on 'original' or 'unique' areas. In fact, my first
attempt at my own mud was to write it from scratch. I looked at no source
code apart from my own, when writing that first effort.
What I learned through that, made university of negligible importance.
The quickest way to learn, in my experience, is to attempt what is an
impossibility with your current skills. What I needed to know, I learnt
- and fast.
Yes, I'm an elitist little fuck; I make no apologies for that. If this
newsgroup is a true representation of the current mudding community (and
I sincerely hope it is not), then it needs a damn good kick up the ass.
In my view, the evolution of muds has failed. Since 1990, all that has
been achieved is a steady watering-down of 3 or 4 different mud types.
This is not good. I believe that the way forward is for more and more
scratch code to be downloadable, rather than an ever-increasing
proliferation of 'modified DIKU' shite.
Of course, this will be even more food for Reese's Morons to regurgitate
in 10 seconds flat. That will never change. Hopefully it will channel
people into more originality, and smash the accepted thought that to
run a mud, you have to download source to do it.
The Mud Tree needs width.
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
"My fucking job fucking sucks, and you don't fucking care"
Alberto BARSELLA
In article <Pine.LNX.3.91.97070...@uni-corn.demon.co.uk> Greg Munt <gr...@uni-corn.demon.co.uk> writes:
> ------------------------------------------------------------------------------
> T H E F R O N T I E R S P R O J E C T
> http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
I tried the site. If this is the "future of muds" I'll stay with stock
diku. At least when I type help I get something more informative than
"Sorry, the help system is currently unavailable.". I also liked
rules: "Sorry, this command has been temporarily disabled - please try
again later.". Ah, the info system is not to be missed, too: "Sorry,
the tutorial & information system is currently unavailable."
Let us know when it's actually worth looking at.
Alberto
--
Alberto BARSELLA
PGP fingerprint = 13 3F 22 D2 0B 0A D3 25 F1 89 FE B5 82 AD 75 2A
Jerry Gilyeat
On 7 Jul 1997, Alberto BARSELLA wrote:
> In article <Pine.LNX.3.91.97070...@uni-corn.demon.co.uk> Greg Munt <gr...@uni-corn.demon.co.uk> writes:
>
> > ------------------------------------------------------------------------------
> > T H E F R O N T I E R S P R O J E C T
> > http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
>
> I tried the site. If this is the "future of muds" I'll stay with stock
> diku. At least when I type help I get something more informative than
> "Sorry, the help system is currently unavailable.". I also liked
> rules: "Sorry, this command has been temporarily disabled - please try
> again later.". Ah, the info system is not to be missed, too: "Sorry,
> the tutorial & information system is currently unavailable."
> Let us know when it's actually worth looking at.
>
I don't think he ever said it was done, debuggd, and had everything
working, now, did he? I thought not. Quite frankly, I'm at the point
now where when I log onto a newly advertised MUD I EXPECT things to not
be working.
As far as having other codebases freely downloadable: it would be
really nice, and I can think of a couple that are in VERY alpha stages
(Mud++ and Sapphire). I know of about a dozen or so others that will
never be made public because of people like Vryce of Medthievia who look
at licensing agreements as nothing more than tripe. If people in general
were honest (people being MUD Imps) than I think we'd be seeing more
bases and a wider Tree. Unfortunately, there's enough assholes in the
world to give most "scratch coders" an excuse to not release their code.
An excuse I completely agree with.
Paitre/Caendar
Greg Munt
On Mon, 7 Jul 1997, Jerry Gilyeat wrote:
>
>
> On 7 Jul 1997, Alberto BARSELLA wrote:
>
> > In article <Pine.LNX.3.91.97070...@uni-corn.demon.co.uk> Greg Munt <gr...@uni-corn.demon.co.uk> writes:
> >
> > > ------------------------------------------------------------------------------
> > > T H E F R O N T I E R S P R O J E C T
> > > http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
> >
> > I tried the site. If this is the "future of muds" I'll stay with stock
> > diku. At least when I type help I get something more informative than
> > "Sorry, the help system is currently unavailable.". I also liked
> > rules: "Sorry, this command has been temporarily disabled - please try
> > again later.". Ah, the info system is not to be missed, too: "Sorry,
> > the tutorial & information system is currently unavailable."
> > Let us know when it's actually worth looking at.
If you recall my post, I said that my first effort was a heap of shite.
Frontiers is that first effort. Additionally, I never said *my* mud was
the future of the field. I said that I would like scratch muds (in a
general sense) to be the future, or at least part of it. I fear this
won't be the case, mainly because you have to work at scratch muds, and
have to work a lot, before you have anything worth speaking about.
But what makes me smile is that an attack on the general state of muds in
general is greeted by a flame of my self-admitted underdeveloped mud. If
you can't think of any counter-arguments, dont post in the thread. It
makes you look rather silly.
> Quite frankly, I'm at the point
> now where when I log onto a newly advertised MUD I EXPECT things to not
> be working.
Opening a mud before its openable can only ever be a bad thing.
> As far as having other codebases freely downloadable: it would be
> really nice, and I can think of a couple that are in VERY alpha stages
> (Mud++ and Sapphire). I know of about a dozen or so others that will
> never be made public because of people like Vryce of Medthievia who look
> at licensing agreements as nothing more than tripe. If people in general
> were honest (people being MUD Imps) than I think we'd be seeing more
> bases and a wider Tree. Unfortunately, there's enough assholes in the
> world to give most "scratch coders" an excuse to not release their code.
>
> An excuse I completely agree with.
Is this the only reason mud growth has been stunted for years? If so, how
did it not apply in the late 80's?
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
Scott McMahan
In article
<Pine.LNX.3.91.970707213915...@uni-corn.demon.co.uk>,
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
:If you recall my post, I said that my first effort was a heap of shite.
He probably missed it like I did. Which statement talked about the
quality of your mud?
:Frontiers is that first effort. Additionally, I never said *my* mud was
:the future of the field. I said that I would like scratch muds (in a
:general sense) to be the future, or at least part of it. I fear this
:won't be the case, mainly because you have to work at scratch muds, and
:have to work a lot, before you have anything worth speaking about.
There seems to be a lot that your missing about muds. Coding/play is only
about 25% of what makes a mud good, there's also the world/zone/objs/mobs
etc, the attitude of the imps, the players on the mud, the hardware etc.
A scratch mud can still be awful in all the other areas, and a stock mud
could excel in the others to such an extent to make it a very fun
experience.
As for working a lot on scratch muds, IMO, the same can be said about
stock muds. If you want to have something worth speaking about, you have
to put a lot of work in it. However, because some routines are already
written for you, you can spend more time on those innovative ideas and
less on mundane stuff. When I took my first programming class (all those
years ago), I, like probably many others here, was more qualified to teach
it than to take it. But there was one important lesson my teacher taught
me. Don't waste your time re-inventing the wheel. Quite frankly, I'd
like to see many more stock muds made available. However, I think the
other post in this thread is right, until licensing agreements are honored
better, don't expect anyone to make their hard work available to us for
nothing.
--
Scott McMahan
mcm...@oncology.wisc.edu
Alberto BARSELLA
In article <Pine.BSI.3.91.970707...@tommy.chesapeake.net> Jerry Gilyeat <jgil...@tommy.chesapeake.net> writes:
> I don't think he ever said it was done, debuggd, and had everything
> working, now, did he? I thought not. Quite frankly, I'm at the point
> now where when I log onto a newly advertised MUD I EXPECT things to not
> be working.
Well....from the tone of his post I had expected something at least
decent. Also, its login screen says NOTHING about the mud server being
anything like alpha or beta. What I saw is yet another stock basher
which whines about "lack of improvement" in muds and then puts on-line
a thing which I can code in 1 month (and yes, I did it, but I never
dared to put it online).
> As far as having other codebases freely downloadable: it would be
> really nice, and I can think of a couple that are in VERY alpha stages
> (Mud++ and Sapphire).
We're going back to the generic discussion here....
Ahem....it's HIM bashing stock muds, not me. I know that there are
nice codebases around, and I also think that the codebase is not the
most imoprtant thing for a good mud. Usually every codebase has its
strength, directly related to what its creator felt "most important".
> I know of about a dozen or so others that will never be made public
> because of people like Vryce of Medthievia who look at licensing
> agreements as nothing more than tripe.
I think this has already given rise to enough flame wars....
> If people in general were honest (people being MUD Imps) than I
> think we'd be seeing more bases and a wider Tree. Unfortunately,
> there's enough assholes in the world to give most "scratch coders"
> an excuse to not release their code. An excuse I completely agree
> with.
I agree with you, but what is the relation with bashing stock muds?
The fact that there are a lot of muds which suck because people just
download the distribution, compile it, and then run it, without having
any skill in mud aministration is not a good reason to jump in here
and just attack everyone.
Alberto BARSELLA
In article <Pine.LNX.3.91.970707213915...@uni-corn.demon.co.uk> Greg Munt <gr...@uni-corn.demon.co.uk> writes:
> > On 7 Jul 1997, Alberto BARSELLA wrote:
> > > I tried the site. If this is the "future of muds" I'll stay with stock
> > > diku. At least when I type help I get something more informative than
> > > "Sorry, the help system is currently unavailable.". I also liked
> > > rules: "Sorry, this command has been temporarily disabled - please try
> > > again later.". Ah, the info system is not to be missed, too: "Sorry,
> > > the tutorial & information system is currently unavailable."
> > > Let us know when it's actually worth looking at.
>
> If you recall my post, I said that my first effort was a heap of shite.
> Frontiers is that first effort. Additionally, I never said *my* mud was
> the future of the field. I said that I would like scratch muds (in a
> general sense) to be the future, or at least part of it. I fear this
> won't be the case, mainly because you have to work at scratch muds, and
> have to work a lot, before you have anything worth speaking about.
Don't you find just a bit contradictory to just flame everyone in
sight because the mud scene has not improved and then putting on-line
a not-even-alpha thing?
> But what makes me smile is that an attack on the general state of muds in
> general is greeted by a flame of my self-admitted underdeveloped mud. If
> you can't think of any counter-arguments, dont post in the thread. It
> makes you look rather silly.
I would say as silly as you who attack "the state of muds in general"
and then show that you don't have any contribution.
I'll be very impressed the day when you put on-line an innovative
system, and even more impressed if you release the source code.
Of course you can't expect me to be very impressed if after your stock
code bashing you have nothing better to offer than something which
looks even worse than stock code. There's nothing wrong in having and
building prototypes, but what's the point of advertising them (you
have the address in your .sig)?
It just looks that you want to show us how good you are....
> > Quite frankly, I'm at the point
> > now where when I log onto a newly advertised MUD I EXPECT things to not
> > be working.
>
> Opening a mud before its openable can only ever be a bad thing.
So you know this :)
> > As far as having other codebases freely downloadable: it would be
> > really nice, and I can think of a couple that are in VERY alpha stages
> > (Mud++ and Sapphire). I know of about a dozen or so others that will
> > never be made public because of people like Vryce of Medthievia who look
> > at licensing agreements as nothing more than tripe. If people in general
> > were honest (people being MUD Imps) than I think we'd be seeing more
> > bases and a wider Tree. Unfortunately, there's enough assholes in the
> > world to give most "scratch coders" an excuse to not release their code.
> >
> > An excuse I completely agree with.
>
> Is this the only reason mud growth has been stunted for years? If so, how
> did it not apply in the late 80's?
There has already been some discussion about this, with many people
defending many sides. This is probably one of the reasons, but I find
that the competition from the stock muds can cut down the number of
players on innovative muds, thus making developement more "hidden".
When I code for myself I never get to something usable (I never put
anything online), because I just want to experiment with those parts
of the mud where I'm interested in (= physical model of the world).
Let's suppose I manage to build a mega-whizbang server, which can
actually run on Pentium with a reasonable amount of RAM.
If I want to get players I'd better have something which attracts
them. If I don't put this and end up with 5 dedicated players then I
could be coding for myself and never bothering about the multi-user
part of the thing. But I find that one of the aims of mud creation is
building something which is not just playable, but IS PLAYED. I
suppose that you have tried some of the stock stuff, and even if it's
not very innovative it's quite playable. VERY playable I would say,
expecially for the majority of people, which (I think) is not made of
hard-code mudders, but of "occasional players" (like me).
So, even if there's a lot of discussion about possible improvement of
muds, and lots of work going on, the resulting stuff tends to be too
much towards the ultracomplex game thing, which is good for an hard
core mudder, but not for an occasional player. The innovative muds
which open find themselves with few players. The best mud I ever
played (it was some time ago) was Dartmud, still it had few players,
and always the same players. A codebase (it was an LP mudlib) like
that just won't spread around like ROM/Circle. The result is that you
have good and innovative muds, but they are very hard to find, hard to
play and with few players. Would you say that this kind of mud is
"successful"?
Alberto
PS: again, let us know when you have something good on-line, I'll be
more than glad to be impressed by it....
Broly
On Sun, 6 Jul 1997, Greg Munt wrote:
> In all probability, my attitude is derived from innate disgust at
> the code-illiterate setting up a mud, and, by implication, disgust at the
> state of this newsgroup right now; also, it may be due to the fact that
> my first attempt at serious programming (read: my first attempt at my own
> mud) was not to download someone else's code (and declaring it as 'extensively
> modified') and bolt-on 'original' or 'unique' areas. In fact, my first
> attempt at my own mud was to write it from scratch. I looked at no source
> code apart from my own, when writing that first effort.
>
> Yes, I'm an elitist little fuck; I make no apologies for that.
> I believe that the way forward is for more and more
> scratch code to be downloadable, rather than an ever-increasing
> proliferation of 'modified DIKU' shite.
>
You seem to forget why we are doing this. This is a hobby. Very few
people make a living mudding (Man..what a job...the boss yells at you for
recalling in the middle of a battle while ya still got plenty of mana...)
We therefore only code those parts of the game of interest to us, while
not re-inventing the wheel for the mundane tasks. Mind you, many of the
the stock bases out there shipped with square tires...
What would be nice would be some truly 'stock' bases upon which to build.
I'd like to see a codebase that does the following:
-runs a generic boot cycle.
-handles non-blocking socket i/o (the socket code)
-creates and stores generic "characters".
-runs a generic command-line interpreter.
-loads a bulliten board system with a decent editor
And nothing else.
Well, maybe a couple of string-handling functions...
By generic boot cycle, I mean, establish the server, not boot the
mud-specific info. A generic character maybe has 5 data members (name,
password, some id-number, a list (linked or array?) of aliases, and
probably some command history). A generic command-line interpreter has
maybe 5 or 6 'social' commands, but has a decent search engine to find
commands, as well as the 'help' command.
Basically a 'stock' codebase should handle the non-game stuff that most of
us find boring, but force us to write the actual game. LPMud approaches
this but adds on LPC and a couple other things in such a way that you
can't just cut them out neatly.
What I ended up doing is taking a Circle and gutting it. I mean _really_
gutting it. I kept probably a hundred useful little functions like
"is_abbrev(char *test, char *standard)" and "REMOVE_FROM_LIST". Stuff I
would probably write *exactly* the same if I were to write it from
scratch. The rest is gone. My basic data structures are different from
what I've seen in any base, so most of the code wouldn't work anyways..
Stock codebases have a very important role, and shouldn't be bashed.
Someone else has written a lot of very boring code, and I don't see why I
should have to suffer the same fate. God forbid I actually learn how to
write decent socket code in C. If anyone has any, I'll find a good home
for it.
> The Mud Tree needs width.
The Mud Tree needs stronger roots. And maybe a good pruning.
Gunther.
Greg Munt
On 8 Jul 1997, Alberto BARSELLA wrote:
> > Opening a mud before its openable can only ever be a bad thing.
>
> So you know this :)
Yes, I do, noting that Frontiers was never officially opened, and never
advertised in any mud newsgroups.
[SNIP]
> The result is that you
> have good and innovative muds, but they are very hard to find, hard to
> play and with few players. Would you say that this kind of mud is
> "successful"?
Yes. Don't confuse 'successful' with 'popular'. Any administration which
sees the demands of the players as an overriding priority, will soon find
their mud to be decaying.
> PS: again, let us know when you have something good on-line, I'll be
> more than glad to be impressed by it....
Thanks. After only 6 months of development, I'd challenge anyone to come
up with a fantastic game - 6 years maybe :)
Greg Munt
On Tue, 8 Jul 1997, Scott McMahan wrote:
> There seems to be a lot that your missing about muds. Coding/play is only
> about 25% of what makes a mud good, there's also the world/zone/objs/mobs
> etc, the attitude of the imps, the players on the mud, the hardware etc.
> A scratch mud can still be awful in all the other areas, and a stock mud
> could excel in the others to such an extent to make it a very fun
> experience.
Already, I notice how your ideas are constrained. You think in terms of
world/zone/objs/mobs. You think in terms of what has come before. Dont
let that happen! Do we really want more and more muds which are simply 'a
new slant' on older servers? I say that we don't.
I *do* however, wholeheartedly agree that the code is of little
consequence when considering how enjoyable a mud is. Design is the most
important factor. When you FTP a code base, you don't just get someone
else's code: you get the design implemented by that code too. Often that
design stays within the mud forever. (Indeed, it would take a considerable
amount of work to remove that - possibly flawed - design.)
> As for working a lot on scratch muds, IMO, the same can be said about
> stock muds. If you want to have something worth speaking about, you have
> to put a lot of work in it.
Agreed. Perhaps a distinction should be drawn between stock muds (e.g. a
'heavily modified DIKU') and a derivative mud.
> Don't waste your time re-inventing the wheel.
Currently, you have to take on an entire mud, rather than just the socket
code, or just the file I/O (I'm sure I'll be corrected if this is
inaccurate.)
It would be preferable to release libraries of code spefically for use in
mud development, rather than an entire mud (with its associated design
baggage).
> Quite frankly, I'd
> like to see many more stock muds made available. However, I think the
> other post in this thread is right, until licensing agreements are honored
> better, don't expect anyone to make their hard work available to us for
> nothing.
Again, I point out that many new mud bases emerged in the late
eighties/early nineties. The licence problem will have existed just as
much then as it does now. I would therefore suggest that there are other
contributing factors to the currently stifled development of muds.
Greg Munt
On 8 Jul 1997, Alberto BARSELLA wrote:
> In article <Pine.BSI.3.91.970707...@tommy.chesapeake.net> Jerry Gilyeat <jgil...@tommy.chesapeake.net> writes:
>
> > I don't think he ever said it was done, debuggd, and had everything
> > working, now, did he? I thought not. Quite frankly, I'm at the point
> > now where when I log onto a newly advertised MUD I EXPECT things to not
> > be working.
>
> Well....from the tone of his post I had expected something at least
> decent. Also, its login screen says NOTHING about the mud server being
> anything like alpha or beta. What I saw is yet another stock basher
> which whines about "lack of improvement" in muds and then puts on-line
> a thing which I can code in 1 month (and yes, I did it, but I never
> dared to put it online).
For my opinion to be valid, I have to have a fantastic mud running?
FYI, Frontiers is not 'open' - it was originally put online for testing
purposes only. Then several people started using it, and so it was never
brought down again.
> > As far as having other codebases freely downloadable: it would be
> > really nice, and I can think of a couple that are in VERY alpha stages
> > (Mud++ and Sapphire).
>
> We're going back to the generic discussion here....
A discussion which we should never have left in the first place.
> Ahem....it's HIM bashing stock muds, not me. I know that there are
> nice codebases around, and I also think that the codebase is not the
> most imoprtant thing for a good mud. Usually every codebase has its
> strength, directly related to what its creator felt "most important".
Is it what the person downloading the code feels most important though?
Or is it just 'a mud, any mud'?
> > I know of about a dozen or so others that will never be made public
> > because of people like Vryce of Medthievia who look at licensing
> > agreements as nothing more than tripe.
>
> I think this has already given rise to enough flame wars....
>
> > If people in general were honest (people being MUD Imps) than I
> > think we'd be seeing more bases and a wider Tree. Unfortunately,
> > there's enough assholes in the world to give most "scratch coders"
> > an excuse to not release their code. An excuse I completely agree
> > with.
>
> I agree with you, but what is the relation with bashing stock muds?
> The fact that there are a lot of muds which suck because people just
> download the distribution, compile it, and then run it, without having
> any skill in mud aministration is not a good reason to jump in here
> and just attack everyone.
I'm not the one who initiated personal attacks, sir. I was attacking the
fact that you have just highlighted.
Scott McMahan
In article <Pine.LNX.3.91.9707...@uni-corn.demon.co.uk>,
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
:On Tue, 8 Jul 1997, Scott McMahan wrote:
:
:> There seems to be a lot that your missing about muds. Coding/play is only
:> about 25% of what makes a mud good, there's also the world/zone/objs/mobs
:> etc, the attitude of the imps, the players on the mud, the hardware etc.
:> A scratch mud can still be awful in all the other areas, and a stock mud
:> could excel in the others to such an extent to make it a very fun
:> experience.
:
:Already, I notice how your ideas are constrained. You think in terms of
:world/zone/objs/mobs. You think in terms of what has come before. Dont
:let that happen! Do we really want more and more muds which are simply 'a
:new slant' on older servers? I say that we don't.
Already I notice how your attitude is arrogant. I'm not thinking in terms
of what has come before, I'm posting in terms of what has come before. I
used those terms because people reading this group would be familiar with
them. Had I used terms to describe the way _I_ would implement a mud, no
one here would understand what I was talking about. By saying
"world/zone/objs/mobs etc" most people understand what I mean, the
creative, story part of the mud as opposed to the people playing
characters or the code or other aspects of it.
:> Don't waste your time re-inventing the wheel.
:
:Currently, you have to take on an entire mud, rather than just the socket
:code, or just the file I/O (I'm sure I'll be corrected if this is
:inaccurate.)
:
:It would be preferable to release libraries of code spefically for use in
:mud development, rather than an entire mud (with its associated design
:baggage).
I'm not sure it would be preferable. At least with circle, I've found it
easy to start gutting the game specific stuff and code in my own stuff,
but I get to look at some things as I do it, using the stock zones. I
think this is letting me go through it quicker, but not having tried it
from scratch, this is purely unfounded opinion. If I ever do set it up,
there'll be little to nothing left that anyone else would recognize as
circle, though.
If you feel that just the basics would be better, please feel free to make
Frontier's stripped down code available for FTP.
--
Scott McMahan
mcm...@oncology.wisc.edu
John Adelsberger
Distribution:
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: Currently, you have to take on an entire mud, rather than just the socket
: code, or just the file I/O (I'm sure I'll be corrected if this is
: inaccurate.)
It's called LP. It's gotten a lot faster/more efficient recently. The
best Dikus are similar in quality to mediocre LPs:-)
: It would be preferable to release libraries of code spefically for use in
: mud development, rather than an entire mud (with its associated design
: baggage).
It's called the driver. If you're lazy or don't ahve time, also a mudlib,
which you'd want to modify heavily.
: Again, I point out that many new mud bases emerged in the late
: eighties/early nineties. The licence problem will have existed just as
: much then as it does now. I would therefore suggest that there are other
: contributing factors to the currently stifled development of muds.
Like the fact that your'e ignoring the fact that almost all really
creative people in muds are doing LP, and that a 'better LP' isn't
really needed so much(although the new mudoses keep getting better:)
Why on earth would anyone in his right mind redo all that work when it's
been done _right_ already, esp since an LP can look/feel/etc like
_anything_ you want, including nonmud network servers?:)
Idea people and code people are so rarely the same people that it
makes sense that a system such as LP that reduced the code effort
would draw almost all the good ideas. And it has.
--
John J. Adelsberger III
j...@umr.edu
John Adelsberger
Distribution:
Broly <br...@mail.bcpl.lib.md.us> wrote:
: I'd like to see a codebase that does the following:
: -runs a generic boot cycle.
: -handles non-blocking socket i/o (the socket code)
Bad idea. Can you say, "eat up CPU for no reason whatsoever?"
I thought you could. Thread the damn thing if you're writing
it from scratch.
: -creates and stores generic "characters".
Bad idea. Connection object is a better idea. Otherwise, what do you do
if the codebase's 'character' is different than yours?
: And nothing else.
: Well, maybe a couple of string-handling functions...
And some stuff for figuring out _how_ to start up the mud specific code
you've written, and some terminal handling, and... and... like I said
in another post, it's called LP(MudOS in particular, but others exist:)
: By generic boot cycle, I mean, establish the server, not boot the
: mud-specific info. A generic character maybe has 5 data members (name,
: password, some id-number, a list (linked or array?) of aliases, and
: probably some command history). A generic command-line interpreter has
Name - um, ok, but what if you want names to work differently(different
max # of chars, different allowable special chars(spaces, etc) and so
on? Not very generic if you ask me.
Passwd - same as name
id number - why? Ever heard of a hash table?
Aliases - if you'd use a linked list or array for aliases, it's no
wonder you talk instead of writing - go look up hash tables. Have
you in fact spent more than 3 hours writing C at all?:)
: maybe 5 or 6 'social' commands, but has a decent search engine to find
: commands, as well as the 'help' command.
What if you don't want social cmds? What if you want help called
something else? You seem to have decided what _you_ want, rather
than what is generic and essential vs optional/specific.
: Basically a 'stock' codebase should handle the non-game stuff that most of
: us find boring, but force us to write the actual game. LPMud approaches
: this but adds on LPC and a couple other things in such a way that you
: can't just cut them out neatly.
LPC is so far superior to C for coding a mud that youwouldn't _want_ to
cut it out. What else is there to cut out? Nothing. Unless, of
course, you are upset by it handling inventories, but try and tell me
you can do a real cmd interpreter w/o some notion of what obs might
want to hook what cmds?
: What I ended up doing is taking a Circle and gutting it. I mean _really_
: gutting it. I kept probably a hundred useful little functions like
: "is_abbrev(char *test, char *standard)" and "REMOVE_FROM_LIST". Stuff I
: would probably write *exactly* the same if I were to write it from
: scratch. The rest is gone. My basic data structures are different from
: what I've seen in any base, so most of the code wouldn't work anyways..
If you did that, why not just _write_ it yourself, in, say, a week, or
less, and avoid the copyright?
: Stock codebases have a very important role, and shouldn't be bashed.
: Someone else has written a lot of very boring code, and I don't see why I
: should have to suffer the same fate. God forbid I actually learn how to
: write decent socket code in C. If anyone has any, I'll find a good home
: for it.
Ah, you are a clueless MudDork[tm] :)
: The Mud Tree needs stronger roots. And maybe a good pruning.
You want to lie about history, or you just have no knack for analogy?
--
John J. Adelsberger III
j...@umr.edu
"The environment may require conventions be maintained beyond those required
for portability." -- Scott Nudds, in comp.lang.asm.x86
Alberto BARSELLA
In article <5q44e9$t6j$3...@news.cc.umr.edu> John Adelsberger <j...@umr.edu> writes:
> Distribution:
>
> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
>
> : Currently, you have to take on an entire mud, rather than just the socket
> : code, or just the file I/O (I'm sure I'll be corrected if this is
> : inaccurate.)
>
> It's called LP. It's gotten a lot faster/more efficient recently. The
> best Dikus are similar in quality to mediocre LPs:-)
Well....there are bad LPs out there, too.
One thing I never liked (I think it's in the faq, too) is the fact
that non-saved inventory objects are a constant in LPs. And I hate
that :)
> : It would be preferable to release libraries of code spefically for use in
> : mud development, rather than an entire mud (with its associated design
> : baggage).
>
> It's called the driver. If you're lazy or don't ahve time, also a mudlib,
> which you'd want to modify heavily.
I looked at LP some time ago. The Lima mudlib probably has solved much
of the problems I had, anyway what turned me down was:
1) LPC is a general purpose language. It don't find it to be enough
mud-specific.
2) Customizing a mudlib means accepting the choices they did or
hacking it so much that in the end it's not very different from
hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
I prefer to practice those languages.
The fact that it's interpreted and thus a tiny error can't just kill
the whole thing with a SEGV is a definitive bonus, anyway.
Someone suggested me to look at the Cold project. I got the homepage,
but I never found the time to study it carefully.....too bad.
Alberto
Matt Chatterley
On 11 Jul 1997, Alberto BARSELLA wrote:
[Huge snippage]
You are correct in stating that there are bad LPs, there are also bad
Dikus, and bad muds in general. It should be pointed out at this juncture
that LPs are significantly different - just the driver itself is not a
game, merely a platform for building one (vaguely like an OS). The Mudlip
is what we are talking about if we move onto the game.
> One thing I never liked (I think it's in the faq, too) is the fact
> that non-saved inventory objects are a constant in LPs. And I hate
> that :)
Rubbish. Many LPs save inventory - Nightmare, and Nanvaent to name two,
my own game-in-the-making to name a third, and there are likely many more
I do not know of. Whether this happens or not is a matter for the mudlib
to decide - none of the 'stock' mudlibs that I am aware of save
inventory. Be careful with definitions of terms - LP is the most flexible
mud server, and can be literally anything in an incarnation. Most
flexible that I am aware of, I should say.
[Snip again]
> I looked at LP some time ago. The Lima mudlib probably has solved much
> of the problems I had, anyway what turned me down was:
Lima is probably the best stock mudlib available.
> 1) LPC is a general purpose language. It don't find it to be enough
> mud-specific.
This is IMHO a huge advantage - you can build an HTTP and FTP server into
your mud with relatively little hassle, for instance. You add your own
mud-specific parts, such as functions to change health state, in your
living/player/monster/whatever object.
> 2) Customizing a mudlib means accepting the choices they did or
> hacking it so much that in the end it's not very different from
> hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
> I prefer to practice those languages.
It's rather easier to change a mudlib online than Diku, and the
structuring makes it easier for those with less coding experience, I'd
say. If you're handling stock code in any sense, you WILL have very
similar situations. Writing an LP lib from scratch is much easier (IMHO)
than writing an entire mud base from scratch.
> The fact that it's interpreted and thus a tiny error can't just kill
> the whole thing with a SEGV is a definitive bonus, anyway.
Quite definitely.
> Someone suggested me to look at the Cold project. I got the homepage,
> but I never found the time to study it carefully.....too bad.
I've not had time to look into the Cold project either. :(
Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"He can't stop us, we're on a mission from Glod!" - Soul Music (Pratchett)
Ho-Sheng Hsiao
Alberto BARSELLA (ish...@lsh01.univ-lille1.fr) wrote:
: In article <5q44e9$t6j$3...@news.cc.umr.edu> John Adelsberger <j...@umr.edu> writes:
: > Distribution:
: > Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: > : Currently, you have to take on an entire mud, rather than just the socket
: > : code, or just the file I/O (I'm sure I'll be corrected if this is
: > : inaccurate.)
: > It's called LP. It's gotten a lot faster/more efficient recently. The
: > best Dikus are similar in quality to mediocre LPs:-)
: Well....there are bad LPs out there, too.
: that non-saved inventory objects are a constant in LPs. And I hate
: that :)
Newer mudlibs (can you say, for example... Lima Beans?) already implement
saved inventory objects.
: > : It would be preferable to release libraries of code spefically for use in
: > : mud development, rather than an entire mud (with its associated design
: > : baggage).
: > It's called the driver. If you're lazy or don't ahve time, also a mudlib,
: > which you'd want to modify heavily.
: I looked at LP some time ago. The Lima mudlib probably has solved much
: of the problems I had, anyway what turned me down was:
: 1) LPC is a general purpose language. It don't find it to be enough
: mud-specific.
That's the point. Having a general purpose language allows you to do
close to anything you want with it. If you *want* a mud-specific language,
the latest release of Lima beans (1.05a, correct?) implements lpscript.
: 2) Customizing a mudlib means accepting the choices they did or
: hacking it so much that in the end it's not very different from
: hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
: I prefer to practice those languages.
I believe the Foundation II mudlib provides a mudlib base for MudOS
without a great deal of mud-specific objects. The last I heard, though,
Foundation II is being rewritten and is unavailable.
In any case, if you were to implement a mud-specific language, other mud
implementors would have to accept "the choices [you] did or hacking it so
much that in the end it's not very different from hacking a C/C++
codebase. And C/C++ has many more uses" than a mud-specific language. Get
my point?
--
---hhh
"Everything is real unless declared an integer." --- Modified from Rick
Cook's Wizardry Compiled. "Life is a suicide mission." ---Jane, from Orson
Scott Card's Children of the Mind.
Nathan F. Yospe
Matt Chatterley <ne...@itl.net> wrote:
:On 11 Jul 1997, Alberto BARSELLA wrote:
:[Huge snippage]
:You are correct in stating that there are bad LPs, there are also bad
:Dikus, and bad muds in general. It should be pointed out at this juncture
:that LPs are significantly different - just the driver itself is not a
:game, merely a platform for building one (vaguely like an OS). The Mudlip
:is what we are talking about if we move onto the game.
And this is a significant point. The real advantage is runtime editing...
which a good dynaload library can solve for you. (Fortunately, I happen
to have designed myself just such a library...)
:> One thing I never liked (I think it's in the faq, too) is the fact
:> that non-saved inventory objects are a constant in LPs. And I hate
:> that :)
:Rubbish. Many LPs save inventory - Nightmare, and Nanvaent to name two,
:my own game-in-the-making to name a third, and there are likely many more
:I do not know of. Whether this happens or not is a matter for the mudlib
:to decide - none of the 'stock' mudlibs that I am aware of save
:inventory. Be careful with definitions of terms - LP is the most flexible
:mud server, and can be literally anything in an incarnation. Most
:flexible that I am aware of, I should say.
Check out ColdCore.
:[Snip again]
:> I looked at LP some time ago. The Lima mudlib probably has solved much
:> of the problems I had, anyway what turned me down was:
:Lima is probably the best stock mudlib available.
:> 1) LPC is a general purpose language. It don't find it to be enough
:> mud-specific.
:This is IMHO a huge advantage - you can build an HTTP and FTP server into
:your mud with relatively little hassle, for instance. You add your own
:mud-specific parts, such as functions to change health state, in your
:living/player/monster/whatever object.
I follow the philosophy of "do the hardcore stuff in a hardcore language
(C++) and the simple stuff in a simple language (Pipcode, the internal
pointer-tabled language of Physmud)" and find it works quite well. If
I wanted an HTTP or FTP server _in_ my mud (why on earth?) I would use
C++, and the linkage library, and hook it into the messaging system. If
there was a flaw in the code, it would kill the new execution thread,
then throw me an exception. Next try.
:> 2) Customizing a mudlib means accepting the choices they did or
:> hacking it so much that in the end it's not very different from
:> hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
:> I prefer to practice those languages.
:It's rather easier to change a mudlib online than Diku, and the
:structuring makes it easier for those with less coding experience, I'd
:say. If you're handling stock code in any sense, you WILL have very
:similar situations. Writing an LP lib from scratch is much easier (IMHO)
:than writing an entire mud base from scratch.
The thing that bugs me is people thinking that its got to be either like
LP (or Tiny) or like Diku. Bleah.
:> The fact that it's interpreted and thus a tiny error can't just kill
:> the whole thing with a SEGV is a definitive bonus, anyway.
:Quite definitely.
Exception handling is nice for this too, and there is no overhead until
things go wrong.
:> Someone suggested me to look at the Cold project. I got the homepage,
:> but I never found the time to study it carefully.....too bad.
:I've not had time to look into the Cold project either. :(
I reccomend you do so.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!
Nathan F. Yospe
John Adelsberger <j...@umr.edu> wrote:
What, did this jerk change something, or is my killfile not working
today? *sigh*
:Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
:: Currently, you have to take on an entire mud, rather than just the socket
:: code, or just the file I/O (I'm sure I'll be corrected if this is
:: inaccurate.)
:It's called LP. It's gotten a lot faster/more efficient recently. The
:best Dikus are similar in quality to mediocre LPs:-)
No, it is most emphatically NOT called LP. LP is a server, with a whole
$#!+load of baggage, and a lot of basic design flaws that cannot be, in
any manner, removed or repaired.
Some existing examples of what Greg is asking for do exist. Robin Carey's
NetServe, for example, is a rather good plug in socket (and telnet) host.
Physmud++ will, if I ever get it cleaned up enough for release, include a
series of plug in class libraries, from containers to string parsers to
message handlers and thread sockets and network (socket) IO managers, all
designed to be freely and safely editable without breaking everything else.
This is a remote concept from that of LP(C).
:: It would be preferable to release libraries of code spefically for use in
:: mud development, rather than an entire mud (with its associated design
:: baggage).
:It's called the driver. If you're lazy or don't ahve time, also a mudlib,
:which you'd want to modify heavily.
No. No, the driver is still design baggage. What if I wanted a lockless,
thread safe database? Ref counting based GC? Pure geographical
distribution? A system that models complex physics? (LP was not nearly
efficient enough for my needs... which is why I wrote my own system, and
tailored, in a native language, those things that needed tailoring.)
:: Again, I point out that many new mud bases emerged in the late
:: eighties/early nineties. The licence problem will have existed just as
:: much then as it does now. I would therefore suggest that there are other
:: contributing factors to the currently stifled development of muds.
:Like the fact that your'e ignoring the fact that almost all really
:creative people in muds are doing LP, and that a 'better LP' isn't
:really needed so much(although the new mudoses keep getting better:)
No, he's not. All the really creative people are doing custom bases,
some driver based, some component library based, many impossible to
pull off in a fixed design (relatively) model like LP. Now, LP is many
orders of magnitude beyond Diku, but it is still one of those 80s
things Greg was talking about. We're talking about stepping beyond the
limitations of LP, and creating something radically different.
:Why on earth would anyone in his right mind redo all that work when it's
:been done _right_ already, esp since an LP can look/feel/etc like
:_anything_ you want, including nonmud network servers?:)
Three reasons... #1, it hasn't been done "right" for everyone's needs,
#2, it can't look/feel/etc (esp. etc) like MY system at its most extreme
(I'd just like to SEE someone pull off a three body system in LPC... you
need lagrangian and fourier support), and #3, it is an all or nothing
proposition... which means you can't get rid of the stuff in the driver
that has no bearing on you. (move something from here to there? But I
don't WANT that to be possible... I use barrier transitions)
:Idea people and code people are so rarely the same people that it
:makes sense that a system such as LP that reduced the code effort
:would draw almost all the good ideas. And it has.
I dunno. I've seen a lot of LPs. Worked on more than a couple. And
you know what? It hasn't really produced the grandest ideas I've
seen. In fact, of the ten greatest muds, designwise (setting, mood,
story, immersion) that I have ever seen, three were Diku dirivatives,
and three were custom. And two were tiny based. Do the math.
John Adelsberger
Distribution:
Alberto BARSELLA <ish...@lsh01.univ-lille1.fr> wrote:
: Well....there are bad LPs out there, too.
Granted, but even most of the bad ones at least have the benefit of being
able to rapidly improve should someone clever come along:)
: One thing I never liked (I think it's in the faq, too) is the fact
: that non-saved inventory objects are a constant in LPs. And I hate
: that :)
Your peeve is unclear - what do you mean? If you mean that it is possible
to ahve an ob in your inventory w/o having it saved w/ your char
immediately, that _can_ be true, but you _can_ make such things save
immedidately, also.
: > It's called the driver. If you're lazy or don't ahve time, also a mudlib,
: > which you'd want to modify heavily.
: I looked at LP some time ago. The Lima mudlib probably has solved much
: of the problems I had, anyway what turned me down was:
: 1) LPC is a general purpose language. It don't find it to be enough
: mud-specific.
As opposed to C?:-)
: 2) Customizing a mudlib means accepting the choices they did or
: hacking it so much that in the end it's not very different from
: hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
: I prefer to practice those languages.
LPC is so much easier itisn't even funny. I don't know if yo utried it,
but it really is. Mudlibs aren't so hard to write as people pretend;
it's just that most mudcoders aren't really programmers.
: The fact that it's interpreted and thus a tiny error can't just kill
: the whole thing with a SEGV is a definitive bonus, anyway.
No kidding.
: Someone suggested me to look at the Cold project. I got the homepage,
: but I never found the time to study it carefully.....too bad.
Where's the homepage? I'd at least want to read about it, whatever it
is:-)
Jon A. Lambert
Greg Munt <gr...@uni-corn.demon.co.uk> wrote in article <Pine.LNX.3.91.9707...@uni-corn.demon.co.uk>...
> On Tue, 8 Jul 1997, Scott McMahan wrote:
>
> > There seems to be a lot that your missing about muds. Coding/play is only
> > about 25% of what makes a mud good, there's also the world/zone/objs/mobs
> > etc, the attitude of the imps, the players on the mud, the hardware etc.
> > A scratch mud can still be awful in all the other areas, and a stock mud
> > could excel in the others to such an extent to make it a very fun
> > experience.
>
> Already, I notice how your ideas are constrained. You think in terms of
> world/zone/objs/mobs. You think in terms of what has come before. Dont
> let that happen! Do we really want more and more muds which are simply 'a
> new slant' on older servers? I say that we don't.
>
I have yet to encounter a server that didn't use the terms, objects and world.
How are these terms constraining? Can you provide alternative terms?
> > As for working a lot on scratch muds, IMO, the same can be said about
> > stock muds. If you want to have something worth speaking about, you have
> > to put a lot of work in it.
>
> Agreed. Perhaps a distinction should be drawn between stock muds (e.g. a
> 'heavily modified DIKU') and a derivative mud.
>
Is ROM a heavily modified DIKU or a derivative mud?
What distinguishes one from the other?
JL
-
"It's not the code, it's the game stupid" - J. Lambert (c)1997
Heavily modified quote based on previously published
material by M. Keegan (1996)
Jon A. Lambert
Greg Munt <gr...@uni-corn.demon.co.uk> wrote in article <Pine.LNX.3.91.97070...@uni-corn.demon.co.uk>...
> On 5 Jul 1997, Scott wrote:
>
> > Ok, I fixed the error. I don't know if I fixed it *correctly*, but it
> > compiles and runs. I made the 'lib' directory a subdirctory of 'src' and lo
> > and behold, it works. Now, why am I compiling a mud if I know nothing about
> > programming? Let me ask you a question first: When you first started, did
> > you know all there was to know about programming? Were you an expert?
>
> Of course not - but I didn't attempt to put up a mud at that stage,
> state of this newsgroup right now; also, it may be due to the fact that
> my first attempt at serious programming (read: my first attempt at my own
> mud) was not to download someone else's code (and declaring it as 'extensively
> modified') and bolt-on 'original' or 'unique' areas. In fact, my first
> attempt at my own mud was to write it from scratch. I looked at no source
> code apart from my own, when writing that first effort.
>
> Yes, I'm an elitist little fuck; I make no apologies for that. If this
> newsgroup is a true representation of the current mudding community (and
> I sincerely hope it is not), then it needs a damn good kick up the ass.
> In my view, the evolution of muds has failed. Since 1990, all that has
> been achieved is a steady watering-down of 3 or 4 different mud types.
> proliferation of 'modified DIKU' shite.
>
I don't follow your logic. How does the state of this newsgroup reflect
the state of mudding? You should know that there is much more discussion
carried on outside this newsgroup than within it. Someone posts a question
about compiling a mud and they get an anal exam on their motivations and
qualifications. So they don't bother posting anymore. Is it your position
that newcomers should be discouraged from entering the ranks of mud
implementers? What exactly have you done that you feel puts you into
the ranks of the elite? Can you point to any "promising" codebases or must
everything be written from scratch? Could it be that you are just a
codebase bigot from a "tiny" leaf of the mud tree who has a gripe against
the DIKU family tree?
You state you would like to see more freely available code, then you bemoan
the fact that someone would actually download it and, god forbid, actually use
it.
What does the phrase "steady watering-down of 3 or 4 different mud types"
mean? There are more than 50 freely available codebases. At least 20 of these
have appeared in the last 6 years. I am also aware of a couple dozen ongoing
server projects, some of them are several years in the making.
Do you have any specific ideas to offer up? Can you point to any particular
posting that you have made in the last year in any of these newsgroups that
contains any thoughts on what muds should evolve into? I only see whining
about the past.
> Of course, this will be even more food for Reese's Morons to regurgitate
> in 10 seconds flat. That will never change. Hopefully it will channel
> people into more originality, and smash the accepted thought that to
> run a mud, you have to download source to do it.
How about smashing the accepted notion that you have to be a programmer
to run a great mud?
>
> The Mud Tree needs width.
No it needs depth. Inheritance is a requisite of evolution.
Miroslav Silovic
John Adelsberger <j...@umr.edu> writes:
> : Someone suggested me to look at the Cold project. I got the homepage,
> : but I never found the time to study it carefully.....too bad.
>
> Where's the homepage? I'd at least want to read about it, whatever it
> is:-)
It's at www.cold.org, predictably enough. Stop by at ice.cold.org 1138
if you want to ask questions (that's the official development/support
site).
Miro
Mackay / Katherine Amanda (COM)
John Adelsberger <j...@umr.edu> wrote:
>Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
>: Currently, you have to take on an entire mud, rather than just the socket
>: code, or just the file I/O (I'm sure I'll be corrected if this is
>: inaccurate.)
>It's called LP. It's gotten a lot faster/more efficient recently. The
>best Dikus are similar in quality to mediocre LPs:-)
>: It would be preferable to release libraries of code spefically for use in
>: mud development, rather than an entire mud (with its associated design
>: baggage).
>
>It's called the driver. If you're lazy or don't ahve time, also a mudlib,
>which you'd want to modify heavily.
Then again I'd argue that the lib is also libraries of code, specifically
for use in mud development ... As someone who doesn't need races, classes,
skills, guilds, shops, etc, one can just #define everything out :)
>: Again, I point out that many new mud bases emerged in the late
>: eighties/early nineties. The licence problem will have existed just as
>: much then as it does now. I would therefore suggest that there are other
>: contributing factors to the currently stifled development of muds.
>
>Like the fact that your'e ignoring the fact that almost all really
>creative people in muds are doing LP, and that a 'better LP' isn't
>really needed so much(although the new mudoses keep getting better:)
Sure a better LP is needed <peers at the lima.bugs and lima.ideas
newsgroups, and mutters nastily> .. lima a7 .. a8 .. a9 <coughs>
'Sides. You're showing signs of LP bigotism (Playwise I prefer abers
</rant on> </rant off> since even though they don't come close to any more
modern base in terms of features and user friendliness, they're fun). I'd
argue that the _really_ creative people are using MU*, due to the
limitations of the servers <evil grin>
>Why on earth would anyone in his right mind redo all that work when it's
>been done _right_ already, esp since an LP can look/feel/etc like
>_anything_ you want, including nonmud network servers?:)
Well .. I don't know if MudOS can currently emulate MOO with any niceness
... (Hmm .. what is it that DGD has that made LPMOO possible??)
--OH.
Mackay / Katherine Amanda (COM)
Ho-Sheng Hsiao <hsh...@freenet.columbus.oh.us> wrote:Yes, bt there are Sooooo many more bad dikus out there ("Yet Another
Midgaard Mud" is _so_ passe ;)
>: One thing I never liked (I think it's in the faq, too) is the fact
>: that non-saved inventory objects are a constant in LPs. And I hate
>: that :)
>Newer mudlibs (can you say, for example... Lima Beans?) already implement
>saved inventory objects.
<ahem> Lima (or LIMA or <massive fit of coughing> GUELib :) .. Lima Bean
is the development/support site. Inventory items save, yes, not all
variables save though ;/ due to not having add_save() called in various
bits and pieces ... Deathblade and I had a chat about ways to automate the
saved variables a while back, but he's been busy last couple of months.
At any rate, most LPs do save inventory .. even the old ones often
implement lockers (urgh :), which is not really very different from the
old-style diku/Circle rent system ...
>: I looked at LP some time ago. The Lima mudlib probably has solved much
>: of the problems I had, anyway what turned me down was:
>: 1) LPC is a general purpose language. It don't find it to be enough
>: mud-specific.
>That's the point. Having a general purpose language allows you to do
>close to anything you want with it. If you *want* a mud-specific language,
>the latest release of Lima beans (1.05a, correct?) implements lpscript.
latest is a6 .. lpscript is mostly there, but a couple of modules need to
get picked up, etc etc ...
At any rate, yes, the driver efuns are general purpose, just as C/C++ is
general purpose .. In fact try and use either C _or_ C++ without the
libraries ... you'll find even _less_ that's mud specific :)
If you want mud specific stuff (<insert Abigail flame here in that MudOS
has parsing and inventory driver stuff> ;), you look in the mudlib stuff..
Why doesn't it have rooms or player "avatars"? Because you may want to
make a BBS. Why not the concept of a weapon? because you may want to do a
talker?
Complaining that LPC is general purpose is extremely silly, especially
when you compare it with C/C++ ... LPC is far more mud specific <grins>
>: 2) Customizing a mudlib means accepting the choices they did or
>: hacking it so much that in the end it's not very different from
>: hacking a C/C++ codebase. And C/C++ has many more uses than LPC, so
>: I prefer to practice those languages.
>
>I believe the Foundation II mudlib provides a mudlib base for MudOS
>without a great deal of mud-specific objects. The last I heard, though,
>Foundation II is being rewritten and is unavailable.
I don't know if it's unavailable .. I thinnnk it's still available, though
last I heard, Desc wasn't really recommending its usage (Any FIII planned?)
I imagine if you #undeffed everything in Lima's /include/config.h, went
through /include mudlib.h and removed all the #defs that you don't need
there (and the associated modules), ripped /domains/*, and all /std/*,
/obj/*, etc stuff you don't need, it would take about half an hour, and
you'd have something roughly on the featuredness of Foundation II (more if
you left in telnet, ftp, news, mail, http (Hmm .. and I3? or does FII
have I3?))
[Warning: Do NOT attempt this unless you have spent some time looking at
the lib - if you remove /std/races/* you WILL hose yourself
(/std/race/human is standard non-raced body), and there are some other
gotchas too .. ]
--OH.
John Adelsberger
Mackay / Katherine Amanda (COM) <u94...@student.canberra.edu.au> wrote:
: Actually a very few Dikus I'd rate up there with the top echelon of LPs...
I won't argue, since I openly admit that I think Diku is
Yesterday's Technology Today[tm] :-)
: Then again I'd argue that the lib is also libraries of code, specifically
: for use in mud development ... As someone who doesn't need races, classes,
: skills, guilds, shops, etc, one can just #define everything out :)
True, but the post I was responding to, as I recall, wanted just
socket code and so on - in LP, that's all driver.
: >Like the fact that your'e ignoring the fact that almost all really
: >creative people in muds are doing LP, and that a 'better LP' isn't
: >really needed so much(although the new mudoses keep getting better:)
: Sure a better LP is needed <peers at the lima.bugs and lima.ideas
: newsgroups, and mutters nastily> .. lima a7 .. a8 .. a9 <coughs>
LP libs have a ways to go. Lima is the best of the stock libs, and
to say the least, it's incomplete. However, the MudOS driver is
rapidly getting to a point where it really won't need much - if the
memory management and a few syntax issues were a bit nicer, and a
few old historical garbage efuns were stripped out, it'd probably
be more driver than any mud needs:)
: 'Sides. You're showing signs of LP bigotism (Playwise I prefer abers
I've never even seen an aber, and can't speak about them. However, having
played a bunch of MU* stuff and LP, and some Diku wannabes, and having
coded some MU* and LP, I can say without any doubt that LP makes creating
the game easier than any of its alternatives, and that's what really
counts.
: Well .. I don't know if MudOS can currently emulate MOO with any niceness
: ... (Hmm .. what is it that DGD has that made LPMOO possible??)
It could be done in MudOS perfectly well if someone wanted to, but it'd
be disgusting and probably slow unless you had a rather huge amount of
memory relative to your db file. DGD is disk based, which makes
emulating monolithic db servers like MOO, MUSH, MUSE, and so on easy
and efficient, but which also has some negative side effects.
Emulating anything isn't too hard in LPC if anything means a mud, mush,
muse, muck, murpe, or whatever. I saw one mud that had emulation for
the original TinyMUD, some Aber stuff of some sort(dont know how it worked)
and stuff to run diku areas/mobs/etc, in addition to lima's lpscript and
native lpc, and another virtual object format - it's too bad the thing
probably closed(it's ISP just disappeared one day - the whole domain.
I have no idea where it went or why:)
(Actually, to be fair, emulating/actually doing any network service you
can imagine is at least theoretically _possible_ in LPC, but only a few
have been done to my knowledge.)
By the way, yes, I am an LP man, but bigotry is senseless discrimination;
I discriminate based on features/extensibility/utility/etc:-)
Greg Munt
On Fri, 11 Jul 1997, Matt Chatterley wrote:
> On 11 Jul 1997, Alberto BARSELLA wrote:
>
> > 1) LPC is a general purpose language. It don't find it to be enough
> > mud-specific.
>
> This is IMHO a huge advantage - you can build an HTTP and FTP server into
> your mud with relatively little hassle, for instance. You add your own
> mud-specific parts, such as functions to change health state, in your
> living/player/monster/whatever object.
A criticism of MudOS (I don't know about other drivers, but I presume
it's the same for those too) I have heard, is that it has pretty much
reimplemented unix. Comments on this?
Do you *really* need to build HTTP and/or FTP servers into your mud,
anyway?
------------------------------------------------------------------------------
A L F A
The slave thought he was released from bondage
only to find a stronger set of chains
Greg Munt
On Thu, 10 Jul 1997, Scott McMahan wrote:
> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
>
> :On Tue, 8 Jul 1997, Scott McMahan wrote:
> :
> :> There seems to be a lot that your missing about muds. Coding/play is only
> :> about 25% of what makes a mud good, there's also the world/zone/objs/mobs
> :> etc, the attitude of the imps, the players on the mud, the hardware etc.
> :> A scratch mud can still be awful in all the other areas, and a stock mud
> :> could excel in the others to such an extent to make it a very fun
> :> experience.
> :
> :Already, I notice how your ideas are constrained. You think in terms of
> :world/zone/objs/mobs. You think in terms of what has come before. Dont
> :let that happen! Do we really want more and more muds which are simply 'a
> :new slant' on older servers? I say that we don't.
>
> Already I notice how your attitude is arrogant.
Yes, I'm an arrogant, elitist pedant.
> I'm not thinking in terms
> of what has come before, I'm posting in terms of what has come before. I
> used those terms because people reading this group would be familiar with
> them. Had I used terms to describe the way _I_ would implement a mud, no
> one here would understand what I was talking about.
Fair enough. But isn't the point of this group to discuss new designs,
new implementations, new ideas? Or maybe it's a medium through which all
mud-related noise flows, in order to cleanse the many, many mailing
lists dedicated to mud design.
> By saying
> "world/zone/objs/mobs etc" most people understand what I mean, the
> creative, story part of the mud as opposed to the people playing
> characters or the code or other aspects of it.
OK. I guess I was objecting to 'zone' more than anything else. Zones are
an abstraction, and therefore an abomination. The Lord has spoken.
> :> Don't waste your time re-inventing the wheel.
> :
> :Currently, you have to take on an entire mud, rather than just the socket
> :code, or just the file I/O (I'm sure I'll be corrected if this is
> :inaccurate.)
> :
> :It would be preferable to release libraries of code spefically for use in
> :mud development, rather than an entire mud (with its associated design
> :baggage).
>
> I'm not sure it would be preferable. At least with circle, I've found it
> easy to start gutting the game specific stuff and code in my own stuff,
> but I get to look at some things as I do it, using the stock zones. I
> think this is letting me go through it quicker, but not having tried it
> from scratch, this is purely unfounded opinion. If I ever do set it up,
> there'll be little to nothing left that anyone else would recognize as
> circle, though.
If you are going to completely gut it, why aren't libraries preferable?
> If you feel that just the basics would be better, please feel free to make
> Frontier's stripped down code available for FTP.
It has always been the intention to release Frontiers via FTP, as it has
always been the intention to allow anyone and everyone to contribute to
its design and development. There are mailing lists set up for this.
(Email frontiers-new...@pogonet.pair.com with subject 'info'.)
You should note that development (or is that under-development?) is
currently at a primitively early stage though!
Greg Munt
From what I have heard of Cold, its design goals appear akin to those of
LP. Could anyone post, comparing and contrasting the two?
George Reese
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: On Fri, 11 Jul 1997, Matt Chatterley wrote:
: > On 11 Jul 1997, Alberto BARSELLA wrote:
: >
: > > 1) LPC is a general purpose language. It don't find it to be enough
: > > mud-specific.
: >
: > This is IMHO a huge advantage - you can build an HTTP and FTP server into
: > your mud with relatively little hassle, for instance. You add your own
: > mud-specific parts, such as functions to change health state, in your
: > living/player/monster/whatever object.
: A criticism of MudOS (I don't know about other drivers, but I presume
: it's the same for those too) I have heard, is that it has pretty much
: reimplemented unix. Comments on this?
Yeah, it is utter nonsense.
: Do you *really* need to build HTTP and/or FTP servers into your mud,
: anyway?
FTP is a bad idea. HTTP is the best way for interfacing with the mud,
however, from the web (getting help files, seeing who is online, etc).
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: It's called LP. It's gotten a lot faster/more efficient recently. The
: best Dikus are similar in quality to mediocre LPs:-)
Which is not saying a whole lot.
: Like the fact that your'e ignoring the fact that almost all really
: creative people in muds are doing LP, and that a 'better LP' isn't
: really needed so much(although the new mudoses keep getting better:)
Codswhallop. LP is a decent MUD server. It is by no means an ideal or
a perfect solution. It has strengths and it has weaknesses. Depending on
what you want to do, and what you consider important those weaknesses can
be catastrophic. LP's not God, its just one among several possible
approaches.
: Why on earth would anyone in his right mind redo all that work when it's
: been done _right_ already, esp since an LP can look/feel/etc like
: _anything_ you want, including nonmud network servers?:)
Lessee: Because I want to do things that LP is just not geared to be able
to do, or to do efficiently?
: Idea people and code people are so rarely the same people that it
: makes sense that a system such as LP that reduced the code effort
: would draw almost all the good ideas. And it has.
BS. Have a look at the work being done in the field -- LP is just a runner.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
John Adelsberger
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
: A criticism of MudOS (I don't know about other drivers, but I presume
: it's the same for those too) I have heard, is that it has pretty much
: reimplemented unix. Comments on this?
It could be said to have reimplemented OS/2, b/c of that OS's system
object model, but there is no concept of objects in Unix. Yes, you
could impose them on the heirarchical process structure, but you'd
have to be a moron to waste the effort. Besides, MudOS runs on a lot
of non unix systems.
: Do you *really* need to build HTTP and/or FTP servers into your mud,
: anyway?
Depends on your OS. Unix? No. Windoze? Yes. DOS? Yes. VMS? Yes.
(Yes, each of those can probably do it some other way, but I for one
wouldn't want to:)
--
John J. Adelsberger III
j...@umr.edu
"The environment may require conventions be maintained beyond those required
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Alberto BARSELLA <ish...@lsh01.univ-lille1.fr> wrote:
: : Well....there are bad LPs out there, too.
: Granted, but even most of the bad ones at least have the benefit of being
: able to rapidly improve should someone clever come along:)
: : One thing I never liked (I think it's in the faq, too) is the fact
: : that non-saved inventory objects are a constant in LPs. And I hate
: : that :)
: Your peeve is unclear - what do you mean? If you mean that it is possible
: to ahve an ob in your inventory w/o having it saved w/ your char
: immediately, that _can_ be true, but you _can_ make such things save
: immedidately, also.
Implicit in this is that LP (largely) does not render a permanent world.
There's an implicit assumption in the LP Libs that user changes to the world
will but only not be permanent, but that the admin will not not want all world
changes to be permanent.
What's permanent? Example: Bubba player drops a pebble in a certain room.
That pebble will remain in that room for all eternity, across crashes,
reboots, etc until something within the game (re)moves it.
Its a design choice, and a valid one, but if you're game is explicitly geared
around permanancy, then its a bloody annoying one to recode about.
: : Someone suggested me to look at the Cold project. I got the homepage,
: : but I never found the time to study it carefully.....too bad.
: Where's the homepage? I'd at least want to read about it, whatever it
: is:-)
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: And some stuff for figuring out _how_ to start up the mud specific code
: you've written, and some terminal handling, and... and... like I said
: in another post, it's called LP(MudOS in particular, but others exist:)
Or MOO, ColdX, Interlude, MUD++ (sorta), Murkle, or any of a half dozen
others.
: Aliases - if you'd use a linked list or array for aliases, it's no
: wonder you talk instead of writing - go look up hash tables. Have
: you in fact spent more than 3 hours writing C at all?:)
Linked lists fit very nicely under hash tables when buckets overflow.
: LPC is so far superior to C for coding a mud that youwouldn't _want_ to
: cut it out. What else is there to cut out? Nothing. Unless, of
: course, you are upset by it handling inventories, but try and tell me
: you can do a real cmd interpreter w/o some notion of what obs might
: want to hook what cmds?
I can, and I and many others have. That sort of linkage is determinable at
runtime. There's no need for the server to have any idea of what might be
going on other than optimisation.
: You want to lie about history, or you just have no knack for analogy?
Nahh, he's just not riding a hobby horse.
Martin Keegan
Matt Chatterley wrote:
> > 1) LPC is a general purpose language. It don't find it to be enough
> > mud-specific.
>
> This is IMHO a huge advantage - you can build an HTTP and FTP server into
A huge distraction, epitomising the triumph of presentation over
content.
Mk
-- "Be interesting! Stop the frusers before it's too late!"
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi
Matt Chatterley
On Wed, 16 Jul 1997, Martin Keegan wrote:
> Matt Chatterley wrote:
>
> > > 1) LPC is a general purpose language. It don't find it to be enough
> > > mud-specific.
> >
> > This is IMHO a huge advantage - you can build an HTTP and FTP server into
>
> A huge distraction, epitomising the triumph of presentation over
> content.
And another occurance of the terribly phenomenon of "Cool stuff" that
dubious point and purpose.
Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"Never enter an arsekicking contest with a porcupine."-Cohen The Barbarian
mor...@niuhep.physics.niu.edu
Matt Chatterley <ne...@itl.net> writes:
>On Wed, 16 Jul 1997, Martin Keegan wrote:
>> Matt Chatterley wrote:
>> > > 1) LPC is a general purpose language. It don't find it to be enough
>> > > mud-specific.
>> > This is IMHO a huge advantage - you can build an HTTP and FTP server into
>> A huge distraction, epitomising the triumph of presentation over
>> content.
>And another occurance of the terribly phenomenon of "Cool stuff" that
>dubious point and purpose.
Matt,
I'm confused, do you think an http server would be a good idea or not?
I'm not sure why you would want to write one from scratch but I can
certainly see why you might want one to access the help files, and
perhaps and ftp server to serve those files or graphics of some kind.
Robert
Mor...@physics.niu.edu
Real Men change diapers
Martin Keegan
Jon A. Lambert wrote:
> I don't follow your logic. How does the state of this newsgroup reflect
> the state of mudding? You should know that there is much more discussion
The state of this newsgroup has more to do with the general state of
Usenet than the state of mudding. I refer in particular to the fruser
efforts to hamper Alan Schwartz' efforts to make this group more
conducive to constructive discussion.
> carried on outside this newsgroup than within it. Someone posts a question
> about compiling a mud and they get an anal exam on their motivations and
> qualifications. So they don't bother posting anymore. Is it your position
> that newcomers should be discouraged from entering the ranks of mud
My position is that everyone should be encouraged, so long as they
can spell "you're" and "its" correctly.
> implementers? What exactly have you done that you feel puts you into
> the ranks of the elite? Can you point to any "promising" codebases or must
> everything be written from scratch? Could it be that you are just a
> codebase bigot from a "tiny" leaf of the mud tree who has a gripe against
> the DIKU family tree?
Ah yes. I was hoping The Mud Tree would help foster understanding
between groups of codebase bigots, but I'm still overjoyed to see that
it's adding a certain piquance to the Dikuhead/Tinybrain war. I say
this from my standpoint on a non-aligned and obscure branch of the
tree :)
> You state you would like to see more freely available code, then you bemoan
> the fact that someone would actually download it and, god forbid, actually use
> it.
It's a catch 22 situation. Bubba programmer sees crappy stock muds.
Bubba writes a scratch mud. Bubba releases mud, and it becomes stock.
What he's probably driving at is to achieve more diversity, by
having a wider variety of codebases available.
> What does the phrase "steady watering-down of 3 or 4 different mud types"
> mean? There are more than 50 freely available codebases. At least 20 of these
> have appeared in the last 6 years. I am also aware of a couple dozen ongoing
Yes, but in the last 6 years, most of those 50 are actually reworkings
of the Big Three. I reject the notion that this constitutes a
watering-down though. The damning statistic that he'll throw back at
us is that since 1990 (after the initial rush of "Can be like AberMUD,
but better" codebases (LP, Diku, Tiny, DUM, YAMud) and their
numerous descendents), the only new widely-used codebase family to
appear has been Mordor.
> > The Mud Tree needs width.
>
> No it needs depth. Inheritance is a requisite of evolution.
It needs diversity, not width or depth.
> "It's not the code, it's the game stupid" - J. Lambert (c)1997
> Heavily modified quote based on previously published
> material by M. Keegan (1996)
Ha!
HSMGF,
Martin Keegan
Matt Chatterley wrote:
>
> On Wed, 16 Jul 1997, Martin Keegan wrote:
>
> > Matt Chatterley wrote:
> >
> > > > 1) LPC is a general purpose language. It don't find it to be enough
> > > > mud-specific.
> > >
> > > This is IMHO a huge advantage - you can build an HTTP and FTP server into
> >
> > A huge distraction, epitomising the triumph of presentation over
> > content.
>
> And another occurance of the terribly phenomenon of "Cool stuff" that
> dubious point and purpose.
?? I think this sentence missing some words.
Matt Chatterley
On 16 Jul 1997 mor...@niuhep.physics.niu.edu wrote:
> Matt Chatterley <ne...@itl.net> writes:
> >On Wed, 16 Jul 1997, Martin Keegan wrote:
> >> Matt Chatterley wrote:
>
> >> > > 1) LPC is a general purpose language. It don't find it to be enough
> >> > > mud-specific.
>
> >> > This is IMHO a huge advantage - you can build an HTTP and FTP server into
>
> >> A huge distraction, epitomising the triumph of presentation over
> >> content.
>
> >And another occurance of the terribly phenomenon of "Cool stuff" that
> >dubious point and purpose.
>
> Matt,
> I'm confused, do you think an http server would be a good idea or not?
I'm somewhat ambivalent on the topic. If nothing else, it's a neat toy to
play with - it's by no means something that is 'essential' or required,
but otoh, it's easier than using the httpd running on the host to
distribute such things as help files. On the whole HTTP is probably a
good thing, but some other things being built in are probably not - I
believe GR expressed some disdain for FTP servers built into muds, and
I'm inclined to agree.
The original line was an attempt to point out that the flexibility (and
generic aim) of LPC is a great thing, albeit not a terribly good attempt.
> I'm not sure why you would want to write one from scratch but I can
> certainly see why you might want one to access the help files, and
> perhaps and ftp server to serve those files or graphics of some kind.
There are certainly reasons why you would want these things, and reasons
why you would not. The nice thing is that you have the capacity for it -
it's not like grabbing a stock base and either having or not having the
server, or the means to easily construct it.
Martin Keegan
Greg Munt wrote:
> A criticism of MudOS (I don't know about other drivers, but I presume
> it's the same for those too) I have heard, is that it has pretty much
> reimplemented unix. Comments on this?
Hmm... your posts could start "On <date> Martin Keegan wrote:" even when
not replying to me! :)
> Do you *really* need to build HTTP and/or FTP servers into your mud,
> anyway?
There's no decent open standard for a better interface yet.
Martin Keegan
Mackay / Katherine Amanda (COM) wrote:
> Ho-Sheng Hsiao <hsh...@freenet.columbus.oh.us> wrote:
> >Alberto BARSELLA (ish...@lsh01.univ-lille1.fr) wrote:
> >: Well....there are bad LPs out there, too.
> Yes, bt there are Sooooo many more bad dikus out there ("Yet Another
> Midgaard Mud" is _so_ passe ;)
You're forgetting that people crave MidgaardMUD and demand the presence
of Midgaard. Perhaps Tim Hollebeek could conduct a survey of pro- and
anti- Midgaard sentiments :)
> [Warning: Do NOT attempt this unless you have spent some time looking at
> the lib - if you remove /std/races/* you WILL hose yourself
> (/std/race/human is standard non-raced body), and there are some other
> gotchas too .. ]
/std/race/gotcha conjures up interesting images :)
Martin Keegan
John Adelsberger wrote:
> I've never even seen an aber, and can't speak about them. However, having
Well why don't you have a look round at what's available before
spouting off?
> played a bunch of MU* stuff and LP, and some Diku wannabes, and having
> coded some MU* and LP, I can say without any doubt that LP makes creating
I'd like to see the use of the term 'MU*' deprecated. In this case I
can't actually tell what you mean (not your fault). I'm assuming you
mean TinyMUD derivatives (those people who use the term MU* to mean
all muds are now condemned to have the stupid thing turned and used
on themselves, it would seem)
> the game easier than any of its alternatives, and that's what really
> counts.
No. Whether the game is any GOOD is what counts. It's the GAME, stupid!
Not how you make it, who plays it, or how fast its host happens to be.
> muse, muck, murpe, or whatever. I saw one mud that had emulation for
> the original TinyMUD, some Aber stuff of some sort(dont know how it worked)
> and stuff to run diku areas/mobs/etc, in addition to lima's lpscript and
> native lpc, and another virtual object format - it's too bad the thing
Are you making up facts to suit your argument again, as you did in
the NoCeM thread?
> probably closed(it's ISP just disappeared one day - the whole domain.
> I have no idea where it went or why:)
How convenient.
> By the way, yes, I am an LP man, but bigotry is senseless discrimination;
> I discriminate based on features/extensibility/utility/etc:-)
as opposed to discriminating on whether the finished product is any
good. Aha.
John Adelsberger
Martin Keegan <mar...@cam.sri.com> wrote:
: John Adelsberger wrote:
: > I've never even seen an aber, and can't speak about them. However, having
: Well why don't you have a look round at what's available before
: spouting off?
Because everything I've _ever_ heard about Aber suggests that it is a
perfectly good server that I wouldn't care for?:)
: can't actually tell what you mean (not your fault). I'm assuming you
: mean TinyMUD derivatives (those people who use the term MU* to mean
Your assumption is correct.
: No. Whether the game is any GOOD is what counts. It's the GAME, stupid!
: Not how you make it, who plays it, or how fast its host happens to be.
The game is primarily a function of the creativity of area coders unless
the admins have absolutely no life. Admins can set policy, theme, and
rules for overall look and feel and so on, but none are likely to be
able to support a mud financially if they have so much free time that
they write the whole thing themselves.
The reason I make that point is that extending an LP to do things the
admins hadn't anticipated is _far_ easier than doing the same to any
other game I've ever seen. Area coders aren't known for their
knowledge of complex programming, in general, but they nevertheless
are far more able to do truly original work(such as, say, a ranged
weapon in a game that has none to speak of,) in an LP than anywhere
else.
: Are you making up facts to suit your argument again, as you did in
: the NoCeM thread?
If you want to call me a liar, go ahead; the people who know me know
better, and if I spent my time worrying about what people like _you_
think, I'd just quit posting:) Besides, since we all know that such
emulation _is_ possible, such a lie would gain me nothing.
: > probably closed(it's ISP just disappeared one day - the whole domain.
: > I have no idea where it went or why:)
: How convenient.
Not really.
: > By the way, yes, I am an LP man, but bigotry is senseless discrimination;
: > I discriminate based on features/extensibility/utility/etc:-)
: as opposed to discriminating on whether the finished product is any
: good. Aha.
Yes, any of the servers out there, or any new one, _could_ be a good game.
Were I a player, this is what I'd care about. However, as a guy _designing_
muds, features, extensibility, utility, and so on matter to me in a server.
Yes, I _am_ a proficient C programmer, and I _could_ modify a diku derived
server or something similar, but it would be a waste of a lot of my time,
and I have other things to do before I die - I can achieve much more in
much less time by using a more featureful server.
John Adelsberger
Distribution:
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: John Adelsberger (j...@umr.edu) wrote:
: : And some stuff for figuring out _how_ to start up the mud specific code
: : you've written, and some terminal handling, and... and... like I said
: : in another post, it's called LP(MudOS in particular, but others exist:)
: Or MOO, ColdX, Interlude, MUD++ (sorta), Murkle, or any of a half dozen
: others.
I have yet to see ColdX, so I can't speak to it. MUD++? You're joking,
right? MOO is ok, if you can stand wearing out a gazillion keyboards'
@ keys prematurely just setting it up:) (Seriously, it really isn't as
utterly redesignable from an interface standpoint as LP, not even close.)
I never heard of Interlude or Murkle, so I'll just keep quiet about them.
: : Aliases - if you'd use a linked list or array for aliases, it's no
: : wonder you talk instead of writing - go look up hash tables. Have
: : you in fact spent more than 3 hours writing C at all?:)
: Linked lists fit very nicely under hash tables when buckets overflow.
Since this comment has _nothing_ to do with the original comment that
was made regarding aliases and linked lists, I'll pretend you're trying
to be funny:)
: I can, and I and many others have. That sort of linkage is determinable at
: runtime. There's no need for the server to have any idea of what might be
: going on other than optimisation.
Ok, I suppose I should put it this way, since I know it can be done:
It is inefficient and generally harder to do anyway - why on earth would
anyone want to? Granted, it might make things a bit more uniform in
appearance, but so would coding standards:)
Matt Chatterley
On Wed, 16 Jul 1997, Martin Keegan wrote:
> Matt Chatterley wrote:
> >
> > And another occurance of the terribly phenomenon of "Cool stuff" that
> > dubious point and purpose.
>
> ?? I think this sentence missing some words.
To coin a phrase. "Oops".
Try:
And another occurance of the terrible phenomenon of "cool stuff" that has
a dubious point and purpose.
Jon A. Lambert
Matt Chatterley <ne...@itl.net> wrote in article <Pine.SOL.3.91.970716155025.6520B-100000@hades>...
> On Wed, 16 Jul 1997, Martin Keegan wrote:
>
> > Matt Chatterley wrote:
> >
> > > > mud-specific.
> > >
> > > This is IMHO a huge advantage - you can build an HTTP and FTP server into
> >
> > A huge distraction, epitomising the triumph of presentation over
> > content.
>
> dubious point and purpose.
>
of content, so you can effectively shovel more at the unsuspecting user.
I have a theory that the minor addition of a pattern of blinking lights would
cause a hypnotic effect on users which would force them to stay forever.
Any volunteers?
Much of muddom rests on the phenomenon of "cool stuff". You call into
question the dubious point and purpose of hobbyist muds. To that
I can only respond - bwahhh ptuuhe!
JL
Jon A. Lambert
Matt Chatterley <ne...@itl.net> wrote in article <Pine.SOL.3.91.970717203411.14466A-100000@hades>...
>
> Theres no doubt that presentation is important. You need to have some
> content first, of course. Hmm. Hypnotism as a user-grabbing device.. heh.
>
I would agree that there ain't much difference between a sheep and a
sheep in a dress. A sheep in a dress might be more appealing.
<insert comebacker here>
> Cool stuff for its own sake ("We have this cool yet utterly useless
> feature!") isn't a good thing, IMHO. Cool stuff that serves some purpose
> is by definition different. Mind you, it's probably not so cool either.
>
Ok take for instance my implementation of tattoos, scars, facial expressions
and item engraving and painting. Even if at the tactical level they added
nothing and effected nothing; they could well be described as frivolous fluff (tm).
Yet the appeal to player/character sense of self and customization is generally
positive not easily quantified.
> On the original point - having the capacity for very generic work within
> your mud driver (LPs being the case in point) is good, because you are
> not limited soley to working upon the linear concept of 'a mud', and can
> do abstract things that something more restrictive might disallow.
>
I wouldn't disagree with this.
> Of course, the main up of LPs (I haven't mentioned cold here, because I
> don't wish to try and discuss something I know *nothing* about at this
> time), is that LPC is far simpler to learn than C, as far as I can tell.
>
I know just enough about both to state that they are conceptually similar.
I don't wish to raise the ire of either servers' proponents who can
likely point out dozens of differences.
JL
Matt Chatterley
On 17 Jul 1997, Jon A. Lambert wrote:
> There exists the possibility that presentation can increase the consumption
> of content, so you can effectively shovel more at the unsuspecting user.
> I have a theory that the minor addition of a pattern of blinking lights would
> cause a hypnotic effect on users which would force them to stay forever.
> Any volunteers?
Theres no doubt that presentation is important. You need to have some
content first, of course. Hmm. Hypnotism as a user-grabbing device.. heh.
> Much of muddom rests on the phenomenon of "cool stuff". You call into
> question the dubious point and purpose of hobbyist muds. To that
> I can only respond - bwahhh ptuuhe!
Nyuk, Nyuk, to you!
Cool stuff for its own sake ("We have this cool yet utterly useless
feature!") isn't a good thing, IMHO. Cool stuff that serves some purpose
is by definition different. Mind you, it's probably not so cool either.
On the original point - having the capacity for very generic work within
your mud driver (LPs being the case in point) is good, because you are
not limited soley to working upon the linear concept of 'a mud', and can
do abstract things that something more restrictive might disallow.
Of course, the main up of LPs (I haven't mentioned cold here, because I
don't wish to try and discuss something I know *nothing* about at this
time), is that LPC is far simpler to learn than C, as far as I can tell.
Regards,
Jon A. Lambert
John Adelsberger <j...@umr.edu> wrote in article <5qkqup$29a$4...@news.cc.umr.edu>...
> Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
> : John Adelsberger (j...@umr.edu) wrote:
>
> : : And some stuff for figuring out _how_ to start up the mud specific code
> : : you've written, and some terminal handling, and... and... like I said
> : : in another post, it's called LP(MudOS in particular, but others exist:)
>
> : Or MOO, ColdX, Interlude, MUD++ (sorta), Murkle, or any of a half dozen
> : others.
>
> I have yet to see ColdX, so I can't speak to it. MUD++? You're joking,
> right? MOO is ok, if you can stand wearing out a gazillion keyboards'
> @ keys prematurely just setting it up:) (Seriously, it really isn't as
> utterly redesignable from an interface standpoint as LP, not even close.)
> I never heard of Interlude or Murkle, so I'll just keep quiet about them.
>
Well I would concur with the Mud++ (sorta). The project is far from
complete. Initially it had the appearance of DIKU in C++ clothing, yet
it has recently taken a number of interesting turns in the area of
programmability.
Murkle? Someone send me a pointer.
It has been 1 and 1/2 years since I've looked at LP, so some comments
on why I didn't choose it.
1) I want a complete and utterly persistent environment under the cover.
2) Multi-threading.
Note: Hollebeek and Reese do provide good arguments against the usefulness
of such constructs and I respect their viewpoint. However I disagree.
3) Backed by a fully functional relational database, with recovery and
full transactional control.
Note: George Reese has also provided convincing arguments as to the suitability
of relational DBs in this area. I happen to have other ideas. More fool me. ;)
4) The conceptual distinction of class vs object.
Note: This may well have changed in LP. However I am still at odds with
Cold and MOO in this area.
These may well be pet peeves. And I may well be more interested in
seeing the theoretical aspects at work. I think it's time well wasted
though. ;)
JL
Derek Harding
>Greg Munt wrote:
>
>> A criticism of MudOS (I don't know about other drivers, but I presume
>> it's the same for those too) I have heard, is that it has pretty much
>> reimplemented unix. Comments on this?
Why is that a criticism? So the command interface is similar to Unix, is
that a problem? It would have been a problem to need lots of Unix user
accounts to run a mud. It simply isn't desirable, but if you want to use the
Unix filesystem (which is the basis of just about every Unix service) you
would need this.
>
>> Do you *really* need to build HTTP and/or FTP servers into your mud,
>> anyway?
No, you don't have to, that's why many muds use separate http and ftp
daemons. However, there are some advantages to using lpc ones, for a start
they can easily use existing lpc code to provide web content. For an example
of a site using an lpc httpd and which has almost its entire content
dynamically generated from the mud (much of it using existing mud code)
visit Discworld at http://discworld.imaginary.com:5678/
Derek (Ceres@Discworld)
--
Derek Harding
Technical Director, Fusion Interactive
http://www.fusioni.com/~derek/
[email address deliberately mangled just change v to c]
Derek Harding
Derek Harding
Matt Chatterley
On 17 Jul 1997, Jon A. Lambert wrote:
> Matt Chatterley <ne...@itl.net> wrote in article <Pine.SOL.3.91.970717203411.14466A-100000@hades>...
> >
> > Theres no doubt that presentation is important. You need to have some
> > content first, of course. Hmm. Hypnotism as a user-grabbing device.. heh.
> >
>
> I would agree that there ain't much difference between a sheep and a
> sheep in a dress. A sheep in a dress might be more appealing.
This depends on your view towards sheep. The most likely difference here
is probably that you could make a bad movie about a sheep in a dress.
> > Cool stuff for its own sake ("We have this cool yet utterly useless
> > feature!") isn't a good thing, IMHO. Cool stuff that serves some purpose
> > is by definition different. Mind you, it's probably not so cool either.
> >
>
> Ok take for instance my implementation of tattoos, scars, facial expressions
> and item engraving and painting. Even if at the tactical level they added
> nothing and effected nothing; they could well be described as frivolous fluff (tm).
> Yet the appeal to player/character sense of self and customization is generally
> positive not easily quantified.
Well, such things add something in this example. It depends on the
context here - if there is a slant in the game whereby someone being
scarred provides an interesting impetus for something (for instance, a
roleplaying or pseudo roleplaying environment rather than one which could
be classified as a 'powermud'), then it's not really useless.
If you had a mud where the appearance of a character played no part - for
instance, a powermud where very few players look at each other, and
typical monster descriptions are "A big dragon!" (yes! these places
exist!), having scars pop up on characters is "Cool stuff" (arguably),
but does nothing whatsoever (except possibly confuse those who encounter
it for the first time, and generate the applicable feedback).
> > On the original point - having the capacity for very generic work within
> > your mud driver (LPs being the case in point) is good, because you are
> > not limited soley to working upon the linear concept of 'a mud', and can
> > do abstract things that something more restrictive might disallow.
> >
> I wouldn't disagree with this.
I'd think noone can really disagree with this as a concept. Stating it as
a reason for LPs being gods gift to muds would of course be suitable food
for a ridiculous flamewar ;)
> > Of course, the main up of LPs (I haven't mentioned cold here, because I
> > don't wish to try and discuss something I know *nothing* about at this
> > time), is that LPC is far simpler to learn than C, as far as I can tell.
> >
> I know just enough about both to state that they are conceptually similar.
> I don't wish to raise the ire of either servers' proponents who can
> likely point out dozens of differences.
Agreed. Learning LPC has certainly helped me grasp the basics of C, at
any rate. :)
Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"Doublethink means the power of holding two contradictory beliefs in one's
mind simultaneously, and accepting both of them." -George Orwell
Maddy
: >> Matt Chatterley wrote:
:
: >> > > 1) LPC is a general purpose language. It don't find it to be enough
: >> > > mud-specific.
:
: >> > This is IMHO a huge advantage - you can build an HTTP and FTP server
: >> > into
:
: >> A huge distraction, epitomising the triumph of presentation over
: >> content.
: >And another occurance of the terribly phenomenon of "Cool stuff" that
: >dubious point and purpose.
: Matt,
: I'm confused, do you think an http server would be a good idea or not?
: I'm not sure why you would want to write one from scratch but I can
: certainly see why you might want one to access the help files, and
: perhaps and ftp server to serve those files or graphics of some kind.
Why would you bother putting a httpd in a mud to view help files? Surely
just opening the file would be easier? Or have I just misunderstood what
you meant, given the context of the thread? Writing the helpfiles in html
is a good idea, as it means they can be viewed using the machines webserver
or nicely formatted by the mud (or if you're really twisted have a search
engine too).
I do see the use of an ftp daemon tho, being able to upload files (such as
freshly written code) is definitely easier than using the built in editors
most muds seem to have. Although you could just as easily use the one that
serves the machine instead - reduce the foot print of the mud.
Maddy
--
The Gathering ------------------------------------------------------------
Telnet: tg.spods.dcs.kcl.ac.uk 5000
URL : http://tg.spods.dcs.kcl.ac.uk/
Email : gath...@zippy.spods.dcs.kcl.ac.uk
--------------------------------------------------------------------------
John Adelsberger
Derek Harding <de...@fusioni.vom> wrote:
: Why is that a criticism? So the command interface is similar to Unix, is
: that a problem? It would have been a problem to need lots of Unix user
: accounts to run a mud. It simply isn't desirable, but if you want to use the
: Unix filesystem (which is the basis of just about every Unix service) you
: would need this.
Actually, it could be done with one account and a wacked out shell, but
it would still suck balls.
--
John J. Adelsberger III
j...@umr.edu
"There are none so blind as those who will not see." - Kansas
John Adelsberger
Distribution:
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: There's an implicit assumption in the LP Libs that user changes to the world
: will but only not be permanent, but that the admin will not not want all world
: changes to be permanent.
: What's permanent? Example: Bubba player drops a pebble in a certain room.
: That pebble will remain in that room for all eternity, across crashes,
: reboots, etc until something within the game (re)moves it.
Your statement is precisely correct; you simply haven't given it enough
thought. See below:)
: Its a design choice, and a valid one, but if you're game is explicitly geared
: around permanancy, then its a bloody annoying one to recode about.
If you want permanancy, you need more differences than that one - you need
a whole new lib, which you would write with that in mind. Mudlibs are
written for muds, not for theoretical perfection(in general, anyway.)
As such, if you want something that doesn't exist, you write it or use
a different server, but this is hardly a criticism of MudOS or other
LPs.
Huibai
John Adelsberger:
Chris Lawrence::
: : That pebble will remain in that room for all eternity, across
: : crashes, reboots, etc until something within the game (re)moves it.
: Your statement is precisely correct; you simply haven't
: given it enough thought. See below:)
Neutrally, I recommend you not presume to know how much
thought someone else has invested into any given concept.
: If you want permanancy, you need more differences than that one -
: you need a whole new lib, which you would write with that in mind.
: Mudlibs are written for muds, not for theoretical perfection(in general,
: anyway.) As such, if you want something that doesn't exist, you write
: it or use a different server, but this is hardly a criticism of MudOS or
: other LPs.
Your initial posts in this thread strayed from "where, the holes we
missed?" to "LPC can tackle everything". The above parag makes
me think you've come full circle from that view.
: "There are none so blind as those who will not see." - Kansas
An amazing group to go back and listen to the words.
Don't know if I've ever got more value out of $4.95 at a
truckstop just for wanting to hear "Dust in the Wind".
ObOnTopic: Muds are not done evolving; some pruning has been
long overdue, in my opinion, of the stale old 'tree' everyone has
been rushing to get their name carved onto now. I see features
being evolved on stock/derivative muds and breakthroughs lying
in wait for some few of the scratchers.
Salud,
- John G.
--
John Greenawalt (as...@pixi.com)
"I came, I saw, she conquered." \ /
(The original Latin seems to have been garbled) /
-R.Heinlein,_TimeEnoughForLove_ / \
Derek Harding
>: >> content.
>
>: >And another occurance of the terribly phenomenon of "Cool stuff" that
>: >dubious point and purpose.
>
That all depends. I've looked at a number of mud websites and many have very
little of value. However, at Discworld we use our website to provide a well
formatted hypertext interface to the help system, to the 'finger' command,
to the player run newspaper, to the FAQ, to the bulletin boards, to
information about the creator (immortal) organisation and administrative
structure.
We also provide a variety of information for new players which I believe is
becoming increasingly important since telnet is one of the less well-known
services on the internet these days.
And, our site does look good (IMHO).
The presentation over content argument can be applied to a poorly
implemented site on any subject. I believe that this, like most other
subjects, can benefit from a well designed site with useful information
presented in an easy to digest, easty to nagivate manner.
ps., god knows what my news client did with my previous post, serves me
right for running beta software I guess :)
Derek (Ceres@Discworld, http://discworld.imaginary.com:5678/)
Matt Chatterley
On Sat, 19 Jul 1997, Derek Harding wrote:
> >: Matt Chatterley <ne...@itl.net> writes:
> >:
> >: >And another occurance of the terribly phenomenon of "Cool stuff" that
> >: >dubious point and purpose.
> >
>
> That all depends. I've looked at a number of mud websites and many have very
> little of value. However, at Discworld we use our website to provide a well
> formatted hypertext interface to the help system, to the 'finger' command,
> to the player run newspaper, to the FAQ, to the bulletin boards, to
> information about the creator (immortal) organisation and administrative
> structure.
Exactly - it depends, which is why I stated the purpose of such things as
being 'dubious' - in many cases, muds build in HTTP daemons, and use them
exactly as they would use their normal website privaleges there or
somewhere else. There are of course the opposing cases (Discworld, and I
believe Nightmare are good examples) where the HTTP daemon built into the
mud is used to provide things that it would be very hard to put on a
normal website, due to the amount of interconnectivity withy the actual
mud that would be required.
> We also provide a variety of information for new players which I believe is
> becoming increasingly important since telnet is one of the less well-known
> services on the internet these days.
>
> And, our site does look good (IMHO).
>
> The presentation over content argument can be applied to a poorly
> implemented site on any subject. I believe that this, like most other
> subjects, can benefit from a well designed site with useful information
> presented in an easy to digest, easty to nagivate manner.
Yes - I can't deny this (well, not while being at all reasonable).
Presentation is definitely important - but you have to have a reasonable
content to present well in the first place. This isn't relevant to the
debate at hand - the purpose/point in such things as built-in HTTP
daemons - any mud can build a very good website without having an HTTP
daemon physically written into the mud itself, and if thats what they
want to do, using something like Apache on the machine itself is probably
better. If they want special things which the mud needs to take care of..
THEN having their own HTTP run as part of the mud works well.
> ps., god knows what my news client did with my previous post, serves me
> right for running beta software I guess :)
<g>
John Adelsberger
Distribution:
Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
: Matt Chatterley <ne...@itl.net> wrote:
: :On 11 Jul 1997, Alberto BARSELLA wrote:
: And this is a significant point. The real advantage is runtime editing...
: which a good dynaload library can solve for you. (Fortunately, I happen
: to have designed myself just such a library...)
If it's secure and can prevent runtime edited/created stuff from crashing
the system, fine, but if you are doing dyanamic linkage into a compiled
binary, be damn sure before you say it, b/c it is amazing how easily
you can make a slipup doing stuff like that.
: :inventory. Be careful with definitions of terms - LP is the most flexible
: :mud server, and can be literally anything in an incarnation. Most
: :flexible that I am aware of, I should say.
: Check out ColdCore.
I haven't yet, but if it has found a way to be more flexible than a system
that can literally look like and do anything you're willing to write code
for, I congratulate the authors.
: I follow the philosophy of "do the hardcore stuff in a hardcore language
: (C++) and the simple stuff in a simple language (Pipcode, the internal
: pointer-tabled language of Physmud)" and find it works quite well. If
: I wanted an HTTP or FTP server _in_ my mud (why on earth?) I would use
: C++, and the linkage library, and hook it into the messaging system. If
C++ would make doing HTTP or FTP immeasurably more difficult than doing
them in LPC. I can't speak for pipcode, b/c I've never seen it.
: there was a flaw in the code, it would kill the new execution thread,
: then throw me an exception. Next try.
Question is, can it throw such exceptions and then recover properly? Not
just stay running, but deallocate all memory appropriately, _accurately_
reset state, and so on? Maybe so; it isn't impossible, just very, very
detailed and exacting work.
: The thing that bugs me is people thinking that its got to be either like
: LP (or Tiny) or like Diku. Bleah.
It doesn't have to be, but the question is, what's better, and why? If
you have an answer, I am not being facetious when I say I want to see and
hear about it, but if you're just talking about being different to talk,
there's no point.
: :I've not had time to look into the Cold project either. :(
: I reccomend you do so.
I intend on it myself, but I doubt it meets one key requirement I have,
which is that there be more than 100 people worldwide who are
familiar enough with it to be able to work _competently_ with it, such
that I can find people to work with me on it:)
(Don't argue that there are; even if it's true, and it may be, there
certainly are nowhere near as many who have even heard of Cold as there
are who are _good_ at coding under MudOS:)
--
John J. Adelsberger III
j...@umr.edu
"There are none so blind as those who will not see." - Kansas
John Adelsberger
Distribution:
Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
: John Adelsberger <j...@umr.edu> wrote:
: No, it is most emphatically NOT called LP. LP is a server, with a whole
: $#!+load of baggage, and a lot of basic design flaws that cannot be, in
: any manner, removed or repaired.
Name them. You keep saying this, but your verbal excrement does not
contain any facts as yet.
: Physmud++ will, if I ever get it cleaned up enough for release, include a
: series of plug in class libraries, from containers to string parsers to
: message handlers and thread sockets and network (socket) IO managers, all
: designed to be freely and safely editable without breaking everything else.
: This is a remote concept from that of LP(C).
If it contains C/C++ code, almost nobody(relative to the number of
competent coders in LPC, for instance) will be able to modify it.
I would have thought that the Diku experience(lots of muds, very
little originality, most short-lived) would have proven this point
by now.
: No. No, the driver is still design baggage. What if I wanted a lockless,
: thread safe database? Ref counting based GC? Pure geographical
: distribution? A system that models complex physics? (LP was not nearly
: efficient enough for my needs... which is why I wrote my own system, and
: tailored, in a native language, those things that needed tailoring.)
Threadsafe and lockless? I'd like to see such a system, since it is
theoretically impossible unless your definition of lockless is different
from everyone elses. Ref counting? Compile in the MudOS devel stuff;
it's there. Geographical distribution? What do you mean by this term?
Complex physics? You could code it, but if your intent is to produce
a game, you're wasting your time.
: No, he's not. All the really creative people are doing custom bases,
: some driver based, some component library based, many impossible to
: pull off in a fixed design (relatively) model like LP. Now, LP is many
: orders of magnitude beyond Diku, but it is still one of those 80s
: things Greg was talking about. We're talking about stepping beyond the
: limitations of LP, and creating something radically different.
If you can actually demonstrate this instead of discussing it in vague
terms that make it impossible to discuss or prove/disprove, fine.
Otherwise, your claims are irrelevant to sane discussion.
: Three reasons... #1, it hasn't been done "right" for everyone's needs,
: #2, it can't look/feel/etc (esp. etc) like MY system at its most extreme
: (I'd just like to SEE someone pull off a three body system in LPC... you
: need lagrangian and fourier support), and #3, it is an all or nothing
Three body system? From what field does this term originate? If you mean
physics stuff, nobody doing a game cares, excepting you. Even then, you
can do lagrangian and fourier support w/o too much difficulty.
: proposition... which means you can't get rid of the stuff in the driver
: that has no bearing on you. (move something from here to there? But I
: don't WANT that to be possible... I use barrier transitions)
You _can_ in fact modify the driver, and you _can_ in fact leave out
support you don't want. Are you talking out your small end?
: I dunno. I've seen a lot of LPs. Worked on more than a couple. And
: you know what? It hasn't really produced the grandest ideas I've
: seen. In fact, of the ten greatest muds, designwise (setting, mood,
: story, immersion) that I have ever seen, three were Diku dirivatives,
: and three were custom. And two were tiny based. Do the math.
I'd like to know what your top ten list is, because I've yet to see _one_
diku that was worth the effort of logging in, as far as gameplay goes.
Tiny I can't speak for, but in general it is a better system than Diku.
The future, however, belongs to MOO, if it continues to be developed,
LP, Cold, and similar systems.
Huibai
John G. and his trusty online dictionary respond:
John Adelsberger delivered:
: Name them. You keep saying this, but your verbal
: excrement does not contain any facts as yet.
You offer no facts, either, John J.
ad hominem argument (argument against the person)
The fallacy of supposing that a proposition should be denied
because of some flaw in the person who affirms it. In its abusive
form, ad hominem is a direct (and often inflammatory) attack on
the appearance, character, or personality of the individual.
: If it contains C/C++ code, almost nobody(relative to the number of
: competent coders in LPC, for instance) will be able to modify it.
LPC contains C code.
: Threadsafe and lockless? I'd like to see such a system, since
: it is theoretically impossible unless your definition of lockless is
: different from everyone elses.
"theoretically impossible" = "as far as I can think of"
"everyone elses" = "my opinion"
: Complex physics? You could code it, but if your intent is to
: produce a game, you're wasting your time.
Your post is loud in sound and fury, yet signifying nothing.
Be careful how you toss about the words "wasting time".
: If you can actually demonstrate this instead of discussing it in
: vague terms that make it impossible to discuss or prove/disprove,
: fine. Otherwise, your claims are irrelevant to sane discussion.
Re-read this and think 'discuss' and see if you don't laugh your
ass off. You've already talked your ass off (and my ears too).
In*ane" (?), a. [L. inanis.] Without contents; empty; void of sense
or intelligence; purposeless; pointless; characterless; useless.
: Three body system? From what field does this term originate? If
: you mean physics stuff, nobody doing a game cares, excepting you.
"nobody" = "John J. Adelsberger III"
A three body system is obviously where a player deals with more
than one body - either controlling multiple bodies or Being multiple
bodies. A half moment's thought before hitting the 'inane reply'
button would reveal that.
Closing the throttle, and back on topic:
LPC is strong in its ease of programming for code-illiterate folks.
Not so easily rewired if you don't know a thing about programming
or C, though. You could 'theoretically' take _any_ codebase and
rip enough out of it and refill it with compost to make it resemble
whatever you like. Because you could theoretically do it in LPC
doesn't mean it's the most appropriate or efficient way to do it, and
therefore it isn't testimony to the flexibility of LPC.
The thread is looking for alternatives to the perceived 'failure' thus
far of existing designs. I don't recall any explicit invitations to stage
your own defense of a platform/language/soapbox which is NOT
under siege.
Jon A. Lambert
John Adelsberger <j...@umr.edu> wrote in article <5qrdng$1ab$3...@news.cc.umr.edu>...
> Distribution:
>
> Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
> : John Adelsberger <j...@umr.edu> wrote:
>
> : No, it is most emphatically NOT called LP. LP is a server, with a whole
> : $#!+load of baggage, and a lot of basic design flaws that cannot be, in
> : any manner, removed or repaired.
>
> contain any facts as yet.
Actually there have been several instances in these threads where "flaws"
have been pointed out. In any non-trivial program design decisions
will have been made to achieve a desired end to the point where
modification of that program to correct these flaws is unproductive.
Your conception of what the game/mud should be capable of seems to be driven
by and limited to the capabilities of the server. For some of us it is the
other way around.
> : Physmud++ will, if I ever get it cleaned up enough for release, include a
> : series of plug in class libraries, from containers to string parsers to
> : message handlers and thread sockets and network (socket) IO managers, all
> : designed to be freely and safely editable without breaking everything else.
> : This is a remote concept from that of LP(C).
>
> If it contains C/C++ code, almost nobody(relative to the number of
> competent coders in LPC, for instance) will be able to modify it.
> I would have thought that the Diku experience(lots of muds, very
> little originality, most short-lived) would have proven this point
> by now.
>
This tends to revive that ancient debate on the maintainability of
object oriented code versus procedural code. My best instincts tell
me that a Physmud server would be more easily maintained by a third
party than a server written in procedural C. Competency in a language
is certainly a requirement. The Diku experience may well be an indicator
as to the maintainability of procedural spaghetti rather than a damnation
of hardcoding in general.
> : No. No, the driver is still design baggage. What if I wanted a lockless,
> : thread safe database? Ref counting based GC? Pure geographical
> : distribution? A system that models complex physics? (LP was not nearly
> : efficient enough for my needs... which is why I wrote my own system, and
> : tailored, in a native language, those things that needed tailoring.)
>
> Threadsafe and lockless? I'd like to see such a system, since it is
> theoretically impossible unless your definition of lockless is different
> from everyone elses.
No it isn't theoretically impossible. It can perhaps be proven semantically
impossible by students of language or philosophy. It can be argued that any
server which provides for task failure has at its core a "locking" mechanism.
Generally these semantic arguments have little use in computer science.
Let's just say a non-locking model differs enough from a traditional locking
model that the expression of it using the term lockless is sufficient and
accurate.
However, I do have doubts whether the lockless model is more efficient
overall than traditional locking models. I am still open minded about
it.
> Complex physics? You could code it, but if your intent is to produce
> a game, you're wasting your time.
I suspect that many flight simulators and space simulations don't fall
under your conception of game. Complex economics, biology, politics,
genetics and AI are other fine ways for one to waste their time.
Sure you could code these things, but no self-respecting mudder wants to
see this sort of SIM-crap polluting the game. ;)
I happen to believe that concurrency and persistence make these constructs
easier to develop. I don't see how LP servers are better able to effect
these concepts than other alternatives.
> : No, he's not. All the really creative people are doing custom bases,
> : some driver based, some component library based, many impossible to
> : pull off in a fixed design (relatively) model like LP. Now, LP is many
> : orders of magnitude beyond Diku, but it is still one of those 80s
> : things Greg was talking about. We're talking about stepping beyond the
> : limitations of LP, and creating something radically different.
>
> If you can actually demonstrate this instead of discussing it in vague
> terms that make it impossible to discuss or prove/disprove, fine.
> Otherwise, your claims are irrelevant to sane discussion.
>
And so are your earlier claims that all creative people are working on
LPs. Touché.
> : proposition... which means you can't get rid of the stuff in the driver
> : that has no bearing on you. (move something from here to there? But I
> : don't WANT that to be possible... I use barrier transitions)
>
> You _can_ in fact modify the driver, and you _can_ in fact leave out
> support you don't want. Are you talking out your small end?
And we come full _Circle_ back to hard-rewiring a server for a particular
and imperative need.
JL
Maddy
Huibai (as...@pixi.com) wrote:
: John G. and his trusty online dictionary respond:
: Closing the throttle, and back on topic:
: LPC is strong in its ease of programming for code-illiterate folks.
: Not so easily rewired if you don't know a thing about programming
: or C, though. You could 'theoretically' take _any_ codebase and
: rip enough out of it and refill it with compost to make it resemble
: whatever you like. Because you could theoretically do it in LPC
: doesn't mean it's the most appropriate or efficient way to do it, and
: therefore it isn't testimony to the flexibility of LPC.
: The thread is looking for alternatives to the perceived 'failure' thus
: far of existing designs. I don't recall any explicit invitations to stage
: your own defense of a platform/language/soapbox which is NOT
: under siege.
Well most servers (ie LP & Diku) all require some kind of complex
programming language to code for them. LPC is just like C with knobs on and
you're average code illiterate person isn't going to have any more luck with
it than normal C.
If we really wanted to make programming muds easy - using a subset of
english (for example) would be better? EG
If the object is here then move object into self, otherwise print "That
isn't here".
The above is far easier understood by someone who doesn't know a thing about
programming compared to the following.
if(object->location==self->location)
{
object->location=self->location;
}
else
{
print(self,"That isn't here");
}
Which although, it's fairly simple would require you to understand what '=='
meant.
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Threadsafe and lockless? I'd like to see such a system, since it is
: theoretically impossible unless your definition of lockless is different
: from everyone elses.
Nope, not impossible -- its been done for years in the DB world, tho the
typical solution renders the commit process single-threaded under the
covers.
: Complex physics? You could code it, but if your intent is to produce
: a game, you're wasting your time.
Hit DejaNews and look at some of Nathan's previous traffic on PysMud++. He's
looking to model the basic laws of physics (gravity, inertia, momentum, etc)
as a base part of the definition of his world(s).
: I'd like to know what your top ten list is, because I've yet to see _one_
: diku that was worth the effort of logging in, as far as gameplay goes.
Legend for one.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Distribution:
: Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
: : Matt Chatterley <ne...@itl.net> wrote:
: : :On 11 Jul 1997, Alberto BARSELLA wrote:
: : And this is a significant point. The real advantage is runtime editing...
: : which a good dynaload library can solve for you. (Fortunately, I happen
: : to have designed myself just such a library...)
: If it's secure and can prevent runtime edited/created stuff from crashing
: the system, fine, but if you are doing dyanamic linkage into a compiled
: binary, be damn sure before you say it, b/c it is amazing how easily
: you can make a slipup doing stuff like that.
Have a looka t the journal of the ACM as of a couple months ago. Look for
Kansas/Oz article. Essentially a set of Sun engineers extended the MOO base
such that as long as the server still continues to run, *ANYTHING* could be
done to the MUDLib, encluding crashing the entire world, while stilling
allowing users to connect and debug the world.
A cute solution, and really trivial once you think of it.
: C++ would make doing HTTP or FTP immeasurably more difficult than doing
: them in LPC. I can't speak for pipcode, b/c I've never seen it.
There are several C++ class libraries available which reduce HTTP and FTP
to a simple class with half a dozen methods. The question becomes a no-op.
Re: ColdX, ColdCore, Genesis etc.
: I intend on it myself, but I doubt it meets one key requirement I have,
: which is that there be more than 100 people worldwide who are
: familiar enough with it to be able to work _competently_ with it, such
: that I can find people to work with me on it:)
Whoops. You lost that bet.
: (Don't argue that there are; even if it's true, and it may be, there
: certainly are nowhere near as many who have even heard of Cold as there
: are who are _good_ at coding under MudOS:)
Popularity does not a good system make.
Chris Lawrence (Contra)
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : There's an implicit assumption in the LP Libs that user changes to the
: : world will but only not be permanent, but that the admin will not not
: : want all world changes to be permanent. What's permanent? Example:
: : Bubba player drops a pebble in a certain room. That pebble will remain
: : in that room for all eternity, across crashes, reboots, etc until
: : something within the game (re)moves it.
: Your statement is precisely correct; you simply haven't given it enough
: thought. See below:)
Having done a little more research, I disagree.
: : Its a design choice, and a valid one, but if you're game is explicitly
: : geared around permanancy, then its a bloody annoying one to recode about.
: If you want permanancy, you need more differences than that one - you need
: a whole new lib, which you would write with that in mind.
The underlieing fact is that while you can write a MUDLib to do this, LP
itself is not geared to offer permanancy. It gets to be a real PITA. You'll
need to explicitly log everything, and then provide ressurection code to
rebuild the world on re-load. Not fun.
The converse is a server which presumes from the design start that
everything is permanent. Permenancy at that point is of course implicit.
Making something impermanent is comparitively easy by adding a case to reset
the object.
LP does not offer the ability to by default make *everything* permanent
without any other code or attention by area builders.
: Mudlibs are
: written for muds, not for theoretical perfection(in general, anyway.)
: As such, if you want something that doesn't exist, you write it or use
: a different server, but this is hardly a criticism of MudOS or other
: LPs.
Not a criticism, a design limitation. Horses for courses, and the tool
for the job.
George Reese
: : Distribution:
: : Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : : There's an implicit assumption in the LP Libs that user changes to the
: : : world will but only not be permanent, but that the admin will not not
: : : want all world changes to be permanent. What's permanent? Example:
: : : Bubba player drops a pebble in a certain room. That pebble will remain
: : : in that room for all eternity, across crashes, reboots, etc until
: : : something within the game (re)moves it.
: : Your statement is precisely correct; you simply haven't given it enough
: : thought. See below:)
: Having done a little more research, I disagree.
Err, all real mudlibs these days offer permanence.
: : : Its a design choice, and a valid one, but if you're game is explicitly
: : : geared around permanancy, then its a bloody annoying one to recode about.
: : If you want permanancy, you need more differences than that one - you need
: : a whole new lib, which you would write with that in mind.
: The underlieing fact is that while you can write a MUDLib to do this, LP
: itself is not geared to offer permanancy. It gets to be a real PITA. You'll
: need to explicitly log everything, and then provide ressurection code to
: rebuild the world on re-load. Not fun.
It is less of a pain having it in the driver? You should look at
existing LP code bases, they manage permanence just fine. The
important thing is that cres do not have to worry about permanence issues/
: The converse is a server which presumes from the design start that
: everything is permanent. Permenancy at that point is of course implicit.
: Making something impermanent is comparitively easy by adding a case to reset
: the object.
Define everything. Not everything is permanent in any system. You
have to design what you think is important.
: LP does not offer the ability to by default make *everything* permanent
: without any other code or attention by area builders.
That is an unfair comparison. LP is not a game, it is a language.
All LP systems offer a way to make *interesting things* permanent.
Making everything permanent is trivial.
DGD, in fact, does offer default complete permanence.
: : Mudlibs are
: : written for muds, not for theoretical perfection(in general, anyway.)
: : As such, if you want something that doesn't exist, you write it or use
: : a different server, but this is hardly a criticism of MudOS or other
: : LPs.
: Not a criticism, a design limitation. Horses for courses, and the tool
: for the job.
I think you are criticising here from a weak foundation. Permanence
is absolutely NOT a limitation of LPMud.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal
Martin Keegan
Jon A. Lambert wrote:
>
> Martin Keegan <mar...@cam.sri.com> wrote in article <33CCAF...@cam.sri.com>...
> > Jon A. Lambert wrote:
> >
> > The state of this newsgroup has more to do with the general state of
> > Usenet than the state of mudding. I refer in particular to the fruser
> > efforts to hamper Alan Schwartz' efforts to make this group more
> > conducive to constructive discussion.
> >
> I'd agreed with that. Except I'm not quite sure what a fruser is.
> I suspect it's not a term of endearment.
Frusers are "freedom losers". They're all for repudiation of
responsibility for anything. So they'll fight and die for the right
of convicted criminals to spam Usenet. They'll denounce anything
to improve the quality of Usenet, *especially* voluntary guidelines,
as "censorship". They are in favour of allowing tobacco companies to
hand out sample fag packets in kindergartens.
I once parodied them as demanding "freedom of freedom".
> > > qualifications. So they don't bother posting anymore. Is it your position
> > > that newcomers should be discouraged from entering the ranks of mud
> >
> > My position is that everyone should be encouraged, so long as they
> > can spell "you're" and "its" correctly.
> >
> Sure, as long as they can spell color and honor correctly as well.
> Some restraint is in order for "Hallo, Ich bin ein mudder."
I am a doughnut! (Shurely "donut"? - SomeYank)
> > > implementers? What exactly have you done that you feel puts you into
> > > the ranks of the elite? Can you point to any "promising" codebases or must
> > > everything be written from scratch? Could it be that you are just a
> > > codebase bigot from a "tiny" leaf of the mud tree who has a gripe against
> > > the DIKU family tree?
> >
> > Ah yes. I was hoping The Mud Tree would help foster understanding
> > between groups of codebase bigots, but I'm still overjoyed to see that
> > it's adding a certain piquance to the Dikuhead/Tinybrain war. I say
> > this from my standpoint on a non-aligned and obscure branch of the
> > tree :)
> >
> You thought wrong. Take Isaac and Ishmael for example. No don't, I'm
> about to start a religious war. :P
>
> Island := Non-aligned branch? I just had an amusing cartoon-like thought
> of you suddenly glancing down and noticing the branch you're walking on
> has mysteriously disappeared.
Given that I chopped it off myself, I think I'd notice. :)
One important point to realise is how The Mud Tree represents diversity.
Basically, muds which are closer together on the tree are going to
be more similar than muds which are further apart (I mean codebases
here - individual muds can be thought of as leaves on each branch).
Greg Munt's point is that basically, since 1989, there haven't been
many new roots to the tree. (There are only 5 or so - the vast majority
of muds are descendents of MUD1). This has come about because most
codebases are rereleases of code that was inspired by or even derived
from Alan Cox's AberMUD.
Here, for the benefit of those who enjoyed "The Tory map of the World",
in which the Falklands and Gibraltar are disproportionately huge, and
Eire is missing, is my impression of Simon Miller's impression of my
impression of The Mud Tree:
MUD1
|
+----+----+
| |
MIST AberMUD
| |
Island clones (Diku, LP, Tiny)
(N.B. The very first version didn't have much more information than is
presented here, but was arranged in a considerably less biased manner.
Still drew a sharp rebuke of course :) )
> > > No it needs depth. Inheritance is a requisite of evolution.
> >
> > It needs diversity, not width or depth.
>
> What about total integration. Imagine a server that encapsulated all
> existing servers, both in user/builder interfaces and capability.
> On second thought, let's not. That makes me queasy.
Most of them are sufficiently similar to make this a possibility.
> > > "It's not the code, it's the game stupid" - J. Lambert (c)1997
> > > Heavily modified quote based on previously published
> > > material by M. Keegan (1996)
> >
> > Ha!
> >
> Ha Ha. At least I acknowleged the source material. Is that a
> derivative quote or a heavily modified stock quote?
Well of course, my original quotes end up as stock after a while :)
Mk
-- "Be interesting! Stop the frusers before it's too late!"
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi
Corey Brenner
Maddy <ma...@fysh.org> wrote:
: If the object is here then move object into self, otherwise print "That
: isn't here".
I will NOT write a MUD lib in COBOL! Thank you. Please drive through.
: The above is far easier understood by someone who doesn't know a thing about
: programming compared to the following.
It can also be fraught with syntax errors, as the parser for such a thing
would be nightmarish.
: if(object->location==self->location)
: {
: object->location=self->location;
: }
: else
: {
: print(self,"That isn't here");
: }
: Which although, it's fairly simple would require you to understand what '=='
: meant.
Which is a concept easily understood by anyone who comes in contact with it.
If someone asks this question, the simple answer is:
"=" : assigns.
"==" : compares.
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
============================================================================
Corey D. Brenner -- (bre...@umr.edu) | #include<standard_disclaimer.h>
----------------------------------------------------------------------------
Our savior, who art in hard disk, |
Unix be thy name. | This .signature is in
Thy daemons run, thy work be done, | [=] FEEL-AROUND [=]
On localhost, even as in network. |
============================================================================
"I yam Popeye of Borg. Resistinks is futile. You will be askimilgrated."
George Reese
Corey Brenner <bre...@umr.edu> wrote:
: Maddy <ma...@fysh.org> wrote:
: : If the object is here then move object into self, otherwise print "That
: : isn't here".
: I will NOT write a MUD lib in COBOL! Thank you. Please drive through.
: : The above is far easier understood by someone who doesn't know a thing about
: : programming compared to the following.
: It can also be fraught with syntax errors, as the parser for such a thing
: would be nightmarish.
: : if(object->location==self->location)
: : {
: : object->location=self->location;
: : }
: : else
: : {
: : print(self,"That isn't here");
: : }
I prefer Python syntax... something in between.
By the way, the code above is rather strange :)
John Adelsberger
Distribution:
Maddy <ma...@fysh.org> wrote:
: If we really wanted to make programming muds easy - using a subset of
: english (for example) would be better? EG
: If the object is here then move object into self, otherwise print "That
: isn't here".
It's called COBOL. There's a reason nobody uses it, and that's because
it sucks. The compilers are good, the language is fairly flexible, and
you have to write a book to print 'Hi' on the screen. Even if you want
that, you aren't going to get perfectly normal English, as an even
reasonably good parser for it has yet to be devised by the best minds
in computing.
: The above is far easier understood by someone who doesn't know a thing about
: programming compared to the following.
: if(object->location==self->location)
: {
: object->location=self->location;
: }
Well, I guess you aren't a programmer. This if case sets a to b _if_ a
is already equal to b. The indentation sucks balls, too.
: Which although, it's fairly simple would require you to understand what '=='
: meant.
If you can't comprehend ==, your ability to write English will not give
you the skill to design a mud. Note the word 'design' as opposed to
'throw together.' Program design is a skill, and changing the semantics
of the language won't change that. MUDs are large programs, and require
significant skill to write _well,_ even if many bad ones are written
anyway:)
John Adelsberger
Distribution:
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: Have a looka t the journal of the ACM as of a couple months ago. Look for
: Kansas/Oz article. Essentially a set of Sun engineers extended the MOO base
: such that as long as the server still continues to run, *ANYTHING* could be
: done to the MUDLib, encluding crashing the entire world, while stilling
: allowing users to connect and debug the world.
: A cute solution, and really trivial once you think of it.
MOO is irrelevant to the discussion you entered, b/c it doesn't do
dynamic linkage into a compiled binary native to the architecture the
game runs on. However, while I respect Sun's people, what you claim
_must_ have some caveat; logging in _does_ in fact require that the
server not have completely crashed:-)
: There are several C++ class libraries available which reduce HTTP and FTP
: to a simple class with half a dozen methods. The question becomes a no-op.
That just means someone else did the work - it doesn't mean it was easy:)
: : I intend on it myself, but I doubt it meets one key requirement I have,
: : which is that there be more than 100 people worldwide who are
: : familiar enough with it to be able to work _competently_ with it, such
: : that I can find people to work with me on it:)
: Whoops. You lost that bet.
I suppose you just don't read fast enough to have read my next sentence.
Anyway, I can assure you that while I personally know many competent
LPC coders, I know personally not even one person who has so much as
learned the basics of Cold:)
: : (Don't argue that there are; even if it's true, and it may be, there
: : certainly are nowhere near as many who have even heard of Cold as there
: : are who are _good_ at coding under MudOS:)
: Popularity does not a good system make.
Agreed, but nobody writes a great mud by himself, either. Besides, it
has already been proven that LPC can produce good results, and I imagine
Cold can also. The _only_ question is whether I can actually get a mud
up with the staff I have available or not.
John Adelsberger
Distribution:
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: The underlieing fact is that while you can write a MUDLib to do this, LP
: itself is not geared to offer permanancy. It gets to be a real PITA. You'll
: need to explicitly log everything, and then provide ressurection code to
: rebuild the world on re-load. Not fun.
Can you say 'easy?' Any so-called admin on an LP who can't figure out
how to do this should be demoted to newbie creator and made to write
'I will not presume to be clever.' on a chalkboard 1000000 times:-)
: The converse is a server which presumes from the design start that
: everything is permanent. Permenancy at that point is of course implicit.
: Making something impermanent is comparitively easy by adding a case to reset
: the object.
If, however, like _most_ muds, you don't want most things to be
permanent, it is a major waste. Besides, if you use the virtual object
mechanisms, permanency is really not a big deal.
: LP does not offer the ability to by default make *everything* permanent
: without any other code or attention by area builders.
Code yes. Area builders? If I wrote the code, the area builders wouldn't
need to have a clue or even consciously consider the issue.
: Not a criticism, a design limitation. Horses for courses, and the tool
: for the job.
Funny these limitations that those of us who know and program on the thing
just don't see:)
Lars Duening
In article <869499536.28552....@news.demon.co.uk> ma...@fysh.org (Maddy) writes:
>Huibai (as...@pixi.com) wrote:
>: John G. and his trusty online dictionary respond:
> Well most servers (ie LP & Diku) all require some kind of complex
> programming language to code for them. LPC is just like C with knobs on and
> you're average code illiterate person isn't going to have any more luck with
> it than normal C.
> If we really wanted to make programming muds easy - using a subset of
> english (for example) would be better? EG
>
> If the object is here then move object into self, otherwise print "That
> isn't here".
>
> The above is far easier understood by someone who doesn't know a thing about
> programming compared to the following.
>
> if(object->location==self->location)
> {
> object->location=self->location;
> }
> else
> {
> print(self,"That isn't here");
> }
>
> Which although, it's fairly simple would require you to understand what '=='
> meant.
Well, I think it's a common misconception that it's the (formalistic) syntax
which makes programming hard. Unfortunately it isn't - it's the need to think
in an abstract and organized way to get things done.
Admittedly, plain English makes it easier for absolute beginners to dare to
try programming - but aside from this function as a dooropener, plain English
as programming language is just painful. It's more important that the
structure of the language is driven by few consistent rules, so that the
beginner can concentrate on syntax-independent fundamentals like the
difference between variables and values.
--
Lars Duening; due...@ibr.cs.tu-bs.de
George Reese
John Adelsberger <j...@umr.edu> wrote:
: If, however, like _most_ muds, you don't want most things to be
: permanent, it is a major waste. Besides, if you use the virtual object
: mechanisms, permanency is really not a big deal.
What kind of nonsense is this? Virtual objects have ABSOLUTELY
NOTHING to do with permanence.
: : Not a criticism, a design limitation. Horses for courses, and the tool
: : for the job.
: Funny these limitations that those of us who know and program on the thing
: just don't see:)
This particular issue is not a design limitation, but lack of
threading and lack of support for distrivuted computing support are
limitations. And the one cannot be addressed without the other.
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Funny these limitations that those of us who know and program on the thing
: just don't see:)
Less amusing that you seem to have chosen tasks for which your tool is suited.
Which leads?
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Distribution:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : Have a looka t the journal of the ACM as of a couple months ago. Look for
: : Kansas/Oz article. Essentially a set of Sun engineers extended the MOO base
: : such that as long as the server still continues to run, *ANYTHING* could be
: : done to the MUDLib, encluding crashing the entire world, while stilling
: : allowing users to connect and debug the world.
: : A cute solution, and really trivial once you think of it.
: MOO is irrelevant to the discussion you entered, b/c it doesn't do
: dynamic linkage into a compiled binary native to the architecture the
: game runs on.
Utter and compleat codswhallop, both as to the attempted redefinition of the
thread and as to your misunderstanding of MOO's built-in function support.
: However, while I respect Sun's people, what you claim
: _must_ have some caveat; logging in _does_ in fact require that the
: server not have completely crashed:-)
I mentioned the explicit caveat: "...as long as the server continues to
run...". With the definition of "run" being able to accept connections.
You can have a totally and compleat crashed world which *won't* accept
connections or operate at all (all verbs are effectively dead), and still
be able to connect to the server and debug the world.
Cute stuff.
: : There are several C++ class libraries available which reduce HTTP and FTP
: : to a simple class with half a dozen methods. The question becomes a no-op.
: That just means someone else did the work - it doesn't mean it was easy:)
True. However it renders to point negligable for any further questions or
value.
: : : I intend on it myself, but I doubt it meets one key requirement I have,
: : : which is that there be more than 100 people worldwide who are
: : : familiar enough with it to be able to work _competently_ with it, such
: : : that I can find people to work with me on it:)
: : Whoops. You lost that bet.
: I suppose you just don't read fast enough to have read my next sentence.
: Anyway, I can assure you that while I personally know many competent
: LPC coders, I know personally not even one person who has so much as
: learned the basics of Cold:)
Not surprised. I know several, and know of (guesstimate) 30+ if I put my
a little attention on it. I have no doubt that a little work would fill
the rest of the tally.
Then again. I can't see defining the value of a system based on its
popularity.
: : : (Don't argue that there are; even if it's true, and it may be, there
: : : certainly are nowhere near as many who have even heard of Cold as there
: : : are who are _good_ at coding under MudOS:)
: : Popularity does not a good system make.
: Agreed, but nobody writes a great mud by himself, either. Besides, it
: has already been proven that LPC can produce good results, and I imagine
: Cold can also. The _only_ question is whether I can actually get a mud
: up with the staff I have available or not.
Getting it up is the easy part. Getting it to do what you want it to do
is the next harder. Getting the users to populate it and do those things
is the toughest.
Heck, I want a MUD where I can roll back time for any area or object and see
everything that happened to it, or happened in its presence exactly as if I
had been there at the time (across system crashes and resets too); *real*
time travel (and no ability to affect the past). Its not a trivial problem,
esp given performance concerns, but I've got most of it cracked (testing will
show if I have the performance). The biggie is if the players and admins
will use the feature, and more importantly, how they will use it.
(BTW: This is a side-effect of that psersistance I was talking of earlier)
Maddy
Corey Brenner (bre...@umr.edu) wrote:
: Maddy <ma...@fysh.org> wrote:
: : If the object is here then move object into self, otherwise print "That
: : isn't here".
: I will NOT write a MUD lib in COBOL! Thank you. Please drive through.
Did I mention COBOL? Although COBOL is english-like, it's still a
programming language. What is stopping someone taking the english and
producing C code or something and then using that. Coders can use C,
everyone else could use English.
: : The above is far easier understood by someone who doesn't know a thing
: : about programming compared to the following.
: It can also be fraught with syntax errors, as the parser for such a thing
: would be nightmarish.
It would only be full of syntax errors if you allowed a much greater subset
of the language to be used. Parsers are fairly easy.
: : if(object->location==self->location)
: : {
: : object->location=self->location;
Oops - guess I wasn't paying attention. *8)
: : }
: : else
: : {
: : print(self,"That isn't here");
: : }
: : Which although, it's fairly simple would require you to understand what
: : '==' meant.
: Which is a concept easily understood by anyone who comes in contact with it.
: If someone asks this question, the simple answer is:
: "=" : assigns.
: "==" : compares.
And how many times when you were learning C did you put a '=' instead of a
'=='. Just having 'is equal to' (or '=') makes everything simple and anyone
can pick it up straight away. Take your average C based mud. Bob the
bored, potential mudadmin downloads a copy and starts fiddling with the
code. Well first he's got to learn C, no wonder he's going to just give up
and put it up as it is.
(The same goes with LP muds too - except that there are docs on LPC with
it?)
Maddy
Lars Duening (due...@ibr.cs.tu-bs.de) wrote:
: In article <869499536.28552....@news.demon.co.uk>
: ma...@fysh.org (Maddy) writes:
[Snip all my lovely insane rantings]
: Well, I think it's a common misconception that it's the (formalistic)
: syntax which makes programming hard. Unfortunately it isn't - it's the
: need to think in an abstract and organized way to get things done.
Well in some ways it's probably a bit of each - it is so easy when you're
starting to learn C to put '=' rather than '==' by accident, and it's
perfectly legal syntax. The fact it causes random sideeffects, which unless
you're looking for them are a pain in the butt to spot.
: Admittedly, plain English makes it easier for absolute beginners to dare
: to try programming - but aside from this function as a dooropener, plain
: English as programming language is just painful. It's more important that
: the structure of the language is driven by few consistent rules, so that
: the beginner can concentrate on syntax-independent fundamentals like the
: difference between variables and values.
English does have consistent rules, but I agree that using all of them would
be a nightmare. If you cut them down dramatically, it makes it far more
managable. For example, you'll always know that "if" will always have an
expression after it. If you say an expression is either a value or value
operator value etc..etc..etc..
I don't think there really is that much difference between variables and
values, apart from not being able to store new values in a value. And a
parser should pick this up - values will appear as '"value"' or 5636, as
opposed to 'variable'. At any other time I'd assume a variable was being
used for it's value.
I would hope that any other problems like that should be solved in much the
same manner. I can't think of any at the moment, but I'm sure someone will
think of some. *8)
John Adelsberger
Distribution:
Huibai <as...@pixi.com> wrote:
: John Adelsberger delivered:
: : Name them. You keep saying this, but your verbal
: : excrement does not contain any facts as yet.
: You offer no facts, either, John J.
In fact I did, and was willing to back those with yet more facts, but
since you nkow this, you snipped all of them and didn't choose to ask.
: ad hominem argument (argument against the person)
Ad hominem would suppose that I attacked _him._ I attacked his argument,
for being unsupported. If you must refer to formal logical fallicies,
at least use them correctly?
: : If it contains C/C++ code, almost nobody(relative to the number of
: : competent coders in LPC, for instance) will be able to modify it.
: LPC contains C code.
LPC is a language. It is written in C, but the mud that even admins
write is in LPC. If you choose to pretend to be so stupid as not to
grasp this simplest of points, why are you bothering?
: : Threadsafe and lockless? I'd like to see such a system, since
: : it is theoretically impossible unless your definition of lockless is
: : different from everyone elses.
: "theoretically impossible" = "as far as I can think of"
: "everyone elses" = "my opinion"
No, it is a proven impossibility result. Sorry, but your lack of
education does not reflect on the general state of reality.
: : Complex physics? You could code it, but if your intent is to
: : produce a game, you're wasting your time.
: Your post is loud in sound and fury, yet signifying nothing.
: Be careful how you toss about the words "wasting time".
I maintain that a game does not require simulation of complex
physics. Designers of amazingly realistic 3D simulators, such
as those used by the military, agree with me.
: : If you can actually demonstrate this instead of discussing it in
: A three body system is obviously where a player deals with more
: than one body - either controlling multiple bodies or Being multiple
: bodies. A half moment's thought before hitting the 'inane reply'
: button would reveal that.
Sucn a thing can easily be done in LPC, but is not likely what the
original poster meant, since 3 body system is in fact terminology
from physics. Do you in fact possess any education whatsoever?
: Closing the throttle, and back on topic:
: LPC is strong in its ease of programming for code-illiterate folks.
: Not so easily rewired if you don't know a thing about programming
: or C, though. You could 'theoretically' take _any_ codebase and
: rip enough out of it and refill it with compost to make it resemble
: whatever you like. Because you could theoretically do it in LPC
: doesn't mean it's the most appropriate or efficient way to do it, and
: therefore it isn't testimony to the flexibility of LPC.
If you can't see the difference between the flexibility offered by
a general purpose programming language and that offered by completely
rewriting a static code base written in C, you are being deliberately
obtuse.
: The thread is looking for alternatives to the perceived 'failure' thus
: far of existing designs. I don't recall any explicit invitations to stage
: your own defense of a platform/language/soapbox which is NOT
: under siege.
I guess I don't perceive the failure. Moreover, I merely claimed that
LPC could do what people wre asking for; I didn't defend anything until
morons who clearly can't even list off LPC's typelist started attacking
something they know nothing about, and then only because itis amusing
to do so.
John Adelsberger
Distribution:
Jon A. Lambert <jlsy...@ix.netcom.com> wrote:
: Actually there have been several instances in these threads where "flaws"
: have been pointed out. In any non-trivial program design decisions
: will have been made to achieve a desired end to the point where
: modification of that program to correct these flaws is unproductive.
: Your conception of what the game/mud should be capable of seems to be driven
: by and limited to the capabilities of the server. For some of us it is the
: other way around.
Why is it that when I ask for facts, I get more generalization? Do you
folks in fact believe that repeating yourselves makes you right? Do you
in fact know of something you want a mud to do that can't be done on an
LP of some form? If so, will you please point it out, rather than
blathering? Keep in mind that I really do ask that what you 'point out'
be comprehensible - if you can't explain it, you're bullshitting, b/c
I'm not stupid and I'm not uneducated.
: This tends to revive that ancient debate on the maintainability of
: object oriented code versus procedural code. My best instincts tell
: me that a Physmud server would be more easily maintained by a third
: party than a server written in procedural C. Competency in a language
: is certainly a requirement. The Diku experience may well be an indicator
: as to the maintainability of procedural spaghetti rather than a damnation
: of hardcoding in general.
Then why is it that the hardcoded OO servers have almost no users
whatsoever? They do exist; they just don't get used. Hardcoded
muds are the past; all the new servers I'm aware of are running a
VM of some sort.
: > Threadsafe and lockless? I'd like to see such a system, since it is
: > theoretically impossible unless your definition of lockless is different
: > from everyone elses.
: No it isn't theoretically impossible. It can perhaps be proven semantically
: impossible by students of language or philosophy. It can be argued that any
: server which provides for task failure has at its core a "locking" mechanism.
Any server that provides for threadsafe access to global data on a
multiprocessor 'has at its core a locking mechanism' you moron. You
can replace multiprocessor with premptively scheduled thread library,
if you like.
: Generally these semantic arguments have little use in computer science.
: Let's just say a non-locking model differs enough from a traditional locking
: model that the expression of it using the term lockless is sufficient and
: accurate.
Lets just say that I've read a good deal on this subject, as it
interested me very much, and a threadsafe lockless access mechanism
for even simple datatypes is an impossibility result from many moons
ago.
: However, I do have doubts whether the lockless model is more efficient
: overall than traditional locking models. I am still open minded about
: it.
Even if it were possible to use the processor's clock as a pseudolock
by having single instructions that do what you want done to your data,
which is a bad idea anyway, the result wouldn't be something you'd want
to use.
: I suspect that many flight simulators and space simulations don't fall
: under your conception of game. Complex economics, biology, politics,
The most complex physics used in most such simulations is Newtonian.
Such is easily implementable in LPC, so I assume it isn't what Mr. Yospe
meant.
: genetics and AI are other fine ways for one to waste their time.
: Sure you could code these things, but no self-respecting mudder wants to
: see this sort of SIM-crap polluting the game. ;)
Precisely my point.
: I happen to believe that concurrency and persistence make these constructs
: easier to develop. I don't see how LP servers are better able to effect
: these concepts than other alternatives.
LP, despite the verbal incontinence of another poster, makes doing
persistence easy. Concurrency is an efficiency thing, and a good one,
but it never makes anything easier.
: > If you can actually demonstrate this instead of discussing it in vague
: > terms that make it impossible to discuss or prove/disprove, fine.
: > Otherwise, your claims are irrelevant to sane discussion.
: And so are your earlier claims that all creative people are working on
: LPs. Touché.
Actually, a few of them do Cold and Mud++ and MOO, but the total number
of users of such things is probably less than the number of users of
even crusty _old_ LP drivers like 2.4.5, much less modern MudOS, so I
tend to forget about them too much:) An apology to them, though.
: > You _can_ in fact modify the driver, and you _can_ in fact leave out
: > support you don't want. Are you talking out your small end?
: And we come full _Circle_ back to hard-rewiring a server for a particular
: and imperative need.
I didn't say I wanted to mod the driver. I said it can be done. Moreover,
tweaking a makefile does not count as coding; there is a difference.
Chris Lawrence (Contra)
Chris Ebenezer (chr...@nortel.ca) wrote:
: Chris Lawrence (Contra) (claw...@cup.hp.com) wrote:
: : Have a looka t the journal of the ACM as of a couple months ago. Look for
: : Kansas/Oz article. Essentially a set of Sun engineers extended the MOO base
: : such that as long as the server still continues to run, *ANYTHING* could be
: : done to the MUDLib, encluding crashing the entire world, while stilling
: : allowing users to connect and debug the world.
: I take it this is the main ACM magazine ' Communications of the ACM', do you
: have a date and page number for this article ? I would very much like to get
: hold of it.
AFAIR, yes. I don't have the issue handy for a page number (it was leant
to me by a friend). I do recall that you can find it by searching the ACM
site. Good key words are "Kansas" and "Oz".
Jon A. Lambert
John Adelsberger <j...@umr.edu> wrote in article <5r5lh7$jdd$1...@news.cc.umr.edu>...
>
> Jon A. Lambert <jlsy...@ix.netcom.com> wrote:
>
> Why is it that when I ask for facts, I get more generalization? Do you
> folks in fact believe that repeating yourselves makes you right? Do you
> in fact know of something you want a mud to do that can't be done on an
> LP of some form? If so, will you please point it out, rather than
> blathering? Keep in mind that I really do ask that what you 'point out'
> be comprehensible - if you can't explain it, you're bullshitting, b/c
> I'm not stupid and I'm not uneducated.
Your position as you clearly stated it was that LP is the best system for
handling these items. You position seems to now be that it merely can be
done. This is a significant position change and you make the point of argument
moot. We might as well be arguing with one who claims anything that can
be done on a mud can be done in COBOL.
> Then why is it that the hardcoded OO servers have almost no users
> whatsoever? They do exist; they just don't get used. Hardcoded
> muds are the past; all the new servers I'm aware of are running a
> VM of some sort.
Sigh... if we are going to do the "most users" thing, you might as well
be arguing against servers with VMs. The "most users" and "most creative
people" arguments are highly subjective and are useless tripe in debates on
design and technical issues.
>
> : > Threadsafe and lockless? I'd like to see such a system, since it is
> : > theoretically impossible unless your definition of lockless is different
> : > from everyone elses.
>
> : No it isn't theoretically impossible. It can perhaps be proven semantically
> : impossible by students of language or philosophy. It can be argued that any
> : server which provides for task failure has at its core a "locking" mechanism.
>
> Any server that provides for threadsafe access to global data on a
> multiprocessor 'has at its core a locking mechanism' you moron. You
> can replace multiprocessor with premptively scheduled thread library,
> if you like.
>
An example of such a threadsafe lockless database system:
Replication database technology. A server database provides a replica of
a database or portion of the database to a client machine. The client
has full access to the replication without any form of locking. Later a
backend process attempts to resolve data inconsistencies and integrity issues
by merging all the client replicas back into the server database using a
replication algorithm. While this technology is suitable for some
applications, it poses all kinds of problems for many more. These problems
are obvious. Resolving update conflicts correctly and automatically,
timely or no notification of the client process, and providing data currency.
Yet it is certainly a threadsafe lockless database system.
Sounds like pretty useless technology for muds. But wait, it gets better.
Now imagine we have a process running on a machine and under that process
we have many threads. One of these threads is a database server, the rest
are client threads. Now instead of replicating an entire database for
each client, we instead replicate objects to each client that requests
them. The server thread does not restrict any clients access to an object
nor does it require the client to provide information as to its intention.
This is generally known as a lockless database and in most cases is considered
a bad thing. Except that now when the client returns the object to the
database server thread, the database attempts to "merge" the object into the
real database. A comparison is made between with what database knows it sent
the client and the current condition of the "real" object. There are several
methods of doing this. If they are the same, then the new object passed back
is copied over the database's "real" object. If they are not we have a data
integrity problem and the server thread disallows the update and sends a
notification message to the client thread.
The client thread attempts to reschedule itself until it is successful may
may even determine that it can no longer succeed after the object state
change. Note the real and global version of the object is held by the
database server thread and is very much threadsafe. There is no need
sharing this global data by multiple threads nor is there any thread locking
on it.
This solves the problems of the earlier model. It resolves update conflicts
correctly, automatically and immediately. It provides immediate notification
to the client process. It ensures data is current.
Such a model can become more efficient with early warning messages sent
to client threads holding potentially invalid objects. Such a model
has problems graduating to a fully transactional system involving multiple
objects. Many of these problems have solutions. Some have been presented
here in the rgm* groups many moons ago and elsewhere.
Now on to the moron comment. I can assume this is the spirited ignorance of
one who is damn sure the world is flat.
> : Generally these semantic arguments have little use in computer science.
> : Let's just say a non-locking model differs enough from a traditional locking
> : model that the expression of it using the term lockless is sufficient and
> : accurate.
>
> Lets just say that I've read a good deal on this subject, as it
> interested me very much, and a threadsafe lockless access mechanism
> for even simple datatypes is an impossibility result from many moons
> ago.
Perhaps some creative thinking along with that reading would help.
> which is a bad idea anyway, the result wouldn't be something you'd want
> to use.
I fully the expect some form of the above phrase to be included in your
arguments against the incredibly impossibly moronic threadsafe lockless
database model.
> The most complex physics used in most such simulations is Newtonian.
> Such is easily implementable in LPC, so I assume it isn't what Mr. Yospe
> meant.
>
I'm sure Mr. Yospe means a whole lot more than Newtonian. Some of us
are aware that his sci-fi theme revolves around galactic level events
and are likely to involve blackholes, wormholes, radiation, radio and
electromagnetic effects, vacuum, rocketry and other such stuff. You
may poo poo this as being unnecessary and not provide anything of value
to players. On further thought, should you be capable of it, you might
realize that sci-fi addicts find this level of realism very appetizing
and is could likely be a popular player draw.
Much of this does not interest me, my mud physics are more Aristotelian
than Newtonian.
> : genetics and AI are other fine ways for one to waste their time.
> : Sure you could code these things, but no self-respecting mudder wants to
> : see this sort of SIM-crap polluting the game. ;)
>
> Precisely my point.
>
No the winky means sarcasm. These things are good things and a server
should be able to handle them.
> : I happen to believe that concurrency and persistence make these constructs
> : easier to develop. I don't see how LP servers are better able to effect
> : these concepts than other alternatives.
>
> LP, despite the verbal incontinence of another poster, makes doing
> persistence easy. Concurrency is an efficiency thing, and a good one,
> but it never makes anything easier.
Moving persistence into the server driver removes the need for the internal
mud language to handle it or deal with it at all. Neither LPC, C, COBOL, or
many other languages handle persistence well. Object persistence is implicit
in ColdC. Making a completely persistent world requires you to preserve not
only objects but preserve their associations with other objects. This is
by no means a no brainer and IS a big deal.
Concurrency, if also abstracted from the mud language, by handling within the
driver is a good thing IMO.
>
> I didn't say I wanted to mod the driver. I said it can be done. Moreover,
> tweaking a makefile does not count as coding; there is a difference.
>
Based on your posts in rgm.lp and the reactions from those who know the
LP drivers best, I suspect you'd f*ck it up real good.
JL
Huibai
[lots of snips - deal with it]
John Adelsberger:
: Ad hominem would suppose that I attacked _him._
Referring to this thread, you repeatedly question and insult
my education (a subject you have zero information about),
which has nothing to do with the topic or my observations.
Referring to your responses to others, you refer to another
poster as a moron while neglecting to either refute his point
or support your own.
I snip out the rest because, whether you consider it important
or not, it's irrelevant to my point, and tedious to scan through.
: Sorry, but your lack of education does not reflect
-
: Do you in fact possess any education whatsoever?
: I guess I don't perceive the failure. Moreover, I merely claimed that
As I stated originally, the thread deals with "the perceived 'failure'"
of MUD evolution. I put the failure in single quotes and qualified
that with 'perceived' for a solid reason.
: "There are none so blind as those who will not see." - Kansas
Or read.
John Adelsberger
Distribution:
Maddy <ma...@fysh.org> wrote:
: Did I mention COBOL? Although COBOL is english-like, it's still a
: programming language. What is stopping someone taking the english and
: producing C code or something and then using that. Coders can use C,
: everyone else could use English.
Or, as you point out below, a highly restricted subset of it, both in
syntax and vocabulary which a parser could actually comprehend. Which,
fyi, is called COBOL:)
: It would only be full of syntax errors if you allowed a much greater subset
: of the language to be used. Parsers are fairly easy.
If you use a small subset, you're no better off than if you write C;
remembering which parts of the huge English language are legal would
be far mroe difficult than learning C.
: And how many times when you were learning C did you put a '=' instead of a
: '=='. Just having 'is equal to' (or '=') makes everything simple and anyone
I still do it on occasion, and I am a quite decent C programmer; it's
called debugging, you should read about it - they'd have to debug English
if you got your way, and I don't even want to think about that mess:)
: can pick it up straight away. Take your average C based mud. Bob the
: bored, potential mudadmin downloads a copy and starts fiddling with the
: code. Well first he's got to learn C, no wonder he's going to just give up
: and put it up as it is.
Sounds like Bob the bored should find a hobby he's willing to put the effort
into to do right.
: (The same goes with LP muds too - except that there are docs on LPC with
: it?)
Some, yes, and they get better all the time. LPC is a much easier
language than C, also. Frankly, anyone who can't learn it isn't going
to make a worthwhile mud admin anyway; area coder, quite possibly, and
hemight have the nicest areas in human history, but his mud would suck
anyway.
--
John J. Adelsberger III
j...@umr.edu
"There are none so blind as those who will not see." - Kansas
John Adelsberger
Distribution:
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: John Adelsberger (j...@umr.edu) wrote:
: : Threadsafe and lockless? I'd like to see such a system, since it is
: : theoretically impossible unless your definition of lockless is different
: : from everyone elses.
: Nope, not impossible -- its been done for years in the DB world, tho the
: typical solution renders the commit process single-threaded under the
: covers.
'renders the commit process single-threaded' == 'locks,' geniusboy.
: Hit DejaNews and look at some of Nathan's previous traffic on PysMud++. He's
: looking to model the basic laws of physics (gravity, inertia, momentum, etc)
: as a base part of the definition of his world(s).
To each his own, I suppose. Unless it has a truly profound impact on
the gaming experience, he's wasting too much time for something nobody
will ever care about, but maybe it does; I'm not him, so I'll just
hope he has thought about what he's doing:)
Martin Keegan
Corey Brenner wrote:
> : Which although, it's fairly simple would require you to understand what '=='
> : meant.
>
> Which is a concept easily understood by anyone who comes in contact with it.
> If someone asks this question, the simple answer is:
>
> "=" : assigns.
> "==" : compares.
>
If you're one of those people who worships at the altar of the
subjunctive, then a nice mnemonic is
= equal
== equals
So
bar = 15;
is read as "bar equal fifteen". Older BASIC drove this home with
LET A = 10
No-one would ever have read that as "let A equals ten". And the C
if(foo == 10)
can just be read as "if foo equals ten".
This is probably only of use to someone explaining the basics of C
(or LPC, or perl) syntax to a novice, though it is pretty neat.