Best Laid Plans

It's Friday and I have plans for EVE. I'm going to log in with Geo, see if I can get into some fleets and shoot people or die trying. As Rabbie Burns once wrote "The best-laid schemes o' mice an 'men / Gang aft agley". Before the working day is over I am getting pinged about issues with the alliance authentication server. A quick check reveals it isn't just one person with an expired API; the whole alliance is no longer matching the test to allow them to read the forums. The knock-on effect of this is nobody can log into Jabber, Teampeak or submit wormhole loot or PI to my corp's buyout scheme. Oh hell, what have CCP changed now?

A long time ago I wrote about setting up the alliance forums so it is no secret that I use Simple Machines Forum (SMF) with Temar's EVE API (TEA) for access control. It has been some time since TEA was actively developed so these problems crop up from time to time. The last time was when CCP forced SSL access to api.eveonline.com and I had to dig around in the code to find where that needed fixed. After a little bit of exploration in the code I realised it wasn't going to be as easy as grep'ing for 'http://api.eve-online.com/' and replacing it with the correct domain. On top of that real work was running well into my evening and I was trying to do a bit of both. Oh, and I had promised to watch a film with my wife. Oh, and call a friend I'd not spoken to for a while. Suddenly my Friday was probably going to feature a lot less pewpew with Geo.

Once all my committments were cleared it was 22:30 and various workarounds had been put in place to allow people to use TeamSpeak and the buyback site with little inconvenience. Now I needed to dig into the cause of my spoiled Friday plans. There is no exciting way to describe debugging code. It's a case of following the flow and getting the code to spit out interesting information in various places. Once you work out something that doesn't look right you dig deeper into where that came from. After a little while I worked out that the thing which is only meant to contain the ID CCP gives to corporations actually contains additional information. I suspect this has just been added or rearranged by CCP recently. If TEA used a proper XML parser to read attributes there would be no problem here. It doesn't and instead relies on the order and number of things appearing in the API output.

<row name="Oreamnos Amric" characterID="1047741762" corporationName="Z3R0 Return Mining Inc." corporationID="226346106" />

or something similar to it became

<row name="Oreamnos Amric" characterID="1047741762" corporationName="Z3R0 Return Mining Inc." corporationID="226346106" allianceID="99002348" allianceName="Illusion of Solitude" factionID="0" factionName="" /> 

TEA was matching the finishing "/>" in the first example to find the corporationID value. So when it used the same logic on the second string the value found for the corporationID also included the allianceID, allianceName, factionID and factionName. The upshot of this is the new string didn't match any corporation in my alliance therefore every member was considered not in my alliance any more.

The workaround to this was rather trivial. I just updated the code to look for "allianceID" instead of "/>" to find where the corporationID was set.

$char = explode('" />', $char[1], 2);

was changed to

 $char = explode('" allianceID="', $char[1], 2);

but this is only a workaround. The proper fix would be to rewrite the code to actually process the XML as XML. Doing that means CCP can modify the output of the API to add and remove things without breaking TEA. As long as the attributes TEA requires are present the code would still work.

Something good did come of all this mess. While trawling the forums to see if anyone else was having problems with the API I discovered the task of updating the TEA code has been taken on by someone new. In this forum post I found links to a github repository so now I need to look at that and see what changes have been made and if upgrading will make my API checking more robust.

Origins of Quafe

An interesting question arose on our alliance jabber server today:

Olari: Wonder what the stations do with used pod goo

Studley: mix it with goon tears and recycle it as quafe

I nearly fell off my chair at that one. Thanks Studley.

More IT

Hot on the heels of creating the loot submission system I suddenly found myself in possession of a corp and proto-alliance unexpectedly displaced from its forums and comms. Alliances are meant to be more about a common goal and shared 'belonging' rather than just some badge beneath the corp badge. Part of making that so is having shared comms and forums to communicate through. For me, if I wanted the wormhole side of our former alliance to survive, getting a replacement for these things as fast as possible was essential.

After setting up an emergency TeamSpeak server on a box I have in London I had a quick check with what would be best to use for the forums. I pretty much knew the answer already but wanted to confirm there wasn't some better choice out there. As I turned out, I was correct and needed to get myself Simple Machines Forum with Temar's EVE API to allow API authentication. This would also allow TeamSpeak integration with the forums to ensure only forum members in the correct corps would be able to get onto our comms.

Having attempted to fight with the development version of Temar's EVE API already on behalf of Li3 Alliance it was with some trepidation that I re-approached the task. I was well advised that the 'stable' version of TEA is exploitable so I didn't really have any choice other than to win this time. Renting a cheap server to run it all on was easy. Installing SMF was also pretty simple with a nice, easy to follow installation interface. Installing TEA was also pretty simple once I found the link to the development version. Now came the battle to understand the way TEA's 'rules' work.

For some reason I found it all a lot easier to understand this time. You need to create the appropriate groups under SMF first and then it's a simple case in TEA to say "people in corp 226346106 go to group Z3R0R" and any new members will be put in that group. Piece of cake. So I set up rules for the main corp and the academy, created forum subsections, stuck a suitably dark theme on it and told people to sign up. Voila, one SMF forum integrated with new-style API keys thanks to Temar, whoever he is.

Next up was the TeamSpeak integration which I got myself a little confused over. I got the connection from TEA to TS3 sorted no bother and could see a list of available groups fine. I just could not figure out how on earth to make the rules apply to forum members and allow them access to the TS3 server. The sticking point was my impression that setting up TeamSpeak to use a database was optional. Turns out that this is not so. As soon as I got TS3 and SMF linked to the database everything just worked and people could register themselves with TS3.

So, what was left? Well some people had mentioned a jabber server. A number of Z3R0 were already hanging out on jabber.org but we could do cool things with our own jabber server. It turns out TEA only supports the Openfire jabber server. I battled with this for a while but it really wasn't up for running in the small amount of RAM available. Plan B - write my own authentication layer for some other jabber server. So some Python and a weekend later I rolled that out too.

Today our proto-alliance has all its IT needs taken care of. Just need to create the actual alliance in-game now.