micolous.id.au

the result of a blogging accident

Saturday, August 29, 2009

games-action/pink-pony 1.2.1

Filed under: Gaming, Gentoo — micolous @ 02:37

I’ve bumped games-action/pink-pony to 1.2.1 now in my overlay.

Thursday, July 16, 2009

Mapping Steam

Filed under: Coding, Gaming — micolous @ 09:20

I’ve been playing around for a little while with the idea of mapping the Steam Community social network. A couple of days, I decided I’d dig up the old code and get it going again. I ported some old code I wrote in C# for the purpose to Python using the Django framework (mainly to make database access easier). I then wrote a script that would go through Steam, starting with myself, find all the person’s friends who were in Adelaide, then work out from there.

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:

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… :)

Sunday, January 11, 2009

Webcam 2000 Timelapse Photography

Filed under: Gaming, Interesting stuff — micolous @ 12:13

Happy new year! I should really update my blog more…

This is a simple bash (shell) script to do timelapse photography with Webcam 2000. 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).

1
2
3
4
5

#!/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:

1
2
3
4
5
6
7
8
9
10

#!/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:

1
2
3
4
5
6
7
8
9
10
11

#!/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.

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.

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.

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