EVE Technology Lab

I was asked by FoxFour to produce this, so:
A simple list, albeit with explanation as to why, of API improvements/additions/fixes.

1. New Character/Alliance/Corporation/Faction Endpoint.
This is already in the works, it was suggested to FoxFour and he agreed it made sense and had a prototype running pretty much the next day. I'll go over it again anyway.

The problem is, sometimes developers have a name and nothing else. To resolve it into more meaningful information, you have to call the public characterInfo sheet. This in principle is fine, however, there are situations now where you have several hundred or even thousand names you want to resolve. Calling them all is bad for developers, bad for users who have to wait and bad for CCP who feel unhappy that their beautiful systems are being challenged in unhealthy ways.

FoxFour has created an endpoint that allows developers to call multiple characterIDs at the same time and produce a list with rows detailing corporation, alliance and faction. He is definately a fuzzy and cuddly guy. I took the liberty of writing a wiki entry based on info he's given prior to it's release. You can read/fix it here.

As an example of an application that uses characterInfo this way, here's a local scanner. There is at least 3 public apps that perform this function. They take the list of names from local and gather the information on each to produce meaninful breakdowns of the composition of local. To do this required 3823 characterInfo requests after resolving all of the names into IDs. Resolving the IDs can be done efficiently and in batch by using the CharacterID call.

2. More Detail For FacWarTopStats page.
The detail given in FacWarTopStats is limited upto the point where it's kind of pointless. To use the sheet and give the user meaningful data, you need details like corporation and alliance where applicable. Without it you have to make calls to characterInfo (although the above fix mitigates this greatly). Generally for a simple stats page though, it'd be better if the info came with the stats page and didn't require further API calls just to make it useful.

I don't think anyone uses this page at the moment as it requires too much extra to make meaningful information during which the user has to wait.

3. Omission of I-Hub and Station reinforced notifications.
I can't say whether this is due to an oversight or technical constraints that I wouldn't understand, I hope it's the former. With the notification data both ingame and via API we can get wonderful little timers telling us when our PoCos are reinforced and when they come out. This enables us to automate defensive OP Timers for them. Strangely the same notifications do not exist for stations or i-hubs. While powerful alliances such as Pandemic Legion, able to project their will anywhere in the spacegame universe, have little need for such defensive timers. Smaller, weaker, more feeble alliances, those such as Goonswarm Federation, Those Russian Alliances, Against All Authorities and Black Legion, who all operate on the opposite side of the universe to where PL happens to be, suffer greatly from not having automated timers. Only last weekend, -A- were completely oblivious to one of their systems and station entering final timers. The result was a hastily cobbled together 9 full fleets of ill prepared and ill informed pilots jumping in late to the party.

I think we can all agree that notifications ingame that can be used by the API to generate forum timers and webpage timers would benefit everyone. Especially those little guys trying their best.

4. CharacterID and CharacterName type resolution.
FoxFour is a good ol' boy and is on the case. Basically we have various APIs that can resolve IDs into names, but it's unclear with characterID and characterName what type of ID has just been resolved. This is because the initial scope of the APIs expanded to include more than just characters. He has a new endpoint in testing which will be awesome and will tell developers what it is thats just been resolved. Awesome.

5. Outpost list when using Legacy Keys.
Probably redundant, but this never worked for me when using a Legacy type key. It always returned "General Error: Scotty the docking manager heard you were talking **** about him behind his back and refuses to service your request.".

If there were anymore I've forgotten about them.

6. This idea is for the sake of reducing API errors. The Char/FacWarStats page returns error 124 when a character is not part of FW. From what I understand, this error is calculated towards the maximum amount of errors you can have before a 904, which doesn't help as there isn't any other reliable way of figuring out if a character is part of FW.

I suggest to either remove the error and send the "Character isn't part of FW" in another way, or stop counting this error towards the 904.

As I am a lazy ****, what is another page that works with the legacy key that should require the same roles as this? So I can better look at how much work might be needed.

I'd really like to see the introduction of a BlueprintAssets API which will provide specific details for blueprints owned by a character or a corporation. Columns could be:

• itemID - The unique ID corresponding to the itemID in the AssetList API call
• typeID - The type ID of the blueprint
• materialLevel - The ML of the blueprint
• productivityLevel - The PL of the blueprint
• runsRemaining - The number of runs remaining on the blueprint (set to -1 in the case of originals)

A location ID would be useful to have as well if that's at all feasible.

While we can do a copy/paste of personal and corporate blueprints from the Science and Industry UI when working with our blueprint data, this has some major limitations:

1. Blueprints in containers are not listed
2. Blueprints in different regions are not listed

Having all the blueprint information available via an API without having to travel through multiple regions and manually process a list would be a great help to industrialists from a production and logistics point of view.

This new API should have a new access mask so that producers within a corporation can see the blueprint details without requiring access to other details (e.g. the full asset list).

I have noticed that assets list xml is inconsistent in ending row itemID= row lines with /> or >. I don't know if this would upset programming wrapper functions that dump xml into some sort of array in one or a few lines of code. Myself I program in .NET C# and do manual string butchery to parse every line and every variable within a line.

Just had a look at a fresh assets xml file and you are right. I probably got myself tied up by copy and pasting xml fragments from a web browser into a text editor.

i would love to see an api telling about current incursions + state info

Why no one asks about wrong sigleton flag for blueprints bpo's in containers for killmail APIs? It drives me mad

Ship CREST please? (https://wiki.eveonline.com/en/wiki/CREST_Documentation)

I'd really like to see the IGB headers issue fixed.

This isnt a new problem and has been discussed many times before. Essentially the IGB headers return data about your client to the host web site in a header message. The client headers unfortunately use underscores, which is not permitted when the host web site is using Nginx or newer versions of Apache.

While this can ~sometimes~ be worked around by modifying settings on the web server. But if you are on a shared host using Nginx or Apache 2.4 and up then you're pretty much S O O L.

An excellent solution was proposed here ... https://forums.eveonline.com/default.aspx?g=posts&m=1906461#post1906461