LP: How does it work?
Kevin J. Chen
I'm considering implementing a pseudo-language to make on-the-fly
modifications to MUD behavior simpler, so I'm curious how this is done
in LPMUDs (folks responding, keep in mind that I'm fairly LP-ignorant,
although I have perused George's basic and intermediate LP tutorials,
just to get an idea of the language's capabilities). I'm guessing
that the various drivers all handle implementing the language in
different ways.
So:
1) What's the best way to construct a parser for the language? Simple
character-by-character automata? Lexx/yacc? Do-it-yourself-because-
scratch-stuff-is-manly?
2) What is the language compiled to? C (to allow native code
generation)? A driver-specific bytecode? Something else entirely?
Hopefully, these questions will generate enough discussion that I'll
be able to think of the rest of the questions which currently elude
me. :)
Kevin.
Tatu P Saloranta
kc...@vnet.net (Kevin J. Chen) writes:
>I'm considering implementing a pseudo-language to make on-the-fly
>modifications to MUD behavior simpler, so I'm curious how this is done
>in LPMUDs (folks responding, keep in mind that I'm fairly LP-ignorant,
>although I have perused George's basic and intermediate LP tutorials,
>just to get an idea of the language's capabilities). I'm guessing
>that the various drivers all handle implementing the language in
>different ways.
Probably no; I haven't checked sources of MudOS or DGD, but I'd
think they use the same basic architecture as Amylaar's GD (I mean,
as far as your 2 questions go):
>1) What's the best way to construct a parser for the language? Simple
>character-by-character automata? Lexx/yacc? Do-it-yourself-because-
>scratch-stuff-is-manly?
Well, Lex + Yacc/Bison is IMHO the way to go. And that's what Amylaar
does (more or less; Lex-part is bit messy though). There's little to
gain (if anything) by doing your own Reinvent-the-wheel-Lexer/
compiler-compiler.
>2) What is the language compiled to? C (to allow native code
>generation)? A driver-specific bytecode? Something else entirely?
LPMuds usually compile to (driver-specific) bytecode, although some
drivers are able to compile to C I've heard. How efficient the c-code
is compared to bytecode is hard to say (anyone have statistics? I would
be really interested in seeing some?); depends on what sort of C is output
(ie. is it just 'unrolling LPC & efuns', using same sort of stack
machine, or something else).
--
Tatu Saloranta, aka Doomdark.
doom...@cc.hut.fi
Corey Brenner
Kevin J. Chen <kc...@vnet.net> wrote:
: 1) What's the best way to construct a parser for the language? Simple
: character-by-character automata? Lexx/yacc? Do-it-yourself-because-
: scratch-stuff-is-manly?
If you can do it, lex/yacc would be the Right Thing To Do[tm], because
many times their code will surpass that generated by the average programmer.
It is also a good idea to use those language tools because you are less
likely to have a nasty bug appear and spend a lot of time tracking it
down. I, however, am a masochist, and would write one from scratch.;-)
: 2) What is the language compiled to? C (to allow native code
: generation)? A driver-specific bytecode? Something else entirely?
Yes. On both counts. Something different entirely? I suppose if you were
even more insane than I you could generate assembly for the language
of your choice, or directly generate loadable libraries. ;-)
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
============================================================================
Corey D. Brenner -- (bre...@umr.edu) | #include<standard_disclaimer.h>
----------------------------------------------------------------------------
One Net to rule them all, | (I like wide open spaces in .signature files)
One Net to find them, |
One Net to bring them all, | This .signature is in
And using UNIX bind them. | [=] FEEL-AROUND [=]
============================================================================
"I yam Popeye of Borg. Resistinks is futile. You will be askimilgrated."
Adam Helps
Kevin J. Chen wrote:
>
> I'm considering implementing a pseudo-language to make on-the-fly
> modifications to MUD behavior simpler, so I'm curious how this is done
> in LPMUDs (folks responding, keep in mind that I'm fairly LP-ignorant,
> although I have perused George's basic and intermediate LP tutorials,
> just to get an idea of the language's capabilities). I'm guessing
> that the various drivers all handle implementing the language in
> different ways.
>
>
> 1) What's the best way to construct a parser for the language? Simple
> character-by-character automata? Lexx/yacc? Do-it-yourself-because-
> scratch-stuff-is-manly?
>
> generation)? A driver-specific bytecode? Something else entirely?
>
> be able to think of the rest of the questions which currently elude
> me. :)
>
> Kevin.
The whole point of an LP is that you can change ANYTHING on the fly,
excluding your player object and the master object and anything that was
designed badly. You could even, theoretically, modify your room behavior
and then immediately create rooms with the new behavior (and update the
old ones) without restarting at all.
You can either take advantage of this total flexibility or, if you
really want a script language, design it yourself (pretty much from
scratch, although LPC string handling is incredibly good). Just making
another C interpreter would be pointless since that's what the driver
does anyway...?
-=-=-=-=-=-=-=-=-=-=-=-=-
,.~*~% |\ __ o. . __ ,.~*~%
~,....~~$&$& -- |_\| || |`--, ~,....~~$&$&
*~~..~~**&$@#% | \-- ``--'`--' *~~..~~**&$@#%
~~~****&$#@@#$ -=-=-=-=-=-=-=-=-=-=-=-=- ~~~****&$#@@#$
$&$$&&$@@##$$$ aka Adam Helps $&$$&&$@@##$$$
$&$#@@#$$$$% -=-=-=-=-=-=-=-=-=-=-=-=- $&$#@@#$$$$%
$%$$$% hel...@slkc.uswest.net $%$$$%
-=-=-=-=-=-=-=-=-=-=-=-=-
rlo...@franck.princeton.edu.composers
In article <5q42u4$d8m$1...@ralph.vnet.net>, kc...@vnet.net writes:
>
> 1) What's the best way to construct a parser for the language? Simple
> character-by-character automata? Lexx/yacc? Do-it-yourself-because-
> scratch-stuff-is-manly?
Whatever compiler tools you feel comfortable with will do quite
nicely. Most (if not all) LP servers use yacc based grammars with
hand written lexical analysis. You might want to look at something a
bit more up to date; there are better packages out there these days.
See the comp.compilers FAQs for a full listing of tools.
> 2) What is the language compiled to? C (to allow native code
> generation)? A driver-specific bytecode? Something else entirely?
driver specific bytecode under normal conditions. Two drivers can do
C as well, but that is really less useful, especially for a first pass.
Well designed bytecode can fly along fast enough for MUD purposes.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
spamming idiots please email sp...@franck.princeton.edu so I know who you are.
Thanks for being stupid and doing this automatically.
rlo...@franck.princeton.edu.composers
In article <doomdark....@snakemail.hut.fi>, doom...@piano.hut.fi writes:
> kc...@vnet.net (Kevin J. Chen) writes:
>
> >2) What is the language compiled to? C (to allow native code
> >generation)? A driver-specific bytecode? Something else entirely?
>
> LPMuds usually compile to (driver-specific) bytecode, although some
> drivers are able to compile to C I've heard. How efficient the c-code
> is compared to bytecode is hard to say (anyone have statistics? I would
> be really interested in seeing some?);
Roughly 3-7x faster, depending on the operation.
[of course, it is as slow as 1x when the bottleneck is some high
powered efun, but the above range is typical]
> depends on what sort of C is output
> (ie. is it just 'unrolling LPC & efuns', using same sort of stack
> machine, or something else).
MudOS currently just unrolls, although the original LPC->C compiler I
wrote used an entirely different architecture. It turns out that most
of the speed gain comes from the lack of spinning through the
decode/dispatch loop, so the unroll version is almost as fast, and
much easier to maintain.
DGD is similar, but does a bit more inference and manages to convert
some common constructs and also does a better job of eliminating
runtime type checks, IIRC.
You really need to keep the stack machine around if you want to be
able to arbitrarily intermix LPC and C programs (though I believe DGD
actually disallows this in some cases; i.e. programs inherited by
compiled programs must be compiled, or something like that) which I
consider to be an important goal. IMO, the noticeable only difference
should be the speed.
John Adelsberger
Adam Helps <hel...@slkc.uswest.net> wrote:
: The whole point of an LP is that you can change ANYTHING on the fly,
: excluding your player object and the master object and anything that was
: designed badly. You could even, theoretically, modify your room behavior
: and then immediately create rooms with the new behavior (and update the
: old ones) without restarting at all.
You can replace the master ob in MudOS, and upgrade is easy to write to
replace the player ob w/o even really logging out.
--
John J. Adelsberger III
j...@umr.edu
Tatu P Saloranta
Adam Helps <hel...@slkc.uswest.net> writes:
>The whole point of an LP is that you can change ANYTHING on the fly,
It's one of the useful points, but probably not _the_ point. It just is
generally a good language for muds, much due to its very dynamic nature
(which is of course necessary for being able to change anything etc. etc).
>You can either take advantage of this total flexibility or, if you
>really want a script language, design it yourself (pretty much from
>scratch, although LPC string handling is incredibly good). Just making
I would not call LPC string handling incredibly good actually. It depends
a bit on which LPC-dialect you are referring to (ie. which gamedriver),
but all in all, for pure string-handling, LPC doesn't IMHO come close
to, say, Perl. Then again, if you meant it as compared to, say, vanilla
C/C++, you are right, it is good. :-)
On the other hand, whether LPC even needs more versatile string handling
tools (_good_ regexp-support, for example) is questionable; after all,
usual string handling tasks (in muds I've worked on at least) are rather
simple (concatening, splitting to words, comparing string parts, sscanfing
for numbers/words).
>another C interpreter would be pointless since that's what the driver
>does anyway...?
Another c-interpreter doesn't sound too useful a thing at LPC-level, but
you can have yet another level, a scripting language or such. I have done
this on my mud (which is still on development, the usual case); the system
is used for defining actions NPCs take (normal actions, reactions to
external events etc). This could of course be all done in plain LPC, but this
way the whole 'program' is more compact, and hopefully makes it easier
for others to quickly see what the NPC does and when. In addition, it means
that a person doesn't need as much LPC-knowledge (or exact mudlib-knowledge
either) to implement 'smart' NPCs.
John Viega
In article <5q42u4$d8m$1...@ralph.vnet.net> kc...@vnet.net (Kevin J. Chen) writes:
> So:
>
> 1) What's the best way to construct a parser for the language? Simple
> character-by-character automata? Lexx/yacc? Do-it-yourself-because-
> scratch-stuff-is-manly?
As with any language you write, this is going to depend on you. If
you were going to write a language w/ LPC's complexity, though, you
are almost certainly going to be a lot better off using a parser
generator like yacc or PCCTS.
>
> 2) What is the language compiled to? C (to allow native code
> generation)? A driver-specific bytecode? Something else entirely?
Most current LPC implementations compile to a driver specific virtual
machine (bytecodes). Some of them can translate to C as well. You
might want to compile to something like the Java VM, instead of
writing, debugging and maintaining your own virtual machine.
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Adam Helps <hel...@slkc.uswest.net> wrote:
: : The whole point of an LP is that you can change ANYTHING on the fly,
: : excluding your player object and the master object and anything that was
: : designed badly. You could even, theoretically, modify your room behavior
: : and then immediately create rooms with the new behavior (and update the
: : old ones) without restarting at all.
: You can replace the master ob in MudOS, and upgrade is easy to write to
: replace the player ob w/o even really logging out.
To digress a tad, LP does not encourage (I don't know it well enough to say
it won't support) runtime morphism. ie it does not allow users at runtime
to modify the object heirarchy and transparently have the entire world
change about them as the objects and inheritance tree also change.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Jukka Vaisanen
In article <5q69gi$imq$4...@news.cc.umr.edu> Corey Brenner <bre...@umr.edu> writes:
> : 2) What is the language compiled to? C (to allow native code
> : generation)? A driver-specific bytecode? Something else entirely?
> Yes. On both counts. Something different entirely? I suppose if you were
> even more insane than I you could generate assembly for the language
> of your choice, or directly generate loadable libraries. ;-)
Hey, we have an LP-like language that generates assembly. It's not
insane at all, it's fast :) The things that work are fast, that
is... It's still very very alpha and full of bugs (and a
when-we-have-time project). But it has some promise.
JAVA has JIT, why not do the same for LP?
--
Jukka Vaisanen
Iscape Software Email: vai...@iscape.fi
Pieni Roobertinkatu 11 A 3 GSM: +358-40-5007978
FIN-00130 Helsinki
Tel: +358-9-648686 Fax: +358-9-6121243
Adam Helps
Tatu P Saloranta wrote:
>
> Adam Helps <hel...@slkc.uswest.net> writes:
>
> >The whole point of an LP is that you can change ANYTHING on the fly,
>
> generally a good language for muds, much due to its very dynamic nature
> (which is of course necessary for being able to change anything etc. etc).
True, it's reason #2 on Lars Penjo's (sp?) list of concepts for LPC (LPC
was designed to be an improvement over AberMUD, which required complete
recompilation of the driver for every modification) -- The LP is his
initials, so I guess he gets to decide. In case you've never seen the
list, the points were:
1. A wizard can extend the game.
2. The game can be extended on fly, without rebooting the mud.
3. There is no difference between objects (one object type)
4. All objects are in interpreted C, with the specs loaded/compiled
the first time they are referenced.
5. There is no player parser. All commands are defined by the objects.
6. Rooms are just objects that define commands like 'look' and 'north',
etc.
7. A 3 second heart_beat to move monsters, burn out torches, etc.
8. Player object defines player commands like get, smile, kill, etc.
9. Wizards make their own 'castles' (areas)
10. Language for objects is in interpreted C
11. Built in editor, ls command, and cat command, for manipulating
files.
This list was on the old Genesis LP-MUD. I found it in LIB245's
doc/helpdir/concept.
> I would not call LPC string handling incredibly good actually. It depends
> a bit on which LPC-dialect you are referring to (ie. which gamedriver),
> but all in all, for pure string-handling, LPC doesn't IMHO come close
> to, say, Perl. Then again, if you meant it as compared to, say, vanilla
> C/C++, you are right, it is good. :-)
Since I spend most of my time writing in vanilla C/C++, LPC is a nice
break from using strxxx functions for EVERYTHING :) (Wow, you can
concatenate with a +! You know how long it takes to get that working in
C++? etc.)
> >another C interpreter would be pointless since that's what the driver
> >does anyway...?
>
> Another c-interpreter doesn't sound too useful a thing at LPC-level, but
> you can have yet another level, a scripting language or such. I have done
> this on my mud (which is still on development, the usual case); the system
> is used for defining actions NPCs take (normal actions, reactions to
> external events etc). This could of course be all done in plain LPC, but this
> way the whole 'program' is more compact, and hopefully makes it easier
> for others to quickly see what the NPC does and when. In addition, it means
> that a person doesn't need as much LPC-knowledge (or exact mudlib-knowledge
> either) to implement 'smart' NPCs.
Makes sense. Anybody have a favorite ideas on how to implement a
scripting language, btw? (i.e. good commands, syntax, easy and fast
parsing, etc.) I've thought of this before but I've never actually tried
to make one, and I was wondering what's been done before.
Tatu P Saloranta
rlo...@franck.Princeton.EDU.composers () writes:
>In article <doomdark....@snakemail.hut.fi>, doom...@piano.hut.fi writes:
>> LPMuds usually compile to (driver-specific) bytecode, although some
>> drivers are able to compile to C I've heard. How efficient the c-code
>> is compared to bytecode is hard to say (anyone have statistics? I would
>> be really interested in seeing some?);
>Roughly 3-7x faster, depending on the operation.
Ah. Interesting. It's higher than I would have guessed. :-)
>> depends on what sort of C is output
>> (ie. is it just 'unrolling LPC & efuns', using same sort of stack
>> machine, or something else).
>MudOS currently just unrolls, although the original LPC->C compiler I
>wrote used an entirely different architecture. It turns out that most
>of the speed gain comes from the lack of spinning through the
>decode/dispatch loop, so the unroll version is almost as fast, and
>much easier to maintain.
If the speed gain is that significant even as is, it makes sense to do
(just) the unrolling. For a while I was considering removing type checks
from the driver (tweaking Amylaar's GD every now & then, have had to
modify few efuns at some points), but without lots of work it probably
doesn't help much, as you still have to make sure stack objects are
de-allocated as needed etc. I guess the less advanced Java JIT-compilers
also mostly do the unrolling.
Btw, have you (or some other GD-implementor) thought about changing
string datatype to contain length information in svalue? (btw, I'm not
familiar with MudOS, so hopefully I'm not asking FAQ-stuff) I mean,
when accessing parts of strings, GD always seems to do strlen() to make
sure it's not indexing outside the string. And when you have long strings,
scanning for ending \0 probably takes some time (cache helps a lot etc
but still)... Without any gain (except for saving 4 bytes or so that
length-information would use, minus one byte used to mark the end).
>DGD is similar, but does a bit more inference and manages to convert
>some common constructs and also does a better job of eliminating
>runtime type checks, IIRC.
Perhaps one could optimize the looping constructs? Although, whether
it's worth the hassle is another thing.
>You really need to keep the stack machine around if you want to be
>able to arbitrarily intermix LPC and C programs (though I believe DGD
>actually disallows this in some cases; i.e. programs inherited by
>compiled programs must be compiled, or something like that) which I
>consider to be an important goal. IMO, the noticeable only difference
>should be the speed.
Yes, in ideal situation speed should be the only difference. Although,
the restriction (compiled can only inherit compiled code) doesn't sound
too bad because you probably mostly do compile often inherited (and used)
base objects?
John Adelsberger
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: To digress a tad, LP does not encourage (I don't know it well enough to say
: it won't support) runtime morphism. ie it does not allow users at runtime
: to modify the object heirarchy and transparently have the entire world
: change about them as the objects and inheritance tree also change.
It does indeed allow for this, although it requires a bit of skill in
design to pull off reasonably. There is no reason imaginable why you
would really want to do it on a large scale, since it would be a rare
enough event that a reboot would hardly hurt you, but you _can_ if you
want.
--
John J. Adelsberger III
j...@umr.edu
"There are none so blind as those who will not see." - Kansas
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : To digress a tad, LP does not encourage (I don't know it well enough to say
: : it won't support) runtime morphism. ie it does not allow users at runtime
: : to modify the object heirarchy and transparently have the entire world
: : change about them as the objects and inheritance tree also change.
: It does indeed allow for this, although it requires a bit of skill in
: design to pull off reasonably. There is no reason imaginable why you
: would really want to do it on a large scale, since it would be a rare
: enough event that a reboot would hardly hurt you, but you _can_ if you
: want.
Chris simply said that LP does not encourage it; and in fact, Chris
would be right.
--
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
Felix A. Croes
> To digress a tad, LP does not encourage (I don't know it well enough to say
> it won't support) runtime morphism. ie it does not allow users at runtime
> to modify the object heirarchy and transparently have the entire world
> change about them as the objects and inheritance tree also change.
On the other hand, it is debatable whether runtime morphism as implemented
on other servers is a good thing. If the object at the root of an
inheritance tree can change at any time, fewer assumptions can be made at
compile-time, resulting in less efficient code; compile-time typechecking
of inherited functions and variables/properties becomes "unencouraged";
indeed the very <presence> of a function or variable is something that
cannot be relied upon.
Still, something like runtime morphism is a must for continuous muds. For
DGD, I've decided on a different solution: if the root object of an
inheritance tree is recompiled, also recompile all the other objects in the
tree (unlike other LPC servers, DGD allows an existing object to be
recompiled without first destructing it). Only the basic operation of
recompiling a single object is actually supported directly by the server,
the rest needs mudlib support. This makes changing the auto-inherited (root)
object a painfully slow process, but that is something you'd only want to do
during your weekly maintenance hour, anyway.
Regards,
Dworkin
Tim Hollebeek
In article <55g1tf5...@transmogrifier.iscape.fi>, vai...@transmogrifier.iscape.fi writes:
>
> Hey, we have an LP-like language that generates assembly. It's not
> insane at all, it's fast :) The things that work are fast, that
> is... It's still very very alpha and full of bugs (and a
> when-we-have-time project). But it has some promise.
>
> JAVA has JIT, why not do the same for LP?
Waste of time. JVM code is easier to generate than most assembly
code, and then Java's popularity gives you JIT support on all sorts of
queer architectures for free.
John Adelsberger
Adam Helps <hel...@slkc.uswest.net> wrote:
: 5. There is no player parser. All commands are defined by the objects.
This has turned out to be a poor design decision, but so was the hardnosed
centralized method now being employed in Lima, as area coders on less
centrally controlled muds are discovering already:) The probable best
solution is a hybrid of both.
: 8. Player object defines player commands like get, smile, kill, etc.
This has turned out to be a _colossal_ mistake, and the modern libs
are all redesigning to avoid it to my knowledge.
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Adam Helps <hel...@slkc.uswest.net> wrote:
: : 5. There is no player parser. All commands are defined by the objects.
: This has turned out to be a poor design decision, but so was the hardnosed
: centralized method now being employed in Lima, as area coders on less
: centrally controlled muds are discovering already:) The probable best
: solution is a hybrid of both.
The Lima decision is an excellent design decision. Language syntax is
a FIXED concept. You suggest somehow creators should be able to
change languge into their own little private system. That concept is
patently absurd.
: : 8. Player object defines player commands like get, smile, kill, etc.
: This has turned out to be a _colossal_ mistake, and the modern libs
: are all redesigning to avoid it to my knowledge.
No mudlib in the last 5 years has used a local object or player object
to define those commands.
Tim Hollebeek
In article <5qqngt$jpi$1...@darla.visi.com>, Felix A. Croes <dwo...@nospam.imaginary.com writes:
>
> Still, something like runtime morphism is a must for continuous muds. For
> DGD, I've decided on a different solution: if the root object of an
> inheritance tree is recompiled, also recompile all the other objects in the
> tree (unlike other LPC servers, DGD allows an existing object to be
> recompiled without first destructing it). Only the basic operation of
> recompiling a single object is actually supported directly by the server,
> the rest needs mudlib support. This makes changing the auto-inherited (root)
> object a painfully slow process, but that is something you'd only want to do
> during your weekly maintenance hour, anyway.
Daily reboots are bad enough; the suggestion that things should be
designed in such a way that weekly maintenance *hours* are required
bothers me. Yet another argument why persistence should be done in
the mudlib and not the driver, IMHO.
Tim Hollebeek
In article <33CFA8F9...@slkc.uswest.net>, Adam Helps <hel...@slkc.uswest.net> writes:
> >
> > Another c-interpreter doesn't sound too useful a thing at LPC-level, but
> > you can have yet another level, a scripting language or such. I have done
> > this on my mud (which is still on development, the usual case); the system
> > is used for defining actions NPCs take (normal actions, reactions to
> > external events etc). This could of course be all done in plain LPC, but this
> > way the whole 'program' is more compact, and hopefully makes it easier
> > for others to quickly see what the NPC does and when. In addition, it means
> > that a person doesn't need as much LPC-knowledge (or exact mudlib-knowledge
> > either) to implement 'smart' NPCs.
>
> Makes sense. Anybody have a favorite ideas on how to implement a
> scripting language, btw? (i.e. good commands, syntax, easy and fast
> parsing, etc.) I've thought of this before but I've never actually tried
> to make one, and I was wondering what's been done before.
Download Lima and look at LPscript.
Tim Hollebeek
In article <5qrc6v$1ab$1...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
> Adam Helps <hel...@slkc.uswest.net> wrote:
>
> : 5. There is no player parser. All commands are defined by the objects.
>
> This has turned out to be a poor design decision, but so was the hardnosed
> centralized method now being employed in Lima, as area coders on less
> centrally controlled muds are discovering already:) The probable best
> solution is a hybrid of both.
This is actually a vast mischaracterization of the Lima system, and
demonstrates the author has little or know experience with what he has
decided to criticize.
I could explain at length, but I'll simply point out that most verbs
dispatch to the objects involved quite quickly; e.g. the _parsing_ is
centralized, but the _what happens_ is not. So John's assertion that
Lima takes centralization to the extreme is just plain wrong. Most
centralized parsing systems I have seen in mudlibs are in fact _more_
centralized than Lima's.
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : To digress a tad, LP does not encourage (I don't know it well enough to say
: : it won't support) runtime morphism. ie it does not allow users at runtime
: : to modify the object heirarchy and transparently have the entire world
: : change about them as the objects and inheritance tree also change.
: It does indeed allow for this, although it requires a bit of skill in
: design to pull off reasonably. There is no reason imaginable why you
: would really want to do it on a large scale, since it would be a rare
: enough event that a reboot would hardly hurt you, but you _can_ if you
: want.
What about a game being offered requires or at least encourages user
programming by (almost?) all users. cf LambdaMOO. Or how about a standard
social simulation where the base rules of the society are being re-written
as the society evolves?
Suffice to say that for what I'm doing I expect the base object heirarchy to
morph with decent frequency (every few days) if not more often (user
programming is key to surviving the game, and the base heirachy will
reactively reo-org itself in response to user programs). I don't intend to
have to reboot the server more than yearly if that.
<<No, this is not your typical hack'n'slash Monty Haul>>
Chris Lawrence (Contra)
Felix A. Croes (dwo...@nospam.imaginary.com) wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: > To digress a tad, LP does not encourage (I don't know it well enough to say
: > it won't support) runtime morphism. ie it does not allow users at runtime
: > to modify the object heirarchy and transparently have the entire world
: > change about them as the objects and inheritance tree also change.
: On the other hand, it is debatable whether runtime morphism as implemented
: on other servers is a good thing. If the object at the root of an
: inheritance tree can change at any time, fewer assumptions can be made at
: compile-time, resulting in less efficient code; compile-time typechecking
: of inherited functions and variables/properties becomes "unencouraged";
: indeed the very <presence> of a function or variable is something that
: cannot be relied upon.
True. Or to put it another way: It **REALLY** exercised my exception code.
To a large extent it also comes down to the same chestnut as the old
type-less vs hard/soft typed languages.
: Still, something like runtime morphism is a must for continuous muds. For
: DGD, I've decided on a different solution: if the root object of an
: inheritance tree is recompiled, also recompile all the other objects in the
: tree (unlike other LPC servers, DGD allows an existing object to be
: recompiled without first destructing it). Only the basic operation of
: recompiling a single object is actually supported directly by the server,
: the rest needs mudlib support. This makes changing the auto-inherited (root)
: object a painfully slow process, but that is something you'd only want to do
: during your weekly maintenance hour, anyway.
I basically JIT it.
I took the approach of doing a quick currency check on the inheritance tree
of an object when a method is called on that object. If the compiled
inheritance tree is not current, then I recompile the object and move on.
Essentially its a JIT, but I short circuit the leaf conditions by having the
list of inheritance changes detect when the number of direct children falls
below a set value (or age) and then force recompiles for the remaining
children, (which may spawn new entries for the children of the recompiled
children). This is done to keep the change efficient for currency checks.
The result is that changing root slows down the whole game until the
current working set gets recompiled. The game then operates a slightly
slower rate from there on out for a while as new additions to the working set
get recompiled. Eventually it just all pans out and you're down to the
standard steady rate of recompiles from general user activity.
Chris Lawrence (Contra)
Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
: Daily reboots are bad enough; the suggestion that things should be
: designed in such a way that weekly maintenance *hours* are required
: bothers me. Yet another argument why persistence should be done in
: the mudlib and not the driver, IMHO.
I fail to see that putting persistance into the driver implies either
daily reboots or weekly (argh!!!) maintenance hours. Neither is
necessary.
Chris Lawrence (Contra)
George Reese (bo...@imaginary.com) wrote:
: : : To digress a tad, LP does not encourage (I don't know it well enough to say
: : : it won't support) runtime morphism. ie it does not allow users at runtime
: : : to modify the object heirarchy and transparently have the entire world
: : : change about them as the objects and inheritance tree also change.
: : It does indeed allow for this, although it requires a bit of skill in
: : design to pull off reasonably. There is no reason imaginable why you
: : would really want to do it on a large scale, since it would be a rare
: : enough event that a reboot would hardly hurt you, but you _can_ if you
: : want.
: Chris simply said that LP does not encourage it; and in fact, Chris
: would be right.
<bow>
Ahh! Support from an unexpected quarter! Well met Sirrah!
George Reese
: : Daily reboots are bad enough; the suggestion that things should be
: : designed in such a way that weekly maintenance *hours* are required
: : bothers me. Yet another argument why persistence should be done in
: : the mudlib and not the driver, IMHO.
: I fail to see that putting persistance into the driver implies either
: daily reboots or weekly (argh!!!) maintenance hours. Neither is
: necessary.
The post he was referencing stated that updating core objects takes
time and thus is best left for maintenance times. I am guessing his
point is that putting overarching persistence support in the driver is
less effective than doing it in the mudlib, where issues of what sort
of persistence matters can better be decided. No matter what the
system, not all persistence issues matter.
Chris Lawrence (Contra)
George Reese (bo...@imaginary.com) wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
: : : Daily reboots are bad enough; the suggestion that things should be
: : : designed in such a way that weekly maintenance *hours* are required
: : : bothers me. Yet another argument why persistence should be done in
: : : the mudlib and not the driver, IMHO.
: : I fail to see that putting persistance into the driver implies either
: : daily reboots or weekly (argh!!!) maintenance hours. Neither is
: : necessary.
: The post he was referencing stated that updating core objects takes
: time and thus is best left for maintenance times. I am guessing his
: point is that putting overarching persistence support in the driver is
: less effective than doing it in the mudlib, where issues of what sort
: of persistence matters can better be decided. No matter what the
: system, not all persistence issues matter.
True. My point, facetious as it was, was that the implied link between
persistance based designs and weekly maintenance hours or daily reboots
was bogus. Persistant designs can and have been made which require
neither maintenance times or regular reboots. I'm sure Tim realises this,
but his above comment gleefully doesn't. (Straw target?)
Felix A. Croes
> I basically JIT it.
>
> I took the approach of doing a quick currency check on the inheritance tree
> of an object when a method is called on that object. If the compiled
> inheritance tree is not current, then I recompile the object and move on.
> Essentially its a JIT, but I short circuit the leaf conditions by having the
> list of inheritance changes detect when the number of direct children falls
> below a set value (or age) and then force recompiles for the remaining
> children, (which may spawn new entries for the children of the recompiled
> children). This is done to keep the change efficient for currency checks.
>
> The result is that changing root slows down the whole game until the
> current working set gets recompiled. The game then operates a slightly
> slower rate from there on out for a while as new additions to the working set
> get recompiled. Eventually it just all pans out and you're down to the
> standard steady rate of recompiles from general user activity.
Suppose A and B are both at the root of separate inheritance trees. A calls
functions in B, or rather, objects inheriting from A call functions in
objects inheriting from B through the interfaces inherited from A and B.
Only A calls these functions.
I want to change the interface of B. To ensure that calls from A do not go
awry, I recompile A and B at the same time (or in the same thread without
any intervening code). Now assume that this recompile is done from a thread
which passes through B, a few stack frames back.
- If B changes instantly, then the stack frame for the function in B might
no longer be valid.
- If B changes instantly but the stack frames that use it remain tied to the
old version, then a newly changed A might attempt to call a function in this
old B.
- If this is solved by postponing the actual replacement of code for A and B
until the end of the thread (DGD does this), then JIT compiling
reintroduces the problem: not all compilations happen during the same
thread, so it is possible for a new A to call a function in an old B.
How do you deal with the above situation?
Regards,
Dworkin
Tim Hollebeek
In article <5r0q9k$e2q$2...@ocean.cup.hp.com>, claw...@cup.hp.com writes:
> George Reese (bo...@imaginary.com) wrote:
> : Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
> : : Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
>
> : : : Daily reboots are bad enough; the suggestion that things should be
> : : : designed in such a way that weekly maintenance *hours* are required
> : : : bothers me. Yet another argument why persistence should be done in
> : : : the mudlib and not the driver, IMHO.
>
> [...]
>
> True. My point, facetious as it was, was that the implied link between
> persistance based designs and weekly maintenance hours or daily reboots
> was bogus. Persistant designs can and have been made which require
> neither maintenance times or regular reboots. I'm sure Tim realises this,
> but his above comment gleefully doesn't. (Straw target?)
Straw target indeed. If you look carefully, you'll see that I said
that a design that requires maintenance hours is bad, not that
persistence is bad, and that persistence should be done in the mudlib
in order to _avoid_ the problems.
I think the confusion was caused by the fact that 'design' in my post
means "the way persistence is implemented" and not "the fact that
things persist".
Tim Hollebeek
In article <doomdark....@snakemail.hut.fi>, doom...@piano.hut.fi writes:
>
> Btw, have you (or some other GD-implementor) thought about changing
> string datatype to contain length information in svalue? (btw, I'm not
> familiar with MudOS, so hopefully I'm not asking FAQ-stuff) I mean,
> when accessing parts of strings, GD always seems to do strlen() to make
> sure it's not indexing outside the string. And when you have long strings,
> scanning for ending \0 probably takes some time (cache helps a lot etc
> but still)... Without any gain (except for saving 4 bytes or so that
> length-information would use, minus one byte used to mark the end).
Yes, in fact I changed this in MudOS about one or two years ago. Calls to
strlen() are actually quite rare now; I think there are only one or two in
the entire source tree. This is one of the reasons why MudOS tends to beat
the pants off 3.2[.1] in string benchmarks. Even the nonshared ones now
how refcounts, so the number of string_copy()'s is also drastically lower.
This also saves a nontrivial amount of memory.
> >DGD is similar, but does a bit more inference and manages to convert
> >some common constructs and also does a better job of eliminating
> >runtime type checks, IIRC.
>
> Perhaps one could optimize the looping constructs? Although, whether
> it's worth the hassle is another thing.
Both MudOS and 3.2[.1] (IIRC) have opcodes for common loop structures;
it was added to MudOS 3 or 4 years ago, and migrated to 3.2 at some point.
> codefor for (int i = 0; i < 10; i++) {}
;; Function eval
0000: const0
0001: (void)assign_local LV0 // assignments to locals is optimized too
0003: branch 0004 (0008)
0006: loop_incr LV0 // the loop is only two instructions; the
// increment and the conditional branch.
// This next one is by far MudOS's
// hairiest opcode; it takes 8 bytes.
0008: loop_cond_number LV0 < 10 bbranch_when_non_zero 0008 (0006)
0010: return_zero // this case optimized too since it
// is also the return for void functions.
LPs tend to be pathetically highly optimized due to the LP/MudOS speed war
of several years ago. This is what makes the Diku crowd's "LPC is too
slow" arguments so pathetic. Slow LPmuds are almost always due to badly
written mudlibs, not inherent limitations of LPC itself.
> >You really need to keep the stack machine around if you want to be
> >able to arbitrarily intermix LPC and C programs (though I believe DGD
> >actually disallows this in some cases; i.e. programs inherited by
> >compiled programs must be compiled, or something like that) which I
> >consider to be an important goal. IMO, the noticeable only difference
> >should be the speed.
>
> Yes, in ideal situation speed should be the only difference. Although,
> the restriction (compiled can only inherit compiled code) doesn't sound
> too bad because you probably mostly do compile often inherited (and used)
> base objects?
Yeah, except that for example you might have an area object with a
computational "hot spot" you want to speed up. If that means you have
to compile the entire object hierarchy, you may be f'ed.
John Adelsberger
Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
: > This has turned out to be a poor design decision, but so was the hardnosed
: > centralized method now being employed in Lima, as area coders on less
: > centrally controlled muds are discovering already:) The probable best
: > solution is a hybrid of both.
: This is actually a vast mischaracterization of the Lima system, and
: demonstrates the author has little or know experience with what he has
: decided to criticize.
Yeah, reading the source wouldn't give me any idea of how it works. I'm
just impaired that way:) Actually, rather than turn this into a
flamewar with a guy I really do respect, I'll just say that I _think_
this is a misunderstanding. See below:)
: I could explain at length, but I'll simply point out that most verbs
: dispatch to the objects involved quite quickly; e.g. the _parsing_ is
: centralized, but the _what happens_ is not. So John's assertion that
: Lima takes centralization to the extreme is just plain wrong. Most
: centralized parsing systems I have seen in mudlibs are in fact _more_
: centralized than Lima's.
The point is, while it works well for your ZorkMUD, which is basically
you and some friends and a few others, and a _very_ tight theme, it
doesn't work so well if there is a genuine need on the part of area
coders on a highly decentralized power structure to, say, add a verb.
I didn't say the code was inefficient; I said the result is a bad
_policy_ move for a _traditional_ mud, as opposed to ZorkMUD:-)
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
: : > This has turned out to be a poor design decision, but so was the hardnosed
: : > centralized method now being employed in Lima, as area coders on less
: : > centrally controlled muds are discovering already:) The probable best
: : > solution is a hybrid of both.
: : This is actually a vast mischaracterization of the Lima system, and
: : demonstrates the author has little or know experience with what he has
: : decided to criticize.
: Yeah, reading the source wouldn't give me any idea of how it works. I'm
: just impaired that way:) Actually, rather than turn this into a
: flamewar with a guy I really do respect, I'll just say that I _think_
: this is a misunderstanding. See below:)
There is no misunderstanding. You Beek are completely not in
agreement. And Beek is right.
: : I could explain at length, but I'll simply point out that most verbs
: : dispatch to the objects involved quite quickly; e.g. the _parsing_ is
: : centralized, but the _what happens_ is not. So John's assertion that
: : Lima takes centralization to the extreme is just plain wrong. Most
: : centralized parsing systems I have seen in mudlibs are in fact _more_
: : centralized than Lima's.
: The point is, while it works well for your ZorkMUD, which is basically
: you and some friends and a few others, and a _very_ tight theme, it
: doesn't work so well if there is a genuine need on the part of area
: coders on a highly decentralized power structure to, say, add a verb.
: I didn't say the code was inefficient; I said the result is a bad
: _policy_ move for a _traditional_ mud, as opposed to ZorkMUD:-)
So you have a need to allow your creators to dynamically define the
English language as they go? That is truly bizarre.
There is no need to dynamically add verbs. The language that people
use is fairly static and unchanging--it belongs centrally maintained.
Only the events that occur as a result to those actions are fluid and
dynamic. The MudOS parser as used by both NM and Lima supports the
centralized language structure with the fluidity of events.
Again, since you believe you make no baseless claims, I invite you to
define a situation in which a creator should be able to add a verb to
the system just for one room. Language does not work that way. If
the command is valid in one place, it is valid in all places. It is
just that different things happen in different places. The NM and
Lima systems both allow different things to happen in different places
without allowing the stupidity of people defining their own private
language.
Chris Lawrence (Contra)
Apologies for the long quote -- I felt context was needed.
Felix A. Croes (dwo...@nospam.imaginary.com) wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: > I basically JIT it.
: the old B.
: - If this is solved by postponing the actual replacement of code for A and B
: until the end of the thread (DGD does this), then JIT compiling
: reintroduces the problem: not all compilations happen during the same
: thread, so it is possible for a new A to call a function in an old B.
: How do you deal with the above situation?
Its actually fairly transparent for me as my base server is multi-threaded.
Taking the relationship between objects A and B etc as described above:
I don't share code segments between code segments for MUDlib objects
between threads/events. This prevents the stack frame problems you identify
(outside of the fact that I don't really run a stack based system). Instead,
as each event requests a method from an object a read only copy of that
object is provided for the event. This provides most of the solution for
your last problem (the old code being called) as a side effect of my lockless
DB system:
-- When the event which is calling the old version of B terminates and
attempts to commit, it fails due to one of its object dependancies (B in
this case) having changed in the interim. So, the event fails to commit
and is rescheduled to try again, now with the new versions of the requisite
objects.
-- (This only applies to the case where A references the exact object which
was changed). When the change to B occurs and is committed, change
notification messages are sent to all events which currently reference B
(members of its interested party list). This acts as an early warning
system to the event that it will likely fail to commit.
This still leaves a corner case open:
The objects are A, B and C.
A and C are children of B.
A references methods on C.
An event X is executing which calls A, which in turn calls C.
B is changed (method code altered).
The modify B event commits successfully.
The potential problem is that there is an implicit race condition for which
versions of A and C get loaded. If A's copy gets referenced pre-change,
and C's post-change, event X could have two implicitly different versions
of B loaded. This gets detected by the JIT code when C attempts to call
an method inherited from B. It attempts to rebuild the inheritance tree
for C, finds that it already has a state-dated version of B incontext (per
the tags on C), and thus invalidates the entire event, which dies and
reschedules.
Tim Hollebeek
In article <5r3321$3ct$1...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
> Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
>
> : > This has turned out to be a poor design decision, but so was the hardnosed
> : > centralized method now being employed in Lima, as area coders on less
> : > centrally controlled muds are discovering already:) The probable best
> : > solution is a hybrid of both.
>
> : This is actually a vast mischaracterization of the Lima system, and
> : demonstrates the author has little or know experience with what he has
> : decided to criticize.
>
> Yeah, reading the source wouldn't give me any idea of how it works. I'm
> just impaired that way:)
No, reading the source wouldn't. Writing it might. Oh, woops; I did
that, not you.
> : I could explain at length, but I'll simply point out that most verbs
> : dispatch to the objects involved quite quickly; e.g. the _parsing_ is
> : centralized, but the _what happens_ is not. So John's assertion that
> : Lima takes centralization to the extreme is just plain wrong. Most
> : centralized parsing systems I have seen in mudlibs are in fact _more_
> : centralized than Lima's.
>
> The point is, while it works well for your ZorkMUD, which is basically
> you and some friends and a few others, and a _very_ tight theme, it
> doesn't work so well if there is a genuine need on the part of area
> coders on a highly decentralized power structure to, say, add a verb.
> I didn't say the code was inefficient; I said the result is a bad
> _policy_ move for a _traditional_ mud, as opposed to ZorkMUD:-)
And you're still wrong. The addition of random verbs by area wizards
doesn't allow anything other than "syntax quests" which are hell for
players. Evidentally you have a poor understanding of both the Lima
parser, and why your original comments are wrong (see my response,
which you haven't rebutted at all) and the concepts in
/doc/wizard/design_decisions/add_action.
For the record, you actually can do something very add_action-like
with Lima with almost no modifications. I'm not going to tell you
how, though, since all you will manage to do is add a bunch of
inconsistent verb handling and "guess the verb" problems. Besides, if
you understand the parser as well as you claim, it should be trivial
for you to figure out what I'm alluding to. After you've figured that
out, you can tell me what prevents an area coder from adding a new
verb to a stock Lima lib (hint: nothing). Running MUDs probably want
to restrict this a bit more (e.g. to the domain level or something).
Lima actually makes _fewer_ policy decisions for you than the average
mudlib. What we _do_ give you is a clean design, instead of a
complete mess to start with. If you want to/need to/can't avoid
fucking it up, that's your problem. If you start working on it with
such a poor understanding of why it is the way it is, and why that is
superior to the way things are traditionally done, and try to make
everything conform to your preconceived notion of the way things are
done best (i.e. "the way we've _always_ done them") then I guarantee
you will end up with a mess.
Your posts spread completely uninformed lies about something you have
demonstrated you have a very, very poor understanding of, so if you
really have so much respect for me, it would be nice if you would
quit. An apology would be nice, too, but you don't seem that
rational, and I'm my expectations are probably quite a bit too high.
Chris Lawrence (Contra)
George Reese (bo...@imaginary.com) wrote:
: Again, since you believe you make no baseless claims, I invite you to
: define a situation in which a creator should be able to add a verb to
: the system just for one room. Language does not work that way. If
: the command is valid in one place, it is valid in all places. It is
: just that different things happen in different places. The NM and
: Lima systems both allow different things to happen in different places
: without allowing the stupidity of people defining their own private
: language.
Carefully avoiding the flammage:
What about a world context which defines possible actions which not only
are impssible elsewhere. but which have no possible frame of reference
there? Specifically I'm looking at the case where a verb from one locale
in the MUD world actually has no possible expression in another reference
frame, where the key is that a single server is presenting two (entirely?)
distinct language reference frames.
example: Your typical fake medieval world with a partner spirit world
which is navigated by reference to "like <object>" and "dislike <object>"
to move toward or away from identities, and where all other actions are
defined in terms of flows.
Sure, you could have the bogus frame merely report a, "that doesn't work
here," but that's a little presumptive, no?
George Reese
: Carefully avoiding the flammage:
In the MudOS parser system, <object> determines how it respondes to
'like' and 'dislike' events. Thus in your spirit world, they would
behave one way and in the 'real' world they would behave another.
This is in fact a global situation. The default behavious i 'that
doesn't work here'. But that is presumptive of nothing since at any
point a cre can redefine that behaviour. The advantage of the global
verb is:
#1 A player knows that command exists no matter where they are. They
can easily pull it up and get help on it. There are no guessing games
because they are in a different area.
#2 While the original vision for the verb may have been limited to
that one spiritual area, you have now given cres the tool to make use
the like and dislike commands in a way that is 100% consistent with
the syntax of the existing ones.
#3 You lose absolutely nothing over the 'willy-nilly' command systems
like add_action()
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Distribution:
: Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
: : > Yeah, reading the source wouldn't give me any idea of how it works. I'm
: : > just impaired that way:)
: : No, reading the source wouldn't. Writing it might. Oh, woops; I did
: : that, not you.
: If you can't read code and comprehend what it does, even if it takes
: awhile, I pity you, but given your history of writing MudOS and so on,
: I just don't believe that, so you must know that comprehension of a thing
: is possible without writing it from scratch. I think you need to mellow
: out a bit - I still think you're basically a good guy, but this post I'm
: replying to sounds like Reese more than like you.
Where Reese == disagree with you?
: : parser, and why your original comments are wrong (see my response,
: : which you haven't rebutted at all) and the concepts in
: : /doc/wizard/design_decisions/add_action.
: Oh, I do understand it; I just think you underestimate the variety of
: verbs area coders are going to find useful. Surely you don't want
: to maintain a central repository of at least one of each possible set
: of synonyms that might be useful in a mud?
I thought you said you read the code? Synonyms are a one line
addition.
: If not, then a hardnosed
: no add policy is not going to work for large decentralized muds. On
: the other hand, allowing adding, but requiring the add to be global
: and to have a standard default fail and so on _will._
Bah, you don't know what you are talking about.
#1 MudOS verbs are global and can be added at will. This is actually
a problem, IMHO, because it makes testing verbs difficult.
#2 Centralized systems work very well. Nightmare is a very successful
system that manages the centralized addition of verbs into the game.
: : For the record, you actually can do something very add_action-like
: : with Lima with almost no modifications. I'm not going to tell you
: : how, though, since all you will manage to do is add a bunch of
: : inconsistent verb handling and "guess the verb" problems. Besides, if
: If it requires mods, who cares? I'm not into maintaining modded versions
: of someone elses parser for the same reason I'm not into maintaining
: modded drivers. It's stupid, its too mcuh work to upgrade, and if I care
: that much, I can write my own.
So you would rather the piece of shit that is add_action()?
: : you understand the parser as well as you claim, it should be trivial
: : for you to figure out what I'm alluding to. After you've figured that
: : out, you can tell me what prevents an area coder from adding a new
: : verb to a stock Lima lib (hint: nothing). Running MUDs probably want
: : to restrict this a bit more (e.g. to the domain level or something).
: When you decide to behave in a semicivilized fashion, mail me about it.
: Until then, I respect your driver(and use it) but I have no desire to
: discuss with you, because whenever anyone disagrees with you, you
: behave like a spoiled child.
How is he behaving like a spoiled child? Nothing prevents area
creators from adding a very to either stock Nightmare or stock Lima
muds. Nothing whatsoever. Him pointing that out for Lima is
childish when you are ignorantly stating the contrary?
: : Lima actually makes _fewer_ policy decisions for you than the average
: : mudlib. What we _do_ give you is a clean design, instead of a
: I know. That's why I respect Lima; do you really need to be so
: defensive?
You are slamming one of the main architectural design decisions based
on zero information. I expect that he has every right to defend those
decisions against your moronic attacks.
: : complete mess to start with. If you want to/need to/can't avoid
: : fucking it up, that's your problem. If you start working on it with
: : such a poor understanding of why it is the way it is, and why that is
: : superior to the way things are traditionally done, and try to make
: : everything conform to your preconceived notion of the way things are
: : done best (i.e. "the way we've _always_ done them") then I guarantee
: : you will end up with a mess.
: But I don't want to use it; I'm writing my own. You seem to miss a
: lot by assuming things you don't know.
You and every one else. And the percentage who end up with completed
mudlibs? I would venture something like 1%.
: : Your posts spread completely uninformed lies about something you have
: : demonstrated you have a very, very poor understanding of, so if you
: : really have so much respect for me, it would be nice if you would
: : quit. An apology would be nice, too, but you don't seem that
: : rational, and I'm my expectations are probably quite a bit too high.
: I respect your programming and design skills. Apparently you have
: no ability whatsoever to have a reasonable discussoin with anyone who
: disagrees with you on anything you care about at all, though, and I
: question therefore your attempt to preempt the term 'rational' for your
: use. When you can actually interact with the grace of, say, a 16 year
: old, make sure you tell everyone about it.
: As for Lima, yes, it is a good mudlib. No, I don't think everything about
: it is wonderful and perfect. If that's such an insult to your very
: existance, then be insulted; such is your problem, not mine.
I cannot speak for Beek, but knowing him, I doubt he would have a
problem if you were making a valid criticism. The fact is, however,
your criticism has been shown to be baseless; one you make without
having the slightest understanding of the system you are criticizing.
You have a track record of this, and it is growing at an
unprecendented pace.
John Adelsberger
George Reese <bo...@imaginary.com> wrote:
: John Adelsberger <j...@umr.edu> wrote:
: : This has turned out to be a poor design decision, but so was the hardnosed
: : centralized method now being employed in Lima, as area coders on less
: : centrally controlled muds are discovering already:) The probable best
: : solution is a hybrid of both.
: The Lima decision is an excellent design decision. Language syntax is
: a FIXED concept. You suggest somehow creators should be able to
: change languge into their own little private system. That concept is
: patently absurd.
I suggest no such thing. When you decide to take the flame stick out
of your ass and pretend you're a human being with a brain, you'll see
this. What I _did_ suggest is that regardless of the neatness of not
allowing area coders to completely define the behavior of verbs, in
Lima, only admins can even _add_ a verb at all, and this would be a
disaster on a large mud with many coders and overworked admins.
: : : 8. Player object defines player commands like get, smile, kill, etc.
: : This has turned out to be a _colossal_ mistake, and the modern libs
: : are all redesigning to avoid it to my knowledge.
: No mudlib in the last 5 years has used a local object or player object
: to define those commands.
The DW player ob as of last year still had something like 20 add_actions
in it. Not for smile, I grant, but so what? Also, while I am guessing
you are right, where did you get complete knowledge of every mudlib
written in the last 5 years? Oh, you didn't; you're just full of shit.
John Adelsberger
Distribution:
Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
: > Yeah, reading the source wouldn't give me any idea of how it works. I'm
: > just impaired that way:)
: No, reading the source wouldn't. Writing it might. Oh, woops; I did
: that, not you.
If you can't read code and comprehend what it does, even if it takes
awhile, I pity you, but given your history of writing MudOS and so on,
I just don't believe that, so you must know that comprehension of a thing
is possible without writing it from scratch. I think you need to mellow
out a bit - I still think you're basically a good guy, but this post I'm
replying to sounds like Reese more than like you.
: And you're still wrong. The addition of random verbs by area wizards
: doesn't allow anything other than "syntax quests" which are hell for
: players. Evidentally you have a poor understanding of both the Lima
If you don't like syntax quests(I don't either, but thats beside my point)
why are you simulating Zork, a game by people infamous for such?
: parser, and why your original comments are wrong (see my response,
: which you haven't rebutted at all) and the concepts in
: /doc/wizard/design_decisions/add_action.
Oh, I do understand it; I just think you underestimate the variety of
verbs area coders are going to find useful. Surely you don't want
to maintain a central repository of at least one of each possible set
of synonyms that might be useful in a mud? If not, then a hardnosed
no add policy is not going to work for large decentralized muds. On
the other hand, allowing adding, but requiring the add to be global
and to have a standard default fail and so on _will._
: For the record, you actually can do something very add_action-like
: with Lima with almost no modifications. I'm not going to tell you
: how, though, since all you will manage to do is add a bunch of
: inconsistent verb handling and "guess the verb" problems. Besides, if
If it requires mods, who cares? I'm not into maintaining modded versions
of someone elses parser for the same reason I'm not into maintaining
modded drivers. It's stupid, its too mcuh work to upgrade, and if I care
that much, I can write my own.
: you understand the parser as well as you claim, it should be trivial
: for you to figure out what I'm alluding to. After you've figured that
: out, you can tell me what prevents an area coder from adding a new
: verb to a stock Lima lib (hint: nothing). Running MUDs probably want
: to restrict this a bit more (e.g. to the domain level or something).
When you decide to behave in a semicivilized fashion, mail me about it.
Until then, I respect your driver(and use it) but I have no desire to
discuss with you, because whenever anyone disagrees with you, you
behave like a spoiled child.
: Lima actually makes _fewer_ policy decisions for you than the average
: mudlib. What we _do_ give you is a clean design, instead of a
I know. That's why I respect Lima; do you really need to be so
defensive?
: complete mess to start with. If you want to/need to/can't avoid
: fucking it up, that's your problem. If you start working on it with
: such a poor understanding of why it is the way it is, and why that is
: superior to the way things are traditionally done, and try to make
: everything conform to your preconceived notion of the way things are
: done best (i.e. "the way we've _always_ done them") then I guarantee
: you will end up with a mess.
But I don't want to use it; I'm writing my own. You seem to miss a
lot by assuming things you don't know.
: Your posts spread completely uninformed lies about something you have
: demonstrated you have a very, very poor understanding of, so if you
: really have so much respect for me, it would be nice if you would
: quit. An apology would be nice, too, but you don't seem that
: rational, and I'm my expectations are probably quite a bit too high.
I respect your programming and design skills. Apparently you have
no ability whatsoever to have a reasonable discussoin with anyone who
disagrees with you on anything you care about at all, though, and I
question therefore your attempt to preempt the term 'rational' for your
use. When you can actually interact with the grace of, say, a 16 year
old, make sure you tell everyone about it.
As for Lima, yes, it is a good mudlib. No, I don't think everything about
it is wonderful and perfect. If that's such an insult to your very
existance, then be insulted; such is your problem, not mine.
--
John Adelsberger
Distribution:
George Reese <bo...@imaginary.com> wrote:
: There is no misunderstanding. You Beek are completely not in
: agreement. And Beek is right.
He should probably speak for himself. I doubt he likes being spoken for
by morons.
: So you have a need to allow your creators to dynamically define the
: English language as they go? That is truly bizarre.
Well, it's either that, or I have to put the entire Websters Dictionary
in my mudlib. Guess which one I would prefer?
: There is no need to dynamically add verbs. The language that people
: use is fairly static and unchanging--it belongs centrally maintained.
Only if you intend to maintain a _large_ base of verbs; if your mudlib
is for distribution, you have only 3 choices in this case:
1) distribute it with many, many verbs(the dictionary thing was a joke,
and I'm sure you'll pretend it wasn't b/c you're a dick, but still:)
2) don't, and make everyone who wants to use it spend a _lot_ of boring
time doing his own - this is so stupid deserves to be titled as the
"Reese way."
3) Be like Reese, and just pull your mudlib from distribution.
: Only the events that occur as a result to those actions are fluid and
: dynamic. The MudOS parser as used by both NM and Lima supports the
: centralized language structure with the fluidity of events.
Provided of course, that there is a verb available that means what
a given coder wants. If not, either the coder is screwed, or else
an admin has to modify the lib just to support some area. Can you
say stupid? It's spelled "R E E S E."
: Again, since you believe you make no baseless claims, I invite you to
: define a situation in which a creator should be able to add a verb to
: the system just for one room. Language does not work that way. If
: the command is valid in one place, it is valid in all places. It is
But you see, I advocated a hybrid system, not the DW like one. Perhaps
if you'd quit attacking straw men? The fact of the matter is that I
think that verbs _should_ be addable, should have a standard default
failure message which should be overridable, but should be global when
added. There are a few more little details I'd thrown in to meet my own
idea of how a mud's coder structure should work, but they aren't general
enough to be worth discussing here.
: just that different things happen in different places. The NM and
: Lima systems both allow different things to happen in different places
: without allowing the stupidity of people defining their own private
: language.
Comparing your pathetic attempt at a mudlib to Lima is a joke; while
I disagree with a few of the design choices in Lima, that lib was
designed, as opposed to being grown in a dish along with some nasty
fungi. No, George, nobody is ripping off your code; yes, thousands of
copies probably do still exist all over the place - I used to have one,
but then I read some of it, and it had to go.
George Reese
John Adelsberger <j...@umr.edu> wrote:
: : : This has turned out to be a poor design decision, but so was the hardnosed
: : : centralized method now being employed in Lima, as area coders on less
: : : centrally controlled muds are discovering already:) The probable best
: : : solution is a hybrid of both.
: : The Lima decision is an excellent design decision. Language syntax is
: : a FIXED concept. You suggest somehow creators should be able to
: : change languge into their own little private system. That concept is
: : patently absurd.
: I suggest no such thing. When you decide to take the flame stick out
: of your ass and pretend you're a human being with a brain, you'll see
: this. What I _did_ suggest is that regardless of the neatness of not
: allowing area coders to completely define the behavior of verbs, in
: Lima, only admins can even _add_ a verb at all, and this would be a
: disaster on a large mud with many coders and overworked admins.
Exhibit 951 of why you talk out of your ass.
The MudOS parser system does not require admins to add verbs. Anyone
with write access to a directory can add a verb.
Furthermore, it is not a huge burden on admins to ask them to QC new
verbs. If they do not have the time to do that, they do not have the
time to run a mud.
: : : : 8. Player object defines player commands like get, smile, kill, etc.
: : : This has turned out to be a _colossal_ mistake, and the modern libs
: : : are all redesigning to avoid it to my knowledge.
: : No mudlib in the last 5 years has used a local object or player object
: : to define those commands.
: The DW player ob as of last year still had something like 20 add_actions
: in it. Not for smile, I grant, but so what? Also, while I am guessing
: you are right, where did you get complete knowledge of every mudlib
: written in the last 5 years? Oh, you didn't; you're just full of shit.
DW is just around 5 years old, give or take 6 months. Try again for a
real example.
John Adelsberger
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: What about a game being offered requires or at least encourages user
: programming by (almost?) all users. cf LambdaMOO. Or how about a standard
: social simulation where the base rules of the society are being re-written
: as the society evolves?
This will require a slow evolution, not frequent alterations of the most
basic parts of the game. How often is any user going to change the way
connections ar handled? He is not, probably ever. The fact that MOO
emulation exists for DGD and could be done for MudOS, and works rather
well from what I've heard(which was not a complete report, I admit)
kinda makes my point, but an even better way of making it is this:
I admin on a mud on which for months I had no shell access; I was
able to, and still frequently do, make alterations to the most basic
stuff in the game, from within it.
: Suffice to say that for what I'm doing I expect the base object heirarchy to
: morph with decent frequency (every few days) if not more often (user
: programming is key to surviving the game, and the base heirachy will
: reactively reo-org itself in response to user programs). I don't intend to
: have to reboot the server more than yearly if that.
If user programming is required to survive, your playerbase should be
interesting people:)
Chris Lawrence (Contra)
George Reese (bo...@imaginary.com) wrote:
: ... The fact is, however,
: your criticism has been shown to be baseless; one you make without
: having the slightest understanding of the system you are criticizing.
: You have a track record of this, and it is growing at an
: unprecendented pace.
I would *love* to see the top 10 list...
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Distribution:
: George Reese <bo...@imaginary.com> wrote:
: : There is no misunderstanding. You Beek are completely not in
: : agreement. And Beek is right.
: He should probably speak for himself. I doubt he likes being spoken for
: by morons.
I talk to Beek every day. I understand his parser design as good as
anyone.
: : So you have a need to allow your creators to dynamically define the
: : English language as they go? That is truly bizarre.
: Well, it's either that, or I have to put the entire Websters Dictionary
: in my mudlib. Guess which one I would prefer?
No doubt, since you seriously seem to have no idea how many verbs it
takes to support a robust mud environment. The answer is not very
many.
And what happens when you need to add a new one?
* Well, you can follow your example and let an area creator willy-nilly
define a new action that is 100% not reusable, does not integrate into
the muds help systems or anything else that suggests to a player that
the new verb even exists, and whose parsing capabilities are dependent
on area coders (better area coders == more complex syntaxes, novice
area coders == simplistic syntaxes).
* The other options is to centrally define that verb, make it so
everyone else in the mud can use it, players are immediately aware of
its existence and know its syntax which is consistent across the
entire mud.
Both options require the exact same amount of coding for the first
time the verb is used on the mud. The second solution requires
significantly less coding for subsequent uses.
Which solution is more likely to create a quality mud?
: : There is no need to dynamically add verbs. The language that people
: : use is fairly static and unchanging--it belongs centrally maintained.
: Only if you intend to maintain a _large_ base of verbs; if your mudlib
: is for distribution, you have only 3 choices in this case:
: 1) distribute it with many, many verbs(the dictionary thing was a joke,
: and I'm sure you'll pretend it wasn't b/c you're a dick, but still:)
I am aware the dictionary thing is a joke. The point you are trying
to make however is that you seem to think it takes a hell of a lot of
verbs to support a mud. It does not.
: 2) don't, and make everyone who wants to use it spend a _lot_ of boring
: time doing his own - this is so stupid deserves to be titled as the
: "Reese way."
Let me know when you have ever seen a completed mudlib of mine. I
know for a fact you have not, so you certainly have no idea what *my*
way is.
: 3) Be like Reese, and just pull your mudlib from distribution.
What is wrong with pulling the lib from distribution? Sounds like you
got a case of sour grapes.
: : Only the events that occur as a result to those actions are fluid and
: : dynamic. The MudOS parser as used by both NM and Lima supports the
: : centralized language structure with the fluidity of events.
: Provided of course, that there is a verb available that means what
: a given coder wants. If not, either the coder is screwed, or else
: an admin has to modify the lib just to support some area. Can you
: say stupid? It's spelled "R E E S E."
What a witty person you are.
You just don't seem to have the faintest idea of how quality control
works, even more so, no idea of how the parser works.
* The parser system has no concept of area. Anyone can code a verb
and it becomes immediately available to the whole world.
* Nightmare *mud* mandates that only mudlib adds new verbs. This is
for QC purposes, because we believe verbs should be coded in a
reusable, OO fashion. This makes certain that command syntax is is
consistent for all verbs on the mud.
: : Again, since you believe you make no baseless claims, I invite you to
: : define a situation in which a creator should be able to add a verb to
: : the system just for one room. Language does not work that way. If
: : the command is valid in one place, it is valid in all places. It is
: But you see, I advocated a hybrid system, not the DW like one. Perhaps
: if you'd quit attacking straw men? The fact of the matter is that I
: think that verbs _should_ be addable, should have a standard default
: failure message which should be overridable, but should be global when
: added. There are a few more little details I'd thrown in to meet my own
: idea of how a mud's coder structure should work, but they aren't general
: enough to be worth discussing here.
I am attacking your non-points. And you have no point here. I refer
above to my analysis of the situations.
: : just that different things happen in different places. The NM and
: : Lima systems both allow different things to happen in different places
: : without allowing the stupidity of people defining their own private
: : language.
: Comparing your pathetic attempt at a mudlib to Lima is a joke; while
: I disagree with a few of the design choices in Lima, that lib was
: designed, as opposed to being grown in a dish along with some nasty
: fungi. No, George, nobody is ripping off your code; yes, thousands of
: copies probably do still exist all over the place - I used to have one,
: but then I read some of it, and it had to go.
Given that you have demonstrated your complete incompetence with
respect to mud design time and time again, your assessment of my
mudlib means nothing to me.
Tim Hollebeek
In article <5r3nvj$elf$1...@ocean.cup.hp.com>, claw...@cup.hp.com writes:
>
> example: Your typical fake medieval world with a partner spirit world
> which is navigated by reference to "like <object>" and "dislike <object>"
> to move toward or away from identities, and where all other actions are
> defined in terms of flows.
>
> Sure, you could have the bogus frame merely report a, "that doesn't work
> here," but that's a little presumptive, no?
You really think players will appreciate you "playing dumb" and giving them
a generic error message when you know exactly what they were trying to do
and could give a helpful one?
Tim Hollebeek
In article <5r5jmu$ebl$1...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
> Distribution:
>
> Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
>
> : > Yeah, reading the source wouldn't give me any idea of how it works. I'm
> : > just impaired that way:)
>
> : No, reading the source wouldn't. Writing it might. Oh, woops; I did
> : that, not you.
>
> If you can't read code and comprehend what it does, even if it takes
> awhile, I pity you, but given your history of writing MudOS and so on,
> I just don't believe that, so you must know that comprehension of a thing
> is possible without writing it from scratch.
Given that you have proved in this thread you have very little if any
understanding of the code, you either didn't read it, or you can't
understand things based on reading them. You go figure out what your
problem is.
I've used a number of concrete arguments to point out why your
original statement is wrong. You seem unable to comprehend them,
since your only responses so far have been garbage. After a few
attempts to explain things to irrational morons, I give up, and you
are inches from being added to my kill file.
> If you don't like syntax quests(I don't either, but thats beside my point)
> why are you simulating Zork, a game by people infamous for such?
Compared to traditional LPs??? That assertion is laughable.
[stuff which completely misses the point delted]
> : For the record, you actually can do something very add_action-like
> : with Lima with almost no modifications. I'm not going to tell you
> : how, though, since all you will manage to do is add a bunch of
> : inconsistent verb handling and "guess the verb" problems. Besides, if
>
> If it requires mods, who cares? I'm not into maintaining modded versions
> of someone elses parser for the same reason I'm not into maintaining
> modded drivers. It's stupid, its too mcuh work to upgrade, and if I care
> that much, I can write my own.
Which part of "almost no" did you not understand? We're talking a handful
of lines here. If you can't deal with that, you shouldn't be running a MUD.
> When you decide to behave in a semicivilized fashion, mail me about it.
I have no interest in talking to someone who cannot understand fairly
basic concepts anyway. No big loss.
> I respect your programming and design skills. Apparently you have
> no ability whatsoever to have a reasonable discussoin with anyone who
> disagrees with you on anything you care about at all, though, and I
> question therefore your attempt to preempt the term 'rational' for your
> use. When you can actually interact with the grace of, say, a 16 year
> old, make sure you tell everyone about it.
This is bullshit. I started with rational arguments about why your
position was completely wrong, and you started whining and throwing in
personal attacks, instead of responding to them. I guess I will put
you in my killfile so I can continue to discuss things reasonably with
the more rational members of this newsgroup.
People log onto Lima and criticise various elements of its design all
the time; many times I agree with them or just agree to disagree. I
have little patience for the pathetic losers who whine about
add_action being missing just because they don't understand how the
parser works, and still can't figure it out when it is explained to
them. Their loss, not mine. I don't want closeminded idiots like
that using Lima anyway.
Chris Lawrence (Contra)
John Adelsberger (j...@umr.edu) wrote:
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: : What about a game being offered requires or at least encourages user
: : programming by (almost?) all users. cf LambdaMOO. Or how about a standard
: : social simulation where the base rules of the society are being re-written
: : as the society evolves?
: This will require a slow evolution, not frequent alterations of the most
: basic parts of the game.
Nope. Try again.
: How often is any user going to change the way
: connections ar handled? He is not, probably ever.
Connection objects aren't really a base heirarchy as far as the game is
concerned. They exist off to the side in a seperately rooted tree that
handles IO. Things like $Object, $Container, $Thing, $Room, $*_Group,
$Body, etc are key heirachy components rooted in the main heirarchy
whose immediate children will be changing rapidly.
: The fact that MOO
: emulation exists for DGD and could be done for MudOS, and works rather
: well from what I've heard(which was not a complete report, I admit)
: kinda makes my point, but an even better way of making it is this...
I'm not discussing MOO above. Why are you?
: I admin on a mud on which for months I had no shell access; I was
: able to, and still frequently do, make alterations to the most basic
: stuff in the game, from within it.
Not a big claim. Was it run-time morphic? Did it offer full persistance?
: : Suffice to say that for what I'm doing I expect the base object heirarchy
: : to morph with decent frequency (every few days) if not more often (user
: : programming is key to surviving the game, and the base heirachy will
: : reactively reo-org itself in response to user programs). I don't intend
: : to have to reboot the server more than yearly if that.
: If user programming is required to survive, your playerbase should be
: interesting people:)
Quite. In many ways it is coming to barely resemble the current style of
MUDs: perma-death, free user programming, goal oriented, highly malleable
world, implicit energy/magic economy (all the standard conservation laws),
skill web, seperation of "soul" and body, support for body stealing, mental
fights and multiple bodies per character (swarm bodies too), single-login
multi-charring, deliberately unstable combat system (probability of
win/loss for any given combat is not well predictable), highly interactive
combat system, active support and encouragment for indirect attacks, etc.
Chris Lawrence (Contra)
Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
: In article <5r3nvj$elf$1...@ocean.cup.hp.com>, claw...@cup.hp.com writes:
: >
: > example: Your typical fake medieval world with a partner spirit world
: > which is navigated by reference to "like <object>" and "dislike <object>"
: > to move toward or away from identities, and where all other actions are
: > defined in terms of flows.
: >
: > Sure, you could have the bogus frame merely report a, "that doesn't work
: > here," but that's a little presumptive, no?
: You really think players will appreciate you "playing dumb" and giving them
: a generic error message when you know exactly what they were trying to do
: and could give a helpful one?
If one of the challenges of the game is to discover the spirit world and its
mechanics, then yes.
John Adelsberger
Distribution:
George Reese <bo...@imaginary.com> wrote:
I'll try one more time to discuss this politely - if you or Beek choose
to ignore this fact again, to hell with you; I've a life and code to
write, and can only repeat myself so many times.
: point a cre can redefine that behaviour. The advantage of the global
: verb is:
1) I advocated global verbs, just not the Lima system, where admins
have to add/maintain them. You and Beek both ignored this for
whatever reason.
: #1 A player knows that command exists no matter where they are. They
: can easily pull it up and get help on it. There are no guessing games
: because they are in a different area.
2) Despite Beek's posts, I did not deny this.
: #2 While the original vision for the verb may have been limited to
: that one spiritual area, you have now given cres the tool to make use
: the like and dislike commands in a way that is 100% consistent with
: the syntax of the existing ones.
3) Or to use it in a way that is completely inconsistent - the advantage
of centralized verbs is purely in point 1 of your list; this latter
one is also true of add_action() - it is entirely possible for
cres to use add_action() to make verb usage completely consistent.
In both systems, it is also possible for them to make a complete
mess.
: #3 You lose absolutely nothing over the 'willy-nilly' command systems
: like add_action()
Not if you allow cres to add new verbs(with certain guidelines, of
course.) If you don't then your game becomes limited by its
vocabulary, whicih is clearly not the entire language we use.
Why do you and Beek fail to understand that you can have a
global verb list without requiring that only admins be allowed
to add to it? Even though I am rapidly learning that you have
no tolerance for people who don't just echo your sentiments,
I do respect your intellects, and somehow, I can't believe
you don't at least understand what I'm talking about, despite
your choice to ignore it and pretend I advocated add_action.
George Reese
: : In article <5r3nvj$elf$1...@ocean.cup.hp.com>, claw...@cup.hp.com writes:
: : >
: : > example: Your typical fake medieval world with a partner spirit world
: : > which is navigated by reference to "like <object>" and "dislike <object>"
: : > to move toward or away from identities, and where all other actions are
: : > defined in terms of flows.
: : >
: : > Sure, you could have the bogus frame merely report a, "that doesn't work
: : > here," but that's a little presumptive, no?
: : You really think players will appreciate you "playing dumb" and giving them
: : a generic error message when you know exactly what they were trying to do
: : and could give a helpful one?
: If one of the challenges of the game is to discover the spirit world and its
: mechanics, then yes.
That's not a game challenge.... unless the spirit of your game is to
bea word game, kinda like a glorified wheel of fortune.
John Adelsberger
Distribution:
George Reese <bo...@imaginary.com> wrote:
: Exhibit 951 of why you talk out of your ass.
Don't worry, George, you've just made my killfile. You're the first person
ever to be such a strong combination of rudeness, arrogance, and lack of
amusement value, and you'll never see me posting anything for your lame
eyes again. What follows is not for you; it is for anyone else who
cares to read it, and while I can't stop you from posting a reply, I
won't see it, so you'll be wasting your time.
: The MudOS parser system does not require admins to add verbs. Anyone
: with write access to a directory can add a verb.
This may be true of the MudOS parsing efuns, but Lima claims to have
restricted it. If this is not the case, their code is misleading and
their documentation false.
: Furthermore, it is not a huge burden on admins to ask them to QC new
: verbs. If they do not have the time to do that, they do not have the
: time to run a mud.
Since most large muds have QC teams which don't ahve admin privileges,
any assertion that admins who don't QC shouldn't be running a mud is
so silly I'm surprised even to hear it from Reese's small mind.
: : The DW player ob as of last year still had something like 20 add_actions
: : in it. Not for smile, I grant, but so what? Also, while I am guessing
: : you are right, where did you get complete knowledge of every mudlib
: : written in the last 5 years? Oh, you didn't; you're just full of shit.
: DW is just around 5 years old, give or take 6 months. Try again for a
: real example.
Their player ob has been written over and over, as recently as a year
ago. As usual, Reese doesn't know what he's talking about, doesn't
know what he's replying to, doesn't care to be bothered with little
matters like context in a discussion, and is rude on top of it.
George Reese
I already talked about this stuff in another post. You seem to pick
the posts to whcih you respond very carefully so that you don't have
to answer any direct questions.
John Adelsberger <j...@umr.edu> wrote:
: Distribution:
: George Reese <bo...@imaginary.com> wrote:
: I'll try one more time to discuss this politely - if you or Beek choose
: --
: John J. Adelsberger III
: j...@umr.edu
: "There are none so blind as those who will not see." - Kansas
--
Craig S Dohmen
John Adelsberger <j...@umr.edu> wrote in article
<5rb5n8$1tq$1...@news.cc.umr.edu>...
> Their player ob has been written over and over, as recently as a year
> ago. As usual, Reese doesn't know what he's talking about, doesn't
For the record, the DW player ob currently has the following verbs
add_actioned:
restart
score
brief
verbose
save
quit
review
examine (<--- ack!)
wimpy
refresh
cap
What this has to do with anything is beyond me, but at least you have
the facts now. :-b
--Craig
Mackay / Katherine Amanda (COM)
Tim Hollebeek <t...@wfn-shop.princeton.edu> wrote:
>In article <5r3321$3ct$1...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
>> Tim Hollebeek <t...@franck.Princeton.EDU.composers> wrote:
>> The point is, while it works well for your ZorkMUD, which is basically
>> you and some friends and a few others, and a _very_ tight theme, it
theme (IE: Starcross, Zork1, Trinity, Plundered Hearts, and AMFV synthesized
nicely) [Apologies for non-Infocom affectionados here :].
>> doesn't work so well if there is a genuine need on the part of area
>> coders on a highly decentralized power structure to, say, add a verb.
>> I didn't say the code was inefficient; I said the result is a bad
>> _policy_ move for a _traditional_ mud, as opposed to ZorkMUD:-)
Actually .. Except for the by-and-large lack of combat, ZM will be closer
in feel to traditional muds than most LPs [IE: BartleMUD/Shades/Abers]
<evil grin> (But then again .. there's a reason why MUD (originally) stood
for Multi-User Dungeon (IE: Zork 1-3)
>And you're still wrong. The addition of random verbs by area wizards
>doesn't allow anything other than "syntax quests" which are hell for
>players. Evidentally you have a poor understanding of both the Lima
Actually .. there's 1 thing that I hate more than syntax quests .. it's
syntax quests where when you examine something it tells you:
"It's a blah blah blah blah blah. Perhaps you should <FROBNICATE> it."
>For the record, you actually can do something very add_action-like
>with Lima with almost no modifications. I'm not going to tell you
Out of curiosity .. is this the hack that was added to the attic a looong
while ago .. hmm .. was it "plover"? :)
--OH.
John Viega
> : with write access to a directory can add a verb.
>
> This may be true of the MudOS parsing efuns, but Lima claims to have
> restricted it. If this is not the case, their code is misleading and
> their documentation false.
Euh?? That's absolutely, patently untrue. We definitely encourage
having all of the verbs managed by the admins in a central place,
however:
1) none of the documentation that I am aware of even suggests that
verbs in a wizards directory shouldn't work.
2) Verbs anywhere on the mud *do* work.
3) The only thing I can come up w/ for even slightly misleading code
is that on startup the lib loads all the verbs in /cmds/verbs. Other
verbs must be loaded by other means. It wasn't worth it to us to keep
a database that is so likely to lose consistancy, when it's fairly
easy to come up with your own local solutions to this. However, if
that is what you were mislead by, I think you are easily misled.
> : Furthermore, it is not a huge burden on admins to ask them to QC new
> : verbs. If they do not have the time to do that, they do not have the
> : time to run a mud.
>
> Since most large muds have QC teams which don't ahve admin privileges,
> any assertion that admins who don't QC shouldn't be running a mud is
> so silly I'm surprised even to hear it from Reese's small mind.
But verbs are very important, since they affect all of your coders,
and they should be QC'd by someone whos abilities and judgement you
respect a lot. If someone like that isn't an admin, then I worry
about you. Either way, you're way too combatative here. If you would
have politely pointed out that "admin" is a bit too rigid in this case
instead of personally attacking him, you wouldn't come off looking
like a jerk provoking a fight.
Please CC any flames or replies to my mailbox, because I only ever
read news when enough people implore me to go read a thread, which
might be every 4 months.
Chris Lawrence
Heh. New Moon's player object (based on the Disc's circa 1992-93) has
restart, save, quit, review and refresh from that list. Of course, some
lower-level stuff (alias, for example) is also there (and I suspect still in
DW's too). And so are the queue actions and add_command action (for
new_parser, where the command server is hacked in).
One of these days I'll sit down, figure out PACKAGE_PARSER and clean the
whole mess up :-)
Chris [LordSutch @ New Moon: http://eclipse.cs.pdx.edu/]
--
============================================================================
| Chris Lawrence | My home page: |
| <qua...@ix.netcom.com> | http://www.clark.net/pub/lawrencc/ |
| | |
| Amiga A4000/040 and | Visit the Lurker's Guide to Babylon 5: |
| Linux/m68k 2.1.29 | <*> http://www.midwinter.com/lurk/ <*> |
============================================================================
John Adelsberger
Distribution:
George Reese <bo...@imaginary.com> wrote:
: I already talked about this stuff in another post. You seem to pick
: the posts to whcih you respond very carefully so that you don't have
: to answer any direct questions.
While I'm slowly coming to realize that the KC edu feed is shitty and
doesn't give me half the traffic on these groups, I responded to the
first post I read that was suitable. Mind giving a ref # for that
other post, or is it in fact _you_ who is trying to avoid answering
any direct questions? It must be; it would hardly have hurt you
to post your replies one more time if you were going to bother
replying at all.
George Reese
John Adelsberger <j...@umr.edu> wrote:
: Distribution:
: George Reese <bo...@imaginary.com> wrote:
: : I already talked about this stuff in another post. You seem to pick
: : the posts to whcih you respond very carefully so that you don't have
: : to answer any direct questions.
: While I'm slowly coming to realize that the KC edu feed is shitty and
: doesn't give me half the traffic on these groups, I responded to the
: first post I read that was suitable. Mind giving a ref # for that
: other post, or is it in fact _you_ who is trying to avoid answering
: any direct questions? It must be; it would hardly have hurt you
: to post your replies one more time if you were going to bother
: replying at all.
I see, in order for a point to be worth considering for John, it has
to be posted in a newsgroup TWICE?
Sorry, John, I doubt anyone here thinks you are worth that.