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.

CCP Abandon POSs

In case you missed it, the CSM summit minutes are out. You can go read the 113 pages of minutes if you like. I can't bring myself to read something as verbose as that so I'll go with the digested output from others.

The first rage inducing thing that has come out of these minutes is CCP's position on the POS rework. Bizarrely, CCP has the opinion that only a very small number of people who play EVE are impacted by the terribleness that is the POS management system. The last time I checked there were POSs in highsec, lowsec, nullsec and wormholes. For sure the terrible permissions system does not impact the teeny little corps who have a single person managing their POS. As soon as you try to have any sensible level of hierarchy in a larger corp you run face first into the limited flexibility of the massive number of permissions available.

Bob help us wormhole dwellers who actually have to live in a POS. The POS security is probably the single largest sticking point for corp recruitment. Before I can recruit someone I need to form as good a picture as possible of who that person is and what they are likely to do to the existing members. Is this person a nice guy? Is he a total asshat who's going to steal all our ships? Is he a spy who aim is to offline the POSs as soon as he gets the rights to react some gas? While this is all part of living in wormholes, I would also like to be able to relax some and take many more people in to enjoy the first-class content we have access to in W-space.

CCP started to go down a route of removing complexity for the sake of complexity. This problem still exists in spades with POSs. If you've ever done gas reactions you'll know exactly what I'm talking about. If you have ever been unfortunate enough to set up titles for reasonable secure hanger tabs or to allow people to have the correct permissions to make them useful without giving dangerous levels of access you'll know what I'm talking about. Unfortunately CCP only see this one side of the problem - the person making the permissions.

The other side is the inconveniences the rest of the players who have any interaction with POSs have to endure. Many wormhole corps have a POS per small group of corp members. This means the whole corp has to deal with getting in a ridiculous quantity of POS fuel on a regular basis, taking time away from more enjoyable activities. POS passwords became slightly less annoying recently, but the fact we need them at all is a pain.

Two Step has a forum threadnaught up to show CCP just how small the affected player base actually is. There are 79 pages as I write this. I suggest you go add a message there to show your support to fix this embarrassingly broken aspect of life in New Eden.

Or wear the t-shirt to Fanfest

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.