Any chance of getting x, y, z position on kilmails? That , plus more accurate than a second timestamps would make for some awesome battle visualizations

Please also keep in mind that as it stands the EVE API and Public CREST are pet projects and are worked on in spare time. Don't go expecting a mad rush of new changes.

I'd like to discuss this.

Most game developers would be ecstatic to have the level of 3rd party development that EVE (or even DUST) gets. Most developers (myself included) would not be happy to work under this level of support.

How much more important does the API need to be before it stops being a pet project? What needs to happen before CCP decides to allocate more time to this?

There are ongoing discussions about this very topic, I would rather not discuss it any further at this time. Sorry.

Idea: SenderName in char/Notifications
Description: Same use as in MailMessages.

If we give the ID I see no reason not to denormalize it.

Idea: denormalize everything \o/ - just kidding, but would love to have all names everywhere id of corp,character,item,etc pops up - it would have a big toll on sent data. But still its my dream to have this

Since we're talking API stuff, two things stand out to me in relation to popular goonfleet tools:

1. We have a program, GarpaUI, which essentially copies the account/character settings from one acct/char to others. There used to be an API which returned userID ( https://wiki.eveonline.com/en/wiki/EVE_API_Account_Status ) but that was apparently stealth changed. It is difficult for a third party to robustly associate a "character" settings file with a specific "user" settings file. That would be very easy if a vcode/API let you give charid of all chars associated with a specific userid.

Then, in our app, we could have the user enter said vcode and they would be able to more easily determine which account settings file to copy over the other account settings files, so that their selected accts/chars had identical client settings.

Sorry for the short description but we'll have a public release of this tool soon, so you'll get to see it in action.


2. Market data, but specifically not just 'history' but all market orders in a region for all items. IT WOULD BE OKAY IF THESE WERE TIME DELAYED, so that the API was, say, a few hours out of date. That would combat possible abuse cases. But we need accurate market data for a nullsec import guide ( http://goonmetrics.com ) which many people in GSF/CFC use. Right now we rely on a data uploader that we actually created before the Eve Market Data Relay (EMDR) existed. A good CREST market order API would obsolete both our uploader and EMDR and let CCP continue with what appears to be their long term goal in altering what's in the client cache.

We will NOT be adding user IDs back. Sorry, but it is just not happening.

As for the market data, hopefully at some point in the future yes, we would love to add market orders to CREST. It's something we are talking about internally and discussing the hows, whens, and whys of doing it.

Music listened to while making this post:

• DJ Skazka - -É-¦-Ç-¦-+-¦-+-+-+ - https://www.youtube.com/watch?v=EDcYDXgP5hA - While writting the main post.
• Lucky mc ft. Little B - Vmeste mi (DJ MELNIKOFF Remix) - https://www.youtube.com/watch?v=ndZ5HBYL0Mw

Will update the list as I make posts. :)

Added faction and alliance information to the API on sisi for account/APIKeyInfo: http://api.testeveonline.com/account/APIKeyInfo.xml.aspx

Idea: Notification Ref Type Name
Description: Notifications endpoint returns a typeID that refers to what type the notification is. Until now we are relying on user input to 'decipher' the ID to a name (the list can be found at http://wiki.eve-id.net/APIv2_Char_Notifications_XML). It would be great if the returned data includes also the 'typeName'.

Idea: Update that AssetList.xml API to return material level and production level for blueprints in assets.

Description: Many industry applications, asset tracking programs and personal spreadsheets query blueprints but no information is provided on the attributes of the blueprint to use for production calculations - thus, requiring manual updates. Furthermore, the in game copy and paste functionality is more cumbersome than typical asset copy/paste as it also does not contain this information unless opening a new window through the industry interface. Other than manually updating info or the cut/paste method, the only other way to get bp data is to pull from the industry jobs API, which isn't complete and becomes almost useless when using corp pos labs because all jobs are corp and not personal.

Alternative to the above idea:

Idea: Add a new API for blueprint only data.

Description: The asset API does what it says, it provides information on assets, which include blueprints. However, updating the assets API for blueprints doesn't fit because all assets do not have bp type attributes. Since blueprints in game are managed through the industry interface, it makes more sense to repeat the blueprint information contained there in its own API instead of altering the asset API. Furthermore, given the issues with changing information to show different icons for bp copies, any update to the AssetList API May be a bridge too far to cross. This change would provide a mirror to in game data and also solve the problems stated above wrt bp dat in third party apps.

source: https://forums.eveonline.com/default.aspx?g=posts&m=4454173

Idea: Add all endpoints to /api/Calllist
Description: Including ContractItems, ContractBids & other endpoins (MailBodies is inside it -.-)

idea: Add cache types to /api/Calllist
Description: No more handwork for us :)
Example:

row cache="short" accessMask="134217728" type="Character" name="Locations" groupID="3" description="..."
row cache="long" accessMask="67108864" type="Character" name="Contracts" groupID="3" description="..."
row cache="long" accessMask="33554432" type="Character" name="AccountStatus" groupID="3" description="..."
row cache="mShort" accessMask="16777216" type="Character" name="CharacterInfo" groupID="3" description="..."
row cache="mShort" accessMask="8388608" type="Character" name="CharacterInfo" groupID="4" description="..."
row cache="short" accessMask="4194304" type="Character" name="WalletTransactions" groupID="1" description="..."

[indizies]
military/strategic/industry indizies of nullsec systems. To not increase the already huge file of the Sovereignty API you could add an additional api just for the indizies only (solarSystemID + 3x indizies) otherwise combine them (which will make the api call just bigger). It depends on what works better for you and the cache/api system.

Assuming it passes code review I will be releasing the following API update on Tuesday (still has to pass code review but **** it right?)

So, planetary interaction. Before we talk about API stuff I want to discuss PI within EVE. You must understand that when PI was built it did something a bit crazy, it was built in such a way that it actually only updates and simulates when you look at it. Nice for us on server load, not so nice for the API since we only have access to the DB and cannot force a simulation update.

When thinking about PI however and what you want access to there are a few things:

1. When do my PI extractor jobs expire expire
2. How full/empty are all of my things

So, for #1 we actually store in the DB what the expire time is for extractor control units... so that doesn't take much...

As for #2, I don't know... for now I am hoping #1 makes doing this endpoint valuable enough and then will also spend a bit of time seeing what I can dig up for the contents stuff later.

All of the following endpoints require the characters API key to have access to the asset list.

/char/PlanetaryColonies
/char/PlanetaryPins
/char/PlanetaryLinks
/char/PlanetaryRoutes

All of the endpoints will need characterID attribute, keyID, and vCode. You will then need planetID for all but the colonies endpoint.

Sample returns:
http://pastebin.com/ZTmSFZu1

I am telling you this now so that if you have any suggestions you can tell me before I release this stuff and don't want to go back and touch it. :P

Assuming it passes code review I will be releasing the following API update on Tuesday (still has to pass code review but **** it right?)

So, planetary interaction. Before we talk about API stuff I want to discuss PI within EVE. You must understand that when PI was built it did something a bit crazy, it was built in such a way that it actually only updates and simulates when you look at it. Nice for us on server load, not so nice for the API since we only have access to the DB and cannot force a simulation update.

When thinking about PI however and what you want access to there are a few things:

1. When do my PI extractor jobs expire expire
2. How full/empty are all of my things

So, for #1 we actually store in the DB what the expire time is for extractor control units... so that doesn't take much...

As for #2, I don't know... for now I am hoping #1 makes doing this endpoint valuable enough and then will also spend a bit of time seeing what I can dig up for the contents stuff later.

All of the following endpoints require the characters API key to have access to the asset list.

/char/PlanetaryColonies
/char/PlanetaryPins
/char/PlanetaryLinks
/char/PlanetaryRoutes

All of the endpoints will need characterID attribute, keyID, and vCode. You will then need planetID for all but the colonies endpoint.

Sample returns:
http://pastebin.com/ZTmSFZu1

I am telling you this now so that if you have any suggestions you can tell me before I release this stuff and don't want to go back and touch it. :P

Suggestions:
1) Add position of pins
2) Would be nice to have the stuff stored in each pin, even if it was only updated the last time you look at it. As long as you have that timestamp in the data, people could build stuff to guess when things were full
3) It seems silly to repeat the planet name, owner and whatnot in the calls that require planet ids. In fact, owner seems silly to have in there at all until I can take over someone's PI or something... :P
4) It is odd to me that upgrade level is on the colonies call but not in the pins call, but it isn't a huge deal.
5) Routes don't say what link(s) they are on, does the waypointX field refer to pins or links? I assume pins. Are we really only allowed 5 waypoints for a route?

You are not the first to ask, so OK but not sure what you guys will do with them.

Another request: is it possible to expose how many extractor heads are currently being deployed from the Extractor Control Unit?

If you guys think thats of use...

I couldn't figure out what you would use that for.

It would let you determine how depleted a given setup is. You divide material extracted by number of heads and get an efficiency rating.

Will take your word, I don't know PI well enough.

I will have a chat with the design department and see how they feel about these being added.

Thank you, FoxFour.

All of the following endpoints require the characters API key to have access to the asset list.

/char/PlanetaryColonies
/char/PlanetaryPins
/char/PlanetaryLinks
/char/PlanetaryRoutes

All of the endpoints will need characterID attribute, keyID, and vCode. You will then need planetID for all but the colonies endpoint.

What about the access mask? will there be another category or which category does that falls in?

Also, having the constellationID and solarSystemID of each planet in the PlanetaryColonies call would be nice.

Then, the dates contain "AM" but the usual API format is "yyyy-MM-dd HH:mm:ss".

Sorry for being annoying while I implement your stuff :-)

1) Please add a typeID to the CharacterName/CharacterID API. Would save one or multiple calls depending on what type it is. (I always check char/corp/alliance, in that order, so it could theoretically cut down two-thirds of the calls for CharacterInfo/CorporationSheet.)

Any update on the ability to query the mysteriously missing Battle Win/Loss transactions from corp members in the Dust Wallet?

Is there any news on CREST? (Especially contact list reading/writing)

It would be lovely if we could get the names of the hangar divisions for a corporation. Going for the generic names Division 1, Division 2, Division 3, etc., from invFlags is a bit dull. Definitely not user friendly.

I thought we gave those out on the corporation sheet... we give out wallet names...

https://neweden-dev.com/Corporation/Corporation_Sheet

Do those always say div1 and such?

I thought we gave those out on the corporation sheet... we give out wallet names...

https://neweden-dev.com/Corporation/Corporation_Sheet

Do those always say div1 and such?

I must've been completely blind! I've been on the lookout for these names for quite a while now. And FoxFour, thank you for all these improvements you've been making to the API, very much appreciated.

On a unrelated note, is it possible to change /corp/Locations.xml.aspx so that it doesn't fail completely on invalid asset IDs? In the minute it takes me to fetch and process the assets list, someone undocks in a ship, invalidating one of the asset IDs. For me, that's a relatively frequent event.

Currently, when that happens, I repeatedly split the list of asset IDs I request into two halves and call the API again on those two lists. This usually results in 9 to 11 requests instead of just one that would've otherwise been required.

I must've been completely blind! I've been on the lookout for these names for quite a while now. And FoxFour, thank you for all these improvements you've been making to the API, very much appreciated.

On a unrelated note, is it possible to change /corp/Locations.xml.aspx so that it doesn't fail completely on invalid asset IDs? In the minute it takes me to fetch and process the assets list, someone undocks in a ship, invalidating one of the asset IDs. For me, that's a relatively frequent event.

Currently, when that happens, I repeatedly split the list of asset IDs I request into two halves and call the API again on those two lists. This usually results in 9 to 11 requests instead of just one that would've otherwise been required.

The ContractItems API's have a similar thing going like explained in the quote, where I have to split the requests up in order to get the max details. This after you do the ContractsItems call for contractID's you just got via Contracts API...

But, what grinds me the most is the fact that a request for the corp AssetList would contain IDs that did not move, though, when you request the Locations API for those IDs (moments after receiving the IDs from the AssetList. endpoint), you'd get "135: Owner is not the owner of all itemIDs..." : \ I also have to split the assetIDs up and kinda ignore the errors though, which sucks.

Possibly because I just woke up and also because it's the weekend... but I am not really understanding what you are saying. Could you explain in more detail. Sorry. :(

<?xml version='1.0' encoding='UTF-8'?>
<eveapi version="2">
<currentTime>2014-04-20 18:08:13</currentTime>
<error code="135">Owner is not the owner of all itemIDs or a non-existant itemID was passed in. If you are not trying to scrape the API, please ensure your input are valid locations associated with the key owner.</error>
<cachedUntil>2014-04-21 06:08:13</cachedUntil>
</eveapi>

PI updates in WH seem to be less than 100% reliable. And now I got an idea of maybe why. Two on demand services (PI & wh system) --

no wonder 1 in 6 time you can reconfigure or renew extraction, double check it at end before logging off hours later...and find out when you go back days later to collect that it all stopped at the next DT.

I guess the on demand nature of things means stuff doesn't always get stored in non-volatile DB if server priorities and log off mix wrong. On demand server processes simply do not always flush all data to non-volatile DB if coders missed one caffeine injection when reviewing the code logic.

Let me try to explain in a reproducible manner.

I pull the assets list from the API. From it, I compute what assets are new in it compared to what I already have in my database. Most of the time, it's just new ships appearing in our ship maintenance array, hangars being restocked; very ordinary normal stuff going on.

Downloading the assets list from the API takes about 20 seconds (it is huge), processing it and adding it to the database takes about 40 seconds. Finally, I now have a list of all the asset IDs of new ships / containers / corpses / stuff that came with the last API pull.

Now it's time to query the names of all those new assets with the /corp/Locations.xml.aspx endpoint. In order to save load on the API, I request the names in batches of 50 IDs at a time.

In the 60 seconds it took me to get to this point, someone has undocked in a ship that happens to be one of the asset IDs I'm just about to request. This means that the ship is no longer the corporation's, it would no longer appear in our assets list (if it weren't cached, that is).

I fire off the request! The API notices that one of the asset IDs does not belong to us (but did, just a minute ago), invalidates the whole request and throws an error.

I have no idea which asset ID failed; could be just one, could be more if a fleet undocked or something. All I can do now is divide & conquer.

OK, thats what I thought you meant. Your wording previously just made me a little confused, sorry.

I will have a look at this ASAP, I think I know why it was done but have a better idea for fixing what it tried to fix.

Speaking of that. My way around it is making a lot of 1 item calls. I have 20 calls to single items every 10 minutes on CRON (so keeping well under 32 per second as the job itself takes about 5 seconds on avarage to compleete it could be increased to a 100 calls per job, but my assets have less than 1000 entries for named objects, so i dont mind going slow on this). Initially I populated my corp assets DB with name values until i only got errors for the rest. Then my CRON job is doing the job of populating whatever new shows up in my assets DB. It also updates names if they change (my script takes oldest 20 entries in terms od time of name checking, and all new items have date set to 0, so if less than 20 new items shows up in DB whatever if left goes to updating the names of existing items and updating time of name checking).

If i get error I also update the time of name checking, so this item is not checked again until it turn comes around. It have a lot of downsides and its not perfect in any means, its just a way to always get names for things that are in assets and dont have to worry that api return error for whole call.

Yeaaaaaa the fact that you are having to do things like that is just... /face_palm

Yeaaaaaa the fact that you are having to do things like that is just... /face_palm

Also - btw what XYZ coordinates means exactly? Are those XYZ coords inside the system or inside the grid or what? Are those exactly the same for a ship and SMA that it is stored in? I need to check that, never bothered to use Locations API other than for names

CCP FoxFour: GÖÑGÖÑGÖÑGÖÑGÖÑ for all the API GÖÑ

Unable to even get api.testeveonline.com to come up...keeps timing out.

it keeps redirecting to the main eveonline.com site

nevermind...

goto http://community.testeveonline.com/support/api-key to create your keys

although that site never comes up...

You need to already have an API key. community on testeveonline.come is not running. Sorry.

Would it be possible to get the dates into ISO format, like the rest of the API does? That is, the YYYY-MM-DD HH:MM:SS format.

Will our tranquility keys work?

They are not! /derp! Well thats dumb dumb of me. Todays a day off here but I was going to go into the office anyways. I will try and see if I can figure out whats up with that. Sorry!

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

1 is easier to handle, rather than having to maintain a list of what you asked for, and knocking bits off it to see what's left.

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

1 is easier to handle, rather than having to maintain a list of what you asked for, and knocking bits off it to see what's left.

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

Possibly. Depends when you made them. Give them a try. When TQ gets mirrored to Sisi that includes the API keys.

Looks like they expire them when the mirror is done...I tried a non-expiring key, and it told me it was expired.

Do the same thing you do when someone provides an invalid ID for anything else...

Add a new API Error Code in the 100 series, "Invalid **** Id specified", and return that whenever the ID is invalid

or, if you tried to pass an ID to which you do not have access to (such as it belongs to another person/corp's PI)
Add a new API Error Code in the 200 series, "Id does not belong to account"

I don't think our error handling really supports saying WHAT failed.

****... sorry. :(

errorCode="107" errorText="Invalid beforeRefID provided."
errorCode="213" errorText="Character must have Factory Manager role."

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

In any case, it's just fluff; 0,0,0 is detectable and works.

While I agree that it's fluff, it also raises some rather hairy and uncomfortable memories of unexpected and unexplainable errors crashes caused by Ye Olde "let's indicate error by returning a value that never ever will be valid (at least not in the current design and according to what we know now)".

Some explicit "this line is false/failed" can't be that much more expensive and far safer.

And besides, the latter is "Good Design", instead of "it effing works doesn't it?" ;)

Well, the x/y/z attributes would have to have SOMETHING there, but yeah -- I agree.

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

The second option is more sane. Comparing the list of IDs requested and IDs returned is trivial, if needed. Often, one does not even need to know any items failed, just process what was returned. The first option has the possibility of biting someone in the future.

Imagine, someone that doesn't know that the API treats invalid IDs by returning an empty name. Now, imagine the same person looking through all the empty names in his database. That person attempting to diagnose this would have no idea what would be causing this, even by looking at the XML returned by the API.

My reasoning for it, and this maybe isn't a good reason, is that thats how we handle invalid things on our other endpoints. Give a bad ID to the eve/OwnerName endpoint It just returns blanks but still returns that ID.

OK, I have a fix for the locations endpoint shitting itself when an invalid ID is supplied. The question is which would you guys prefer.

1) Return the invalid items with blank name, and 0's for X, Y, Z
2) Drop invalid items from the return all together.

Let me know which you think would be better. :)

The second option is more sane. Comparing the list of IDs requested and IDs returned is trivial, if needed. Often, one does not even need to know any items failed, just process what was returned. The first option has the possibility of biting someone in the future.

Imagine, someone that doesn't know that the API treats invalid IDs by returning an empty name. Now, imagine the same person looking through all the empty names in his database. That person attempting to diagnose this would have no idea what would be causing this, even by looking at the XML returned by the API.

Is it? I can't find a consistent handling of ID errors across the API.

Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

• [EVE API] Adding endpoints for PI to the EVE API
• [EVE API] /char/PlanetaryColonies added
• [EVE API] /char/PlanetaryPins added
• [EVE API] /char/PlanetaryRoutes added
• [EVE API] /char/PlanetaryLinks added
• [EVE API] All PI related endpoints require having access to the assets list
• [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
• [EVE API] All PI related endpoints require a characterID be supplied
• [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*

This should all be live as soon as TQ is back from downtime.

Patch notes for todays deployment are up on the first page of this thread. Here they are as well though:

2014/04/29:

• [EVE API] Adding endpoints for PI to the EVE API
• [EVE API] /char/PlanetaryColonies added
• [EVE API] /char/PlanetaryPins added
• [EVE API] /char/PlanetaryRoutes added
• [EVE API] /char/PlanetaryLinks added
• [EVE API] All PI related endpoints require having access to the assets list
• [EVE API] All PI related endpoints, except colonies, require a planetID in the URL
• [EVE API] All PI related endpoints require a characterID be supplied
• [EVE API] *CCP FoxFour hopes he has not screwed up access requirements horribly*

This should all be live as soon as TQ is back from downtime.

It looks like /char/PlanetaryPins caches and serves the same result even if you supply different planetID values.

HAHAHAHAHA yes it would and I know why even at 2AM after a long night of drinking. I am very sorry about that and will see if I can get a fix out ASAP. That should actually be the case for all of them.

Idea: add expiration and account/character fields to api-creating uri
Description: something like api-key/CreatePredefined?accessMask=9830414/account/false/false

Can you change the returned HTTP status code to something more sensible than 000 when /char/killlog is exhausted? The .NET WebRequest/WebClient seem to be unable to deal with this, and won't even let me fetch the response body. 000 is a custom code for client-abort, and not part of any standard.

Returning 500 or 503 would make more sense.

I noticed the "columns" attribute in the rowset of PlanetaryPins mention "headRadius" but it is missing from the rows.
(also the columns don't mention longitude and latitude)

columns="pinID,typeID,typeName,schematicID,lastLaunchTime,cycleTime,quantityPerCycle,installTime,expiryTime,headRadius,contentTypeID,contentTypeName,contentQuantity

row pinID="1011768140479" typeID="2848" typeName="Barren Extractor Control Unit" schematicID="0" lastLaunchTime="0001-01-01 00:00:00" cycleTime="15" quantityPerCycle="21296" installTime="2013-08-25 17:07:49" expiryTime="2013-08-25 18:37:49" contentTypeID="0" contentTypeName="" contentQuantity="0" longitude="-3.11917281639712" latitude="-3.11917281639712"

I'm trying to access /char/PlanetaryColonies but it is returning an empty colonies rowset for both of my characters that actually have PI colonies. I'm using an API with all feeds on...

Anybody else had this problem?

Can the attribute "description" be added to /char/Medals.xml.aspx for the "currentCorporation" rowset? It is present in the "otherCorporations" rowset.

The legacy API keys granted access to /corp/Medals.xml.aspx, getting the description was easy and trivial from that endpoint. With the new customizable keys, it is not possible to get the medals' descriptions without a corporation key form a director or the CEO.

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint.

Our wormhole mapper software relies on this information to determine the current status of the systems we are connected to. I would very much like to keep this information in the API as the information it provides is essential for us.

Bloemkoolsaus wrote:

CCP FoxFour wrote:
as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint.


Our wormhole mapper software relies on this information to determine the current status of the systems we are connected to. I would very much like to keep this information in the API as the information it provides is essential for us.

+1. Speeds up WH content creation.

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

Our wormhole mapper software relies on this information to determine the current status of the systems we are connected to. I would very much like to keep this information in the API as the information it provides is essential for us.

And as such IT SHOULD BE DISCUSSED AT LEAST WITH WH REPRESENTATIVE ON CSM..

Our wormhole mapper software relies on this information to determine the current status of the systems we are connected to. I would very much like to keep this information in the API as the information it provides is essential for us.

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

What do you mean by status?

Hey guys,

as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it.

What do you mean by status?

What do you mean by status?

But I will admit that you will have a damn hard time convincing me of not doing it.

Also THIS =>

no, this is not a thing to discuss. For us ( wh pvpers) this intel is essential, we do need it everyday, its general channel to get information about pvp possibilities, so removing it...is like making PvE paradise for every cap group, and saying to PvPers: Hey guys, we do NOT care about you and your activities, we do not need you in wspace-go find other places for pvp. Before even thinking about removing this intel, remove local in some other areas, so we would have some place to leave, otherwise its just -11 accounts only from me.

Our wormhole mapper software relies on this information to determine the current status of the systems we are connected to. I would very much like to keep this information in the API as the information it provides is essential for us.

Sounds like bull. Does CCP hate wormholes? It keeps getting ****** with, for the worst.

Here we go: while I have to agree that from clearly technicall standpoint this is correct - we cant see kills data on map for wspace, removing this data affects wspace gameplay and should looked at from game design viewpoint.

In wspace we have to strugle with a lot of issues to get content. We leave in barelly working posses, have to roll for hours to get pvp content, heavly rely on third-party apps to do basic stuff like knowing our conection map.

Information about kills lessen some burden of rage-rolling for pvp as we caj faster assess if given system is promising we we shoul spend time and scan chain from it or close it and roll more.

Ofc one can say that kill data only show past kills and its not guaranted to have anyone logged in still in that chain but its a filter kind off thing, something that slightly ease out hard life of wspace. And as such IT SHOULD BE DISCUSSED AT LEAST WITH WH REPRESENTATIVE ON CSM.

Also - during ff you said that you are thinkimg about providing all killmails trough api. Soooo that contraditcs this change. If you will get greej light for km's then what you are sayijg is this: I will not tell you how many kills where in this system, but this is a list of all 23 of them.

RMTers finnaly paid a bill to CCP or what? just cant find another reason for CCP to do it

Is there a chance to get some timetable instead of "whenever I have time"? Would be nice to have time to test some existing tools so that people aren't suddenly left with broken mappers.

You should not break tools people have already written.

At the very least this is an issue for the CSM, because these endpoints are widely used.

But that's only because we (the whole dwellers) don't have a nice ingame, ccp made map.
The rest of the eve residents do have a map, in which case they can see the stats without a problem.

So to counter this problem we made our own maps, tools ander other whatnots
=>

And now you are telling us we wrote our maps with info we should not have?
Because it to powerfull? If that's really the case, maybe it should be removed from the game and not only whole space.

Come on think this over, we need this info as much as other eve players.
We even worked for it, unlike non whole residents, we fiddled, tinckerd and tried untill we had our own tools and maps.

don't take that away from us ccp.

Is taking all PvP out of wormholes and just making them PvE paradise isk printing factories really such a bad thing?

Think of how many more pvp ships nullsecers could afford...

Could we at least get some discussion as to the reasons behind you think it's a powerul tool and discuss it with our WH CSM rather than just removing a valuable tool from WH space?

It's hard enough to get content in WH space without you removing tools we use to help us find it...

This information helps only those who know how to access it, and it helps them in a dramatic way. This information is also counter to our design for WH space. This information is also primarily helpful to one group, the invaders while being incredibly counter helpful to the defenders.

So lets answer a few questions:



Your software relying on it is basically why we are doing this. This is information that you guys using software outside the game get a huge advantage over those who do not. CCP by design specifically did not include a map of WH space, and we specifically did not include this information in the client.

.

So then when will you be making an ingame map function that actually works. Why is it other parts of the game are allowed to pull this info and more like jump data. Why is it nullsec is allowed to use out of game tools like dotlan that are supported by CCP?

Do you really expect us to go back to pen and paper maps?

So lets answer a few questions:



Your software relying on it is basically why we are doing this. This is information that you guys using software outside the game get a huge advantage over those who do not. CCP by design specifically did not include a map of WH space, and we specifically did not include this information in the client.

Earlier we removed jumps for WH systems from the API. Removing this was something that should have been done then.

OMG! WTF dude... this is removing the KILL COUNT! This has NOTHING to do with your ability to generate maps with siggy and such. i don't know where this confusion is coming from but yea... no... keep making your maps, thats fine, I don't care. Thats cool and everyone at CCP, that I have talked to, is cool with that.

What we are not cool with is you guys have the number of pvp kills, pod kills, and NPC kills for systems and the historical information on that.

Big difference. But yea, guess you can go back to pen and paper if you want.

Null sec is allowed to because by design that information should be there. By design this information should NOT be in WH systems.

What we are not cool with is you guys have the number of pvp kills, pod kills, and NPC kills for systems and the historical information on that.

So your idea behind removing kill API data is because CCP's software design model is flawed and the people in charge do not want to spend money we pay you to play the game you developed that is missing client side code to display info you already have been tracking for 6 years. And your response is to remove this data from outside access so you don't have to spend money to fix the EVE client to show what the community has stepped up and done for you?

I think this is a prime example of why CCP as a company has continued to use it's own shortcoming as an excuse to avoid development expenses. Saying "We are removing it because we don't include it in the client" is a statement that should never be said to begin with.

So lets answer a few questions:


Your software relying on it is basically why we are doing this. This is information that you guys using software outside the game get a huge advantage over those who do not. CCP by design specifically did not include a map of WH space, and we specifically did not include this information in the client.