EVE Technology Lab

(Be warned bad syntax, spelling, grammar follows since Im both typing this on my tablet after dipping into the vodka)

Im not buying the infamous line myself either, here's my reasoning for it.

1
Even with x y z coordinates it wouldn't do anything other than tell us stuff is somewhere around over there (not to also mention that since this statement such safeapots have all been either moved or deleted by ccp)

2
We still have to probe someone at the safe spot unless we also have a bookmark in game. last I checked wrecks/cans where still not probeable (is that a word?)
with just x y z coordinates we still can't magick them into bm's unless someone proceeds to hack the games bookmark server (unleashing all kinds of dev aggro)

3
this would be for a corporate api key not a world accessible xml like the alliance listings.
If someone gets it that shouldn't have it it means YOU gave the key to someone you shouldn't have.

Bottomline even with x y z in the api not alot can be done outside of cooler tools from third party devs.


No i think simply that this is a problem mainly faced by larger scale wormhole operations, inow a very small amount of corporations in eve, and I didnt go into w space to have it easy., neither would I expect nor want special treatment.
(a couple of statues and our names remebered in song would be nice)
Not to mention ccp has had bigger problems to fix since incarna than this.

I promised a resolution from itemID to (x,y,z) coordinates at Fan Fest 2011 and have yet to deliver. My shame would make the Marquis de Sade blush.
I've just started resolving API defects again now so stuff is finally happening.

It will probably end up under both /char/ and /corp/ as characters might want to query the location of anchored containers or whatnot. Input on a similar form to the CharacterName call, a CSL of IDs.

This is all pending approval from other parties who might think that this data should not be exposed to the players at large. I doubt that as we did discuss this on FF11 but I'd rather announce the caveat as it is better to be safe than sorry. Also, I'm not sure on my available QA resources at the moment so deployment might be delayed.

I'm one of those kinda developers that'll push back a deadline to get it right, instead of fast. ;) You guys have been great this past expansion, so keep up the good work! Not to mention its the holidays, so, I kinda didn't expect a "Get right on it" kinda thing. ;)

I know its a WIP but could you give a potential example of what we're looking at querying, and maybe offer suggestions?

Myself, I wouldn't mind having the XYZ in the asset list, but some don't want it. If another API comes up, why not just have a list of all anchored items (One for /corp and one for /char) with just the ItemID and XYZ, then we can cross reference against ItemID?

Would there actually be a reason to grab personal anchored items in space, aside from jet cans?

Is itemName the actual name of the object in space such as "My POS Structure" or is it going to be 'factory default' of "Corporate Hangar Array"?

Can the option of excluding the IDs on the URI provide all items out in space?

If an ids is given to an object that is not in space
- Would anything be returned?
- Is the itemName the in-game name of the item, such as a ship name?

That said, since we're querying itemID's anyway, will this also allow us to query an itemID that is not actually in space to get the personalized name? Or will this just be for items in space? Either would be fine, but the first would be awesome

An items name is his actual name, what you refer to as "factory default" I call "type name".


Absolutely not.


Something will be returned, yes. Otherwise you couldn't get names of docked ships belonging to the key. How that will be handled I have yet to decide. If returning all coordinates as 0 does incurr some overhead I haven't anticipated already then that will probably be it. I don't really see a very useful usecase for querying the coordinates of ships anyways, caching will cause them to be pretty damn inaccurate if it is moving. Blah blah blah, next question!


It is of course possible. However I wont do that, we already have a weird way of getting the typeName from CharacterName and people should not be querying static stuff over the wire (with the exception of mobile apps who might have too limited storage to keep their own type information). There is no way of getting an itemID to query the location of without getting the typeID back and there's no point for me to embiggen the return set for some weird special case.

Think that should cover all questions.

On a more serious note it is very dark, cold and slushy over here in Iceland.

How about what? There's nothing wrong with a types name being a part or the entirity of an items name. We're also not going to be changing any rules regarding what you can and cannot rename.

What's the confusion here?

Correct, if you cannot rename the item you'll be stuck with the default name. You wouldn't be able to differentiate between them in the client either by just looking at them (except by position, which you'll get returned to you albeit in a less visual form).

So I went to write a huge post about why the ids COULD be excluded, but I kind of kicked my own ass thinking about the problem and decided it'd be a moot point.

I was surprised with the "Absolutely not" statement, and wrote the post in NOTEPAD cuz I know how this forum loves to drop all my text on long winded posts. However, I kind of ended up working out the problem at this end anyways.

Typically with this call, the first time through populating the EVE Application database, you'd hit a heavy toll on the API server making requests. I remembered that URL calls can only be of a certain length, but this is dependent on the client, and the server SHOULD be able to handle any URL length. SHOULD. I don't know how CCP has the API server setup to handle long URL calls if this becomes an issue, but it might be client side.

So that got me to thinking about exactly what kind of data I'd be querying and how often it'd change (In my case).

At least two questions;

1> If an object in space, say, a research station, is shut down, unanchored, moved, then when redeployed/reanchored, does that station get a new itemID?

2> Are the cache timer and ids URI linked?

If a new ID is given, then really, I'd be happy with an XYZ report based on the 23 hour cache simply because if I find a new list of itemIDs with a locationID being that of a solarSystemID, I just prepare a URL query and fire it to the API server and work through the results, and never make a query about that particular itemID again.

However, if new itemIDs aren't given to the station, then it'd be a daily/weekly poke at the server to ensure proper locations. This is where the question with the cache timer and ids being linked come in.

If they aren't linked, then I would assume that means that I can only poke /corp/Locations once during the cached period regardless if I provide new ids.

If they are linked, is the cached timer based on the ids URI as a whole, or, do I get a new cache timer if I provide a new set of itemIDs?

As for the tune (Which I've played on repeat for the past couple hours); http://images.ctv.ca/archives/CTVNews/img2/20120102/600_snow_squalls_120102.jpg - Your idea is MUCH better than what I had to deal with here a couple days ago. Fortunately I avoided this particular highway and went the backway, but, still was a rather "entertaining" drive if your sadistic enough.

You can be fairly certain I'll have a solar system mapper out within a week of CCP releasing this ^^ as to querying names of items not in space, hell yeah!

Edit: I think someone meant all items out in space owned by the key owner, not ALL items out in space. This might still be impossible due to performance reasons though.