Threshold RPG = Copyright Infringment?
Michael
violation making its player having to pay for additional access (levels and
stuff)? There is a recent post/flame on the Mudconnector about this and was
wondering what should/could be done about this since the last I heard using
an LPmud for gaining money as a 'business' (other than using DGD w/ a
license) was illegal.
Can someone update me and others about this?
Thanks.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
John Adelsberger
: Is Threshold RPG, running a MudOS driver and TMI-2 like mudlib in copyright
: violation making its player having to pay for additional access (levels and
: stuff)? There is a recent post/flame on the Mudconnector about this and was
: wondering what should/could be done about this since the last I heard using
: an LPmud for gaining money as a 'business' (other than using DGD w/ a
: license) was illegal.
: Can someone update me and others about this?
Unless Aristotle has changed a whole lot in recent times(he's the admin
of Threshold, assuming it is the same one,) whoever posted that is either
lying or relying on a source who lies. Any such pay-access would have
come out a long time ago, I'm pretty sure, and we'd certainly have heard
of it in these newsgroups, which isn't the case.
Aristotle DOES get frequent detractors, probably due to the fact that he
runs a game suited to his tastes, and invites those who enjoy it to play
it, rather than providing a game suited to the tastes of players who yell
louder than their peers and inviting idiots to design it. I wouldn't
be surprised if some such decided to adopt the tactics you describe as a
smear campaign, but I obviously don't know the specifics of this particular
case.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
aven...@my-dejanews.com
> Unless Aristotle has changed a whole lot in recent times(he's the admin
> of Threshold, assuming it is the same one,) whoever posted that is either
> lying or relying on a source who lies. Any such pay-access would have
> come out a long time ago, I'm pretty sure, and we'd certainly have heard
> of it in these newsgroups, which isn't the case.
>
Aristotle calls it 'registering'. It is some $50. Visit TMC and you will see
that he admitted it. The problem is not because he demands money and abuses
his players, i don't care a bit about that. My only problem is that he uses
MudOS (he already admitted it) and most likely he uses the TMI-2 mudlib which
is similar to the one on Astaria. I visited his mud and Astaria just to check
their similarity.
> be surprised if some such decided to adopt the tactics you describe as a
> smear campaign, but I obviously don't know the specifics of this particular
> case.
Yes, you obviously don't know a bit about this particular case. Maybe you
should ask Aristotle and/or visit Astaria/Threshold.
>
> --
> John J. Adelsberger III
> j...@umr.edu
>
Avenger
John Adelsberger
: > Unless Aristotle has changed a whole lot in recent times(he's the admin
: > of Threshold, assuming it is the same one,) whoever posted that is either
: > lying or relying on a source who lies. Any such pay-access would have
: > come out a long time ago, I'm pretty sure, and we'd certainly have heard
: > of it in these newsgroups, which isn't the case.
: Aristotle calls it 'registering'. It is some $50. Visit TMC and you will see
: that he admitted it. The problem is not because he demands money and abuses
: his players, i don't care a bit about that. My only problem is that he uses
: MudOS (he already admitted it) and most likely he uses the TMI-2 mudlib which
: is similar to the one on Astaria. I visited his mud and Astaria just to check
: their similarity.
As I recall, Astaria stole his lib. At any rate, I don't know anything
about anything on the mud connector, because I can't stand the sight of
it, and I'm not going to to check up on it; I'm sure Aristotle can tell
us what he said if he wants to, and I'm equally sure that he can't get
away with lying even if he wanted to, which I don't think he does.
At any rate, IF what you are saying is true and IF he actually _makes_
money off of it(you aren't 'commercial' just because there's cash
involved, and he probably knows that better than any of us,) then you
_might_ have a point, assuming there's no _other_ information missing
from the picture.
If there is a point, are you someone who has any actual role in enforcing
any of the supposedly violated licenses, or are you just stirring the
pot to watch it boil?
BTW, this seems like a good time to point out that the single greatest
limitation of LPC is that there is _no_ reasonable way to do anything
more than accept donations in the way of paying for the game, even if
all you want to do is recoup costs, UNLESS you're a lawyer or willing
to break licenses and ignore consequences. This single item
overshadows _all_ technical problems, because:
1) It effectively isolates LPC from the 'open source' software movement,
which does not tolerate noncommercial licensing. This eliminates many
very talented people from the potential development pool.
2) It ensures that no game can grow larger than the finances of the owner,
which means that anyone who _can_ make money in one way or another,
even ones that don't mess everything up, has an unbeatable advantage.
3) It does little or nothing to protect anyone from anything, as people
twisted enough to make you pay for gear or levels are twisted enough
to break licenses anyway.
4) It doesn't even really salve the feelings of the authors who use it
as a way to justify writing 'free' software, because the results
almost never amount to anything, and when they do, they can't grow
to their potential. Even the most socialist of authors know this
at heart, and it can't be fun watching pay-to-play crap like Gemstone
beating your ass.
Frankly, I think it'd be rather interesting to see a _really_ free MudOS
clone, and I'd work on such a project if I could find the time, but I
doubt there's much current support for it; most of the people with the
expertise to even care about such a thing are probably too sympathetic
to the MudOS developers' wishes to even consider doing anything like
this, and whether I agree or not, I can respect that and understand why
they'd feel that way.
Later,
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Wildman, the Cuberstalker
<aven...@my-dejanews.com> wrote:
>Aristotle calls it 'registering'. It is some $50. Visit TMC and you will see
>that he admitted it. The problem is not because he demands money and abuses
>his players, i don't care a bit about that. My only problem is that he uses
>MudOS (he already admitted it) and most likely he uses the TMI-2 mudlib which
>is similar to the one on Astaria. I visited his mud and Astaria just to check
>their similarity.
Most likely does not equate with did. No, he wrote his mudlib himself. It's
obvious that he's influenced by TMI-2, but then so is almost everyone. There
is nothing wrong with what he's charging. He certainly isn't making a profit
or operating as a business. He's barely covering his losses, considering how
few people will play in as strict an environment as he offers.
>> be surprised if some such decided to adopt the tactics you describe as a
>> smear campaign, but I obviously don't know the specifics of this particular
>> case.
>
>Yes, you obviously don't know a bit about this particular case. Maybe you
>should ask Aristotle and/or visit Astaria/Threshold.
Well... if you're bringing Astaria into it, it's clear that you either a)
don't know as much as you think you do, or b) are attempting a smear
campaign. So long, loser!
--
The Wildman ICQ# 32609427
Fight spam - http://www.spamfree.org
Five is a sufficiently close approximation to infinity.
aven...@my-dejanews.com
> Well... if you're bringing Astaria into it, it's clear that you either a)
> don't know as much as you think you do, or b) are attempting a smear
> campaign. So long, loser!
>
Well... I don't care a bit if Astaria stole from Aristotle or vice versa.
Astaria displays the used versions of the software and does not demand money,
while Aristotle does the opposite.
Anyway this is my last note on the topic on any forum, if he really use MudOS
V22.1 or later, i grant him license to use my part of the code.
> --
> The Wildman ICQ# 32609427
> Fight spam - http://www.spamfree.org
> Five is a sufficiently close approximation to infinity.
>
-----------== Posted via Deja News, The Discussion Network ==----------
Aristotle@Threshold
>In rec.games.mud.lp aven...@my-dejanews.com wrote:
>
>:>[snipped some wanker Troll]
>
>As I recall, Astaria stole his lib.
You recall correctly. Although, since the new administration of Astaria is
starting to get a conscience, it might be more appropriate to say
Aurora@Astaria (Kelly Kenworthy) stole my lib/code/areas/etc. For example,
they are removing all of my areas in a few months (supposedly). Of course, it
would be nice if they'd finally admit they are still using my lib code, tons
of my guild cost, etc, but this is at least a start.
>I'm sure Aristotle can tell us what he said if he wants to, and
I considered just ignoring this ridiculous thread, so as not to give it yet
another post to breathe life into it. My girlfriend pleaded with me not to
post, b/c she's seen these same types of flaming jerks organize a lynch mob to
spam message threads elsewhere. However, that will just induce them to post
"see? He didn't say anything! He admits he is wrong", and so unfortunately, I
have to dignify this crap with a response.
>I'm equally
>sure that he can't get away with lying even if he wanted to, which I don't
>think he does.
Thanks. =)
>At any rate, IF what you are saying is true and IF he actually _makes_
>money off of it(you aren't 'commercial' just because there's cash
>involved, and he probably knows that better than any of us,) then you
>_might_ have a point, assuming there's no _other_ information missing
>from the picture.
Threshold has an *OPTIONAL* registration policy. I don't call it "donating"
because I am not a charity or not-for-profit organization (getting that kind
of status is quite difficulty- I don't think people realize that), so I think
thats a misleading term. Anyway, people can choose to register their
character. Yes, we expect people to register if they play for a long time.
However, it is not required for access. Yes, people who register can get some
spiffy bonuses. However, there are plenty of people who have reached the
highest levels of the game without getting all these spiffy bonuses. And yes,
people who HAVE registered tend to ridicule the people who haven't. That is
just human nature. We don't live in a socialist country, so its pretty
understandable that the people who HAVE spent money to keep Threshold running
would be pretty bitter towards those who were freeloading off of THEIR money.
>If there is a point, are you someone who has any actual role in enforcing
>any of the supposedly violated licenses, or are you just stirring the
>pot to watch it boil?
Nope, thats all people like that guy are interested in doing. That's another
reason I hesitated at posting. Posting facts, information, explanations, etc.
are pointless. It doesn't change anything. People like that never listen. They
can post something, you can reply, and they'll post the same exact thing as if
you didn't even say a word. Its truly amazing in its pathetic stupidity.
>[snipped rest of post]
Agreed.
-Aristotle@Threshold
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, mature, detailed roleplaying environment.
http://www.threshold-rpg.com -**- telnet://threshold-rpg.com:23
Caleb Tennis
> You recall correctly. Although, since the new administration of Astaria is
> starting to get a conscience, it might be more appropriate to say
> Aurora@Astaria (Kelly Kenworthy) stole my lib/code/areas/etc. For example,
> they are removing all of my areas in a few months (supposedly). Of course, it
> would be nice if they'd finally admit they are still using my lib code, tons
> of my guild cost, etc, but this is at least a start.
Aristotle, I would appreciate some more insight to this if you could
please.
Back in the early days when I had builder access on Astaria I did some
coding
projects which I now find are on your mud. So, if this is the case,
wouldn't
this be code that you took from Astaria and put on your site, since I
know I
clearly was logged into astaria.pond.com (old site) when I wrote it?
Also, I can clearly remember one character who did most of the coding
online.
His name was Empacher and he was always online making modifications to
the code.
He even helped me on occasion. Would this be you? Or was this the
person who stole most of your code?
I am in no way saying you are a liar nor am I trying to imply anything,
but I would like some clarification since this whole story of a war
between admins was never to my knowledge made public.
Caleb
mwi...@my-dejanews.com
> BTW, this seems like a good time to point out that the single greatest
> limitation of LPC is that there is _no_ reasonable way to do anything
> more than accept donations in the way of paying for the game, even if
> all you want to do is recoup costs, UNLESS you're a lawyer or willing
> to break licenses and ignore consequences.
To quote from the Copyright file in the MudOS source code:
"Source code herein refers to the source code, and any executables
created from the same source code.
All rights reserved. Permission is granted to extend and modify the
source code provided subject to the restriction that the source code may
not be used in any way whatsoever for monetary gain."
That's pretty damn restrictive. Could this be interpreted so far as to say
that I can't have an object in my mud that takes orders and does bookkeeping
for, say "Dreamshadow" logo T-shirts, hats and posters? Something about the
language "in any way whatsoever" seems far too vague and far reaching to even
be enforceable. Exactly how far can this restriction be enforced?
[SNIP]
> Frankly, I think it'd be rather interesting to see a _really_ free MudOS
> clone, and I'd work on such a project if I could find the time, but I
> doubt there's much current support for it; most of the people with the
> expertise to even care about such a thing are probably too sympathetic
> to the MudOS developers' wishes to even consider doing anything like
> this, and whether I agree or not, I can respect that and understand why
> they'd feel that way.
I'd also like to see a free MudOS, or at least one where I could specifically
buy a license for commercial use. I'm still debating moving my project to
DGD or Cold because of the licensing restrictions of MudOS. I might never
charge a dime, but it would still be nice to have the *option*.
--
Visit us at Dreamshadow today! -
telnet: dreamer.telmaron.com 3333
http://homestead.dejanews.com/dreamshadow/DreamshadowMain.html
John Adelsberger
: To quote from the Copyright file in the MudOS source code:
: "Source code herein refers to the source code, and any executables
: created from the same source code.
: All rights reserved. Permission is granted to extend and modify the
: source code provided subject to the restriction that the source code may
: not be used in any way whatsoever for monetary gain."
: That's pretty damn restrictive.
Actually, in some ways it isn't. For instance, 'gain' is profit, rather
than revenue. If I lose money on a mud, I can take in as much as I want,
as far as I can tell. It really isn't _hard_ to lose money on a mud:)
Granted, this isn't what they meant when they wrote it, I imagine, but
that's why you hire lawyers to write these things if you're going to
bother at all...
: Could this be interpreted so far as to say
: that I can't have an object in my mud that takes orders and does bookkeeping
: for, say "Dreamshadow" logo T-shirts, hats and posters? Something about the
: language "in any way whatsoever" seems far too vague and far reaching to even
: be enforceable. Exactly how far can this restriction be enforced?
Oh, I'm sure that it is enforcable in some sense, but I doubt it can be
made to prevent anyone from accepting money, or even from expecting or
demanding it, so long as he doesn't _make_ money off the mud. I suspect
that in the case of your vendor object, you'd have to make sure you didn't
make a profit on the goods sold, for instance.
: > Frankly, I think it'd be rather interesting to see a _really_ free MudOS
: > clone, and I'd work on such a project if I could find the time, but I
: > doubt there's much current support for it; most of the people with the
: > expertise to even care about such a thing are probably too sympathetic
: > to the MudOS developers' wishes to even consider doing anything like
: > this, and whether I agree or not, I can respect that and understand why
: > they'd feel that way.
: I'd also like to see a free MudOS, or at least one where I could specifically
: buy a license for commercial use. I'm still debating moving my project to
: DGD or Cold because of the licensing restrictions of MudOS. I might never
: charge a dime, but it would still be nice to have the *option*.
I'm not interested in anything but a _free_ MudOS clone; DGD is neat, but
it isn't the same thing, and it wasn't meant to be. Cold is nice, and I
played with it for awhile, but the people I tend to work with know nothing
about it, and I don't feel like telling them that in order to do anything
on my new toy, they have to learn a whole new system; if MudOS's LPC had
serious problems, I'd probably switch, but it doesn't, and if you configure
it right, it even has a clean interface, free of application specific
garbage.
Another possibility, which someone else mentioned, would be to write a
translator and a runtime(probably both in Java, unfortunately, but they
could be in any language for which a compiler will target the JVM,) to
allow running MudOS libraries on a JVM. This would probably be easier,
but it would also be uglier.
(For anyone who wants to know why I said what I said about DGD, since one
seemingly can't suggest that it isn't the ultimate answer to all things
without pissing someone or other off these days, I suggest you compare
the complexity and size of a minimal DGD lib with that of a minimal
MudOS lib. DGD is terrific, but it is _not_ the same thing, and there
are going to be people who don't _want_ what it does.)
luv...@andru.sonoma.edu
[snip]
> I'd also like to see a free MudOS, or at least one where I could specifically
> buy a license for commercial use. I'm still debating moving my project to
> DGD or Cold because of the licensing restrictions of MudOS. I might never
> charge a dime, but it would still be nice to have the *option*.
it doesn't have good inter-object security, but pike is an LPC clone
which could be used to implement a mud.
see pike.idonex.com
andru
John Adelsberger
: it doesn't have good inter-object security, but pike is an LPC clone
: which could be used to implement a mud.
: see pike.idonex.com
I'm aware of it. I _could_ do what I want to do with it, but I don't want
to suffer.
Ilya
>
> BTW, this seems like a good time to point out that the single greatest
> limitation of LPC is that there is _no_ reasonable way to do anything
> more than accept donations in the way of paying for the game, even if
> all you want to do is recoup costs, UNLESS you're a lawyer or willing
> overshadows _all_ technical problems, because:
>
Acuity recently started selling licenses to the DGD LPC driver
for commercial use. The one I heard of first sold for a great
deal of money, but that doesn't mean it can't be cheaper
depending on circumstances.
Anyway, you can indeed make money with LPC at least in
this way.
--
Ilya (at) gamecommandos (dot) com a mud list & review site
www.gamecommandos.com for online roleplaying games
aven...@my-dejanews.com
> As I recall, Astaria stole his lib. At any rate, I don't know anything
> about anything on the mud connector, because I can't stand the sight of
> it, and I'm not going to to check up on it; I'm sure Aristotle can tell
> us what he said if he wants to, and I'm equally sure that he can't get
> away with lying even if he wanted to, which I don't think he does.
>
No matter who stole whom, it is based on TMI-2.
>
> If there is a point, are you someone who has any actual role in enforcing
> any of the supposedly violated licenses, or are you just stirring the
> pot to watch it boil?
>
As i wrote in another post, IF he use a MudOS version with a release date
after Jul. 1. 1996. then yes, I am part (very tiny part) of the team which
produced MudOS. Just grep the changelog file for Avenger.
> BTW, this seems like a good time to point out that the single greatest
>
Well. But does this 'flaw' allow Aristotle to 'market the ware' as his own ???
> Frankly, I think it'd be rather interesting to see a _really_ free MudOS
Hmm. Write one from scratch.
>
> --
> John J. Adelsberger III
> j...@umr.edu
>
> "Civilization is the process of setting man free from men."
>
> - Ayn Rand
>
Avenger
PS: ohh, btw. This name (Avenger) has nothing to do with Aristotle. Read the
changelog in MudOS, i've used the name for a long time. ;)
PS2: better be a troll than a thief, trolls are stronger and regenerate :>
John Adelsberger
: Acuity recently started selling licenses to the DGD LPC driver
: for commercial use. The one I heard of first sold for a great
: deal of money, but that doesn't mean it can't be cheaper
: depending on circumstances.
: Anyway, you can indeed make money with LPC at least in
: this way.
Yes, but I was referring to practical methods. For most of us, investing
what any of those licenses is going to amount to(it probably is a renewal
based thing too, right?) just isn't going to work out; even if I _can_
make money off a mud, which I'm not convinced of personally, I surely
can't do it without acquiring a playerbase and whatnot, which takes time,
and most people aren't exactly swimming in venture capital to blow on
ultrarisky theoretical new markets.
There's a difference between 'can be done in theory' and 'will ever happen.'
Notice that, in theory, someone could buy a license for the sources to MFC,
port it to Linux, and then _give away_ the compiled library. Notice that
nobody has done such a thing, or probably ever will.
mwi...@my-dejanews.com
aven...@my-dejanews.com wrote:
> In article <372f8...@news.cc.umr.edu>,
> John Adelsberger <j...@umr.edu> wrote:
>
> > As I recall, Astaria stole his lib. At any rate, I don't know anything
> > about anything on the mud connector, because I can't stand the sight of
> > it, and I'm not going to to check up on it; I'm sure Aristotle can tell
> > us what he said if he wants to, and I'm equally sure that he can't get
> > away with lying even if he wanted to, which I don't think he does.
> >
> No matter who stole whom, it is based on TMI-2.
Correct me if I'm wrong, but isn't the Threshold/Astaria library too *old* to
have been based on TMI-2? I seem to recall Astaria already existing when the
TMI-2 project was started.
--
Visit us at Dreamshadow today! -
telnet: dreamer.telmaron.com 3333
http://homestead.dejanews.com/dreamshadow/DreamshadowMain.html
-----------== Posted via Deja News, The Discussion Network ==----------
Wildman, the Cuberstalker
<aven...@my-dejanews.com> wrote:
>In article <372f8...@news.cc.umr.edu>,
> John Adelsberger <j...@umr.edu> wrote:
>
>> As I recall, Astaria stole his lib. At any rate, I don't know anything
>> about anything on the mud connector, because I can't stand the sight of
>> it, and I'm not going to to check up on it; I'm sure Aristotle can tell
>> us what he said if he wants to, and I'm equally sure that he can't get
>> away with lying even if he wanted to, which I don't think he does.
>>
>No matter who stole whom, it is based on TMI-2.
You sure about that? Aristotle has stated repeatedly that his mudlib is from
scratch.
John Adelsberger
: In article <372f8...@news.cc.umr.edu>,
: John Adelsberger <j...@umr.edu> wrote:
: > As I recall, Astaria stole his lib. At any rate, I don't know anything
: > about anything on the mud connector, because I can't stand the sight of
: > it, and I'm not going to to check up on it; I'm sure Aristotle can tell
: > us what he said if he wants to, and I'm equally sure that he can't get
: > away with lying even if he wanted to, which I don't think he does.
: No matter who stole whom, it is based on TMI-2.
That's not what people who have factual knowledge say. I've not seen either
lib, but I've been told that while they _look_ a lot like TMI-2, there was
no actual copying of code. I have no way to prove this issue either way,
but I tend to trust people who at least have a _method_ of knowing for sure
over people who saw some code and said 'that looks familiar' or something
like that, without meaning any offense to the latter, whose suspicions
COULD be well founded. Of course, I work hard to offend almost everyone
from time to time, but not when I think there's a worthwhile issue at hand
and people who might actually behave sanely regarding it...
: > Frankly, I think it'd be rather interesting to see a _really_ free MudOS
: Hmm. Write one from scratch.
So far, there are a couple of people interested. If that number(counting
only people I have reason to believe are competent:) grows much at all,
I'm seriously considering it, but we may run into arguments over what to
include, as I prefer a vastly stripped down no-compatibility-hacks no-
world-specific-crap sort of thing(ie, no light, no inventory, etc.)
(In addition to theoretical and aesthetic concerns, eliminating the
quite impressive configurability of the existing system should _vastly_
ease the chore of finding nasty bugs, as well as reduce the incidence
of such bugs. The increased simplicity _might_ (given good code) lend
itself well to better performance, but that obviously remains to be
seen... I know there are things I can do moderately faster on most
architectures than MudOS typically ends up doing them, but they don't
usually matter to a product like this, so...(the big one is avoiding
branches, but how many CPU bound muds do you know?:)
Another possible improvement for a rewrite would be to thread the compiler
out to gain at least _some_ benefit from SMP machines. There's no reason
compilation shouldn't run on as many cpus as possible, as long as it
doesn't starve the interpreter. I suspect the biggest benefit would
show up for people with lots of active development going on, but that
does seem to be the majority of existing games, and I know I've been
pissed off more than once when some nimrod decided to recompile an
entire branch of the lib tree on a running game I was trying to play...
I'm also interested in providing a decent(but fairly minimal) set of
mathematical operations... for processor intensive activity, math is
the norm, and so optimizing math makes more sense than trying to
optimize in general(except for memory usage, but then again... memory
is cheaper now than disk was a few years ago... do I even care?:)
Ilya
>
> In rec.games.mud.lp Ilya <il...@spam.free.gamecommandos.com> wrote:
>
> : Acuity recently started selling licenses to the DGD LPC driver
> : for commercial use.
> Yes, but I was referring to practical methods. For most of us,
> investing what any of those licenses is going to amount to (it
> probably is a renewal based thing too, right?) just isn't going
> to work out;
True enough. The license first sold, or so I heard, went
for USD 75,000, though I believe it was unlimited (no renewal).
Greebo
>In article <7grrou$i99$1...@nnrp1.deja.com>,
> aven...@my-dejanews.com wrote:
>> In article <372f8...@news.cc.umr.edu>,
>> John Adelsberger <j...@umr.edu> wrote:
>>
>> > As I recall, Astaria stole his lib. At any rate, I don't know anything
>> > about anything on the mud connector, because I can't stand the sight of
>> > it, and I'm not going to to check up on it; I'm sure Aristotle can tell
>> > us what he said if he wants to, and I'm equally sure that he can't get
>> > away with lying even if he wanted to, which I don't think he does.
>> >
>> No matter who stole whom, it is based on TMI-2.
>
>Correct me if I'm wrong, but isn't the Threshold/Astaria library too *old* to
>have been based on TMI-2? I seem to recall Astaria already existing when the
>TMI-2 project was started.
From "help astaria" on Astaria itself:
"Astaria uses the MudOS (0.9.20r1) driver with TMI-2 base mudlib.
Many, many changes have been made, and it is now Astaria 1.1 Lib."
That should clear things up.
H. McDaniel
>(In addition to theoretical and aesthetic concerns, eliminating the
> quite impressive configurability of the existing system should _vastly_
> ease the chore of finding nasty bugs, as well as reduce the incidence
> of such bugs. The increased simplicity _might_ (given good code) lend
Hmm. I don't think it's the number of configuration options, so much as
knowing the affect the various combinations will have on the system. If
people who don't *really* understand the existing system add on
configuration options, the chances of something nasty occuring are, of
course, massively high. But when they actually understand how those
different options might interact, I don't think it's really a problem.
I'm thinking of my own experience creating a mud base with many
configuration options. There were times when I scratched my head.. but
there were no 500 pound gremlins, just your run of the mill itty bitty
bugs.
I think having *good* documentation of the system and requiring that
people who work on the system actually use that documentation and add to
it when they make changes goes a long ways towards eliminating the sort of
bugs you're talking about.
That and having a very efficent team, as opposed to an army of people with
vastly varying degrees of comittment.
[...]
>show up for people with lots of active development going on, but that
>does seem to be the majority of existing games, and I know I've been
>pissed off more than once when some nimrod decided to recompile an
>entire branch of the lib tree on a running game I was trying to play...
While online development is great for several things, I have never
understood why so many feel it is essential in a MUD when it comes to
modifying the basic rules. It seems to me that a MUD developer should
want to reach a level of stability, not only in terms of reliability (that
his code does what he wants it to) but in terms of the players knowing
that the behavior is standardized which doesn't necessarily mean they
know all the rules, just that they don't see contradictions in objects of
the same kind.
Having offline compilers and development applications for game
contributors is my preference. But I think, from day 1 as far as my MUD
experience goes, building in MUDs has always been a social opportunity
too. Do people work better online with other builders around? I wonder.
-McDaniel
Felix A. Croes
> > : Acuity recently started selling licenses to the DGD LPC driver
> > : for commercial use.
>
> > Yes, but I was referring to practical methods. For most of us,
> > investing what any of those licenses is going to amount to (it
> > probably is a renewal based thing too, right?) just isn't going
> > to work out;
>
> True enough. The license first sold, or so I heard, went
> for USD 75,000, though I believe it was unlimited (no renewal).
Skotos Tech's license is both unlimited and with the right to
sublicense. If you want to use DGD commercially, licensing from Acuity
is not the only option.
Regards,
Dworkin
John Adelsberger
: Hmm. I don't think it's the number of configuration options, so much as
: knowing the affect the various combinations will have on the system. If
: people who don't *really* understand the existing system add on
: configuration options, the chances of something nasty occuring are, of
: course, massively high. But when they actually understand how those
: different options might interact, I don't think it's really a problem.
If they actually think about all of them _carefully_ every single time,
then you're right. Maybe they do. Given the history of MudOS bugs,
which seems heavy on things that crop up in configurations not many
people use, I'd say that isn't the case, though...
: I think having *good* documentation of the system and requiring that
: people who work on the system actually use that documentation and add to
: it when they make changes goes a long ways towards eliminating the sort of
: bugs you're talking about.
It would, but MudOS doesn't even have complete docs for the language it
implements, including some things that haven't changed in years(the basic
operators, for instance.) I'm not trying to insult or belittle anyone
by saying that, but obviously there are documentation problems.
: That and having a very efficent team, as opposed to an army of people with
: vastly varying degrees of comittment.
Hehe... well, yes, that always helps almost any project:)
: While online development is great for several things, I have never
: understood why so many feel it is essential in a MUD when it comes to
: modifying the basic rules. It seems to me that a MUD developer should
: want to reach a level of stability, not only in terms of reliability (that
: his code does what he wants it to) but in terms of the players knowing
: that the behavior is standardized which doesn't necessarily mean they
: know all the rules, just that they don't see contradictions in objects of
: the same kind.
Usually these sorts of recompiles aren't necessarily things that are basic
to the _design_ of the game so much as they happen to involve code that
gets inherited _everywhere_ because some nimrod put it in the wrong place
or something, but in any case, you still lose, and I admit that I've seen
a couple of times when it made good sense to do what was done - one in
particular fixed a _nasty_ security problem that a player had just found:)
: Having offline compilers and development applications for game
: contributors is my preference. But I think, from day 1 as far as my MUD
: experience goes, building in MUDs has always been a social opportunity
: too. Do people work better online with other builders around? I wonder.
I don't know, but I do know that I get more done in an environment in which
I can repeatedly load and test my work than I do if I have to do it, then
take it somewhere and test it out, then go back to some other place, and
so forth. Even if all you're doing is writing code to make a ring give
someone lockpicking skills when worn, correcting a typo in 10 seconds is
vastly preferable to doing so in, say, 5 minutes, or even just one minute.
H. McDaniel
>In rec.games.mud.lp H. McDaniel <ha...@u.washington.edu> wrote:
>: Hmm. I don't think it's the number of configuration options, so much as
>: knowing the affect the various combinations will have on the system. If
>If they actually think about all of them _carefully_ every single time,
>then you're right. Maybe they do. Given the history of MudOS bugs,
>which seems heavy on things that crop up in configurations not many
>people use, I'd say that isn't the case, though...
That may be do to an inadequate review process. But I'm not familiar with
how the MudOS developers handled that.
>: I think having *good* documentation of the system and requiring that
>: people who work on the system actually use that documentation and add to
>: it when they make changes goes a long ways towards eliminating the sort of
>: bugs you're talking about.
>It would, but MudOS doesn't even have complete docs for the language it
>implements, including some things that haven't changed in years(the basic
>operators, for instance.) I'm not trying to insult or belittle anyone
>by saying that, but obviously there are documentation problems.
I agree. And you're not insulting anybody because coders are (generally
speaking) notorious for not documenting things enough.
>: modifying the basic rules. It seems to me that a MUD developer should
>: want to reach a level of stability, not only in terms of reliability (that
>Usually these sorts of recompiles aren't necessarily things that are basic
>to the _design_ of the game so much as they happen to involve code that
>gets inherited _everywhere_ because some nimrod put it in the wrong place
>or something, but in any case, you still lose, and I admit that I've seen
>a couple of times when it made good sense to do what was done - one in
>particular fixed a _nasty_ security problem that a player had just found:)
I would say that if you use common players in a public game to test your
code, don't be surprised if they find and exploit bugs. People want to
have their cake and eat it to. If games were tested properly one wouldn't
need "fire insurance" like this. It's nice to have, but I see it as a
crutch too.
>: Having offline compilers and development applications for game
>: contributors is my preference. But I think, from day 1 as far as my MUD
>: experience goes, building in MUDs has always been a social opportunity
>: too. Do people work better online with other builders around? I wonder.
>I don't know, but I do know that I get more done in an environment in which
>I can repeatedly load and test my work than I do if I have to do it, then
>take it somewhere and test it out, then go back to some other place, and
>so forth. Even if all you're doing is writing code to make a ring give
>someone lockpicking skills when worn, correcting a typo in 10 seconds is
>vastly preferable to doing so in, say, 5 minutes, or even just one minute.
But the ease of fixing bugs leads us to be more relaxed in our coding,
doesn't it? I mean people spend hours and hours using computer programs
that make fiddling easy to do things that they could do in a simpler
environment much quicker because they get sidetracked or decide to
experiment without as much planning. Some examples of this would be the
use of digitial image editing, and fancy word processors with 50,000
formatting options. When one isn't sure exactly what they want, they
spend a lot of time finding out, but is that time really as productive as
it could be?
In MudOS I would often code on the fly, with little pre-planning as far as
the details went, but I remember when I was working on 1st generation
Diku, where you had to re-complie the whole work for every little change,
I was much, much more delibrate and specific in my planning. I think I
got more done in less time that way. Same for my own mud base. The trade
off was that there were fewer people actually doing the coding.
Note: writing a MudOS lib from stracth was much closer to my Diku
experience, since so much of the basic framework has to work in concert.
A problem I see with the whole way MUDs are developed is that the
development process is often married to the game running one. There is
always pressure to have the code in an optimal state because it is in use
or on the verge of being used. People tend to rush into putting up code
that simply appears to be functional. If on the other hand, the running
side was seperated from the code building side, you could build
progressive stages of the game code without actually making those changes
current for the game players. You could have a team of coders working on
the next version of the game in a seperate environment from another team
of game managers who interact with players/testers and relate what they
learn to the coding team. Then you wouldn't have the running or playing
game in a state of constant flux or modification, you'd just up the game
all at once when you're convinced that a major change is warranted.
The pace of these two teams could vary. The coder would have more freedom
to fiddle with fundamental parts of the game (which is sometimes a good
thing) without concern for how that might affect the players in the short
term, besides addressing larger, general kinds of problems and not having
to focus on plugging a million superfical bugs (that is bugs which annoy
players or coders, but which don't have anything to do with
functionality) on a continuous basis.
Anyhoo,
-McDaniel
John Adelsberger
: But the ease of fixing bugs leads us to be more relaxed in our coding,
: doesn't it?
Writing will lead to people with poor memories.
Calculators will lead to people who can't add.
Computers will lead to people who can't take care of the small necessities
of life.
Assemblers will lead to programmers who don't know every opcode for every
machine on the planet.
High level languages will lead to programmers who don't even know what an
instruction set _is._
Web browsers and television will be the end of reading skills.
LPC will be the end of careful programming?:)
: learn to the coding team. Then you wouldn't have the running or playing
: game in a state of constant flux or modification, you'd just up the game
: all at once when you're convinced that a major change is warranted.
I understand the sentiment, and I've expressed it myself, but this is a
matter of self discipline and policy, rather than codebase.
Ilya
> : coding, doesn't it?
>
> Calculators will lead to people who can't add.
> Computers will lead to people who can't take care of the
> small necessities of life.
> Assemblers will lead to programmers who don't know every
> opcode for every machine on the planet.
> High level languages will lead to programmers who don't even
> know what an instruction set _is._
> Web browsers and television will be the end of reading skills.
> LPC will be the end of careful programming?:)
>
so connected that the truth of one automatically affirms
or denies the validity of another.
- people spent a long time rehearsing songs and stories
before writing, and certainly exercised their 'memorize
long blocks of information' capacities much more than
we typically find today.
- I've met plenty of people, especially younger ones, for
whom the basics of mathematics are a great challenge,
and who couldn't imagine life without calculators. I
regularly astonish them by adding numbers in my head.
Multiplication, on the other hand, goes beyond astonishment.
They pull out their calculators. It's not even a matter
of them 'checking' me, since they _know_ it can't be done.
Now whether this skill is particularly useful is open to
some question. But that it has declined where calculators
are cheap and easy to get is not really.
- Few programmers ever knew every opcode for every machine
on the planet. Every machine that _mattered_ maybe!
But yes, opcode knowledge has declined substantially.
This is, I think, an unlamented loss.
- High level languages do indeed lead to the specified
woe, which leads to all sorts of inefficiencies. I
think the cheapness and availability of memory and
disk space have been more the culprits in creating
bloated and wasteful and slow code. Heck (and this
is not some fairy story, I really did this) I wrote
a complete Doctor's office package with billing,
accounts receivable, superbill forms, patient records,
rvs/icda code lookups, the whole nine yards, back in
1979-1980. The entire program (12,000 lines of Pascal)
plus all the doctor's records (several hundred patients)
plus the entire operating system plus the language
compiler and p-code interpreter all fit in a grand
total of 280kbytes on two floppies. Compiles took
about an hour, and the whole thing executed in a
64k memory space. And a few years later I was sys
manager for a 300million dollar uniform supply company
which kept all corporate records on a machine with
a grand total of 256k in main memory. It controlled
a nation-wide point-to-point multidrop network of
several dozen hosts, with a fixed hard disk of about
500 megabytes.
- I'm not sure about web browsers, but television has
done its fair share to obliterate reading skills.
With the help of a willing public of course!
- I assume you are trying to say something wry about
LPC. I've done the reading, but never used it, so
I can't say much useful here, though I'll try! I'm
sure careful coding was dead long before LPC came
into being.
Cheers,
H. McDaniel
>In rec.games.mud.lp H. McDaniel <ha...@u.washington.edu> wrote:
>LPC will be the end of careful programming?:)
LPC has probably produced more sloppy coders than.... BASIC. But it's
not (as you say below) really the language so much as the individual using
it.
>: learn to the coding team. Then you wouldn't have the running or playing
>: game in a state of constant flux or modification, you'd just up the game
>: all at once when you're convinced that a major change is warranted.
>I understand the sentiment, and I've expressed it myself, but this is a
>matter of self discipline and policy, rather than codebase.
Right. I'd love to be able to say that this codebase or that makes evil
stock games less likely to arise. But every code base that is public
seems to have some bad stock versions out there.
OTOH, it seems that the development method used on most MUDs is only
used because it is the traditional way to do things in muddom. If
admin were to adopt and publicize a method like I layed out, perhaps
it would be picked up by newbie game administrators and it would naturally
lead them to produce better games? I'm thinking that while only 10-15% of
the admin/coders out there are producing really good games, a large
portion of the other 85-90% are indeed capable of better, they just
haven't had the right role models.
-McDaniel
John Adelsberger
: - people spent a long time rehearsing songs and stories
: before writing, and certainly exercised their 'memorize
: long blocks of information' capacities much more than
: we typically find today.
Yes, but does anyone care? That's the point of the answer I gave:)
: - I've met plenty of people, especially younger ones, for
: whom the basics of mathematics are a great challenge,
True enough, but I also know a ten year old who is _meaningfully_
studying mathematics that used to be put off until college. He
understands the principles behind basic mathematics, although he
still finds my ability to multiply large numbers in my head to be
a combination of amazing, masochistic, and archaic. And who
knows... maybe it _is._ For my part, I didn't know the complete
multiplication tables up to 10x10 until I was in high school,
but I think this actually _aided_ my computational skills rather
than harming them.
: - Few programmers ever knew every opcode for every machine
: on the planet. Every machine that _mattered_ maybe!
: But yes, opcode knowledge has declined substantially.
: This is, I think, an unlamented loss.
No kidding.
: - High level languages do indeed lead to the specified
: woe, which leads to all sorts of inefficiencies. I
: think the cheapness and availability of memory and
: disk space have been more the culprits in creating
: bloated and wasteful and slow code.
Maybe so, but I blame the education of programmers more
than the tools they use. Emphasis is on what 'industry
wants' rather than on understanding what you're doing.
I'm graduating in a week, and when I look at the people
who are supposedly my 'peers,' in most cases, I have a
hard time believing anyone is going to actually pay them
money for what they 'know.' They have much better grades
than I do, but they haven't _learned_ a damn thing that
they couldn't have picked up in two weeks with a Visual
C++ book. Talk about a waste of four years.
: - I'm not sure about web browsers, but television has
: done its fair share to obliterate reading skills.
: With the help of a willing public of course!
Actually, literacy rates in the US are at an all time
high, and they're rising last I heard. Slowly, but
they _are_ rising. It is pathetic that schools are
still passing students who _can't_ read on the basis
of academic ability and so forth, but I can't blame this
one on television.
: - I assume you are trying to say something wry about
: LPC. I've done the reading, but never used it, so
: I can't say much useful here, though I'll try! I'm
: sure careful coding was dead long before LPC came
: into being.
I don't think it is dead. I don't think it ever lived
any more or less than it does today. There are programmers,
and I like to think I'm one of them, who are quite
careful - mistakes still happen, but that's life. OTOH,
_most_ programmers are buffoons. HLLs and so forth don't
make that more likely - they just raise the number of
buffoons that can actually cut it by lowering the required
intellect/dedication. Even so, and even though they aren't
the ones you usually hear about, there are some _incredible_
people here and there, doing very, very good work, and their
numbers grow too - just not as quickly.
Anyway, the original point was that the whole purpose of progress
is to make life easier, and the fact that it succeeds in that
purpose is hardly an argument against progress.
John Adelsberger
: OTOH, it seems that the development method used on most MUDs is only
: used because it is the traditional way to do things in muddom. If
: admin were to adopt and publicize a method like I layed out, perhaps
: it would be picked up by newbie game administrators and it would naturally
: lead them to produce better games?
Maybe, but a large part of the problem is the unwillingness of a lot of
people to even learn to program - they think running a mud is a right,
and code should grow on trees to satisfy their exercise of that 'right.'
Dvarsk
John Adelsberger <j...@umr.edu> wrote in message
news:3734f...@news.cc.umr.edu...
> : used because it is the traditional way to do things in muddom. If
> : admin were to adopt and publicize a method like I layed out, perhaps
> : it would be picked up by newbie game administrators and it would
naturally
> : lead them to produce better games?
>
> Maybe, but a large part of the problem is the unwillingness of a lot of
> people to even learn to program - they think running a mud is a right,
> and code should grow on trees to satisfy their exercise of that 'right.'
>
A major advantage of LPC over any precompiled language is the ease of
learning the language. Now I know that coders generally hate the idea that
anything they do is easy to learn, but generally the trend is for tools NOT
to hamper the development process. The beauty of LPC is its ability to teach
coding, albeit a bastardized form thereof, in a fun method. Yes it allows a
plethora of junk muds to sprout up, but unlike diku, it doesn't euthanize
good coders who don't have time to devote to just learning the language.
Instead it allows them to grow into the knowledge.
This ease of learning becomes a major point when it's tied back to the
ancient start of this thread that the programmers/coders/builders are not
paid. However, if they can slowly learn at their own pace with limited road
blocks, many will move on to more serious muds and be able to contribute,
rather than just looking at their midguard setup and say "I don't have time
for this junk."
At this point, I think I need to separate off area coders from the mudlib
coders. Mudlib code should be planed in a methodical manner. For the most
part mudlib should be able to easily work in a precompiled method, and it
would be assumed that they know good coding practices. I suspect, in the
long run, gradualy increasing the responsibility of coding methods will
produce the same quality of code as the initial meat grinder method, as well
as saving the more imaginative programers who would have been ground out of
the process if tested too early. I suppose I should have prefixed all this
that it applies to area coders, because those are the people who benefit
from the flexibility of LPC. Yes, having an easy method for doing something
allows alot of junk to exist, just look at all the horrid web pages out
there, but no one says you have to visit them all. Of more importance
though, you keep the ones with imagination in the process. In the end, muds
are for enjoyment, not for profit. If you want profit, I suggest going
graphical. If not, then remember, all the work on a mud is voluntary and is
done for enjoyment, players and coders alike.
Any shmuck can churn code, it's the dreams I'm after, Dvarsk
John Adelsberger
: A major advantage of LPC over any precompiled language is the ease of
1. You're preaching to the choir.
: learning the language. Now I know that coders generally hate the idea that
: anything they do is easy to learn, but generally the trend is for tools NOT
: to hamper the development process. The beauty of LPC is its ability to teach
: coding, albeit a bastardized form thereof, in a fun method. Yes it allows a
2. LPC doesn't teach anything, and if you aren't a _good_ programmer, the
results are so horrible that I cannot find words for them.
: plethora of junk muds to sprout up, but unlike diku, it doesn't euthanize
: good coders who don't have time to devote to just learning the language.
3. LPC may be easier to learn to hack junk together in, but C is far easier
to learn to use properly. Even so, LPC is the appropriate language for
a text mud, if it and C are the choices.
: Instead it allows them to grow into the knowledge.
4. And produce a barely-functioning set of hacks that almost looks like a
coherent game.
: from the flexibility of LPC. Yes, having an easy method for doing something
: allows alot of junk to exist, just look at all the horrid web pages out
: there, but no one says you have to visit them all. Of more importance
: though, you keep the ones with imagination in the process.
Imagination is not what's lacking in the diku world. Initiative is. People
can't be _bothered_ to actually do anything but assemble snippets and stock
areas. Most won't even do new areas - try and tell me that's 'too hard to
learn.'
Daniel A. Koepke
On 13 May 1999, John Adelsberger wrote:
> LPC doesn't teach anything, and if you aren't a _good_ programmer, the
> results are so horrible that I cannot find words for them.
On the contrary, LPC is quite capable of teaching an unfortunate
dependence upon language specialization. The same occurs, but to a lesser
degree with C and other mid- through high-level languages.
> Imagination is not what's lacking in the diku world. Initiative is.
> People can't be _bothered_ to actually do anything but assemble
> snippets and stock areas. Most won't even do new areas - try and tell
> me that's 'too hard to learn.'
In my experience, there's no real lack of creativity in the Diku camp in
comparison to other MUD families and genres. But there certainly is a
glaring problem with a lot of DikuMUDs: the creativity isn't displayed in
the product. This is a symptom of players willing to play StockMUD,
enabling the continued existence of a MUD that would otherwise die out due
to a faux natural selection. The coders then are led to believe that it's
not only acceptable, but "good," if you put up such crap: they get players
and they think, "That must mean I've done something right..."
All it really means is that our species has perfected a means to allow the
stupid to not only survive, but propagate.
-dak
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Peter R. Sadlon
On Sat, 15 May 1999, Daniel A. Koepke wrote:
> On 13 May 1999, John Adelsberger wrote:
> > LPC doesn't teach anything, and if you aren't a _good_ programmer, the
> > results are so horrible that I cannot find words for them.
>
> On the contrary, LPC is quite capable of teaching an unfortunate
> dependence upon language specialization. The same occurs, but to a lesser
> degree with C and other mid- through high-level languages.
When it comes down to it, you learn programming 1 of 3 ways.
1) You learn from books/classes
2) You learn by yourself, trial and error
3) You wrote the language
Now most of the people I'd consider to be my peers, along with myself,
fall into #2. We played on C64 or VIC20s and we were curious about how
the computer worked, how the game worked and so we hacked into the program
lising and changed it, and from there we slowly learnt on our own. And as
time went on High School, University, and we learn from #1.
I now teach begginner programming labs at the University and let me tell
you you can tell who is a #1 and who is a #2 and the #2s are better
simply because they enjoy it and they learnt things themselves.
Noone becomes a good programmer by sitting in a class and learning from a
book. In time they learn and become better, once they realize they can't
better themselves without it. So by saying LPC makes bad programmers is
completely wrong. It just so happens most people who start their own MUDs
or start coding on one never had any training or experience and so they
will of course be sloppy programmers. And it doesn't matter if its LPC,
C, C++, Pascal, BASIC, ADA, Scheme, Prolog, Java or any other language out
there.
And LPC has LOTS to teach, and if you don't beleive so then you obviously
don't know enough about LPC to make an acurate opinion.
_Peter
Adam Wozniak
>
> A major advantage of LPC over any precompiled language is the ease of
LPC can be precompiled. I doubt your statements are based on whether or not
the language is compiled or interpreted. Compiled/interpreted usually
has little to do with how easy it is to learn the language.
--Adam
--
ad...@mudlist.eorbit.net
I report spam and unsolicited bulk/commercial email.
John Adelsberger
: LPC can be precompiled. I doubt your statements are based on whether or not
: the language is compiled or interpreted. Compiled/interpreted usually
: has little to do with how easy it is to learn the language.
While you're right, your answer is either only partly understood by you
or else truly asinine. It is undeniably true that it is easier to learn
a language when you have a very supportive runtime environment; generally,
interpreted ones are much better about this than compiled ones. Therefore,
even if his statement only makes sense given that context and an
understanding of the fact that it isn't absolute in and of itself, it DOES
make sense, and it does describe an observable and demonstrable benefit
of LPC vs many languages as they are currently implemented(and in what other
possible context could you be talking about learning a language?!)
Greg Miller
> I now teach begginner programming labs at the University and let me tell
> you you can tell who is a #1 and who is a #2 and the #2s are better
> simply because they enjoy it and they learnt things themselves.
Well, one of the things I learned in college was that four years isn't
enough to learn much about programming from scratch. By your senior
year, you can move from "remedial remedial computer science" to
"remedial computer science."
--
http://www.classic-games.com/
President Clinton was acquitted; then again, so was O. J. Simpson.
*** NEWBIES: Limit signatures to four lines! No HTML mail or posts! ***
John Adelsberger
In rec.games.mud.lp Greg Miller <gmi...@classic-games.com> wrote:
: Well, one of the things I learned in college was that four years isn't
: enough to learn much about programming from scratch. By your senior
: year, you can move from "remedial remedial computer science" to
: "remedial computer science."
This depends. I know a guy who never touched a computer til he was 18,
and taught himself C from the K&R book. He's about 25 now; when I met
him, he'd been at it for about 3 years programming, about 4 using
Windows, and about 1 using linux. Said guy is top notch, and was then,
too. OTOH, I know some people who've been at it longer than me(there
probably aren't more than a few tens of thousands of people worldwide
who ever owned an older microcomputer than my family's first) who
don't know their asses from their linkers.
Motivation and a certain capacity for abstraction are the big factors.
Time is almost irrelevant.
Miss K L Simpson
: LPC can be precompiled. I doubt your statements are based on whether or not
: the language is compiled or interpreted. Compiled/interpreted usually
: has little to do with how easy it is to learn the language.
Purely out of interest, are you talking about LPC being precompiled to
produce a pseudo code which only the driver can understand? or being
precompiled to produce a machine dependent executable, which you can run
apart from the driver, and the CPU can understand.
Three or four years ago, some one was offended when we tried to explain
that one of the main differences between C and LPC was the fact that you
couldnt compile a stand alone executable. They inferred, in a sarcastic
tone, that it was possible. If it is, how exactly is LPC precompiled? Is this
something available with one of the drivers? Which one? Can they be
compiled to do anything like C or just specifically to build a MUD? Which one?
What happens when an error occurs? Does the program completely crash? How do
efuns like this_player() and users() behave? How efuns like say() and
write() differ?
Greg Miller
>
> Distribution:
>
> In rec.games.mud.lp Greg Miller <gmi...@classic-games.com> wrote:
>
> : Well, one of the things I learned in college was that four years isn't
> : enough to learn much about programming from scratch. By your senior
> : year, you can move from "remedial remedial computer science" to
> : "remedial computer science."
>
> This depends. I know a guy who never touched a computer til he was 18,
> and taught himself C from the K&R book. He's about 25 now; when I met
> him, he'd been at it for about 3 years programming, about 4 using
> Windows, and about 1 using linux. Said guy is top notch, and was then,
> too. OTOH, I know some people who've been at it longer than me(there
> probably aren't more than a few tens of thousands of people worldwide
> who ever owned an older microcomputer than my family's first) who
> don't know their asses from their linkers.
Yes, but the key is that the guy you're talking about appears to be
mostly self-taught. He's likely got a *LOT* more time in than someone
who spent four years of class time and homework learning to program.
Greg Miller
I don't have much experience using LPC->C compilation, but it's an
option with both MudOS and DGD. Since both drivers are usable for
purposes other than as a MUD server, I see no reason why precompilation
of, say, a web server written in LPC wouldn't work.
Troels Tolstrup
> option with both MudOS and DGD. Since both drivers are usable for
> purposes other than as a MUD server, I see no reason why precompilation
> of, say, a web server written in LPC wouldn't work.
Yeah, but you still need to compile it into the DRIVER in order to use
it dont you?
Jason Cone
news:374A7A82...@get2net.dk...
My understanding of LPC -> C is limited to that of DGD's implementation.
Hence, my explanation will be limited to said driver.
If/when you decide to precompile some/all of your LPC code, you specify
those files (as well as some other miscellaneous precompilation-specific
configurations) in a Makefile that is part of the driver's source tree. DGD
has an independent sub source tree that can be "made" that produces a binary
that takes LPC files as arguments and outputs the associated legitmiate C
source code for the given LPC file as part of the driver's "make" process;
the LPC files' C source code is used as part of the driver's main source
tree and is compiled and linked with the driver.
I don't know for certain if the LPC files are still needed (perhaps Dworkin
can comment on this), but if you plan on updating the LPC files that were
precompiled (via compile_object(), etc.), they are still needed as the
interpreted version of the LPC is then used as if you never precompiled it.
You will need to compile the driver again to get the LPC file changes
precompiled into the driver.
Hope that helps.
--
Jason Cone
Sr. Software Developer
Usability Sciences Corporation
jc...@usabilitysciences.com
Aristotle@Threshold
>I don't have much experience using LPC->C compilation, but it's an
>option with both MudOS and DGD. Since both drivers are usable for
>purposes other than as a MUD server, I see no reason why precompilation
>of, say, a web server written in LPC wouldn't work.
Um, can you guys change the header?
You are having a valid discussion, but you still have the header of the
brainless troll that was already kicked to the curb about a month ago =)
Thanks.
-Aristotle@Threshold
--
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, mature, detailed roleplaying environment.
http://www.threshold-rpg.com -**- telnet://threshold-rpg.com:23
John Adelsberger
In rec.games.mud.lp Greg Miller <gmi...@classic-games.com> wrote:
: Yes, but the key is that the guy you're talking about appears to be
: mostly self-taught. He's likely got a *LOT* more time in than someone
: who spent four years of class time and homework learning to program.
My experience is that competent people put in a lot LESS time, because
they don't spend as much of it on mistakes, but certainly time spent
teaching yourself can be FAR more productive than 99% of the courses
you can take, assuming you can find decent materials from which to
learn. The point is, though, this guy was just like everyone else; he
was a college student at the time, and he had classes - the difference
is, he was there because he gave a damn, and so he didn't limit himself
to the glacial pace of students whose motivation is that they've heard
computing is a good field, and who are no good at it, and who simply
don't care. People of reasonable ability who actually care to do so
_can_ learn a _lot_ in a fairly short time, but you won't do that by
showing up for class, doing your homework, and then hitting the bars
every night.
John Adelsberger
In rec.games.mud.lp Troels Tolstrup <tro...@get2net.dk> wrote:
: Yeah, but you still need to compile it into the DRIVER in order to use
: it dont you?
I can't speak for the abilities of DGD, because I haven't even looked
at it in a couple of years except for very specific purposes, but MudOS
can use dynamic linkage. Log into a reasonably modern unix system and
type 'man dl_open' and then read that and related material such as
that covering dl_sym and dl_close.
While it may or may not be done this way on any given system(and it
probably shouldn't be...) you can get an idea of what this actually
does by imagining that the code gets loaded as data(ie, like reading
in a file, as opposed to starting a new program) and then function
pointers get set into it, creating the illusion that regular linkage
has occurred. This can be done while the program is running, and
such code can also be unlinked.
Therefore, a driver can compile something to C, get a .o file for it
from the c compiler, and then dl_open that file and, through function
pointers provided by dl_sym, call functions in it. When/if it finishes
with the code, it can remove it using dl_close(and perhaps load a newer
version.)
Greg Miller
>
> > I don't have much experience using LPC->C compilation, but it's an
> > option with both MudOS and DGD. Since both drivers are usable for
> > purposes other than as a MUD server, I see no reason why precompilation
> > of, say, a web server written in LPC wouldn't work.
>
> it dont you?
No, you can have it compiled and dynamically loaded.
Troels Tolstrup
>
> You are having a valid discussion, but you still have the header of the
> brainless troll that was already kicked to the curb about a month ago =)
>
> Thanks.
We are keeping the header of sentimental reasons :)
Aristotle@Threshold
Well, I'm sure you wouldn't be pleased if the header was "Troels Tolstrup,
answer yes or no. Have you stopped beating your wife yet?" (just as an
example).
Troels Tolstrup
Tolstrup,
> answer yes or no. Have you stopped beating your wife yet?" (just as an
> example).
Well since im not married im sure she wont mind =)