open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: The API Dev Blog Trilogy - Volume Two
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2]

Author Topic

Lucyna
Interstellar Killer Bee Enterprises
Posted - 2010.09.23 05:36:00 - [31]
 

Originally by: Zendoren
Originally by: CCP Explorer
Originally by: Shirley Serious
I think this answers a question I asked in probably the wrong forum.
You probably asked in the right forum there. We are not running out of space right now but we regularly recycle itemIDs, which we want to stop doing. Also, with Incarna we know we will be risking running out of 32-bit space, therefore we are deploying this now to enable Incarna.


So is this a step towards a way to distinguish BPOs and BPCs?


This.

We want to see more functionallity of reporting the game how it currently is. We want contract API, we want distinguishing of BPO and BPC, we want better wallet reporting, like shares, etc.

Snorre Sturlasson
Posted - 2010.09.23 05:57:00 - [32]
 

This is a good decision. I wondered already how CCP managed itemids with only 32bit. Remind that 32bit including only numbers from 0 to 4.2billion (unsigned). If one think about only the countless transactions every day in Jita it's not really much.

Xavier Linx
Posted - 2010.09.23 08:07:00 - [33]
 

Few things make me as happy as seeing work done on the Eve API.

Keep up the good work.

Bozenski
Minmatar
Posted - 2010.09.23 08:25:00 - [34]
 

Included in this reply, free of any additional charge, is the standardized look of approval for your copy/pasting needs: =D

Mono Loco
Posted - 2010.09.23 11:10:00 - [35]
 

Correct me if I am wrong, but as long as you (CCP) don't use IDs above the Int32-space applications won't break (?). So lifting all applications to tyrannis 1.2+ static exports and code changes may be delayed without breaking functionality until you (again CCP) run out of Int32-space for itemz?

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.09.23 12:49:00 - [36]
 

Originally by: Mono Loco
Correct me if I am wrong, but as long as you (CCP) don't use IDs above the Int32-space applications won't break (?). So lifting all applications to tyrannis 1.2+ static exports and code changes may be delayed without breaking functionality until you (again CCP) run out of Int32-space for itemz?


As I said in the blog it's application specific. I cannot really comment on code I do not know.


For example if you're working in a strongly typed language and your code is fetching an Int16 from a rowset and that ordinal is actually an Int32 in the SDE you will get errors regardless of the actual value.

On the API side all values are returned as XML elements. If the application is working with them all as strings and never casts them to anything you'll get no conversion exceptions. If you cast a value from a string to an x-bit type everything will be alright as long as the numeric representation of the string fits into those x-bits but as soon as it does not you'll get a conversion exception.

And that's the reason for this blog and why it is dedicated to this change alone. It's not up to us whether anything breaks or not. All we can do is give you timely heads-up. Wink

CCP Explorer

Posted - 2010.09.23 13:18:00 - [37]
 

Originally by: Mono Loco
Correct me if I am wrong, but as long as you (CCP) don't use IDs above the Int32-space applications won't break (?). So lifting all applications to tyrannis 1.2+ static exports and code changes may be delayed without breaking functionality until you (again CCP) run out of Int32-space for itemz?
Adding to CCP Prism X's reply above, then I would recommend that 3rd party application developers update their apps as soon as possible. You can update your apps right away even if you are then for a short period of time using wider data types then we are actually returning from the API.

Mynxee
Veto.
Veto Corp
Posted - 2010.09.23 20:42:00 - [38]
 

Nicely written blog, PrismX!


Receg
Tragedy.
Posted - 2010.09.24 07:31:00 - [39]
 

ಠ_ಠ

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2010.09.24 10:12:00 - [40]
 

Good blog.

And very good that we get a notification of such changes before they get released. This surely safes us from "WTF?" moments that happened when the wallet journal refID changed to 64 bit unnoticed in Apocrypha. Very Happy

Usul Atreides
Posted - 2010.09.24 19:26:00 - [41]
 

The forum compels me to disapprove.

I shall obey.

ಠ_ಠ

Yalluto
Gallente
Ascenda Group
Free EVE Alliance
Posted - 2010.09.25 03:12:00 - [42]
 

What is the standardized look of approval, I need that for my copying/pasting needs :)

I'm really glad that I stumbled upon this dev blog before starting my API app, will save me much time when I'm writing from scratch.

Verite Rendition
Caldari
F.R.E.E. Explorer
EVE Animal Control
Posted - 2010.09.28 06:38:00 - [43]
 

Edited by: Verite Rendition on 28/09/2010 06:39:35
Thanks for the heads up.

Just to be clear, when you say that locations are considered item IDs, does that include SolarSystemIDs as used by MapSolarSystems and the like? Basically I need to know whether future solar systems, constellations, and regions (if you do a Black Rise again) are going to be 32bit INTs, or if I need to tweak the influence map to use and store 64bit INTs there.

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2010.09.28 11:56:00 - [44]
 

Edited by: CCP Prism X on 28/09/2010 11:56:46
Originally by: Verite Rendition
Edited by: Verite Rendition on 28/09/2010 06:39:35
Thanks for the heads up.

Just to be clear, when you say that locations are considered item IDs, does that include SolarSystemIDs as used by MapSolarSystems and the like? Basically I need to know whether future solar systems, constellations, and regions (if you do a Black Rise again) are going to be 32bit INTs, or if I need to tweak the influence map to use and store 64bit INTs there.


In the SDE's mapSolarSystem the locationIDs will remain as 32-bit integers as mentioned in the Dev Blog. We will also ensure the data in that specific table will remain 32-bit. But as soon as the table has to accommodate shipIDs as locationIDs it will obviously return them as 64-bit, even though I just promised you that systemIDs will never exceed the 32-bit range, as other rows have to support 64 bit ints. Wink

Makes sense?

Edit: For proper closing of bold tag.

Verite Rendition
Caldari
F.R.E.E. Explorer
EVE Animal Control
Posted - 2010.09.28 21:14:00 - [45]
 

Originally by: CCP Prism X
Edited by: CCP Prism X on 28/09/2010 11:56:46
Originally by: Verite Rendition
Edited by: Verite Rendition on 28/09/2010 06:39:35
Thanks for the heads up.

Just to be clear, when you say that locations are considered item IDs, does that include SolarSystemIDs as used by MapSolarSystems and the like? Basically I need to know whether future solar systems, constellations, and regions (if you do a Black Rise again) are going to be 32bit INTs, or if I need to tweak the influence map to use and store 64bit INTs there.


In the SDE's mapSolarSystem the locationIDs will remain as 32-bit integers as mentioned in the Dev Blog. We will also ensure the data in that specific table will remain 32-bit. But as soon as the table has to accommodate shipIDs as locationIDs it will obviously return them as 64-bit, even though I just promised you that systemIDs will never exceed the 32-bit range, as other rows have to support 64 bit ints. Wink

Makes sense?

Edit: For proper closing of bold tag.
Yep. That's just the answer I needed. Thanks Prism X.Smile

Gehnster
Gallente
RED SUN RISING
Posted - 2010.09.30 16:02:00 - [46]
 

Any plans to change the format of the API to not have the root element inside of the root element anywhere?

Bloody Bolt
Posted - 2010.10.04 14:30:00 - [47]
 

I liked the most this part: "free of any additional charge, is the standardized look of disapproval for your copy/pasting needs: ಠ_ಠ" Very Happy


Pages: 1 [2]

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only