Just a quick post for the moment,

I’ve been steadily working on CELT and DeepEnd but I recently found a few days where I wasn’t sure how to proceed on them, and needed a break from them in general, and so I resurrected an on idea, for an experimental clock.

The backing idea came about when I thought about how I visualize my day, I had soon ascertained that I visualize it on a 24 hour clock with 12am (midnight) at the bottom and 12pm (midday) at the top. But then a most unusual realization hit me, I wasn’t spacing the hours evenly when I thought about them, and I even expanded the current hour on the clock. After much meditating on the workings of the clock I eventually decided it would be possible to program such a clock into reality.

And so over a three or four day period I began writing the clock in my favorite language, haXe. Of course I was targeting flash9 to ease writing of the actual display code, witch makes up a large portion of the code. Having the ability to map the hours to different places on the clock was easier enough to code, having thought it through and decided that I was probable that different people visualize the hours in different places, but the expanding/magnifying took several hours to understand fully and implement correctly.

I plan to post ^Clock as a new project on my project page in the next day or so, but please bear in mind that it is an experiment and lacks features like saving the clocks configuration, different types of transitions between hours and the ability for the user to change the colour scheme.

If you do view it (when I put it up), then you will probably want to know how to use it, well, if you move your mouse to the marks that indicate the hours two yellow circles should appear, holding SHIFT and clicking will add a new handle to that time, releasing SHIFT and, dragging the handle will remap that time to the new place on the clock and all marks will move to accommodate the change. If you drag a handle and YOUR CURSER moves outside of the yellow lines THE HANDLE WILL BE DELETED.

Lastly this post in not as short as I thought it would be and I’M A PROGRAMMER NOT AN ARTIST so don’t expect some fancy clock, it works and that is that, ANY SUGGESTIONS for new clock features will be gladly appreciated.

Project: ^Clock

Clock: Flash9 Clock

Tagged as: Beta, experiment, Flash 9, haXe, time, ^Clock
Filed under: Beta, Programming, Ramblings, haXe by Othrayte
No Comments »

Last Friday (20/2) saw the public release of my long term project Fire Report, albeit in its 3rd incarnation. The first two succeeded in opposite directions before ultimately failing, this time both direction were brought together to create a working solution. OK so now you probably want to know one of two things, either:

• Where can I find this?, or
• What is this?

Both of these questions can be answered by a visit to the Google

Last Friday (20/2) saw the public release of my long term project Fire Report, albeit in its 3rd incarnation. The first two succeeded in opposite directions before ultimately failing, this time both direction were brought together to create a working solution. OK so now you probably want to know one of two things, either:

• Where can I find this?, or
• What is this?

Both of these questions can be answered by a visit to the Google Map Fire Report Direct Link.

What you will see will look like this:

Screenshot: Mapplet client (BETA) just before submision to Google.

As I believe in free and open source software (FOSS), and the rights for anyone in the community to use such a solution, this project in its entirety are licensed under the GPLv3 unless otherwise specified; like in the case of borrowed code. Of course as with the nature of the solutions client side Mapplet that code is already available by searching for it on Google Maps Directory under “Fire Report” and clicking “View Source”. The server side code (PHP) will be avaliable soon; I just need to clean it up a bit.

If you have looked at the Mapplet, read through “help” and “about”, and still don’t understand what this project is then here it is in a nutshell:

The Fire Report (VIC/AUS) is a software project hosted on sourceforge.net with the purpose of viewing the CFA incidents from the CFAs website on a map of Victoria, and future versions will include features above and beyond that that the CFA provide.

This BETA version has all the features of the CFAs incidents summary displayed on the map, all feed through an auto updating solution that can be paused/resumed and that caches everything except the hit counter. All caching is provided first by the server here and secondly by Googles servers before it reaches the masses. If your curies about the hit counter the stats can e viewed on my newly created statistics page; be forewarned this is a pretty basic page.

If you find any spelling mistakes, hey I’m a programmer not a ‘person that writes stuff’, anywhere throughout the project I will gladly correct them, just send me a message, either through email, the sourceforge.net project or a comment here.

And now for some of the technical background, some of which I haven’t spoken about anywhere else. If you either get bored or confused by this kind of thing you are very welcome to got back up to the direct link to the Mapplet and play around with it instead.

The first thing you need to understand is where is all of this data coming from, its one thing to have a map but an entirely separate thing to have something to put on it. Well first of all the CFA create the information, direct from their Incident Management System (IMS) then they put it into an RSS feed which this website collects. At this point the CFA has finished their part of the process and no more load is put on them.

Secondly my website receives the RSS information and makes use of MagpieRSS to parse (decipher) what the information is. This information is broken down and the relevant bits used to geocode (get the longitude and latitude for) the incident. Once this is done the system stores all of this information in a mySql database, all incidents older that 24 hours old are removed and thus a whole days incidents are always kept. Everything in this paragraph is performed by the file GET.php.

To ensure that the mySql database is kept updated a CRON (automated scheduler) job runs the GET.php script 42mins passed each hour, unless the script was run in the last 90 seconds and I’ll get to that in a moment.

Next we make the long leap to the client side. You the end-user enable the Mapplet at google maps, the Mapplet code itself is cached by Google. The Mapplet begins to set things like the menu up and then makes a request (cached by Google) to a file on this website called list.php, this file first checks to see that GET.php has been run in the last 90seconds, if it hasn’t it runs it, and collects the last 500 incidents (usually all of the ones from the last 24 hours) from the mySql database, puts them into a text file in a special format where each incident is on a new line and each piece of information about that incident is separated by a pipe, “|”, symbol, this text fille is returned to the Mapplet. But the websites job hasn’t finished yet, as you will find out later.

Once the Mapplet in your browser receives this data it quickly puts it into an array of incidents, indexed by the incidents id, specified by the CFA in the RSS feed. Then it needs to create that list that will appear on the left hand side under the buttons and status, to reduce load on your browser the details that appear when you click “details” and created on demand only. Now comes the really useful part the Mapplet uses the information now stored in its array to place markers on the map, some people may have to be patient depending on their computer, but this is a one off occurrence that only happens when you enable the Mapplet after that it only has to update the markers.

But instead of the boring old nondescript marker provided by default by Google the Mapplet uses this website to create new descriptive ones. These markers show type, size, age, status, and number of ‘appliances’ in attendance. The Mapplet tells the website what it wants and the website sends it back, cached of course by Google. The markers fade out the older they get, so the Mapplet simply asks for each marker to be redrawn each time the transparency needs to be increased. There are currently eight levels of transparency. Incidents up to one hour old are opaque, and for each half hour older gain another 10% transparency until they are 70% transparent. I am planning of adding a feature to change the time it takes the markers to fade out, your input on this is welcome.

The Mapplet also auto-updated its incident list, the status will flash yellow then fade back when an auto-update occurs. If a new incident arrives it will flash red then fade over a longer period back. In the case that you will be away from the map for more than about 3mins you can pause the auto-updater and it will run again when you resume it. The auto updater runs every 90 seconds.

Clicking on an incident name in the list will take you to it on the map. The details displayed when you click on a marker are also created on demand and include a copy of the icon to help you either find it on the map or find it amongst others.

And now a quick analysis of who gets the load. The Mapplet is cached by Google so anytime someone enables the Mapplet Google takes the load. Therefore this website takes one hit for that about every few hours. Next the Mapplet get the first load of data also cached by Google, refreshed every 90 seconds, list.php takes the call and runs GET.php which only runs if it hasn’t run in the last 90 seconds, if it runs it gets the RSS feed from the CFA, the  if the isn’t anything new then the whole RSS feed won’t be requested, the genius here is that if one person is using the Mapplet then the website here and at the CFA take load equivalent to one user, if two people use it the server here takes a little more load but the CFA receive no more, and after that the load does not increase for the CFA, the only increase in the load here is the hit counter that isn’t cached by Google but that only has a minimalist impact on this website, the rest goes to Google. So if the CFA website is under heavy load you can be assured that the Mapplet wont be, and using the Mapplet can in an indirect way help the CFA to reduce load.

I would have added some more images but there really isn’t any point, you can just go and use it and see for yourself.

Tagged as: Beta, CFA, Fire Report, FireReport VIC/AUS, Google, GPLv3, Javascript, Mapplet, MySql, Open Source, PHP, Public Release, Released
Filed under: Australia, Beta, Javascript, My Projects, PHP, Programming, Release, Victoria by Othrayte
No Comments »

The first thing I should say is that the title is very much a working one, it will be changed. Firstly it’s wrong, the ‘program’ is actually a library for displaying thing in flash, past what flash itself can do. Though its mainly aimed at displaying math functions it could in theory be used to display anything that is based on symbles that has some form of simple regularity to it, any thing from a text document to a webpage to a flow chart. But back to why the name will change, I like the compendious bit but I will drop the ‘equation editor’ bit untill it can actually edit equations. Compendious comes from a correct translation of the title of the first book on Algabra, also where algabra got its name, Kitāb al-muḫtaṣar fī ḥisāb al-ğabr wa-l-muqābala, which translates to ‘The Compendious Book on Calculation by Completion and Balancing’.

The next important thing to say is that, unless you like looking at basic green boarders squares, there isn’t much to actually see yet. But I will be creating a porject on my project page and on sourceforge. I decided that versioning should start when there is actually some visible output, thus the green squares make this version 0.1.0, being major 0, minor 1, build 0; the initial build. Version 0.2.x will be when symbols can be seen, 0.3.x will be when the symbols are arranged and the ‘containers’ and ’spaces’ work correctly, this is the PLANNED milestones. The most major steps will be 0.4.x overall and 1.0.x-rc1 of the display library this will be the ability to import and display BASIC math functions and the first semi-stable release candidate for the diplay library. Beyond this I have no clue. And there is no timeline other than I hope to reach 0.2.x within the week.

The library takes a dynamic aproch to display, the ‘containers’ that things reside in are defined mainly at runtime from an xml file, and thus change xml file and change display type, although I haven’t yet written any of the interaction functions or control structures, that can wait untill it can display more than just green boreder squares.

This project is/will be released under the GPLv3 and is written entirely in haXe (targeting flash9). More to come.

Tagged as: CEEP, Compendious, display, Editor, Equation, GPL, haXe, library, math, Program, Working Title, WT-CEEP
Filed under: Programming, haXe by Othrayte
No Comments »

I have now added openID support and reCAPTCHA verification to the site,

You can post comments simply by entering you openID where it says “Website”, soon to say Website/openID, typing in your comment and completeing the reCAPTCHA image verification, I will still need to moderate the comment though.

Enjoy the freedom and ease.

Tagged as: comments, openID, reCAPTCHA, support
Filed under: Site Admin by admin
No Comments »

Anyone who Google searched for ‘Othrayte’ may have come across my old SourceForge.net project at http://sourceforge.net/projects/firereportvicau/ unfortunatly the original version was written in a language that wasn’t designed to easily facilitate this style of program. So I have now picked up the pace of development, to the point that a alpha level interface is up and working, I will soon have a link to this working version but for the moment there are unresolved copyright issues.

If you haven’t read what is listed on the SourceForge.net page about the project then your probably wondering what I’m talking about. As I concisely put it on the SourceForge.net page:

“The program expands on the data the CFA provides on their incident summary RSS feed and web page by providing a visual representation of each incident the CFA attended over the past five hours; plotted on a map of Victoria, Australia.”

CFA is the Country Fire Authority, the volunteer based fire fighters in my area. The RSS feed mentioned is here http://www.cfa.vic.gov.au/incidents/incident_summary_rss.xml, it provides basic details about all the incidents attended by the CFA and the DSE (Department for Sustainability and the Environment) over the past 5 hours.

This mightn’t seem like the most complicated program to write, but when I first decided to write it I also decided that I wanted to write as much of it as I could by myself; but I not only over estimated my own ability but also that of the languages I was using. I speak of Mono and GTK#; chosen for their cross platform abilities and the fact I had written some C# code before. The problem encountered was that GTK# didn’t provide quite the interface options I wanted and was relatively unused at the time both of these things lead to the program looking nice but really not doing much:

Screen shot of old FireReport program

The screen shot above was taken of the client side of the program when it could display a list of incidents and expand to show extra info, but due to my limitations on GTK# I was unable to get the vital markers on the map, the map however was dragable if a bit buggy. By the time this screen shot was taken the server-side of the program was capable of correctly parsing the rss feed for CFA incidents, thanks to MagpieRSS, but the parsing of the DSE incidents wasn’t implemented, that was/has been a late added feature. The server-side was/is written in PHP.

Thats enough said about that version but not many people know that it wasn’t the first, the first was a pure flash 8 movie that progressed from being capable of plotting location of a Melbourne town the user entered to being capable of getting data and plotting the incidents with little flashing red dots on a rather inaccurate map of the state. This inaccurate map combined with my new love of everything cross platform and Linux was the reason it was abandoned. Ironically the new version will be targeted at flash 9, with an intermediate step as a Google Mapplet, so that I can learn the maps API. But the flash 9 source code will be pure haXe, a cross platform open language currently with 4 targets including flash 9. More on that later.

The one main piece of the program that has remained relatively unchanged since the beginning is the server-side code, unfortunately not what people see. It is based on PHP with a MySql database. It has evolved thought the last two or three programs into a solid base from which a program can be easily built. It takes input in the form of the RSS feed, and hands it to MagpieRSS to convert it into usable illiteratable, in PHP, data. That data is then feed in to the parser incident by incident and parsed for the incidents indetification number; which is at the moment around 1995000000. This id is then used to check if another instance of that incident already exists in the MySql database. If there is a incident already with that id then the last updated DateTime stamp is parsed and used to see if a newer version already exists in the database. If one does then it skips to the next incident, else the rest of the values are parsed like status, type and size. Lastly the information for town and street are used to geocode the position of the incident via Googles geocoding service. Once completed the database is updated to reflect the current data. And this happens every two minutes, Which I figure produces low load on the CFA website in comparison to many of people possibly using my program and highly up to date data. The server also provides a text based file with all the information included from the database when the client-side of the program requests it.

FireReport Google Mapplet Pre-Alpha

The haXe based flash 9 targeted client program is still in the planning stages but the Google Mapplet client interface in well underway. I have a better fire marker icon in mind but haven’t yet got permission to use it; if you have any sugesttion feel free to email the website you-...@othrayte.profusehost.net . I am also planing different icon for different types ans statuses of incident, anyone willing to make them can just post a comment below. Hopefully future versions of the program will include not only CFA/DSE data but also MFB (Metropolitan Fire Brigade) data; I’m currently pushing the MFB for this but I don’t know how far I will get. Other features I would like to add down the track include:

• Distance to know point (ie your house) based warning of major/minor incidents
• Daily personalized report for your area(s) based on what you ask for
• Extra data from the CFA website like a direct link to the extra information they supply for major incidents.
• convert server-side PHP code to haXe code targeted at PHP

All in all its going well.

Tagged as: C#, CFA, DSE, Fire, FireReport VIC/AUS, FLash, flash 8, Flash 9, GTK#, haXe, MFB, Mono, MySql, PHP, SourceForge.net
Filed under: Programming, Ramblings by Othrayte
No Comments »

A couple of weeks ago a friend proposed a new kind of guessing game, where the number your trying to guess is allowed to change by as much as your guess was off by. And in the style of the guessing game all you were told was if the number was higher or lower than your guess. And on top of this the number was allowed to become, but not start off, smaller than 0 and bigger than 100.

So in effect what you were actually told was whether the number was higher or lower when you made your guess, but between then and your guess I will have moved, thus you have to guess where it is going to be based on which direction it was in last time.

I took this idea further and allowed the game to randomly choose whether to tell the player which direction the number was in, higher or lower, or to tell them how far away they were but not in which direction. With this change, a large modification to the places the number can move to, now based on where it has been and where you guessed but preventing it from going where you have already guessed, and some stats at the end showing you how many guesses you made, your average distance from the number and a graph showing where you went and where the number went the game TrapMan was born.

Screen shot of TrapMan 1 title screen

Version 1 of TrapMan like its predecessor was written on and for the TI83-84 calculator in TI-Basic, which is just what we had on hand at the time. This version of TrapMan required the player to remember where they had already guessed, tricky I like I did for testing you play multiple times in a row, and required some skill at preempting the next number but all of my friends who played it where able to get the number withing 25 guesses.

TrapMan 1 - Game play screen shot

Unfortunately due to the way I had written the extra features that weren’t in the predecessor, like the number not moving where the player had already guessed, made the game heavy on memory, that feature alone used a list 999 numbers long, and meant the number was now not allowed to go below -499 or above 499; the game would just die if you tried to guess there or the number tried to move there, luckily the games never really got outside the range of -150 to 150 so it was a reasonably safe bug.

TrapMan 2D - "Yet More Guessing"

Apart from that the success of TrapMan - “The guessing game fights back” lead me to think of improvements. The first major improvement I came up with was moving the concept from 1D, in a line, to 2D, and thus it got named TrapMan 2D - “Yet More Guessing”. The screen of the calculator came in handy for this as I could add guesses to the screen as dots and check if the number (now a set of two numbers X and Y) had already been guessed by checking for a dot at the point o the screen.

After relearning how to split the calculator screen in half so that the graph was displayed on the top half and the IO text for guessing on the bottom half, I had the job of translating all of the code to 2D.

That didn’t prove to difficult and soon I had the main engine part of the game working, next came the text interface, complicated by the fact I only had 4 lines of space to work in. I eventually gave up the first to for the most part of the game to show the last 5 guesses the player had made, both X and Y values, and used the last two for the clue that the game gave, X too small, Y too big, missed by 120.45 etc, and the last line for the input of the new guesses X and Y values.

After I had finished about 3/4 of the code I decided that to do justice to that came I would have to write a new version in flash (using haXe), where I could use colour, a faster processor and replace the guesses with their visual equivalents. The project is now listed as TrapMan 2 - Flash Game on the projects section of this web site.

Copies of TrapMan 1, TrapMan 2 - TI-Basic and the other program Num2Str required for them work are availiable at my file host.

Num2Str is a program designed to convert a number to a string, the number is taken from variable ‘a’ and the string is output in ’str3′, the list ‘XN2S’ is used to make the program variable safe. Feel free to use it or make it better, but I would like to know.

Tagged as: FLash, Game, Guessing, haXe, History, TI-Basic, TI83, TI84, TrapMan, TrapMan 1, TrapMan 2
Filed under: Games, Programming by Othrayte
No Comments »

I didn’t make this but with the way Windows is traveling it seemed suitable to revive what looks like an old campaign against Microsoft and in particular IE, for the number of people who don’t like Windows and/or IE  I’m surprised that there aren’t more.

Microsoft Because You Have No Choice

Its quite accurate, I only use windows when I want to play proprietary games, otherwise I stick to Linux.

The Image above links to the Anti-IE page it came from.

Tagged as: IE, Microsoft, Microsoft Because You Have No Choice, Windows
Filed under: IE, Ramblings, Windows by Othrayte
No Comments »