micolous.id.au

the result of a blogging accident

Friday, June 27, 2008

SVGForm alpha3; menus, input boxes, focus model… oh my!

Filed under: Coding, Projects — micolous @ 18:29

I’ve updated SVGForm now to alpha3. It now includes some new stuff, a simple menu system (and I mean, simple), and a focus model allowing an input control to work.

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, 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), so you may have to wait for Internet Explorer 8 and hope they add support for SVG and the SVG DOM.

Clicking Bricks 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), and the source script file.

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

And there’s SVGForm’s source itself 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, 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.

Monday, May 26, 2008

SVG + Forms = SVGForm begins

Filed under: Coding, Projects — micolous @ 03:14

I’m starting to write a ECMAScript-based (JavaScript) SVG UI toolkit called SVGForm. The idea behind it is that it adds HTML-style form controls to ECMAScript applications, allowing you to have some of the functionality of other systems like Adobe Flash and Microsoft Silverlight without needing browser plugins (where the browser has native SVG support). It also has the bonus of the implementations of SVG and ECMAScript exist on many platforms and architectures, where Flash or Silverlight are unavailable or horribly unstable.

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. 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), the game logic (JS) and the SVGForm library (JS).

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, 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

Thursday, April 24, 2008

Trackmania Disassembler Updated (1.2), and some musings

Filed under: Coding, Gaming, Projects — micolous @ 00:09

I’ve updated my Trackmania Disassembler to support Trackmania Nations Forever and Trackmania United Forever. And it seems Nadeo have finally gone off their weak XOR password obfuscation algorithm. The previous part of the file that held the password is now always blank – wether there is a password there or not, and the password seems to be buried somewhere in the data block.

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.

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.

Wednesday, August 1, 2007

ddrgen 1.1.4, igaeditor hiatus

Filed under: Coding, Projects — micolous @ 00:41

Yay! It’s ddrgen 1.1.4! After way too long leaving the changes without actually publishing them, I’ve published them. ddrgen now features support for Avahi for broadcasting found computer names/addresses over MDNS/Zeroconf/Bonjour (for all you OSX and Linux users), so now you don’t need to be the primary nameserver for your network to advertise found names.

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.

Thursday, December 21, 2006

igaeditor 0.1.5

Filed under: Coding, Gaming, Projects — micolous @ 01:11

A new release of IGA Ad Cache Editor: The “I gotta stop playing Warcraft if I expect to get any development work done” edition. (0.1.5)

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

Older Posts »

Powered by WordPress