In truth, there is absolutely nothing that can be done to CircleMUD to
protect it from hackers of the site. You can add a self-destructing
code, you can add locks to the files, but if someone can get access to
your site, there is really nothing you can do about it. They can take
your MUD, and you will have no chance to stop them.
The only real way to stop code thieves is to be careful who you let on
the site. If you have coders, remember that each of them has access to
the site. And in turn, anyone they let have the password has access to
the site. The thing is, I am constantly hearing how MUD's just let
people have access to the code, without even asking for credentials,
checking them out, or even getting to know them. If you had a locked
room with thousands of dollars in cash lying around, would you give
someone a key to that room, just because they said they were a banker? I
think not. If you would, tell me where you live, I'm a banker. ;) You
have to make a system to 'hire' coders. If you just take whomever
applies, you will end up loosing big time, and the only person to blame
is yourself. I am not condoning the actions of people who do this, in
fact, I still consider it theft/destruction of property. After all, if
you invite the thief into your house and they steal everything, it's
still theft. They just don't get break and entering added on the bill.
The only advice I will give is that the site password should ONLY be
given to coders you trust, and MAYBE one high level administrator (and
not even that if you have online text file editing) That stops any
chance of someone asking any old immortal what the site password is. How
you handle giving out the password is your own business.
Hopefully, we can settle the problem of rampant thieves (hackers are good
people, it's the crackers that are bad) but as long as we have people who
set up MUD's without first knowing what they are doing, we will continue
to have this problem. I have said this on my CircleMUD Resource page,
and I will say it here: Before you start your own MUD, work your way up
to immortal, and eventually coder on another MUD. Learn what works, and
what doesn't when it comes to immortal policies. Learn the coder policy
and obey it. Don't be afraid to ask question about why something is done
a certain way. Talk to the immortals, and learn from them. And don't do
this on your friend Bob's MUD that he set up out of the box on his little
computer at home, do this on a well established, well respected, and
popular MUD that isn't plagued by problems. Too many people want to skip
the middle steps: They play a MUD, they run a MUD. It's like driving a
car, if you don't learn how to drive, or the rules of the road, you will
end up in trouble, or dead. In fact, by going to a MUD, you may end up
learning that despite how well the MUD SEEMS to run from the player's
perspective, there is something wrong when you actually join the
immortals. The MUD I started on (which I shall speak no name) seemed to
run very well, when you were a player. But once you joined the immortals
you found a world of intruigue and backstabbing that ended up ruining the
MUD experience for many people, and gave me and my significant other the
incentive to build our own MUD with a system that we believed would work
better. It also taught me that certain policies are absolutely needed on
a MUD in order for it to survive, and that some policies, which seem to
be good, can actually be counter productive.
Also, while I'm on the rant, I don't think people new to C should be
coding on MUD's. Coding on a MUD is not a good way to learn to program.
Yes, I know I did it that way, but I also had approximately 5 other
programming languages, all similar in style to C, under my belt before I
started it. Learn to program in C FIRST. If I had a choice, I would go
back and have picked up C before I started coding on a MUD. Start with a
few simple applications, and when you feel competant enough to go through
someone's code and be able to know what it does without seeing it work,
then you are ready to start coding on a MUD. And start with the outline
above, don't skip to the final step. All ou will end up doing is
creating YESC (Yet Another Stock CircleMUD) and very few people will find
it interesting, but once again, CircleMUD as a whole will bear the stigma
of being stock.
In closing, I am not going to just give out all that I have learned over
the years of MUDing and being an immortal and coder on many a MUD. By
doing that, I would be defeating the whole point of my statements. It's
not so much what you learn, but HOW you learn it. If you learn it by
hearing it from someone else, it means nothing. You MUST learn it by
your own experience. I know that this whole thing will not change the
minds of most people it is directed at, but if it reaches one of them, I
will consider it a success. I am not advocating the 'hoarding of
knowledge and information', I just think that people need to earn
knowledge through experience. Experience brings wisdom, and wisdom can
never be taught.
ObCircle:
generic_find and the functions within it REALLY need an overhaul. If you
try to look for 2.ring on worn eq, you can't find it, as it doesn't deal
with numbers properly. And if you want to look at 3.ring (1 & 2 are in
the inventory, but you want to look at the one you are wearing) it
doesn't pass the numbers on from one search function to the next
properly. This leads to problems when dealing with the immortal stat
command, which doesn't use the generic_find at all, and suffers the same
problem. If you want to the first blade in the where list, and you
happen to have one in your inventory, you will never be able to do it.
---
"One hundred years from now, none of this will matter because you and I
will be dead -- unless the Grim Reaper has switched his record-keeping to
a Windows 95-based system, in which case we all might live forever. "
-- Associated Press
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST