Archive

Archive for December, 2008

Dead Space with Arrow Keys!

December 22nd, 2008
Dead Space with Arrow Keys

Dead Space with Arrow Keys

Having received Dead Space for my Birthday I was disappointed to find that there was no way to use the arrow keys to play especially since I’m left handed and that is far more natural to me.

However, not being one to give up at the first hurdle Google lead me this page which gives instructions for playing Dead Space with arrow keys using GlovePIE to remap the keys as you press them. It’s a good workaround but it’s simply not ideal.

The file responsible for storing your key mappings is controls.rmp located under “C:\Documents and Settings\<your username>\Local Settings\Application Data\Electronic Arts\Dead Space”, so I began examing this file, how it changed depending what the keys were set to and after an hour or two of playing about I discovered not only the offsets storing the Up/Down/Left/Right key mappings but also the correct values for the arrow keys – AND THEY WORK.

To make these changes for yourself you’ll need a hex editor like XVI32, set the following values at the following offsets in the controls.rmp file (OFFSET:VALUE):-

5C: CB
AC: D0
14C: C8
23C: CD

Now save the file and load up Dead Space, you should find you’re now able to use the arrow keys to move around. Alternatively if that’s too much like hard work you can download my pre-modified controls.rmp file below which is set to use the arrow keys – simply customise the other keys how you would like.

Download: controls.rmp.

Update:
If you’d like to use the Enter/Return key as your reload key, make the following change using XVI32:-

E8: 1C

General, Tech , ,

IWF “block” Virgin Killer wikipedia page

December 8th, 2008

So I just read that the IWF have decided to block the Virgin Killer wikipedia page for what they claim is indecent coverart. Whether it is or is not, is out of scope for this posting.

The problem is they seem to be exclusively targeting wikipedia with this block since the image is easily available from other locations not to mention peoples’ homes.

The result of the block is that due most of UK’s traffic going via the Cleanfeed content blocking system wikipedia has been forced to prevent editing articles to UK contributors because they now effectively share a few IP addresses and do not pass on the real IP address as most proxies should.

The other problem is that they have only blocked the article text and not the actual image which is still accessible from wikipedia’s servers. Infact, had they blocked the actual image to start with the editing problem may never have existed. It’s still possible to view the article text without resorting to technology like tor by using the https:// version of the site instead which ofcourse cannot be transparently filtered. The irony here is that that site renders the full article + the actual image since the actual image hasn’t been blocked.

Far more people have now seen this image on the wikipedia page than would have if this block was never attempted, this block has attracted alot of media attention causing the views to that wikipedia page to sky rocket in the past 24-48 hours.

All in all I don’t think they’ve accomplished a great deal besides drawing attention to the very image they tried to prevent people seeing by raising the profile of that image.

Update: It appears that the image on Amazon (linked above) has now been removed.

Update 2: The IWF have now decided to remove this page from their block list:-

Following representations from Wikipedia, IWF invoked its Appeals Procedure and has given careful consideration to the issues involved in this case. The procedure is now complete and has confirmed that the image in question is potentially in breach of the Protection of Children Act 1978. However, the IWF Board has today (9 December 2008) considered these findings and the contextual issues involved in this specific case and, in light of the length of time the image has existed and its wide availability, the decision has been taken to remove this webpage from our list.

IWF’s overriding objective is to minimise the availability of indecent images of children on the internet, however, on this occasion our efforts have had the opposite effect. We regret the unintended consequences for Wikipedia and its users. Wikipedia have been informed of the outcome of this procedure and IWF Board’s subsequent decision.

http://www.iwf.org.uk/media/news.251.htm

I suppose that’s one way to backtrack without entirely admitting you were wrong in the first place, may they carefully consider their blocks in the future lest they repeat the same mistake.

Incompetence , , ,

asterisk cdr_mysql on Ubuntu 8.04 (Hardy)

December 8th, 2008

After a successful asterisk installation I was asked to also add call recording so that calls could be monitored and reviewed.To allow easy browsing of recorded calls it’s also handy to setup CDR to store call records in a database and since MixMonitor() by records calls named after the UNIQUEID of the call it’s important this ID is recorded as well.

Unfortunately after some simple testing it seems that cdr_mysql in the asterisk-mysql package has not been compiled to log this important ID.Fortunately we can fix this ourselves using the Ubuntu packaging tools. Firstly we need to install the packages needed to edit the package:-

sudo apt-get install devscripts debhelper fakeroot pbuilder dpatch

Next we should download the source package:-

apt-get source asterisk-mysql

Now we can set about editing the package, a quick look in debian/patches tells us that this package uses dpatch to maintain its patches – so we should too:-

cd asterisk-addons-1.4.5/
dpatch-edit-patch loguniqueid

This will drop us into a sub-shell where we can make our code changes for dpatch to record for us in a patch file. All we need to do is edit the file cdr_addon_mysql.c and at around line 52 near the #define DATE_FORMAT line we should add:-

#define MYSQL_LOGUNIQUEID 1

Save the file and quit out of the sub-shell created by dpatch, dpatch will now create our patch file under debian/patches/. All that’s left for us to do is edit debian/patches/00list and insert our new patch file into the list of patch files, I put mine first so the 00list file now looks like this:-

loguniqueid.dpatch
nomarch.dpatch
include_asterisk

With that done we should bump the changelog to reflect our changes:-

dch -i

Add a description after the top blank * indent like “Added logging of uniqueid”, also, it’s advisable to append ~uniqueid1 (or anything you like really, the ~ is important) so that our package doesn’t conflict with any new package versions Ubuntu might release in future (Make sure that the Ubuntu codename still says “hardy” and not “intrepid” or indeed “jaunty” too). Save the changelog.

We are now ready to build our new package:-

debuild -S -uc -us

If all went well our new dsc file has been created in the parent directory, so all that remains is to get pbuilder building the package. If you’ve never used pbuilder before you need to run:-

sudo pbuilder create

If you have run pbuilder before you should check everything is up to date by running:-

sudo pbuilder update

With pbuilder up to date, let’s build our new package:-

sudo pbuilder build ../asterisk-addons_1.4.5~uniqueid1.dsc

After a bit of compiling if all was successful pbuilder will report it has successfully built the package, so let’s install it:-

sudo dpkg -i /var/cache/pbuilder/result/asterisk-mysql*.deb

Once the package is installed all that remains is to restart asterisk to pickup the new module:-

sudo asterisk -rx 'restart when convenient'

Now test your cdr_mysql logging again, you should find the uniqueid is being logged.

Linux , , , , ,

PHP, PDO & Nested Transactions

December 2nd, 2008

I’ve been using PDO as my database library and it works reasonably well (as long as you remember it’s not a full blown database abstraction library), however recently I needed to use nested transactions to ensure that the database remains consistent while doing a series of SQL statements.

Unfortunately PDO does not support nested transactions although PostgreSQL and MySQL do. I decided to extend the PDO class to support nested transactions while also using PDO to keep track of the first transaction. I came up with the following class (released under the GNU General Public License, Version 3):-

class MyPDO extends PDO {
    // Database drivers that support SAVEPOINTs.
    protected static $savepointTransactions = array("pgsql", "mysql");

    // The current transaction level.
    protected $transLevel = 0;

    protected function nestable() {
        return in_array($this->getAttribute(PDO::ATTR_DRIVER_NAME),
                        self::$savepointTransactions);
    }

    public function beginTransaction() {
        if(!$this->nestable() || $this->transLevel == 0) {
            parent::beginTransaction();
        } else {
            $this->exec("SAVEPOINT LEVEL{$this->transLevel}");
        }

        $this->transLevel++;
    }

    public function commit() {
        $this->transLevel--;

        if(!$this->nestable() || $this->transLevel == 0) {
            parent::commit();
        } else {
            $this->exec("RELEASE SAVEPOINT LEVEL{$this->transLevel}");
        }
    }

    public function rollBack() {
        $this->transLevel--;

        if(!$this->nestable() || $this->transLevel == 0) {
            parent::rollBack();
        } else {
            $this->exec("ROLLBACK TO SAVEPOINT LEVEL{$this->transLevel}");
        }
    }
}

This code will only attempt to use the SAVEPOINT code if you’re using a database driver that supports it (it should probably version check the database server) this then means that in your code you can do things like:-

$pdo = new MyPDO(DB_DSN, DB_USER, DB_PASS);
$pdo->beginTransaction();
try {
    $pdo->exec(...);
    $pdo->exec(...);

    $pdo->beginTransaction();
    try {
        $pdo->exec(...);
        $pdo->exec(...);
        $pdo->exec(...);
        $pdo->commit();
    } catch(PDOException $e) {
        // If this statement fails, rollback...
        // NOTE: This will only rollback statements made in the
        //       inner try { block and not the outer one.
        $pdo->rollBack();
    }

    $pdo->commit();
} catch (PDOException $e) {
    $pdo->rollBack();
}

NB: I’ve tweaked the code slightly when transferring it to my blog and I haven’t tested it, so there could be some minor errors – please leave comments if you spot any. Thanks!

Coding , , , ,