So Phoenyx has been an absolute machine in churning out new code, and I have been struggling to get caught up. Things are a little tense and hectic right now, because of a lot of RL things. Nothing bad, just lots of...well, stuff. Buying a car, for instance.
The commands table rebuild is done and functioning, and for that all credit goes to Phoenyx. I am deep in the DB module rebuild. It's making progress, just slow-agonizing-painful-I-wish-I-had-more-time progress.
Updates as they happen.
Wednesday, March 26, 2008
Thursday, March 20, 2008
Objects - The Who and Why
Okay, so there's been a lot of talk about "objects" in relation to PurlMUSH. They've been talked about as if they are the greatest thing since sliced bread(they are) and as if they are going to save the world(virtually speaking) and butter toast(not a chance). This is going to be my attempt to communicate what objects are and what they aren't, and why Phoenyx and I are charging forward with the object-oriented banner held high and proud.
So, in typically "me" style, let me make an analogy for you. Let's take a clock radio as our example. Now, 75 years ago, if you had wanted a clock radio, you would have had to make a circuit board. You would have had to solder the components to the board. You would have had to make a case for it. You would have had to fashion buttons. You would have had to connect the wire. And it would have worked. It would tell time, it would broadcast radio stations, it might even have an alarm if you decided that you wanted it to.
Now, if you want a clock radio, you can go down to Sears and buy a pre-built, ready-to-use, no-soldering-required clock radio. This "object" that you just bought would work just fine, right out of the box. It already has all the components of a clock radio, is aware of what it needs to do in order to fulfill its role as a clock radio, and all you have to do is take this "object" and put it wherever a clock radio is needed.
The first clock radio, the one lovingly soldered together and carefully assembled? That's the original code, and the way a lot of code is written. All of the component parts assembled together carefully putting each piece in place. It's functional, maybe not the easiest thing to use, and unless you have a well-made box to put it in, you can see all of its parts. (And who likes to let their parts hang out for everyone to see?)
The second one, the one you bought at Sears? It is the new version of the code on which Phoenyx and I are working diligently. It has everything packaged up into a nice object, with which we can work.
Each "object" will represent an object in the database. In the original implementation, the database was what is called 'an array of hashes'.
So, here's how that worked. An array is a numbered list of items. For example:
A hash is a referenced list. For example, if I was going to make a hash about this blog, it might look something like this:
If you put the two together, you are going to get an array of hashes. So, in the current implementation, I can refer to the name of room #10 like this:
$db[10]{"name"}
The $ tells Perl that it's a variable. Meaning a label that holds stuff. The [10] part tells the code what number in the array to look for. The {"name"} tells it which key in the hash to retrieve the value for. Now, you might ask yourself: But Santiago, this makes so much sense, why would you want to go and change that? Yes, it makes sense, but to a coder, it's cumbersome and in-elegant. Elegance is everything to a coder.
Under the new system, the arrays of hashes and all of that will be contained within an object. And the whole db will be inside one object. So, if we want the name of object #3, we'll do this:
$db->name(3)
Nicer, eh? An object is a piece of data that includes the methods we will need to be able to manipulate or report that data. So, with this object-oriented method, we can do things like the following. Let's say object #12 wants to set an attribute on #3:
$db->setAttr(12, 3, "foo", "You're a foo master!");
And that will set an attribute named foo on #3 with the value 'You're a foo master!". This attribute will be recorded as having been set by #12. Previously, we would have had to do this:
$db[3]{"foo"} = "You're a foo master!";
And that's just to set the attribute. That doesn't take into account keeping track of who set it, when, or anything else. The other nice thing is that setAttr, as a method of the $db object, will know whether #12 is even allowed to set attributes on #3. Previously, the code had to do all the tests for this in the main body of the code. Now, it's a matter of the object knowing how to do it, instead.
Does that mean we don't have to code those tests anymore? No, not at all. They will be built into the object instead of the main code. What it DOES mean though is that our objects will be handling the work load instead of the main body of the code. This will be easier to maintain, easier to manage, and easier to extend.
I hope this helps you understand what some of this rambling has been about. If you don't, e-mail me. :)
So, in typically "me" style, let me make an analogy for you. Let's take a clock radio as our example. Now, 75 years ago, if you had wanted a clock radio, you would have had to make a circuit board. You would have had to solder the components to the board. You would have had to make a case for it. You would have had to fashion buttons. You would have had to connect the wire. And it would have worked. It would tell time, it would broadcast radio stations, it might even have an alarm if you decided that you wanted it to.
Now, if you want a clock radio, you can go down to Sears and buy a pre-built, ready-to-use, no-soldering-required clock radio. This "object" that you just bought would work just fine, right out of the box. It already has all the components of a clock radio, is aware of what it needs to do in order to fulfill its role as a clock radio, and all you have to do is take this "object" and put it wherever a clock radio is needed.
The first clock radio, the one lovingly soldered together and carefully assembled? That's the original code, and the way a lot of code is written. All of the component parts assembled together carefully putting each piece in place. It's functional, maybe not the easiest thing to use, and unless you have a well-made box to put it in, you can see all of its parts. (And who likes to let their parts hang out for everyone to see?)
The second one, the one you bought at Sears? It is the new version of the code on which Phoenyx and I are working diligently. It has everything packaged up into a nice object, with which we can work.
Each "object" will represent an object in the database. In the original implementation, the database was what is called 'an array of hashes'.
So, here's how that worked. An array is a numbered list of items. For example:
- Bob
- Suzie
- Charles
- Diana
A hash is a referenced list. For example, if I was going to make a hash about this blog, it might look something like this:
- Name = Culturing a Purl
- URL = http://purlmush.blogspot.com
- Started = February 2008
If you put the two together, you are going to get an array of hashes. So, in the current implementation, I can refer to the name of room #10 like this:
$db[10]{"name"}
The $ tells Perl that it's a variable. Meaning a label that holds stuff. The [10] part tells the code what number in the array to look for. The {"name"} tells it which key in the hash to retrieve the value for. Now, you might ask yourself: But Santiago, this makes so much sense, why would you want to go and change that? Yes, it makes sense, but to a coder, it's cumbersome and in-elegant. Elegance is everything to a coder.
Under the new system, the arrays of hashes and all of that will be contained within an object. And the whole db will be inside one object. So, if we want the name of object #3, we'll do this:
$db->name(3)
Nicer, eh? An object is a piece of data that includes the methods we will need to be able to manipulate or report that data. So, with this object-oriented method, we can do things like the following. Let's say object #12 wants to set an attribute on #3:
$db->setAttr(12, 3, "foo", "You're a foo master!");
And that will set an attribute named foo on #3 with the value 'You're a foo master!". This attribute will be recorded as having been set by #12. Previously, we would have had to do this:
$db[3]{"foo"} = "You're a foo master!";
And that's just to set the attribute. That doesn't take into account keeping track of who set it, when, or anything else. The other nice thing is that setAttr, as a method of the $db object, will know whether #12 is even allowed to set attributes on #3. Previously, the code had to do all the tests for this in the main body of the code. Now, it's a matter of the object knowing how to do it, instead.
Does that mean we don't have to code those tests anymore? No, not at all. They will be built into the object instead of the main code. What it DOES mean though is that our objects will be handling the work load instead of the main body of the code. This will be easier to maintain, easier to manage, and easier to extend.
I hope this helps you understand what some of this rambling has been about. If you don't, e-mail me. :)
Wednesday, March 19, 2008
SO many updates
Okay, where to start:
Here's a good place. Phoenyx Black is in da hizzouse. There is a co-developer on the PurlMUSH project. Phoenyx is da bomb. Plain and simple. Thanks to his impressive input, PurlMUSH is advancing by leaps and bounds and has a much better chance of being a success now.
Other updates:
The command parser has been rebuilt by Phoenyx and is waiting my rebuild of the DB load routine before we implement. The command parser rebuild is also going to necessitate a reworking of the existing command subroutines.
The idea of the new command parser is that commands will be able to be registered in the system, their aliases clearly defined, permissions, and the function they are to run will all be structured rather than loosey-goosey as it is now. This will also facilitate developers who will be building extensions to the code later on. (@mail, BBS, etc)
What's up with the DB load routine, you ask? Excellent question my friend. I'll tell you.
The DB loading has been officially abstracted. What this means is that:
Here's a good place. Phoenyx Black is in da hizzouse. There is a co-developer on the PurlMUSH project. Phoenyx is da bomb. Plain and simple. Thanks to his impressive input, PurlMUSH is advancing by leaps and bounds and has a much better chance of being a success now.
Other updates:
The command parser has been rebuilt by Phoenyx and is waiting my rebuild of the DB load routine before we implement. The command parser rebuild is also going to necessitate a reworking of the existing command subroutines.
The idea of the new command parser is that commands will be able to be registered in the system, their aliases clearly defined, permissions, and the function they are to run will all be structured rather than loosey-goosey as it is now. This will also facilitate developers who will be building extensions to the code later on. (@mail, BBS, etc)
What's up with the DB load routine, you ask? Excellent question my friend. I'll tell you.
The DB loading has been officially abstracted. What this means is that:
- The main code doesn't care if the DB is in XML, SQL, HTML, or Elle magazine. As long as there is a module in place that will read in the db and return the appropriate set of objects, we're good.
- The db type will be specified in the .cnf file as the dbType parameter.
- Other db types can be added. Want PostgreSQL? NO problem! Want db4? Hell, want db2 data on a magnetic tape? No problem! Build a module that lets Perl access the data source, read in the data and return the appropriate objects and PurlMUSH won't care if you're reading octal values off punch cards.
- XML will become the "default" format for the flatfiles. Because the XML module will be standard "vanilla" PurlMUSH, you will always be able to read an XML flatfile in, and write an XML flatfile out.
Friday, March 7, 2008
Oh, and...
Also created a Google Group for it as well (http://groups.google.com/group/purlmush) so that we can have mailing lists go out and such as that. Don't know if it will ever get used, but it's there.
E-mail the group at purlmush@googlegroups.com
E-mail the group at purlmush@googlegroups.com
Branching out
Okay, so the project now has a GoogleCode page (http://code.google.com/p/purlmush). This will allow for svn, bug tracking, issue reporting.
I'll also post archives of the code there too.
I'll also post archives of the code there too.
Wednesday, March 5, 2008
Version Change
Given the amount of work that I've put into the code so far and how much it differs now from where I originally started, I have bumped the version up from 0.1 to 0.2. That marks it as a 'stable' version...though still Beta because we're pre-1.0. I don't know if I'm going to get to the point anytime soon where I have a third branch on the version number for builds...but I might get there. I will see if there's a way that I can post the code somewhere publicly without having to go to Sourceforge or something like that. I don't know if I'm ready for that kind of exposure just yet.
README
Welcome to PurlMUSH, a different way to do MUSH. This project is a labor of love more than anything else. It is a determined effort to take the robust and functional platforms provided by PennMUSH and TinyMUX and implement them using the Perl programming language. That means that, by definition, it is a proof-of-concept.
Of course, that also means that you can have fun with it, as well. Everything that has gone into the development of this project is based on the idea of code being fun...and something of an obsession as well.
A little bit of history on this project:
- Originally this project was started sometime around 2000 or 2001, when Santiago downloaded and registered a copy of PerlMUD from Boutell.com. Yes, the software was registered, conferring the rights to modify the code on to the Santiago. The idea was tantalizing...a MU*, in Perl. And thus, PurlMUSH was born.
- Help was solicited from a number of people online, most notably Steele from steelemountain.com, who shared Santiago's vision for doing outrageously cool stuff with the code.
- June 2005 - Project was effectively halted when Santiago began the RL trauma of separating and divorcing his wife. The code was lost to the divorce, and has not been seen since. Baby Jesus cried. The code had been some of the best work he had ever done in Perl.
- February 2008 - A new version of PerlMUD was downloaded by Santiago, and he felt the pull and tug of that earlier obsession. He renewed his license with
Boutell.com and began working on the code in earnest. Friends were able to provide server space, and the work began.
A little bit of the vision for what PurlMUSH might become:
- Fully object-oriented code structure, with each db object type having its own corresponding code object. Ideally, Flags and Logging will get OOP'ed too.
- Well-formed and fully compliant XML database flatfile structure.
- Internal systems such as comm/channels, BBS, Places/Mutter, IC time (with configurable ratios), Cron, and whatever other goodies are considered to be 'standard' softcoded systems on MUSHes today. Myrrdin's amazing softcoded systems are the de facto standard for BBS and Cron, there's two standard places and mutter packages out there, and a million things for IC time and other functionality like weather (Keran's *shudder*) or a +wear-style multi-descer (MANY many of these out there). One of the 'standard' and dreaded jobs that goes into starting a MU* is quoting in these very standard bits of code. Why? Projects like Sandbox Globals Project (SGP, again *shudder*) are built around the idea that your game comes with code. Comes with the systems that you need, "out of the box". Insta-MUSH, just add water.
- Easy to setup. Purl doesn't require compiling. You don't have to know a lot of fancy Unix/Linux commands to get your game running. Pretty much, as long as your server is connected to the Internet, has a "standard" installation of Perl (and eventually ActivePerl for Windows), you will be able to have a PurlMUSH up and running in under five minutes. No, seriously. There will be (eventually) a config script that you will run which will query for the necessary bits in the mush.cnf file, the things that won't be "assumed". For example, IP and hostname, file path for the db, etc. Other configuration options can be changed by hand-editing the file. Once you've been through the config script, you type ./Startpurl (or double-click the icon if you're on Windows) and VIOLA! You have a MUSH.
INSTALLATION
Download the code.
Unpack the code - tar jvxf purlmush-###.tar.bz2 (where ### is the version)
Edit the mush.cnf file to suit your mush and environment.
Type: ./Startpurl &
Connect to the host and port you have specified in the mush.cnf file and log in as the God character (default password: lollipops).
HELP
If you need help with PurlMUSH, first off: RTFM. Read the help files. If those don't help, read the blog (http://purlmush.blogspot.com). If that doesn't help, e-mail purlmush@gmail.com and Santiago will answer your query as best he can.
EXTENDING PURLMUSH
Yes, we want to be able to have modules that extend the functionality of Purl. If you have Perl-fu and want to build and contribute modules, please do so. In time, there will be a central repository for submissions, sort of a CPAN for Purl. For now, just e-mail them to Santiago (purlmush@gmail.com).
Good luck, and happy MUSHing!
Of course, that also means that you can have fun with it, as well. Everything that has gone into the development of this project is based on the idea of code being fun...and something of an obsession as well.
A little bit of history on this project:
- Originally this project was started sometime around 2000 or 2001, when Santiago downloaded and registered a copy of PerlMUD from Boutell.com. Yes, the software was registered, conferring the rights to modify the code on to the Santiago. The idea was tantalizing...a MU*, in Perl. And thus, PurlMUSH was born.
- Help was solicited from a number of people online, most notably Steele from steelemountain.com, who shared Santiago's vision for doing outrageously cool stuff with the code.
- June 2005 - Project was effectively halted when Santiago began the RL trauma of separating and divorcing his wife. The code was lost to the divorce, and has not been seen since. Baby Jesus cried. The code had been some of the best work he had ever done in Perl.
- February 2008 - A new version of PerlMUD was downloaded by Santiago, and he felt the pull and tug of that earlier obsession. He renewed his license with
Boutell.com and began working on the code in earnest. Friends were able to provide server space, and the work began.
A little bit of the vision for what PurlMUSH might become:
- Fully object-oriented code structure, with each db object type having its own corresponding code object. Ideally, Flags and Logging will get OOP'ed too.
- Well-formed and fully compliant XML database flatfile structure.
- Internal systems such as comm/channels, BBS, Places/Mutter, IC time (with configurable ratios), Cron, and whatever other goodies are considered to be 'standard' softcoded systems on MUSHes today. Myrrdin's amazing softcoded systems are the de facto standard for BBS and Cron, there's two standard places and mutter packages out there, and a million things for IC time and other functionality like weather (Keran's *shudder*) or a +wear-style multi-descer (MANY many of these out there). One of the 'standard' and dreaded jobs that goes into starting a MU* is quoting in these very standard bits of code. Why? Projects like Sandbox Globals Project (SGP, again *shudder*) are built around the idea that your game comes with code. Comes with the systems that you need, "out of the box". Insta-MUSH, just add water.
- Easy to setup. Purl doesn't require compiling. You don't have to know a lot of fancy Unix/Linux commands to get your game running. Pretty much, as long as your server is connected to the Internet, has a "standard" installation of Perl (and eventually ActivePerl for Windows), you will be able to have a PurlMUSH up and running in under five minutes. No, seriously. There will be (eventually) a config script that you will run which will query for the necessary bits in the mush.cnf file, the things that won't be "assumed". For example, IP and hostname, file path for the db, etc. Other configuration options can be changed by hand-editing the file. Once you've been through the config script, you type ./Startpurl (or double-click the icon if you're on Windows) and VIOLA! You have a MUSH.
INSTALLATION
Download the code.
Unpack the code - tar jvxf purlmush-###.tar.bz2 (where ### is the version)
Edit the mush.cnf file to suit your mush and environment.
Type: ./Startpurl &
Connect to the host and port you have specified in the mush.cnf file and log in as the God character (default password: lollipops).
HELP
If you need help with PurlMUSH, first off: RTFM. Read the help files. If those don't help, read the blog (http://purlmush.blogspot.com). If that doesn't help, e-mail purlmush@gmail.com and Santiago will answer your query as best he can.
EXTENDING PURLMUSH
Yes, we want to be able to have modules that extend the functionality of Purl. If you have Perl-fu and want to build and contribute modules, please do so. In time, there will be a central repository for submissions, sort of a CPAN for Purl. For now, just e-mail them to Santiago (purlmush@gmail.com).
Good luck, and happy MUSHing!
Good Ideas = More Work
So, I realized that there were a couple things that I had done before with PurlMUSH that I was going to have to re-do. The first, and one of the most important, is building the cnf parameters into a hash that can be changed using an @config command. As well, I still haven't written the code to have .cnf reloaded when the game does an @reload. This is important...that way a MUSH admin can change config options on the server-side, @reload, and they take effect. A practical example of this would be turning building on.
At the same time I was thinking about that, I realized that we should probably have a config script that nicely prompts the user for things like IP, hostname, name of the MU*, etc. This will gently and pleasantly write the mush.cnf file for them and move them speedily along the path of getting the game up and running. Oooh, here's an idea...have the config script prompt them for a pw for God(#1) and do the md5_base64 encoding on it right into the initial db. In fact, if we made it a requirement that the config be run to write the initial db, that would guarantee a bit more security on the God character. Of course, you could also just have an old db/cnf file that you drop in and away you go...theoretically.
I also remembered that I used to have @module as a command in the original codebase. That allowed you to load in code from an expansion module. I am not sure if I want to go that route again, but I might....the idea is great, but the problem of course is that once you load it in, it's remarkably hard to unload it afterwards. Have to think about that.
Made a few cosmetic changes to the file structure, specifically changing the name of the db file, the executable, and the library file. Did this just to give it its own flavour, more than anything else. mud.db is now mush.db. mud is now Startpurl, and mudlib.pl is now mush_lib.
I also got brave and wrote an initial README. I will post it in another blog posting.
At the same time I was thinking about that, I realized that we should probably have a config script that nicely prompts the user for things like IP, hostname, name of the MU*, etc. This will gently and pleasantly write the mush.cnf file for them and move them speedily along the path of getting the game up and running. Oooh, here's an idea...have the config script prompt them for a pw for God(#1) and do the md5_base64 encoding on it right into the initial db. In fact, if we made it a requirement that the config be run to write the initial db, that would guarantee a bit more security on the God character. Of course, you could also just have an old db/cnf file that you drop in and away you go...theoretically.
I also remembered that I used to have @module as a command in the original codebase. That allowed you to load in code from an expansion module. I am not sure if I want to go that route again, but I might....the idea is great, but the problem of course is that once you load it in, it's remarkably hard to unload it afterwards. Have to think about that.
Made a few cosmetic changes to the file structure, specifically changing the name of the db file, the executable, and the library file. Did this just to give it its own flavour, more than anything else. mud.db is now mush.db. mud is now Startpurl, and mudlib.pl is now mush_lib.
I also got brave and wrote an initial README. I will post it in another blog posting.
Monday, March 3, 2008
Updated ToDo List
1. Change all db objects to true Object-Oriented code objects - Right now it's an array of hashes. I want an array of objects, indexed by dbref. If that's greek to you, no worries. I'll likely write a more eloquent and explanatory post in the near future about the objects and what they do and why I want to use them.
2. XML db format. I want to dump out the db when it's saved into XML format. This will allow for portability, and a few other things. Plus, XML's cool. Again, proof of concept.
3. Logging - Various levels of logging need to be done, including connection logging, system event logging (db dumps, @reloads, etc), and eventual support for the SUSPECT flag for command logging of suspect players.
4. All code projects have to have a README and a Changelog. I will have to write these. Bleh.
5. PerlMUD comes with a built-in 'topics' feature. I will redesign this to implement channels. Should channels log? Hmmm.
6. We need to be able to do non-standard attributes, so that we can move towards custom locks and things like that. &blah #123=Blah.
7. @mail is needed - Have to harvest some ideas on best way to do this.
8. I am going to hardcode the BBS. Myrrdin's +bb system is so universal. Every game has a BBS. So, this one will too, but it will be a better system, hardcoded.
9. @moniker from MUX. I love having ansified names. I will do this. Yes, I will.
10. An idea from Ti'Anna - @paste. This is a command from MOO where you type @paste , hit enter. THen you paste in a whole whack of text that you want to show them, and type a . on a line to signify that you're done. Then, they get it spammed on their screen. I like this, I will do this.
11. The commands table will need to be rebuilt at some point. I know how I did it before and I don't think I want to do that again. I will have to come up with something new for that.
12. Guests - Guests on a MU* are limited in what they can do. They're like a player...with FAS. If that sounds mean, too bad.
13. WHO - Oh gods...WHO. I hate the current WHO. I have to get it to behave like a regular WHO. And that means building an admin WHO as well.
14. examine - See WHO. Oy.
15. Recycle Bin - This was something I had done before. When you @recycle an object, it goes into the recycle bin, and can be @restore'd. One time only. Once something else is @recycled, your object is lost.
16. inventory - See examine, see WHO. Oy x 2.
17. Help files need to be reformatted, rewritten, and constantly, constantly, constantly updated. Ow. Programmers hatelovehatelovehate documentation.
18. news file functionality - It's gotta be there. Why? Cause it's a standard.
19. Rebuild setting the various standard attr's (fail, ofail, succ, osucc, etc). Each one has its own subroutine, which is just dumb.
20. Book objects need to be revisited. Not sure on these.
21. Names need to be able to have spaces.
22. @teleport needs to have arrive, depart, oarrive, odepart messages.
23. I seem to remember that @find/@search stunk. I may have to revisit this.
24. @aconnect - Things to do when you connect.
25. @dolist - Make a list of things to do and do them
26. Creatures - You can't currently page a Creature, but everything else "seems" to work. I should probably add in a filter that prevents output from going to the owner if the owner and the object are in the same room.
27. Do I want to do @power? Probably. But, ew.
28. OMFG. I just realized that gags are based on player name, not dbref. FIX THIS!
2. XML db format. I want to dump out the db when it's saved into XML format. This will allow for portability, and a few other things. Plus, XML's cool. Again, proof of concept.
3. Logging - Various levels of logging need to be done, including connection logging, system event logging (db dumps, @reloads, etc), and eventual support for the SUSPECT flag for command logging of suspect players.
4. All code projects have to have a README and a Changelog. I will have to write these. Bleh.
5. PerlMUD comes with a built-in 'topics' feature. I will redesign this to implement channels. Should channels log? Hmmm.
6. We need to be able to do non-standard attributes, so that we can move towards custom locks and things like that. &blah #123=Blah.
7. @mail is needed - Have to harvest some ideas on best way to do this.
8. I am going to hardcode the BBS. Myrrdin's +bb system is so universal. Every game has a BBS. So, this one will too, but it will be a better system, hardcoded.
9. @moniker from MUX. I love having ansified names. I will do this. Yes, I will.
10. An idea from Ti'Anna - @paste. This is a command from MOO where you type @paste , hit enter. THen you paste in a whole whack of text that you want to show them, and type a . on a line to signify that you're done. Then, they get it spammed on their screen. I like this, I will do this.
11. The commands table will need to be rebuilt at some point. I know how I did it before and I don't think I want to do that again. I will have to come up with something new for that.
12. Guests - Guests on a MU* are limited in what they can do. They're like a player...with FAS. If that sounds mean, too bad.
13. WHO - Oh gods...WHO. I hate the current WHO. I have to get it to behave like a regular WHO. And that means building an admin WHO as well.
14. examine - See WHO. Oy.
15. Recycle Bin - This was something I had done before. When you @recycle an object, it goes into the recycle bin, and can be @restore'd. One time only. Once something else is @recycled, your object is lost.
16. inventory - See examine, see WHO. Oy x 2.
17. Help files need to be reformatted, rewritten, and constantly, constantly, constantly updated. Ow. Programmers hatelovehatelovehate documentation.
18. news file functionality - It's gotta be there. Why? Cause it's a standard.
19. Rebuild setting the various standard attr's (fail, ofail, succ, osucc, etc). Each one has its own subroutine, which is just dumb.
20. Book objects need to be revisited. Not sure on these.
21. Names need to be able to have spaces.
22. @teleport needs to have arrive, depart, oarrive, odepart messages.
23. I seem to remember that @find/@search stunk. I may have to revisit this.
24. @aconnect - Things to do when you connect.
25. @dolist - Make a list of things to do and do them
26. Creatures - You can't currently page a Creature, but everything else "seems" to work. I should probably add in a filter that prevents output from going to the owner if the owner and the object are in the same room.
27. Do I want to do @power? Probably. But, ew.
28. OMFG. I just realized that gags are based on player name, not dbref. FIX THIS!
Updated Done List
- ; (semicolon) needs to be changed so that it does an emote with no space between the character's name and the text - DONE. This turned out to be simpler than I expected, though I don't know why I expected it to be hard.
- IP/Site stored as attributes on a player - DONE. No +alts command yet, but I need to rebuild @search/@find first. But, now it works and will record both site and IP. Admin WHO reports IP if no site stored (box with no reverse DNS lookup for instance)
- WHO - Admin and Mortal WHO look better. Not 100% yet but much better.
- Time Format - Fixed so that it's proper 00:00 format.
- Although I thought it was in there already since it was in the help files, I built in support for 'creatures'. The MU* world knows these more commonly as puppets. Now, not only do creatures exist and relay all that they see to their owner, but there is a hardcoded way to control your creature. Traditionally, you've had to code your own $command on a MUSH to control a creature. Not so here. You can just use %
and it will do whatever you tell it to do. The caveat to this is that you have to register your creature with the MUSH using the @creature command. Syntax is: @creature #123. Once that's done, the creature is entered into the playerIds hash so that it can be referenced as a player...to some degree. There will be some development on this. Yes, I know this is a new way of doing things, but...let's try it out, kthx.
Ansi Redux Redux
Okay, it's official. I kicked ansi's ass. Right after I kicked my own, that is. I'm a moron, and I was having a forest vs. trees moment. The entire issue had to do with the fact that it wasn't evaluating the regular expression I was using for substitution properly, because I had set the wrong flags.
It also was being evaluated by pulling from a hash value.
If all of this is too geeky for you, let me boil it down: I'm an idiot. I fixed it.
For the geeky amongst you, it's the difference between:
$arg =~ s/\%xh/$ansi{"HILITE"}/ge;
AND
$arg =~ s/\%xh/\033[1m/g;
The latter works, the former didn't. Problem solved, now on to my next challenge.
It also was being evaluated by pulling from a hash value.
If all of this is too geeky for you, let me boil it down: I'm an idiot. I fixed it.
For the geeky amongst you, it's the difference between:
$arg =~ s/\%xh/$ansi{"HILITE"}/ge;
AND
$arg =~ s/\%xh/\033[1m/g;
The latter works, the former didn't. Problem solved, now on to my next challenge.
Friday, February 29, 2008
Ansi Redux
Thank you to the MUX crew...Their ansify tool allowed me to create ansi in my login screen. I have now been able to do this...and will be asking Brazil if he minds if I either a) make a Perl version of that script or b) just use the ansify tool outright.
Onwards...
Onwards...
Ansi
It seems that I have a current love-hate relationship going with ansi on PurlMUSH. The %x substitutions don't want to work quite right and when I tried to put ansi in the connect screen...(which would be incredibly cool)...it didn't work. I will have to work on this a bit more.
I seem to remember that this was relatively easy before. Of course, I also had 24/7 to work on it before. Ahh, the good old days. (good? Who the hell am I kidding?)
I seem to remember that this was relatively easy before. Of course, I also had 24/7 to work on it before. Ahh, the good old days. (good? Who the hell am I kidding?)
Thursday, February 28, 2008
Lest I forget - Thank you Steele
I want full complete and total kudos to go out to Antonio@ChicagoMUSH, Steele@Steelemountain.com, Nebic@CDI, and any of his other aliases. This guy was my rock when I started this project several years ago, originally. He was a source of Perl wisdom, an incredible RPer, an awesome MU* coder, a true friend.
Life took him in a very different direction, very suddenly. I regret losing contact with him, and regret that my life kept me from working harder to keep that friendship.
A lot of the ideas and solutions that populated the original incarnation of PurlMUSH can be attributed to his influence, and this project could not possibly go forward without me sending a shout out to him.
Thank you, my friend. Please don't hesitate to contact me if this post ever finds you. I miss you.
Life took him in a very different direction, very suddenly. I regret losing contact with him, and regret that my life kept me from working harder to keep that friendship.
A lot of the ideas and solutions that populated the original incarnation of PurlMUSH can be attributed to his influence, and this project could not possibly go forward without me sending a shout out to him.
Thank you, my friend. Please don't hesitate to contact me if this post ever finds you. I miss you.
Updates!
Okay, please keep in mind that I am representing a week's worth of work here with these posts. Pretty soon we will be posting in real time, but for now, I am just updating on the things I have accomplished so far.
- Rebuild the flags table - DONE! Flags table is a hash with two dimensions. Full name of hash is first dimension, and then fields like 'value', 'name', and 'symbol'. Symbol is the abbreviation that will eventually be going in ()'s after the dbref.
- Update the % substitutions - IN PROGRESS. I have the parsing code rewritten, a bit more elegantly I believe. Support for %r, %b, and %t is in. Ansi, on the other hand, is being a PITA. I believe I know which way I have to go with it, but it's going to take about 20m to sit down and rebuild that code to make it work the way I want. So much for my initial idea. But, ansi will work, I know this.
- think command - DONE
- @chown needs to work better, for changing ownership - DONE, or at least an initial version of this.
- Encrypt passwords - DONE! Passwords are encrypted using md5_base64 and authentication is done versus the encrypted version.
- Ability to use 'create' on the login screen - DONE!
- Break out config options in a .cnf file for the MU* to load - DONE! But I need to add support in so that this file is reloaded when the @reload command is done.
- @doing should have a string length limit - DONE!
- Autosay sucks. I hate it. Right now if you type something in that doesn't match a command, it will just say it. Now, some people might like this, so I will retain the feature, but as a flag. Not as a default hardcoded behaviour. - DONE!
- Gender is currently part of @set, like a flag. I don't like that. We need a standardized @sex command - DONE!
- IP/Site stored as attributes on a player - IP now being resolved properly. I think the box I'm on doesn't allow for reverse DNS lookups, but the code is in there to do it. I'm counting this as...you guessed it...DONE!
- Standard error message of Huh? (Type "help" for help.) - DONE!
- WHO - Started on this. There are now both admin and mortal WHO but there is a lot of work left to do on this.
- Look shows d/c'ed or dark players - DONE!
- Help files need to be reformatted, rewritten, and constantly, constantly, constantly updated - Reformatted. It's a start.
- Ansi in the connect splash. Gotta be done. Just gotta be. :)
- Substitutions/evaluations need to be done on ALL messages, whether it's a page, an osucc, a whisper, whatever - DONE! (I think)
- xyzzy will be added, as an homage. :) - DONE!
- Aliases need to be enabled through @alias - DONE!
- Added the SO_KEEPALIVE option so that people with dropping connections "shouldn't" have a problem anymore. Still in testing.
- Changed up connect screen options so they're matching on regexps rather than bareword literals.
- Made sure all players logging in would have a location. This wasn't set explicitly, though it should have been. Bit of a hack for now, will work on something more permanent later.
ToDo List
Well, I had to get started somewhere. I've talked earlier about having to take out the http server engine from the PerlMUD code and reformat a lot of the code for stylistic and syntactic consistency. This is my first fell swoop of 'making it mine'. Now, I shall list a rather sizable list of bullet points that represent things that I am going to be doing on Purl to develop it.
- Rebuild the flags table - Right now, flags are defined as individual variables. I want to be able to have a flag name, value, abbreviation in one hash table.
- Change all db objects to true Object-Oriented code objects - Right now it's an array of hashes. I want an array of objects, indexed by dbref. If that's greek to you, no worries. I'll likely write a more eloquent and explanatory post in the near future about the objects and what they do and why I want to use them.
- XML db format. I want to dump out the db when it's saved into XML format. This will allow for portability, and a few other things. Plus, XML's cool. Again, proof of concept.
- Update the % substitutions - Lots of work here. %r and %t (carriage return and tab) aren't supported, ansi's not supported, and the way it's currently programmed is...inefficient, imnsho.
- think command - Unbelievably useful for testing things. Not currently supported and easy to implement.
- @chown needs to work better, for changing ownership.
- Encrypt passwords - Dear gods! Passwords are stored in plain text in the db. Have to encrypt those.
- Logging - Various levels of logging need to be done, including connection logging, system event logging (db dumps, @reloads, etc), and eventual support for the SUSPECT flag for command logging of suspect players.
- Ability to use 'create' on the login screen - Players need to be able to create themselves at the login screen.
- Break out config options in a .cnf file for the MU* to load.
- @doing should have a string length limit
- Autosay sucks. I hate it. Right now if you type something in that doesn't match a command, it will just say it. Now, some people might like this, so I will retain the feature, but as a flag. Not as a default hardcoded behaviour.
- ; (semicolon) needs to be changed so that it does an emote with no space between the character's name and the text. Right now, it's for something else. I want the behaviour of this codebase to be very similar to established "standards" for MU*ing.
- All code projects have to have a README and a Changelog. I will have to write these. Bleh.
- PerlMUD comes with a built-in 'topics' feature. I will redesign this to implement channels. Should channels log? Hmmm.
- Gender is currently part of @set, like a flag. I don't like that. We need a standardized @sex command.
- We need to be able to do non-standard attributes, so that we can move towards custom locks and things like that. &blah #123=Blah.
- @mail is needed - Have to harvest some ideas on best way to do this.
- I am going to hardcode the BBS. Myrrdin's +bb system is so universal. Every game has a BBS. So, this one will too, but it will be a better system, hardcoded.
- @moniker from MUX. I love having ansified names. I will do this. Yes, I will.
- An idea from Ti'Anna - @paste. This is a command from MOO where you type @paste
, hit enter. THen you paste in a whole whack of text that you want to show them, and type a . on a line to signify that you're done. Then, they get it spammed on their screen. I like this, I will do this. - The commands table will need to be rebuilt at some point. I know how I did it before and I don't think I want to do that again. I will have to come up with something new for that.
- IP/Site stored as attributes on a player. Currently the game doesn't record what IP you connected from. I may build in a +alts-style command, at some point.
- Standard error message of Huh? (Type "help" for help.)
- Guests - Guests on a MU* are limited in what they can do. They're like a player...with FAS. If that sounds mean, too bad.
- WHO - Oh gods...WHO. I hate the current WHO. I have to get it to behave like a regular WHO. And that means building an admin WHO as well.
- Look shows d/c'ed or dark players. Cannot have this.
- examine - See WHO. Oy.
- Recycle Bin - This was something I had done before. When you @recycle an object, it goes into the recycle bin, and can be @restore'd. One time only. Once something else is @recycled, your object is lost.
- inventory - See examine, see WHO. Oy x 2.
- Help files need to be reformatted, rewritten, and constantly, constantly, constantly updated. Ow. Programmers hatelovehatelovehate documentation.
- news file functionality - It's gotta be there. Why? Cause it's a standard.
- Ansi in the connect splash. Gotta be done. Just gotta be. :)
- Rebuild setting the various standard attr's (fail, ofail, succ, osucc, etc). Each one has its own subroutine, which is just dumb.
- Book objects need to be revisited. Not sure on these.
- Substitutions/evaluations need to be done on ALL messages, whether it's a page, an osucc, a whisper, whatever.
- Names need to be able to have spaces.
- @teleport needs to have arrive, depart, oarrive, odepart messages.
- I seem to remember that @find/@search stunk. I may have to revisit this.
- xyzzy will be added, as an homage. :) If you don't know what that is, Wikipedia is your friend.
- Aliases need to be enabled through @alias.
- @aconnect - Things to do when you connect.
- @dolist - Make a list of things to do and do them.
- Time and Date format - Again, needs to be standardized. Currently does it as a single value (1d, 32s, 14h). Needs to be in 00:00 format.
The seed is planted
PurlMUSH will be reborn. This is something I have decided. This project existed a long time ago, and was relatively well-advanced before RL tragedy struck. All of the previous code was lost. This is a shame, because it was excellent code.
Regardless, it will be rebuilt. We will make it bigger, faster, stronger. We have the technology.
First off, what IS PurlMUSH? PurlMUSH is an endeavour to build a MUSH (a la TinyMUX, PennMUSH, TinyMUSH) purely in the Perl programming language. This is proof of concept more than anything else. It is never going to compete with the major flavours of MUSH, but it will be done for the sake of doing it. Perversity at its best.
Now, first off, I have to give credit where credit is due. Thomas Boutell of Boutell.com originally developed PerlMUD (http://www.boutell.com/perlmud/index.html) and it is FROM PerlMUD that a great deal of this is inspired. That being said, I have purchased a license for PerlMUD and from there I am developing my own version of this. I make NO CLAIM that this is entirely my code. However, all changes and differences from the original code of PerlMUD are entirely my own. My bugs are my own and will remain that way. I will fix them. Eventually. :)
Why am I doing this project? Because I love Perl. And I love MUSH. Therefore, it's the love child of my two online passions. I believe that I can make this a good piece of code. I know that I can write good Perl code, and I know that I have a very good understanding of how MUSHes operate. I've been on them for a long time.
So, all that being said, this project officially launched on February 15th. Thanks to the generosity of Lorinthal and Ti'Anna, PurlMUSH is up and running on the development server of supermassive.blackhole-ninjas.net, port 8301.
Before the code was functional, I had to strip out the http server that was bundled into PerlMUD. That took a while. I also optimized some of the code for readability according to my style specifications.
An example is, PerlMUD had code like this:
if (!&wizardTest($me)) {
&tellPlayer($me, "You must be a wizard to do that.");
}
Standard code, right? Yes, it is. However, I enjoy the following syntax MUCH much better.
&tellPlayer($me, "You must be a wizard to do that.") if (!&wizardTest($me));
It's more readable to me. If you're not a code junkie, you may not get the distinction, and that's okay. Read on, as I will document many more things to come.
One last note. Why PurlMUSH? Well, there's the obvious homonymic similarity between Perl, and Purl. The accusation was, at one point, that Purl was short for 'purloined', aka stolen. That I had stolen the idea from Boutell and was claiming it as my own. Not true. I wanted something distinct. And I also remember from my many years watching my mother knit and crochet that there is a stitch called a purl stitch. It can be done to put, for example, a golden or silver stitch around the edge of something. Which, in some senses, is what I am doing. I am taking the core server functionality of PerlMUD and gilding it, purling it if you will. There is also a definition out there of Purl being the murmuring sound of water. I may not be murmuring constantly through this, but...I like the idea. And last, a Purl is a Persistent Uniform Resource Locator. A permanent place on the web, if you will. I'm very persistent about making PurlMUSH a reality. Hence, the name. And so yes, the name of this blog is 'Culturing a Purl' and will continue to be so, because I have taken a seed, placed it in my oyster-ish brain, and I hope a true 'pearl' will emerge.
This will be the story of how this Purl is cultured.
Regardless, it will be rebuilt. We will make it bigger, faster, stronger. We have the technology.
First off, what IS PurlMUSH? PurlMUSH is an endeavour to build a MUSH (a la TinyMUX, PennMUSH, TinyMUSH) purely in the Perl programming language. This is proof of concept more than anything else. It is never going to compete with the major flavours of MUSH, but it will be done for the sake of doing it. Perversity at its best.
Now, first off, I have to give credit where credit is due. Thomas Boutell of Boutell.com originally developed PerlMUD (http://www.boutell.com/perlmud/index.html) and it is FROM PerlMUD that a great deal of this is inspired. That being said, I have purchased a license for PerlMUD and from there I am developing my own version of this. I make NO CLAIM that this is entirely my code. However, all changes and differences from the original code of PerlMUD are entirely my own. My bugs are my own and will remain that way. I will fix them. Eventually. :)
Why am I doing this project? Because I love Perl. And I love MUSH. Therefore, it's the love child of my two online passions. I believe that I can make this a good piece of code. I know that I can write good Perl code, and I know that I have a very good understanding of how MUSHes operate. I've been on them for a long time.
So, all that being said, this project officially launched on February 15th. Thanks to the generosity of Lorinthal and Ti'Anna, PurlMUSH is up and running on the development server of supermassive.blackhole-ninjas.net, port 8301.
Before the code was functional, I had to strip out the http server that was bundled into PerlMUD. That took a while. I also optimized some of the code for readability according to my style specifications.
An example is, PerlMUD had code like this:
if (!&wizardTest($me)) {
&tellPlayer($me, "You must be a wizard to do that.");
}
Standard code, right? Yes, it is. However, I enjoy the following syntax MUCH much better.
&tellPlayer($me, "You must be a wizard to do that.") if (!&wizardTest($me));
It's more readable to me. If you're not a code junkie, you may not get the distinction, and that's okay. Read on, as I will document many more things to come.
One last note. Why PurlMUSH? Well, there's the obvious homonymic similarity between Perl, and Purl. The accusation was, at one point, that Purl was short for 'purloined', aka stolen. That I had stolen the idea from Boutell and was claiming it as my own. Not true. I wanted something distinct. And I also remember from my many years watching my mother knit and crochet that there is a stitch called a purl stitch. It can be done to put, for example, a golden or silver stitch around the edge of something. Which, in some senses, is what I am doing. I am taking the core server functionality of PerlMUD and gilding it, purling it if you will. There is also a definition out there of Purl being the murmuring sound of water. I may not be murmuring constantly through this, but...I like the idea. And last, a Purl is a Persistent Uniform Resource Locator. A permanent place on the web, if you will. I'm very persistent about making PurlMUSH a reality. Hence, the name. And so yes, the name of this blog is 'Culturing a Purl' and will continue to be so, because I have taken a seed, placed it in my oyster-ish brain, and I hope a true 'pearl' will emerge.
This will be the story of how this Purl is cultured.
Subscribe to:
Comments (Atom)