This past week I've been working on creating a theme from some stunning graphics provided for the Sloth III website. There are several points of difficulty I'm running into while applying the theme to the site.
The first is that the graphics provided, while stunning, don't quite cover the spectrum of content types we have on the site. For example, we have a few pages where the entire content is simply a table, such as the list of players online. Of course, I got distracted trying to make them look nicer within the theme by hacking up some of the graphics provided. I had to download and install GIMP to do reasonable amount of editing on images because Microsoft Paint doesn't cut it and Adobe Photoshop costs too much. It doesn't look any better; but, what I did learn is that the code that I put together for the auction module and what I have done so far on the
The second is that the method for creating a theme for Post Nuke CMS isn't well documented (surprise). Yes, there are some documents, but there are undocumented sections of the config file that is required for each theme. That indicates likely one of two things, either the developers haven't gotten to documenting it, or they haven't gotten to coding it. I'd guess the latter since I can't find any examples of anything using the undocumented config settings, but it is time consuming to figure out the useless config sections.
The third point of difficulty is that I haven't finished applying the entire theme before I skipped to modifying a few of the modules. It's a tough choice to figure out the best order of this since, I don't know the best way to make the theme and I don't know the best way to make a module look in a theme, I'm bumbling back and forth between the two. My current lean is to go back to the theme and finish either the two-column or three-column format. So far, I have finished the home page and found that there is one graphic mistake provided to us that I will have to address at some point.
Sunday, April 30, 2006
Saturday, April 22, 2006
Yahoo has some nice free code
I'm currently working on creating a set of functions that will serve as a library for making simple form-based applications on top of the Post Nuke CMS framework. So far I have taken the approach that I'll abstract the details of creating the html, processing the return and creating an SQL query by making it all configurable in a single helper file.
It's a work in progress, but so far I have created a set of functions that will generate a form based on a configuration file that has the following types of inputs:
So what's left to do is to finish the parser for each of these form pieces (most are done) and then plug that into the dynamic SQL generator. I know I am missing a whole layer for business logic in this but I don't need it yet for the application I'm building. It is a replacement for the the SlothMud III Equipment List that was previously built on core PHP and is linked to on the site. It has a tremendous breadth of features that all boil down to a generating the right query based on a set of checkboxes and a few text fields. It selects the appropriate data without really much further processing and then returns the results.
When I began approaching this problem, I wanted to just make the core scripts look like the rest of the site, but that really was going to leave a lot of functionality on the table, plus when I got into it, I really didn't like what I saw on how it was written (no disrespect to Enea intended).
The current difficulty with integrating this with Post Nuke is that though the 0.8 has a scripting language being built, it seems to be currenlty just an engine without a script library to leverage. I believe that once I have this working it could be relatively easy to wrap it into the format needed for use in the scripting engine and potentially become part of the core with some additional administration functions around table creation to support the scripts.
When I get the processor and dynamic SQL generator done, I'll post a link to the main page here.
It's a work in progress, but so far I have created a set of functions that will generate a form based on a configuration file that has the following types of inputs:
- a text field
- a radio button with "yes, no, maybe" options
- a radio button with "yes, no" options
- a text field with a linked greater than, less than, equals drop down list
- a drop down list that is populated from a colum of a table
- a drop down list that is populated from a colum of a table with a linked greater than, less than equals drop down list
- a date picker with a linked greater than, less than, or equals, drop down list
So what's left to do is to finish the parser for each of these form pieces (most are done) and then plug that into the dynamic SQL generator. I know I am missing a whole layer for business logic in this but I don't need it yet for the application I'm building. It is a replacement for the the SlothMud III Equipment List that was previously built on core PHP and is linked to on the site. It has a tremendous breadth of features that all boil down to a generating the right query based on a set of checkboxes and a few text fields. It selects the appropriate data without really much further processing and then returns the results.
When I began approaching this problem, I wanted to just make the core scripts look like the rest of the site, but that really was going to leave a lot of functionality on the table, plus when I got into it, I really didn't like what I saw on how it was written (no disrespect to Enea intended).
The current difficulty with integrating this with Post Nuke is that though the 0.8 has a scripting language being built, it seems to be currenlty just an engine without a script library to leverage. I believe that once I have this working it could be relatively easy to wrap it into the format needed for use in the scripting engine and potentially become part of the core with some additional administration functions around table creation to support the scripts.
When I get the processor and dynamic SQL generator done, I'll post a link to the main page here.
Sunday, April 16, 2006
PostNuke Auction Module
I'm going to write in a bit about the work I am currently doing to create a new module for the Slothmud III site that will be used for an equipment list, but first I wanted to brag a little about a module I wrote a couple of years ago based on the PostNuke CMS that is nominally and Ebay-style auction module. It has been up and running for a couple of years now and only has a couple of known bugs, but has several limitations.
Here are some of the features it has:
It needs a lot of features like:
I learned a lot of things from working on the module. The first thing is that the example modules that come with Post Nuke absolutely suck. They aren't documented and have no usable functionality to exemplify any best practices. There are about 30 ways to do anything in PHP/Post Nuke and there really should be some suggestions on what is at least unacceptable, much less is ideal.
The second thing I learned is that there doesn't seem to be much early benefit from doing any of the abstraction that is common in many of the other modules I have seen written in Post Nuke. There are two main types that I saw when I did it, internationalization support and database query abstraction. I think the big problem was that there is not a good MVC architecture example template.
The latest version of Post Nuke I have used (about 0.7.6) has samples that uses the pnRender engine and this seems to have a scripting language in it to create the view layer, but I still think there isn't a good example of a controller (the missing piece that at least I haven't seen).
In any case, when I work on the next module I may take a look at the pnRender system but I doubt I'll go through the effort of using it throughout the entire module since I haven't yet figured out it really is going to be useful.
Here are some of the features it has:
- Integration with PostNuke CMS user tables
- Automatic bid increments while bidder is away
- Requires users to be registered in PostNuke
- Allows user to select the time for auction to end
- Allows a minimum bid to be set
- Built-in support for internationalization
It needs a lot of features like:
- Online Administration
- Auction Search
- Archiving Auctions
- Feedback
- Closing an auction early if there are no bids
- Editing an auciton if there are no bids
I learned a lot of things from working on the module. The first thing is that the example modules that come with Post Nuke absolutely suck. They aren't documented and have no usable functionality to exemplify any best practices. There are about 30 ways to do anything in PHP/Post Nuke and there really should be some suggestions on what is at least unacceptable, much less is ideal.
The second thing I learned is that there doesn't seem to be much early benefit from doing any of the abstraction that is common in many of the other modules I have seen written in Post Nuke. There are two main types that I saw when I did it, internationalization support and database query abstraction. I think the big problem was that there is not a good MVC architecture example template.
The latest version of Post Nuke I have used (about 0.7.6) has samples that uses the pnRender engine and this seems to have a scripting language in it to create the view layer, but I still think there isn't a good example of a controller (the missing piece that at least I haven't seen).
In any case, when I work on the next module I may take a look at the pnRender system but I doubt I'll go through the effort of using it throughout the entire module since I haven't yet figured out it really is going to be useful.
Friday, April 14, 2006
Return of Krom
I must say it is good to have some more Immortals around. I was just glancing at the board at the west gate and noticed a few of the posts on there were from people from long ago. The first couple posts are on average 7 years old from Jake.
Posts included contributions from Ming, Judge and Alana. Ming is gone and likely never to return. Alana said she is gone, but may well come back at some point. Judge is around, but very infrequently. He's done coding, which is a shame, because he was a great contributor.
Judge and I started on a really interesting project to upgrade the live maps to have much more information. He did some good reorganization of the code in the mud and then turned over some stuff to me for the web page, but I haven't had time to get to it and don't have the art to back it up, so it won't happen any time soon (if at all). To go into a little more detail, we had discussed making a graphical interface for immortal information such as areastats and mobstats. This would be tremendously helpful for us as we continually try to balance the areas so that players don't get in a rut of cycling one area at a time over and over.
This was a pretty daunting task to me a couple of years ago, but a lot of technologies have evolved (or at least become more mainstream) in that time. Things like SVG, AJAX and even to some extent PHP could make this quite a bit easier than it was the last time we discussed it. For now, I'm going to try to stay focussed on my current project which is building a better version of the equipment list. I'll post more on the approach I am taking to that in the future.
Posts included contributions from Ming, Judge and Alana. Ming is gone and likely never to return. Alana said she is gone, but may well come back at some point. Judge is around, but very infrequently. He's done coding, which is a shame, because he was a great contributor.
Judge and I started on a really interesting project to upgrade the live maps to have much more information. He did some good reorganization of the code in the mud and then turned over some stuff to me for the web page, but I haven't had time to get to it and don't have the art to back it up, so it won't happen any time soon (if at all). To go into a little more detail, we had discussed making a graphical interface for immortal information such as areastats and mobstats. This would be tremendously helpful for us as we continually try to balance the areas so that players don't get in a rut of cycling one area at a time over and over.
This was a pretty daunting task to me a couple of years ago, but a lot of technologies have evolved (or at least become more mainstream) in that time. Things like SVG, AJAX and even to some extent PHP could make this quite a bit easier than it was the last time we discussed it. For now, I'm going to try to stay focussed on my current project which is building a better version of the equipment list. I'll post more on the approach I am taking to that in the future.
Easter Egg Hunt
I decided to run an Easter Egg Hunt. So I made 100 bunnies, 100 eggs. I put 3 million gold coins into one of the eggs. Ninety-nine of the eggs were pink and blue and the one with the gold in it was blue and white. I then scattered them all over the mud with mscatter and told the players to "go get'em!"
Getting the gold coins into the egg was actually pretty difficult. For some reason you can't put gold into containers, and this is probably to avoid some crash bug.
Mandos found the egg with the coins in it after about 15 minutes.
The post reference on the Sloth Town Crier mentions using the empty found eggs as an entrance fee to a future quest. I'm not 100% certain yet when I'll use the eggs as an entrance fee, but it will likely not be on Easter Sunday.
I thought this was an amusing gossip from a 3x40:
Sickcow gossips-- 'sux man clink .. u sux.. ur quest too hard for me'
I'm not entirely sure he was joking since he struggled with the basic concept of an easter egg hunt.
Getting the gold coins into the egg was actually pretty difficult. For some reason you can't put gold into containers, and this is probably to avoid some crash bug.
Mandos found the egg with the coins in it after about 15 minutes.
The post reference on the Sloth Town Crier mentions using the empty found eggs as an entrance fee to a future quest. I'm not 100% certain yet when I'll use the eggs as an entrance fee, but it will likely not be on Easter Sunday.
I thought this was an amusing gossip from a 3x40:
Sickcow gossips-- 'sux man clink .. u sux.. ur quest too hard for me'
I'm not entirely sure he was joking since he struggled with the basic concept of an easter egg hunt.
Thursday, April 13, 2006
Ramblings
I thought I would start this blog for the heck of it as it relates to my experiences in SlothMUD III.
Here is an update on some interesting information about your Admin:
- Nia is having her first baby in a couple of months.
- Splork probably won't have to have his thumb amputated.
- Kjartan is working an a really interesting electronics project for Burning Man. If he says it is OK, I'll post a link to his blog from here later.
Here is an update on some interesting information about your Admin:
- Nia is having her first baby in a couple of months.
- Splork probably won't have to have his thumb amputated.
- Kjartan is working an a really interesting electronics project for Burning Man. If he says it is OK, I'll post a link to his blog from here later.
Subscribe to:
Posts (Atom)