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…

* I’ve released DDRHelper 0.9.2. This includes automatic service class generation, which allows you to define new service types with no coding required, as well as Windows 2000 support. You can grab that from the [ddrhelper][] page. I must admit this has been ready for a while, I just needed to do some more testing, and bother to release it…
* ddrgen needs to have some final cleanups done before it’s ready for the next release. The major change is that it includes threaded scanning support, greatly reducing scan times.
* igaeditor (aka: Battlefield 2142 Ad Cache Editor) v0.1.5 is nearing completion for the Windows version. I want to run some more tests on it, and possibly implement a DXT-5 decompressor before releasing it. At the moment, it only has DXT-1 and DXT-3 DDS file support, whereas the older versions supported many more (because it was using an external decompressor). I’ve fixed the major issue of broken file import that was stopping me from releasing it earlier – there was a bug in the old version of the Mono SQLite ADO.NET provider I was using. After updating it to v1.2.1 it works nicely. There’s a really bare GTK#/Linux version at the moment, however I think I will put that on hold. The impatient may wish to [check out the source in SVN][igasvn].

[igasvn]: http://sourceforge.net/svn/?group_id=181663
[ddrhelper]: /projects/ddrgen/ddrhelper/

* An all new configuration file system
* Automatic network detection on Linux
* DNS record generation is now optional
* ddrgen fixes permissions on zone and stats files automatically.
* Fixed BIND record generation
* Improved detection of Ubuntu Linux (includes many pre-release Samba versions)
* Updated generic Samba detection for versions 3.0.0 to 3.0.23
* A new XSL stylesheet for the XML stats
* Fixed a bug that caused XML parse errors while the page was updating
* Temporary files are now handled dynamically by ddrgen (and ddrgen.tmp isn’t used anymore)

The configuration file stuff is the biggest change, and the README file explains the changes.

So go and [yoink the latest version][dl113] of [ddrgen][].

[dl113]: /static/projects/ddrgen/ddrgen-1.1.3.tar.bz2
[ddrgen]: /projects/ddrgen/

This project would work in a similar way to DDRHelper: games use dynamically compiled plugins. A thin “layer” seperates the plugin from the actual win32api calls, to try and limit potential damage, and make it so the only thing that the plugin should care about is trying to locate where the game is installed to.

Presently, x86\_64 detection of Windows XP is done by the build number only – Windows XP x86\_64 reports as having the same build number as a Windows 2003 SP1 system (3790). Windows XP x86 doesn’t report a build number at all. I haven’t downloaded the x86_64 build of Windows Vista yet, but due to it’s size it’s unlikely I will soon.

I intend to do some further work on it, where I will include the build number to beta version translation. This will also be included for any further betas or release candidates I gain access to, and get around to examining.

Do you have access to Vista or Longhorn betas? Mind doing me a favour?

I’m looking for more information about what all the Vista and Longhorn betas are numbered. I’d love to be able to detect them all. I don’t want you to send me copies of Vista or Longhorn. All you need to do is send me an email with:

• The output of smbclient -gNL [ip address] from a computer with Samba installed, where the IP address is that of the Vista/Longhorn box. For example: smbclient -gNL 192.168.1.5. Make sure there is at least one folder shared from the Vista/Longhorn system.
• The build number, version number, edition (eg: Starter, Home Premium, Ultimate) and architecture (x86 or x86_64/32-bit or 64-bit) of the installation.
• Any additional information about the build (was it a public beta, or is it a leaked or private beta version?)

Thanks!