In the end, there are 2,195 people on Steam in Adelaide, who are friends with other people in Adelaide, who are somehow connected to me. There are a total of 4,814 friendships linking these people together, and I excluded a total of 32,561 people who didn’t write in their profile that they were from Adelaide (so, for example, if you only said you were in South Australia, or didn’t put in a location at all, you’d be excluded), but were friends with someone who was. Considering that there’s only two or three of degrees of separation in the geek/gamer community in Adelaide, I’m reasonably certain I got everyone on the main “island”. Of course, there’s going to be some people that will be cut off for whatever reason (such as one of their friends blocking the route to them because their friend isn’t listed as being in Adelaide), but 2,195 people sounds about correct.

I’m also not counting relationships through groups. Groups take more code to make it work.

Now that I have this data, I can also tell you who the most popular people are in Adelaide on Steam. These are the people with the most amount of friends in Adelaide, based on what they wrote in their profile:

• 1st: (49) G! Devastator (James Dunn)
• 2nd: (41) [LotF] [Muppets] Techa (Tasos Chrysostomou)
• 2nd: (41) `viNNN.Q³ (Paul Camporeale)
• 4th: (36) CdM.Kantong (Brock)
• 5th: (31) ramirez[iw] (davo mac)
• 6th: (30) »ќ« iC (Izzy Gramp)
• 6th: (30) ]ap]> Horsey (Nick)
• 8th: (29) #eLeVaTe Reaper|* (Liam Rowan-Kelly)
• 9th: (28) Ap.# | Pickles « (Oscarrr)
• 10th: (27) Q.E.D ∫ FR3DST4R[<3A] (Nathan Zeppel)
• 10th: (27) Longie[iw] (Chris Long)
• 10th: (27) Noodles<< (Noodles)
• 14th: (26) Vertex ๖ۣۜ₪DiPlaTdoCus (David Eddy)
• 15th: (25) BBH | Phoozle
• 15th: (25) [TEA]Scoobth
• 15th: (25) cYn (Ryan)
• 18th: (24) Sub_^- (Christ…)
• 19th: (23) pheN (Ash)
• 19th: (23) AG Servers | Kevin (Kevin)

I’m playing around with different graphs in graphviz to generate a more graphical representation of this data. Unfortunately for me, it seems to take a lot of CPU power to generate these things. Here are a couple I’ve made up so far:

twopi, overlap=true: Warning: The full-size image that is linked to is a 2636×2678 pixels PNG (7.7MB).

fdp: Warning The one-third size image that is linked to is a 5064×10138 pixels PNG (24.1MB), and may crash your browser.

I’m going to keep playing with these graphs though, hopefully I can make something really pretty.

Once I’ve done that, maybe it’s time to map all of Australia as well? But I think I’ll need to offload the script somewhere else to do that…

This is a simple bash (shell) script to do timelapse photography with [Webcam 2000][wc2k]. In fact, it’ll work with any webcam software that outputs a single JPEG frame when given a HTTP request (as opposed to a multipart image stream).

#!/bin/bash
while [ 1 -lt 2 ]; do
    wget http://localhost:8080/ -O`date +%Y%m%d-%H%M%S.jpg`
    sleep 5s
done

This assumes the camera is running on http://localhost:8080/ I found over the space of two days worth of samples, it took `wget` about a quarter of a second to run on the machine I was using. It doesn’t go for pefect timing, and it will drift a bit from day to day. As you get more photos in the folder, the slower things will run. Bear in mind too that your webcam software takes a bit of time to respond to HTTP requests, and also has to encode the JPEG image frames. I was using a OV51x-chipset camera (Creative Webcam Vista) which actually talks JPEG over USB, so there wasn’t a great quality loss saving everything as JPEG. Plus, the camera was only 15$ anyway, and the image quality isn’t that great so I wasn’t worried.

The picture files are named YYYYMMDD-HHmmss, ie: a photo taken at 1:10:56pm on 29th December, 2008 is called 20081229-131056.jpg. This way, the frames can have their filename sorted, and the frames will be in the correct order.

Then, to encode the resulting frames in XVID, I used:

#!/bin/sh
rm divx2pass.log frameno.avi
mencoder "mf://*.jpg" -mf fps=30:type=jpg:w=800:h=600 -nosound \
   -ovc lavc -sws 2 -ffourcc XVID \
   -lavcopts vcodec=mpeg4:vbitrate=1000:vhq:vpass=1 -noskip \
   -o /dev/null
mencoder "mf://*.jpg" -mf fps=30:type=jpg:w=800:h=600 -nosound \
   -ovc lavc -sws 2 -ffourcc XVID \
   -lavcopts vcodec=mpeg4:vbitrate=1000:vhq:vpass=2 -noskip \
   -o timelapse.avi

In that example I assume 800×600 frames to be played at 30fps, with a 1000kbit/s bitrate. You can also encode in H.264 using the x264 encoder, which results in better quality:

#!/bin/sh
rm divx2pass.log frameno.avi
mencoder "mf://*.jpg" -mf fps=30:type=jpg:w=800:h=600 -nosound \
    -of rawvideo -ovc x264 \
    -x264encopts bitrate=1000:frameref=6:analyse=all:me=umh:subme=7:trellis=2:bframes=1:subq=7:brdo:mixed_refs:weight_b:bime:no_fast_pskip:direct_pred=auto:mixed_refs:nr=200:threads=auto:turbo=2:pass=1 \
    -noskip -o /dev/null
mencoder "mf://*.jpg" -mf fps=30:type=jpg:w=800:h=600 -nosound \
    -of rawvideo -ovc x264 \
    -x264encopts bitrate=1000:frameref=6:analyse=all:me=umh:subme=7:trellis=2:bframes=1:subq=7:brdo:mixed_refs:weight_b:bime:no_fast_pskip:direct_pred=auto:mixed_refs:nr=200:threads=auto:pass=2 \
    -noskip -o timelapse.264
mkvmerge -o timelapse.mkv timelapse.264

`mkvmerge` also allows you to define chapters for your time lapse, which is useful for breaking it up by day (and then, by hour if you like). But to do that you’ll need to write your own [chapters XML file][mchap].

As an example, I did some timelapse photography of a LAN at a friend’s house.

You can also see in my example that I turned on labels in Webcam 2000 to have the current time embedded at the top of each frame. They don’t always match the time on the filename (-2 seconds at most), but it’s still good for debugging things, and it also is a good caption to have in the final video.

I’m now looking into a much more elegant Linux-only solution to this. I’m looking at [camsource][] with anticipation, and I’ll do some experiments with that at some point.

[wc2k]: http://www.webcam2000.info/
[mchap]: http://www.matroska.org/technical/specs/chapters/index.html
[camsource]: http://camsource.sourceforge.net/

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

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…

So now, here are some new packages. There’s a basic APT repository too for the lazy, and i386 and amd64 libraries. They’ve been complied against Debian Unstable, however they should also work in Ubuntu Edgy (they’ll also work on Dapper if you run ignoring dependencies, however if you build from source you should be fine).

# On i386, add this to your sources.list file:
deb http://micolous.id.au/debian/openal-legacy/ binary-i386/

# On amd64, add this to your sources.list file:
deb http://micolous.id.au/debian/openal-legacy/ binary-amd64/

# Sources:
deb-src http://micolous.id.au/debian/openal-legacy/ source/

To install, add those repositories, do an `apt-get update`, then `apt-get install libopenal0-legacy`. There’s also a `libopenal-legacy-dev` package, which conflicts with the normal `libopenal-dev` package, should you ever want to develop applications against the old version of OpenAL (which is unlikely).

Then, you need to point the symlink for openal.so in the System folder of UT to `/usr/lib/libopenal.so.0.0.8`. The new version of OpenAL will remain symlinked at `/usr/lib/libopenal.so` pointing to `/usr/lib/libopenal.so.0.0.0`.