Games Detection

What is Game Detection

Game Detection is used by Gfire to detect when you have a game running, so it can tell Xfire and your friends about your ingame-status and Xfire is able to count your gaming hours.

Joining Xfire buddies in games (This manual is for Gfire 0.8.3 and below!)

You can now join buddies in game by right clicking on an in-game buddy and selecting "Join Game...".
"But I don't see that when I click on the buddy. How come?" - We have introduced a new file that needs to reside in your Pidgin preferences directory (along side the gfire_games.xml).

gfire_launch.xml is parsed whenever your start the plugin and tells Gfire exactly how to launch games and with the correct options to get you to join your buddies game and how to detect them. There is an example file in the "data" subdirectory of the distribution.

<?xml version="1.0" encoding="UTF-8"?>
<!--
* This XML file is what gfire plugin for gaim uses
* to determine which games you have that can be
* joined, and how exactly to launch them.
-->

<launchinfo>
	<game id="4097" name="Wolfenstein: Enemy Territory">
		<xqf name="Enemy Territory" />
		<processes windows_process='' unix_process='et' />
		<command>
			<bin>et</bin>
			<dir>/archive/games/enemy-territory/</dir>
			<gamemod>+set fs_game @mod@</gamemod>
			<connect>+connect @ip@:@port@</connect>
			<launch>@options@ @gamemod@ @connect@</launch>
		</command>
	</game>
</launchinfo>

Explanation:

• @ip@ and @port@ will be replaced by the actual ip and port number Xfire sends us with buddy updates.
• id = xfire game id (look it up in gfire_games.xml or here)
• xqf name = this is the name xqf uses in the LaunchInfo?.txt status file
• bin = program name to run (full path if not in your PATH)
• dir = working directory program will start from this directory
• gamemod = This really isn't used yet.
• options = any static options need for the game to run properly
• connect = command line options to bin, so it will connect to ip:port
• launch = this mapping allows us to put the entire command line together in the correct order. the @something@ is replaced by the

options above.

• processes = this is used for game detection, actually there's not difference between the two arguments. Choose what you like. Insert there only the filename of the binary you want to detect.

How does this work?

When you right click a buddy in Pidgin and that buddy is in a game, we check this XML file for the game id that Xfire sent us for that buddy. Xfire also sends us an ip address and port. If you have a <game></game> entry in your gfire_launch.xml that matches the game id of your buddy, we assume you can play this game. If you *DO NOT* have a matching <game> entry with the same id number, we assume you can't play this game.

If you can play the game, we show you the right click menu "Join Game...". If you can't play the game we don't.

If you click the "Join Game..." menu option, we create a commmand line to run the game with the options you specified in the <game> entry. The above entry would run something like this: (assuming ip and port were sent below)

/archive/games/enemy-territory/et +connect 127.0.0.1:26659

We execute this line using the glib api. The detection mechanism should now find your process from the <processes /> tag.

"I've got it working but everytime I launch the game, it works, but I'm only listed as 'in game' for a few seconds and then I'm not 'in game' anymore".

Simple, the game your launching is spawing a new process to handle the game. In this case you have to check for the process name which keeps the game running and correct your <processes /> tag. This can mostly easily be done by the following command:

$ ps -A

This is especially true for "cedega" or "wine" run games.

UT, UT200x, Quake, Doom3 etc, and all the Linux native games I play do not have this issue.