There’s a number of improvements in 2.8.4′s development branch already over 2.8.3:

• Local sign-in and events management system.
• Port forwarding system.
• Migrating several systems over so they work with Django 1.2, and removing some older legacy code.
• All the local authentication hacks have been eliminated.
• Fixed XSS issue in captive landing page.

The code is released under the GNU Affero General Public License v3, and is available from my GitHub repository.

At some point in the future this’ll be pulled into a 2.8.4 release, after some further janitorial work is done. It’s been sitting around for a little while, may as well get it out there now. Eventually this will be migrated to become a part of the LanConnect project, with optional integration with it’s databases.

I’ve written a QR Encoder patch for Quartz Composer based on libqrencode. You give it a string, and then it’ll encode it into an image.

There’s another patch in my github which provides a client to GPSdX. It’s a bit buggy still, and only works with GPSd running on localhost with the older encoding method. Unfortunately libgps is ridiculously annoying to work with, so I took the easy (incompatible) way out.

I’ve also patches for Openbravo POS. They make the “customer” price for an item be the buy price, allowing you to implement a simple discount for registered customers that isn’t based on a percentage. It also includes Australian currency images and some minor UI modification to waste less screen space.

I’m currently working on cleaning portal2 up for release. Which is fun. Most of the legacy authentication hooks have been removed, and it’s getting closer to running standalone in a nice way. As part of this I’m getting rid of lots of ugly and legacy code that was for Django 0.96.

UserProfile objects (returned by whoami and whois_ip) now also include the user’s forum numeric user ID. This means that your application can track when a user has changed their username.

Additionally, there’s now a new “python” output method for the HTTP GET API which gives the output of repr() on the result object. It’s not recommended that you use this with Python (instead use XMLRPC), but there may be instances where you find this useful.

This will allow in-browser applications to determine the identity of who you are logged in as before attempting to fall back to who owns the computer.

In other news, portal2 v2.8.3 now has a couple of other changes to it, such as support for clustering and a new graph on the usage page which is generated client side (and much faster than the server-side graph).

Unfortunately, there’s no online “simulator” available, but that should be trivial for someone to write if they’re testing their program.

I’ve changed the way label elements are positioned now, and they all use the `hanging` `dominant-baseline`. Unfortunately Opera 9.5 doesn’t support `dominant-baseline` [just yet][operasvg], so all the UI elements will look messed up there. It works fine in Firefox 2 and Firefox 3 though, and I’ve heard it also works in Safari on OSX fine too. Unfortunately because Internet Explorer doesn’t have inbuilt SVG support (and [Adobe's SVG viewer is discontinued][adobesvgeol]), so you may have to wait for Internet Explorer 8 and hope they add support for SVG and the SVG DOM.

[Clicking Bricks][cbsvg] has been updated to use the new version of the library… no new functionality in it. There’s an [SVG part (click this to run)][cbsvg], and the [source script file][cbjs].

There’s also a little [focus model test][fsvg] that has an input box and a menu that doesn’t do very much. There’s an [SVG part (click this to run)][fsvg], and the [source script file][fjs].

And there’s [SVGForm's source itself][svgform] if you have a thing for reading source code. It’s now getting quite big, at about 30kB!

Again, it’s still licensed under the [GNU General Public License v2][gpl2], or at your option, any later version published by the Free Software Foundation (this includes GPL3). Once this starts coming along a bit more, I’ll probably change the license to something more appropriate for web application development – as presently you would have to license the JavaScript/ECMAScript and SVG portions of your site also under the GPL as they link to it. As it’s still alpha and incomplete, this shouldn’t be much of an issue for now.

[cbsvg]: /static/projects/svgform/tests/alpha3/clickingbricks.svg
[cbjs]: /static/projects/svgform/tests/alpha3/clickingbricks.js
[svgform]: /static/projects/svgform/tests/alpha3/svgform.js
[fsvg]: /static/projects/svgform/tests/alpha3/focus.svg
[fjs]: /static/projects/svgform/tests/alpha3/focus.js
[operasvg]: http://www.opera.com/docs/specs/svg/
[adobesvgeol]: http://www.adobe.com/svg/eol.html
[gpl2]: http://www.gnu.org/licenses/gpl-2.0.html

As a test so far, I’m upto alpha2 of my UI toolkit. It’s totally unfinished right now, and includes a button and label control, as well as some styling support for them. This allows very simple applications to be created. I haven’t got a focus model done just yet, so text input can’t be done just yet.

Note: Currently, this will not work in Internet Explorer 6 (it does not have SVG support as standard), and other versions of Internet Explorer don’t support parts of the SVG DOM needed to run this library. It does, however, work in Mozilla Firefox 2 and 3, Opera 9.2 and later.

For the first application, I’ve ported a game I developed a very long time ago (2001, if my memory is correct) in Pascal (on DOS) and VB4 (on Windows) to my SVGForm toolkit, called [Clicking Bricks][cba2]. Each of the bricks when pressed toggles one or many other bricks, and the object of the game is to make all the bricks disappear. In the default pattern included, #16545445 (aka “pattern 003″), it takes a minimum of three moves to solve the puzzle. If you want the solution, take a peek in the source file (clickingbricks.js). Unfortunately, I have probably lost the original patterns I made (000-002), so 003 is a new pattern.

In the application there are three files, a small [UI wrapper (SVG)][cba2], the [game logic (JS)][cba2js] and the [SVGForm library (JS)][svgform].

The UI wrapper contains minimal code; references to the game logic and SVGForm library, and some text that is displayed for browsers (or image editors) not capable of running ECMAScript.

The game logic JS is fairly simple too, it creates the game UI, styles it, and contains the game’s logic.

The SVGForm library is heavier, it contains implementations of the SVGButton and SVGLabel classes.

It’s currently all licensed under the [GNU General Public License v2][gpl2], or at your option, any later version published by the Free Software Foundation (this includes GPL3).

To create new patterns, change the query string (the bit of the URL after the question mark) to another number. Each brick has 5 bits (maximum number of 31) representing each of the bricks to be toggled, where bit 1 (1) is brick 1, and bit 5 (16) is brick 5. The various bits are then packed so the most significant bit is brick 1, and the least significant bit is brick 5.

So, for the game #16545445 (the default pattern, 003), the binary code is: 01111 11000 11101 10101 00101, which means:

* Brick 1′s value is 01111, so all but brick 5 is toggled
* Brick 2′s value is 11000, so bricks 4 and 5 are toggled
* Brick 3′s value is 11101, so all but brick 2 is toggled
* Brick 4′s value is 10101, so bricks 1, 3 and 5 are toggled
* Brick 5′s value is 00101, so bricks 1 and 3 are toggled

[cba2]: /static/projects/svgform/tests/clickingbricks/clickingbricks.svg?16545445
[cba2js]: /static/projects/svgform/tests/clickingbricks/clickingbricks.js
[svgform]: /static/projects/svgform/tests/clickingbricks/svgform.js
[gpl2]: http://www.gnu.org/licenses/gpl-2.0.html

Seeing as the algorithm has been now changed, I thought I’d document how the old password algorithm worked.

1. The first three bytes are 31, 180, 229. (`1F B4 E5`)
2. The 5 bytes of the password are XOR’d with 94, 36, 240, 15, 90. (`5E 24 F0 0F 5A`)
3. Go back to step 2 until the end of the password string.

As an example, say my password is “passwd”. That means the encrypted form of my password is `1F B4 E5 2E 45 83 7C 2D 3A`.

XOR for password obfuscation is trivial to decode. If you know the original text and the encoded text, you can determine the cipher text. (Original XOR Encoded = Cipher) Once you know the ciper text, you can then encode or decode text freely. (Original XOR Cipher = Encoded; Encoded XOR Cipher = Original)

The size of the password stored the old way is variable, so a long password will take more bytes to store than a short one.

There’s more about the [XOR cipher on Wikipedia][xor].

So far, looking at the Trackmania Forever stuff, I’ve noticed:

* The thumbnail introduced in Trackmania United changes on each save, due to the lighting and clouds changing in that frame. As a result, the file size will change slightly because of the nature of JPEG.
* The same password on two identical tracks (same UID and name) means the data block is the same. So the password encoding doesn’t have a random element to it.
* The password for the same track is stored in a way that the size is constant. At the moment, I’m thinking there is a hash of the password being stored, meaning the password storage algorithm may be very difficult to break, apart from dictionary attacks (computationally expensive to do).
* I think that the password is stored near the end of the data block, after all the other data.

[tmdisasm]: /tmn/disasm/
[xor]: http://en.wikipedia.org/wiki/XOR_cipher

It also features an improved share scanning module that is multithreaded. This drastically reduces scan time on large networks. It now takes about 30 seconds to scan a network that would have previously taken 5 minutes or more.

There’s no updates to DDRHelper at this time.

igaeditor development is on hiatus until I can find out more about the recent changes to the BF2142 ad cache files (nobody has been nice enough to send me a copy of the new cache file), or the advertising in Counterstrike 1.6 that was recently added. Mainly because I haven’t actually gotten any bug reports and some trolls at Total BF2142 Forums nicely got my research forum thread shut. Because they can’t keep their traps shut and must insist on complaining about any piece of software that they don’t want to use. Then again, I think they’re really corporate shills working for EA or IGA trying to cause trouble. As a result I’ll be operating the project a little differently until I can find another forum that will happily host the thread and keep it spam free.

What’s new in 0.1.5:

- New abstracted database connection system, “IGADatabaseConnector”. This is a part of the “IGA Common” module. This allows you to write non-WinForms interfaces using the same engine. At the moment there is a GTK# version in some development available from the igaeditor SVN repository.
- The AdPackSupport libraries are now no longer used. The AdPackImportForm and AdPackExportForm are now a part of the main module again, and the AdPack and AdPackEntry classes are now a part of IGACommon. As a result, IGACommon.dll now depends on SharpZipLib.
- Localisable stubs added.
- The “vaccum/shrink database” menu item is now no longer disabled if an unsupported appId is found.
- Mono.Data.SqliteClient is used in favour of System.Data.SQLite, so to allow for cross-platform support.
- DDSReader has undergone a major overhaul, with native .NET DDS reading. As a result, DDSReader no longer depends on DevIL or DevIL.NET. This means that the program, uncompressed, is about 1MB smaller. At the moment, the library only supports DXT1 and DXT3 compression modes. Other decompressors are to be added in future versions. Think of it as a test of “will my image work in the game”… the game doesn’t support the uncompressed images.
- IGACommon and DDSReader now build under Mono without issues.
- DDSReader is now licensed under the LGPL (it was previously licensed under a BSD license). This is due to the code ported to C# from DevIL.

All of this can be gotten from the igaeditor website…