open All Channels
seplocked EVE Technology Lab
blankseplocked Static Data Export and Image export for Incarna 1.0
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2

Author Topic

CCP Stillman

Posted - 2011.07.07 20:02:00 - [1]
 

Here’s the Static Data Export and Image Export Collection for Incarna

Static data export:
http://content.eveonline.com/data/Incarna_1.0_43729_db.zip

Image export collection: Types:
http://content.eveonline.com/data/Incarna_1.0.1_imgs_Types.zip

Image export collection: Renders:
http://content.eveonline.com/data/Incarna_1.0.1_imgs_Renders.zip

Image export collection: Icons:
http://content.eveonline.com/data/Incarna_1.0.1_imgs_Icons.zip

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.07 21:54:00 - [2]
 

Any chance of an updated icon pack that contains the old folder/filename structure, together with the new icons?


Lupus Hekki
Caldari
Legio Carminatus
Posted - 2011.07.08 10:37:00 - [3]
 

I wonder when the fankit is released

Asteriade
Posted - 2011.07.09 13:31:00 - [4]
 

Something has changed on database items (invtype)?

Thx Stillman

Thart
U.K.R.A.I.N.E
SOLAR FLEET
Posted - 2011.07.10 14:56:00 - [5]
 

Looking for sqlite conversion.
Thanks in advance!

Zifrian
Deep Space Innovations
Posted - 2011.07.10 21:52:00 - [6]
 

Appreciate the update on the images but now all the Tech and Faction tags are missing? Maybe I'm not seeing something but I thought in a previous post that all items would have unique blueprint files but there aren't any T2/T3 version of the BP's in that file. Has there been a change? I had to go back and resurrect some old logic to get this to work again so it's not a huge deal but I'm trying to stay consistent as possible.

Thanks for any info.

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.11 05:10:00 - [7]
 

Yeah, something is seriously off with the Types dump. Looks like the missing types for starbase structure blueprints that I report got added, but even after that there are about 11k less images than the previous dump.

Philderbeast
Posted - 2011.07.11 08:58:00 - [8]
 

Edited by: Philderbeast on 11/07/2011 08:59:42
Edited by: Philderbeast on 11/07/2011 08:59:03
mysql datadump conversion
this is the conversion by Lupus Hekki, I'm just mirroring it for a bit faster download as its 166mb

please note I'm uploading this now it may take a while to become available.

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.11 16:04:00 - [9]
 

Since he hasn't posted them yet, here's links to Jercy's normal batch of conversions:

inca10-mysql5-v1.sql.bz2 MySQL 5 single file
inca10-mysql5-sql-v1 MySQL one file per table
inca10-pgsql-v1.sql.bz2 PostgreSQL
inca10-sqlite3-v1.db.bz2 SQLite3

CCP Punkturis

Posted - 2011.07.13 15:55:00 - [10]
 

The three links to the image exports in the original post have been updated. Please re-download. Hope our fix solves your problems Smile

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.13 19:55:00 - [11]
 

Someone needs to talk to the folks running the eve image server too, the three new Connections skills are missing the images:

3893 Mining Connections
3894 Distribution Connections
3895 Security Connections

All the Structure blueprints (groupID 1048), and pretty much all the blueprints for non-faction Starbase Structure blueprints.

Here is the list I previously bug reported.
https://bugs.eveonline.com/files/79767204440.TXT

wardson
Posted - 2011.07.13 22:24:00 - [12]
 

Originally by: CCP Punkturis
The three links to the image exports in the original post have been updated. Please re-download. Hope our fix solves your problems Smile


Dunno if it's a big favor or not, but is it possible to upp the versions of the zips too? The previous pack vas 1.0.1 too, yet it has fixes (and still needs some).

Thanks in advance Embarassed

CCP Explorer

Posted - 2011.07.14 11:57:00 - [13]
 

Originally by: wardson
Originally by: CCP Punkturis
The three links to the image exports in the original post have been updated. Please re-download. Hope our fix solves your problems Smile
Dunno if it's a big favor or not, but is it possible to upp the versions of the zips too? The previous pack vas 1.0.1 too, yet it has fixes (and still needs some).
Could you please give us more details on the "and still needs some" part?

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.14 13:16:00 - [14]
 

The icon export doesn't contain updated turret icons. And I miss the old format of the icon export Sad What was the reason for changing it?

The image server also needs updating with the new turret icons, as well as several missing items from the market (namely, apparel).

CCP Explorer

Posted - 2011.07.14 13:59:00 - [15]
 

Originally by: Vessper
The icon export doesn't contain updated turret icons. And I miss the old format of the icon export Sad What was the reason for changing it?

The image server also needs updating with the new turret icons, as well as several missing items from the market (namely, apparel).
The turrets are now in the Types and Renders exports.

We changed how the icons were stored and as a result we had to change the Icon export.

We are currently working on updating the Image Server.

I'll check into the apparels.

CCP Explorer

Posted - 2011.07.14 14:05:00 - [16]
 

Originally by: CCP Explorer
Originally by: Vessper
The icon export doesn't contain updated turret icons. And I miss the old format of the icon export Sad What was the reason for changing it?

The image server also needs updating with the new turret icons, as well as several missing items from the market (namely, apparel).
The turrets are now in the Types and Renders exports.

We changed how the icons were stored and as a result we had to change the Icon export.

We are currently working on updating the Image Server.

I'll check into the apparels.
Apparel is in the Types export and will be on the Image Server shortly.

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.14 22:31:00 - [17]
 

Great, now all the missing blueprint images are on the server.

But now all the T2/T3 items and blueprints are missing the T2 and T3 corner flags.

CCP Explorer

Posted - 2011.07.15 13:50:00 - [18]
 

Can you be more specific and provide us with a few examples? We think we know what might be wrong and are working on fixing that but they are certainly not all missing.

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.15 17:09:00 - [19]
 

Originally by: CCP Explorer
Can you be more specific and provide us with a few examples? We think we know what might be wrong and are working on fixing that but they are certainly not all missing.


Well, all the tags are missing from the Ships category (categoryID 6), none of them have the T2, T3 or Faction tags on them.

The following blueprint groups have the tabs missing:
384 Armor Hardener Blueprint
349 Armor Reinforcer Blueprint
162 Automated Targeting System Blueprint
127 Cargo Scanner Blueprint
401 Cloaking Device Blueprint
346 Co-Processor Blueprint
176 Combat Drone Blueprint
106 Cruiser Blueprint
140 Damage Control Blueprint
917 Data Miner Blueprint
487 Destroyer Blueprint
131 ECCM Blueprint
130 ECM Blueprint
503 Elite Industrial Blueprint
151 Energy Destabilizer Blueprint
147 Energy Transfer Array Blueprint
148 Energy Vampire Blueprint
133 Energy Weapon Blueprint
139 Fast Loader Blueprint
525 Freighter Blueprint
218 Heat Sink Blueprint
158 Hull Mods Blueprint
143 Hull Repair Unit Blueprint
154 Hybrid Weapon Blueprint
727 Mining Crystal Blueprint
177 Mining Drone Blueprint
134 Mining Laser Blueprint
166 Missile Blueprint
136 Missile Launcher Blueprint
371 Mobile Warp Disruptor Blueprint
161 Passive Targeting System Blueprint
137 Power Manager Blueprint
135 Projectile Weapon Blueprint
787 Rig Blueprint
120 Shield Booster Blueprint
118 Shield Extender Blueprint
157 Shield Hardener Blueprint
119 Shield Recharger Blueprint *
121 Shield Transporter Blueprint *
128 Ship Scanner Blueprint

Those are all the blueprint groups that have T2 or faction prints that are missing the tabs. The two groups marked with an asterisk have bad renders for the 32px icons, the tab is there, but has been resized so that it's 8x8px and not 16x16px as it should be.




CCP Explorer

Posted - 2011.07.15 17:14:00 - [20]
 

This should be fixed now, please recheck and let us know if you find further problems. The issue was that during rendering then the meta-group overlay (the T2 / T3 / faction / officer flag or tab) would sometimes not be the top layer and was thus obscured by other elements such as the blue BP overlay or the nebula background.

This file has been re-uploaded with new content

Image export collection: Types:
http://content.eveonline.com/data/Incarna_1.0.1_imgs_Types.zip

and the Image Server has been updated.

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.15 20:06:00 - [21]
 

Looks good now. Kudos for the responsiveness and quick reaction on this issue. I know the tabs are a relatively new addition to the images, but they look so spiffy that they're missed when absent now. Very Happy

CCP Explorer

Posted - 2011.07.15 20:44:00 - [22]
 

Originally by: Ruziel
Looks good now. Kudos for the responsiveness and quick reaction on this issue. I know the tabs are a relatively new addition to the images, but they look so spiffy that they're missed when absent now. Very Happy
Thank you and sorry about the issues.

Again, if anyone finds something broken in the Static Data Export, in the Image Export Collection or in the Image Server (including alliance logos and NPC faction and NPC corporation logos (semi-static and static data) but excluding character portraits and player corporation logos (dynamic data)) then please let us know in this thread.

Murnock Loran
Posted - 2011.07.17 12:05:00 - [23]
 

Edited by: Murnock Loran on 18/07/2011 20:35:22
Edited by: Murnock Loran on 17/07/2011 12:17:16
Hi fellow spreadsheets in space people!

Perhaps it is just me, but I gave the inc_1.0_43729 db dump a try and noticed that the foreign key constraints involving the table eveNames and the two new tables eveOwners and eveLocations are having issues.

IN THE SQL SCRIPT that comes with the dump the table eveNames' definition starts with

Quote:

CREATE TABLE dbo.eveNames
(
itemID int,
[...]



the FKC links it to the table invItems

Quote:
ALTER TABLE eveNames ADD CONSTRAINT eveNames_FK_item FOREIGN KEY (itemID) REFERENCES invItems(itemID)


but the table invItems is defined as

Quote:
CREATE TABLE dbo.invItems
(
itemID bigint NOT NULL,
[...]


so we have a type clash here int vs. bigint.ugh

The new table eveOwners is, despite being described as subset of eveNames, defined as

Quote:
CREATE TABLE dbo.eveOwners
(
ownerID int NOT NULL,
[...]
typeID smallint NOT NULL,



I do dimly remember a DevBlog from CCP Creber Cattus around 22.10.2010 annoucing the refactoring the inventory system in the game to use 64-bit numbers. That was a few weeks after TYRANNIS 1.2 was released. The ChangeLog of the static DB dump states for the TRYRANNIS 1.2 release, that the field typeID was changed from smallint to int.

The table eveOwners is linked to the tables invTypes, invItems, agtAgents, chrFactions, crpNPCCorporations:

The FKC

Quote:
ALTER TABLE eveOwners ADD CONSTRAINT eveOwners_FK_owner FOREIGN KEY (itemID) REFERENCES invItems(itemID)



refers to a field itemID, but eveOwners only has (probably renamed) ownerID.

Quote:

ALTER TABLE eveOwners ADD CONSTRAINT eveOwners_FK_type FOREIGN KEY (typeID) REFERENCES invTypes(typeID)
ALTER TABLE agtAgents ADD CONSTRAINT agtAgents_FK_agent FOREIGN KEY (agentID) REFERENCES eveOwners(ownerID)
ALTER TABLE chrFactions ADD CONSTRAINT chrFactions_FK_faction FOREIGN KEY (factionID) REFERENCES eveOwners(ownerID)
ALTER TABLE crpNPCCorporations ADD CONSTRAINT crpNPCCorporations_FK_corporation FOREIGN KEY (corporationID) REFERENCES eveOwners(ownerID)


As everything in eve is an "item" having mixed types for the same IDs is not good.

invTypes.itemID int
invItems.itemID bigint
agtAgents.agentID int
chrFactions.factionID int
crpNPCCorporations.corporationID int

eveLocations.locationID is however again of type bigint.
agtAgents.locationID is however of type int.

IN THE DUMP itself the types are alike as in the script. The table eveLocations has 6824084 rows and the table invItems has 6847187 rows. The largest IDs are 81000107 for the field locationID and 61000006 for the field itemID. So we should still be fine with 32 bits. It seems that the 64bit IDs have now crept into the static database dump. As the static dump only holds a fraction of the whole EVEDB dataset the IDs of the static dump were changed from 16 bit to 32 bit IDs with TYRANNIS 1.2 (as noted in the changelog), while the live game db already used 64 bit IDs.

However there are more strange ID mismatches:
The largest typeID in invTypes is 32697,
The largest used typeID in invItems is 32698, appearing seven times for the items with itemIDs
81000089, 81000090, 81000091, 81000093, 81000094, 81000095, 81000096.

All this makes me feel a little bit uneasy to use the dump, as I just poked in the dump for a few minutes and I'm afraid what lurks below.

I find it striking that there are such things to be found in a dump from a live database. With all the db technology involved to keep the db in a consistent state, "dangling pointers" like the ones above, should be avoided, or at least detected. But perhaps it's just that CCP Wranglers famous quote:

Quote:
EVE is a dark and harsh world, you're supposed to feel a bit worried and slightly angry when you log in, [...].


applies to the db as well. Twisted Evil

Fly safe! or better dig

Eugen Auberle
Posted - 2011.07.20 18:58:00 - [24]
 

Edited by: Eugen Auberle on 20/07/2011 19:07:10
Will the icon imgs be as they are?
for items with id in name is rl nice thx.
my problem is for market tree. why u have the img size in the middle of the icon name Rolling Eyes would be much much easier and less coding when size is pre or post set in name like 14_11_32 and not 14_32_11 as it is now. (i know its easy to code, but in my eyes not needed steps)
EDIT: what i found atm is more stress ^^. f.e. ORE Icon for market is in db icon id 1277 and iconFile 23_05. The new img has the name 23_64_5 in icons\items folder. so 0 to cut out to. must that be? ^^
or im in some confusing stupid mistake with the db?

Almir Kadric
Posted - 2011.07.22 20:13:00 - [25]
 

I may have found a bug in the database.

When you lookup RAM requirements for invention, the Data interface comes up as consumable (damagePerJob > 0)

Which get's me thinking, is the server hard coded to automatically spit this out when installing an invention?

For some context into what I'm doing: I'm building a website which compares the production costs of different BPO's among other things (production time, income per hour etc) based on the market of a region or system.

Here's an SQL Query example which I used to get the data I mentioned above.

<BEGIN SQL>
SELECT InventionRequirements.*, RequiredItem.groupID, RequiredItem.typeName FROM ramtyperequirements AS InventionRequirements

LEFT JOIN invblueprinttypes AS ItemBlueprint ON ItemBlueprint.blueprintTypeID = InventionRequirements.typeID
LEFT JOIN ramtyperequirements AS RamRequirements ON RamRequirements.requiredTypeID = ItemBlueprint.productTypeID
LEFT JOIN invblueprinttypes AS InventionOutcome ON InventionOutcome.blueprintTypeID = RamRequirements.typeID
LEFT JOIN invtypes AS RequiredItem ON RequiredItem.typeID = InventionRequirements.requiredTypeID

WHERE RamRequirements.typeID = 11401 AND InventionRequirements.activityID = 8 AND InventionRequirements.damagePerJob > 0;
<END SQL>

If I am supposed to just hard code the ignoring of the consumption of data interfaces by invtypes.groupID I guess I will (even though its a little ugly in code) however it does raise some alarms on what CCP is doing in game O_O

But odd's are I missed something in the database ;p

Almir Kadric

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.22 20:23:00 - [26]
 

Originally by: Almir Kadric
I may have found a bug in the database.

When you lookup RAM requirements for invention, the Data interface comes up as consumable (damagePerJob > 0)

Which get's me thinking, is the server hard coded to automatically spit this out when installing an invention?

For some context into what I'm doing: I'm building a website which compares the production costs of different BPO's among other things (production time, income per hour etc) based on the market of a region or system.

Here's an SQL Query example which I used to get the data I mentioned above.

<BEGIN SQL>
SELECT InventionRequirements.*, RequiredItem.groupID, RequiredItem.typeName FROM ramtyperequirements AS InventionRequirements

LEFT JOIN invblueprinttypes AS ItemBlueprint ON ItemBlueprint.blueprintTypeID = InventionRequirements.typeID
LEFT JOIN ramtyperequirements AS RamRequirements ON RamRequirements.requiredTypeID = ItemBlueprint.productTypeID
LEFT JOIN invblueprinttypes AS InventionOutcome ON InventionOutcome.blueprintTypeID = RamRequirements.typeID
LEFT JOIN invtypes AS RequiredItem ON RequiredItem.typeID = InventionRequirements.requiredTypeID

WHERE RamRequirements.typeID = 11401 AND InventionRequirements.activityID = 8 AND InventionRequirements.damagePerJob > 0;
<END SQL>

If I am supposed to just hard code the ignoring of the consumption of data interfaces by invtypes.groupID I guess I will (even though its a little ugly in code) however it does raise some alarms on what CCP is doing in game O_O

But odd's are I missed something in the database ;p

Almir Kadric



It has been that way for a while. What I do, and so does a corp mate who writes an app that uses the db, is just change our copies of the DB for this issue.

the the MySQL version:
UPDATE ramTypeRequirements r
INNER JOIN invTypes i ON i.typeID = r.requiredTypeID
SET damagePerJob = 0
WHERE r.activityID = 8
AND i.groupID = 716;

Ruziel
Minmatar
Twilight Military Industrial Complex
Posted - 2011.07.22 20:26:00 - [27]
 

Originally by: Eugen Auberle
Edited by: Eugen Auberle on 20/07/2011 19:07:10
Will the icon imgs be as they are?
for items with id in name is rl nice thx.
my problem is for market tree. why u have the img size in the middle of the icon name Rolling Eyes would be much much easier and less coding when size is pre or post set in name like 14_11_32 and not 14_32_11 as it is now. (i know its easy to code, but in my eyes not needed steps)
EDIT: what i found atm is more stress ^^. f.e. ORE Icon for market is in db icon id 1277 and iconFile 23_05. The new img has the name 23_64_5 in icons\items folder. so 0 to cut out to. must that be? ^^
or im in some confusing stupid mistake with the db?


If I had to guess, it's probably an error with how the filenames are generated for the latest dump. It makes absolutely no sense to have the size in the middle, someone probably swapped two variables in whatever script/program they are using to generate the image dump.


P.S. Explorer, the Tempest (typeID 693) type icon has a bugged render:
http://image.eveonline.com/Type/639_64.png
http://image.eveonline.com/Type/639_32.png

Almir Kadric
Posted - 2011.07.23 10:06:00 - [28]
 

Originally by: Ruziel
Originally by: Almir Kadric
I may have found a bug in the database.

When you lookup RAM requirements for invention, the Data interface comes up as consumable (damagePerJob > 0)

Which get's me thinking, is the server hard coded to automatically spit this out when installing an invention?

For some context into what I'm doing: I'm building a website which compares the production costs of different BPO's among other things (production time, income per hour etc) based on the market of a region or system.

Here's an SQL Query example which I used to get the data I mentioned above.

<BEGIN SQL>
SELECT InventionRequirements.*, RequiredItem.groupID, RequiredItem.typeName FROM ramtyperequirements AS InventionRequirements

LEFT JOIN invblueprinttypes AS ItemBlueprint ON ItemBlueprint.blueprintTypeID = InventionRequirements.typeID
LEFT JOIN ramtyperequirements AS RamRequirements ON RamRequirements.requiredTypeID = ItemBlueprint.productTypeID
LEFT JOIN invblueprinttypes AS InventionOutcome ON InventionOutcome.blueprintTypeID = RamRequirements.typeID
LEFT JOIN invtypes AS RequiredItem ON RequiredItem.typeID = InventionRequirements.requiredTypeID

WHERE RamRequirements.typeID = 11401 AND InventionRequirements.activityID = 8 AND InventionRequirements.damagePerJob > 0;
<END SQL>

If I am supposed to just hard code the ignoring of the consumption of data interfaces by invtypes.groupID I guess I will (even though its a little ugly in code) however it does raise some alarms on what CCP is doing in game O_O

But odd's are I missed something in the database ;p

Almir Kadric



It has been that way for a while. What I do, and so does a corp mate who writes an app that uses the db, is just change our copies of the DB for this issue.

the the MySQL version:
UPDATE ramTypeRequirements r
INNER JOIN invTypes i ON i.typeID = r.requiredTypeID
SET damagePerJob = 0
WHERE r.activityID = 8
AND i.groupID = 716;



Yeah I just modified my SQL statement to contain the condition "RequiredItem.groupID != 716"

Don't consider it good practice to change their data, because if I were ever to restore the data again I would probably lose track of it and it would take me a while to figure out my calculations were all messed up. BAD PRACTICE!

Plus my additional condition is very future proof as well, since if they change the data no change would occur.

THANKS A LOT FOR THE HELP ^_^

Look forward to EVECQ.COM getting finished ^_^

Almir Kadric
Posted - 2011.07.24 07:28:00 - [29]
 

Is it just me or are all the T2 ore invtypematerials entries wrong?

It seems all the material types 34 - 40 are actually an addition of T1variant material requirements plus it's own. ALSO even contains some materials which shouldn't be there (such as zydrine for wolf)

Has this been this way for a while? or is this something that was missed or broken with a script? What's the best way to correct this?

Jercy Fravowitz
School of Applied Knowledge
Posted - 2011.07.25 09:43:00 - [30]
 

Originally by: Almir Kadric
Is it just me or are all the T2 ore invtypematerials entries wrong?

just you.

see post 30++ here.


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