Just added a small hack to allow some direct linking to markers on the map. The specifics are on the about page.

Also I just was reminded by my very first feedback email that a grid over the map would be a useful feature. It’s not that it’s a total revelation to me (I’ve been asked before). But it’s not an easy thing to add.

The biggest problem isn’t adding the grid (I could just paint it on the map itself). The problem is showing the current relevant grid reference. Trouble is Google don’t seem to think it’s something they should support in their API. So I’ll have to figure out some other solution. I’ll likely come eventually. But I can’t promise it will be soon.

Well. Just wanted to post that the map has been updated with a couple of larger areas uncovered. Mainly I’ve spent some time uncovering the area around – and east of – Al Drifa. But also I’ve done some work on a couple of areas up north in the Galihyalen, Rillu, Sferio and Zaamontel baronies. I’ll likely do some more of that whenever I have the time.

Also I’ve added a couple more zoom levels with this batch of map tiles. So the map now zooms from 2-10 (with 5 being the native resolution of the map screenshots I made in game).

Well. After having worked on the SoG map I finally got around to making it public.

So far the map is basically working although there are a couple of things to do. Some of the things I’m working on are (in no specific order):

• Finish adding all of the towers.
• Add all the location markers I’ve found.
• Add all the Dark side fortresses I’ve found.
• Sync up the Latitude and Longitude with the ones in-game (debug window)
• Improve the map graphics as I improve my in-game one… Or get a better one from other sources

Also I’ve added this WordPress blog software to be the front-page for the site to have a place to post what’s happening on the site.

Anywho… More to come as I improve the map and whatever else I might dream up to improve my experience with playing SoG (and ultimately DnL).

Well. My personal quest for a blogging solution have moved me to the Xoops’ed version of Wordpress.

It seems well equipped with support for all the stuff I really want out of it. AND it’s already integrated with Xoops so I don’t have to (PHP really only something I code in if I have to).

Ah well. Now I can focus on other stuff and ramble about it without feeling bad about not having made a proper blog in my site to do it in

Well. Lately my focus have been on a relativly small online game called A Tale in the Desert. And while I had been playing it I came up with a bunch of ideas for useful tools to have when playing the game.

It started out with making a tool to make mining in the game easier. Keeping track of what ore is in your ore cart either takes paper (I usually don’t have a lot of that at my computer) or a good deal of focus (I can’t really muster that when doing something with this little action) especially when doing alloies. So I set down to make an app that would not only make this easier. But at the same time enable me to do some statistics over the mines I use and what kind of output I was getting.

I quickly desided I wanted to make an app much like the stuff I do at work. I wanted a database to store the data, a persistence layer so I didn’t have to mess with SQL and it all abstracted from my GUI via facades. It was all rather quickly put together with HSQLDB, Hibernate and HibernateSynchornizer for Eclipse and the project was off the ground…

It quickly ground to a halt tho. Mining wasn’t really something I did a lot anyway. Instead I had begun to toy with making food in the game so a new module in the app was started. I wanted to investigate effects of ingredients and store what worked for me… It didn’t last long before I lost interest in that either =). Along the way I also started a resource management module that should make it easy to calculate how much base resources it would take to make more complex stuff… It kinda got off the ground and then died too.

But then I discovered a feature of the game that was either new or I had simply not noticed it before. Basically you can copy the contents of a chest (or other containers) into the clipboard in a format that is pretty easy to parse. Generally a problem with the game is figureing out where you have your stuff and how much you have of it distributed thourgout the gameworld. So a new project started: The Inventory Manager.

Getting it together was pretty quick. Most of the application was already in place. And it only required a little work to get the database worked out to store it in. And behold the first module of my app was functional and packed for deplyment on Mac OS X (and a little later on Windows too). So here is my first Code Divsion branded app in a long time: The ATitD Manager

Mac version:
http://www.codedivision.com/uploads/s … /ATitDManager-osx-a1.sitx

Windows version:
http://www.codedivision.com/uploads/s … e/ATitDManager-win-a1.zip

Wow! A new year and I noticed it’s been almost 5 and a half months since I posted here… Oh well. Not much to report anyway. I did a lot of back and forth coding on this project and ended up getting too annoyed with it all.

Basically the problem is that Xoops and bBlog both wants to control Smarty. And I have to do a lot of coding around that if it’s ever going to work very well.

I still have my progress in Subversion tho. And I just noticed a new version of bBlog has been released for me to toy with so I might try that.

That being said I think it might be more productive to take a working Xoops blog module (like the now – seemingly dead – WebLog module) and then just add some of the missing functionality to it (like remote APIs). All in all it seems like less work.

Also there is a new blog module in development on dev.xoops.org that might be getting under way. So perhaps I should just get into that instead…

Well. It was all going too well. I had bBlog integrated into the Xoops templating system without changing too much of bBlog. And it was all dandy. But then disaster hit! It seems Xoops like to compile any defined templates of a module when it’s installed or updated. AND it don’t offer any hooks to do any initializing. Result: Xoops pukes on all of the plugin usage in bBlog since it can’t find any of them *sigh*.

Ah well. It’s how life is. I’m trying to do some inline php in the templates to set it up. But I can’t figure out if there is access to the current Smarty object from inside a smarty template page so I hack around it for now. In the future of Xoops they have promised this precompile will go away. Making life much easier for me… Although it would have been nice if a plugin could acturlly define it’s smarty plugin locations. But then Xoops use Smarty but isn’t too Smarty centric (some people in the Xoops dev forum, on Sourceforge, are even suggesting going back to raw php in Xoops 3 for some reason).

Anyway. Apart from that I’ve started considering if I should do another OO patch for bBlog. I’d like to split the user info into a class of it’s own. Currently that kind of info is retrieved by joins in SQL. And it’s making it a bit hard to use Xoops user info instead (it’s doable but messy). Shouldn’t take too long either since bBlog don’t expect a consistent source of user date. So it’s not used in a lot of places.

Well. I think I got it in only 2 goes! I’m proud of myself =). The initial patch for bBlog to untangle the bBlog code from Smarty has gone into CVS. And I just posted a patch for the patch to fix some mistakes I made along the way.

Even with Zend Studio PHP development isn’t my favorite past-time activity. The language is so weakly typed it’s impossible to know if you messed up stuff unless you actually go through the entire site and try out everything. And when you are used to re-factoring Java code with tools like Eclipse. Doing it with search and replace just isn’t too much fun.

Ah well. But now I got it done I can get back to improve my Xoops integration. Most stuff should be doable in a subclass of the bBlog one now. So I just have to change the line in init.php where an instance of the bBlog class is initialized. And replace it with my own.

Well. Today I decided to simply do a patch of bBlog that will seperate the main bBlog class from the Smarty one. Simply put it’s horrible OO code. But Eaden McKee – the original author of bBlog – by his own account didn’t quite understand OO when he initially wrote the script. So here we go. Let’s see if we can improve it just a bit.

The nice thing is it don’t really take that long and that I’m pretty much done with it… I think. I still need to do some more testing before I submit the patch tho. Another nice thing is I got a reason to try out the ‘official’ PHP IDE: Zend Studio. Obviously it’s MUCH better than any of the Eclipse plugins I’ve been using so far. With it’s integrated full debug environment that works as well as any you would find in, say, a C or Java IDE. And the code completion is very good considering we are working with a very weakly typed language. For hobby use I’m not sure I’ll sink money into a PHP IDE tho. It’s not like I enjoy PHP enough to do more of it than I do now

On a side note I also tried to make some xmlrpc clients to work with my bBlog module. And so far I have only had w.Blogger working. All Palm based ones I have tried have barfed (and more common than not proceeded to require a reset of the device). Also the Mac OS X ones I tried didn’t work. So it seems I may have to look into what’s going on with the xmlrpc code at some point too. Unless it’s just my mods that has screwed it all up.

Well. Here it is. My first post in my first functional version of bBlog (www.bblog.com) inside of Xoops.

The current bBlog version is .7.3 and that’s what I’m using. It isn’t very integration friendly. But making it work in Xoops wasn’t too hard either. Only trouble is if I’m going to have to make it work with Xoops users instead of it’s own ‘authors’ table since it does a bit of hardcoded sql with table joining to get information for building pages.

So that’s why I’m not going to release the module just yet. It’s too dirty. The admin interface hasn’t been wrapped in the Xoops admin interface. Permissions on bBlogs own smarty cache has to be manually fixed after install (gotta get it to use the one Xoops has – should be trivial but it’s not gonna be tonight). And finally there is the whole users thing I mentioned.

I’m also trying to wrap some of the bBlog plugin/blocks into some Xoops blocks. But it’s a bit tricky since bBlog expects it’s own Smarty object and the code don’t work well with how Xoops integrates Smarty… But I’ll get that ironed out eventually