These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
12Next page
 

SDE and IEC for Crucible

First post
Author
CCP Stillman
C C P
C C P Alliance
#1 - 2011-12-06 15:03:59 UTC  |  Edited by: CCP Prism X
Greetings,

Sorry about getting to you this late. The first SDE had a few issues, which should now be fixed. Smile

Here's the SDE and IEC for Crucible:

Static Data Export

IEC Types
IEC Renders
IEC Icons


-Stillman

Just a random dude in Team Security.

David Magnus
#2 - 2011-12-06 16:03:47 UTC
Awesome!
Thank you very much!

http://soundcloud.com/davidkmagnus/fight-us-maybe

http://soundcloud.com/davidkmagnus/winterupdate

http://soundcloud.com/davidkmagnus/supercaps

http://soundcloud.com/davidkmagnus/pandemiclegion

Irijah Onzo
Caldari Provisions
Caldari State
#3 - 2011-12-06 22:02:05 UTC
Sweet! Thanks again!
Ruziel
Twilight Military Industrial Complex
#4 - 2011-12-07 02:42:14 UTC
CCP Prism X
C C P
C C P Alliance
#5 - 2011-12-07 08:40:42 UTC
The source and change log was missing in this original upload. This has been amended, but for the sake of people who do not feel like DLing the entire SDE again just for the change log here it is:


-- CHANGED IN CRUCIBLE

--
-- Removed table dbo.eveOwners
-- Removed table dbo.eveNames
-- Removed table dbo.eveLocations
-- Added table dbo.invNames
-- Added table dbo.invUniqueNames
-- Added table dbo.invPositions
-- The added tables are not fully compatible with the removed ones as EVE has decided to move away
-- from the item/owner/location paradigm.
-- dbo.invNames contains names of all static items with names.
-- dbo.invUniqueNames contains the names of all entities who have a unique name.
---- It is also seekable on the itemName itself and has a unique constraint on that key.
-- dbo.invPositions contains the (x, y, z) coordinate of static items.
--
--
-- Translation Changes:
-- LanguageID 'EN' changed to 'EN-US'
-- Added table dbo.translationLaguages for all languages that can be found in dbo.trnTranslations
--
--
-- Removed table agtConfig. All info it used to contain is now reflected in agtAgents.
---- Added bit column isLocator to agtAgents to signify wether the agent can locate characters or not.
--
-- Added Tables for Factional Warfare.
---- dbo.warCombatZones
---- dbo.warCombatZoneSystems
Desmont McCallock
#6 - 2011-12-07 11:50:27 UTC
Your action for the above post is the reason why I like you Prism X a bit more.

However,

CCP Prism X wrote:

-- Translation Changes:
-- LanguageID 'EN' changed to 'EN-US'
-- Added table dbo.translationLaguages for all languages that can be found in dbo.trnTranslations


you realize that there is a spelling error on the table name and further more why is it empty?
Pizzutz
Aliastra
Gallente Federation
#7 - 2011-12-07 14:57:37 UTC
Thanks so much for getting this to us.

Will we be getting an updated invControlTowerResources table when the fuel block switchover happens, or will the fuel resources be managed a different way?
TorTorden
Tors shibari party
No Holes Barred
#8 - 2011-12-07 15:55:53 UTC
Since they will only use the one type of fuel, it could possibly just be in invtypes using raceid to figure what fuel type?

Personaly I would just prefer a table for it.
Pizzutz
Aliastra
Gallente Federation
#9 - 2011-12-07 16:22:19 UTC
Yes, but I still need to map each tower type to both a fuel block type and consumption amount, as well as a stront consumption amount. If needed, I can do it manually, but I'd rather not. Still, if I need to do it manually, I'd like to get started. I've asked in a few different threads, but no dev response yet. Hopefully I can get an answer soon before they break my pos tracker. :)
Desmont McCallock
#10 - 2011-12-07 19:52:16 UTC
Pizzutz wrote:
Yes, but I still need to map each tower type to both a fuel block type and consumption amount, as well as a stront consumption amount. If needed, I can do it manually, but I'd rather not. Still, if I need to do it manually, I'd like to get started. I've asked in a few different threads, but no dev response yet. Hopefully I can get an answer soon before they break my pos tracker. :)


No chance on that. Those guys, they brake first and then they fix (calling [once again] CCP Prism X to the rescue).
Luminocity
The Dark Revenants
PLEASE NOT VIOLENCE OUR BOATS
#11 - 2011-12-08 18:19:26 UTC  |  Edited by: Luminocity
MySQL singlefile conversion:
crucible1.0.58224-mysql5-v2.zip

Enjoy!

EDIT: Re-published as v2: Changed from InnoDB to MyISAM. Removed one key for translation tables which was of invalid length
CCP Prism X
C C P
C C P Alliance
#12 - 2011-12-09 08:38:39 UTC
Pizzutz wrote:
Thanks so much for getting this to us.

Will we be getting an updated invControlTowerResources table when the fuel block switchover happens, or will the fuel resources be managed a different way?


Yes, it seems we'll need to generate a new one for you once more. Ugh
I'm going to hunt down the people that did the Fuel Block stuff and pump them for information as to how exactly we're deploying this. I somehow assumed that it would not be done through controlled static data deployments but as far as I can gather that seems to be the case.

I'll also ensure that the API is up to the task although I'm expecting it will not require any changes.
Jarnis McPieksu
Aliastra
Gallente Federation
#13 - 2011-12-09 09:45:01 UTC  |  Edited by: Jarnis McPieksu
Could you also poke whoever is doing this Fuel Block malarky to COMMUNICATE.

We have holidays coming. POS runners would like to prepare but we have no info. Most POS runners assumed that the transition would come very soon after patch and prepared with 2-3 weeks of old fuel and started manufacturing blocks. Those stocks are being chomped up right now and still no word when blocks start to work.

If we can't get a date when blocks start to work, could we at least get a "Don't know yet the date, but absolutely not before X" guarantee if you already know this is not going to happen before the holidays? Would allow us to plan old style fuel supplies that last through December.

Edit: Personally I have already bought additional POS fuels - I can always make more blocks from them if they end up not being needed - but the uncertainty is due to logistics. My logistics are even fairly simple, I can't imagine how sucky the situation is for someone running POSes at the furthest deep end of 0.0...
CCP Prism X
C C P
C C P Alliance
#14 - 2011-12-09 13:55:59 UTC
I hear that Soundwave will be making an announcement regarding the fuel issue today.
If not, feel free to talk smack about Anime to him.
Desmont McCallock
#15 - 2011-12-09 17:57:20 UTC  |  Edited by: Desmont McCallock
Better late than never. Here are the SDE conversions.

MySQL 5.5 : cruc101-mysql5-innoDB-v1.7z

PostgreSQL 9: cruc101-pgsql9-v2.7z

SQLite 3: cruc101-sqlite3-v1.db.7z
Notice: Not compatible with EAM.

SQLite3 for EAM: cruc101-sqlite3-eam-v1.db.7z
Chibisuke
Children of Avalon
Avateas Blessed
#16 - 2011-12-10 12:40:50 UTC  |  Edited by: Chibisuke
The ores that are part of the asteroid belts are missing in this one.

Quote:

SELECT count(0)
FROM invItems ii
INNER JOIN mapSolarSystems mss
ON mss.solarSystemID = ii.locationID
INNER JOIN invTypes it
ON it.typeID = ii.typeID
WHERE solarSystemName = 'Malkalen' and typeName = 'Pyroxeres'

incarna dump:
result: 71

crucible dump:
result: 0

Is this intentional? and if it is, is there another way to get the ores that are located in a belt?
Zifrian
Aideron Robotics
#17 - 2011-12-11 22:23:16 UTC
Chibisuke wrote:
The ores that are part of the asteroid belts are missing in this one.

Quote:

SELECT count(0)
FROM invItems ii
INNER JOIN mapSolarSystems mss
ON mss.solarSystemID = ii.locationID
INNER JOIN invTypes it
ON it.typeID = ii.typeID
WHERE solarSystemName = 'Malkalen' and typeName = 'Pyroxeres'

incarna dump:
result: 71

crucible dump:
result: 0

Is this intentional? and if it is, is there another way to get the ores that are located in a belt?

I posted about this in the earlier thread and he said that they removed asteroids from invNames. I just made a generic table manually What?

Maximze your Industry Potential! - Download EVE Isk per Hour!

Import CCP's SDE - EVE SDE Database Builder

Zalmun
GoonWaffe
Goonswarm Federation
#18 - 2011-12-21 11:13:12 UTC
I'm attempting to use the Postgres conversion on a Postgres 9.0 install on Windows, using the command line interface to try to import:

psql EveOnline eve < cruc101-pgsql9-v1.sql

The import succeeds, but there appear to be no primary keys defined, or any other constraints. Is that normal? I don't remember having this problem with previous conversions (I think the last one I used was Incursion).

Anyone able to help me out?
Ikaef Giasep
Deep Core Mining Inc.
Caldari State
#19 - 2011-12-30 13:32:47 UTC
Luminocity wrote:
MySQL singlefile conversion:
crucible1.0.58224-mysql5-v2.zip

Enjoy!

EDIT: Re-published as v2: Changed from InnoDB to MyISAM. Removed one key for translation tables which was of invalid length


I received the following error while importing it

ERROR 1298 (HY000) at line 3583694: Unknown or incorrect time zone: 'NULL'

Any idea, what this could be?

Thanks!
Desmont McCallock
#20 - 2012-01-05 14:10:39 UTC
Zalmun wrote:
I'm attempting to use the Postgres conversion on a Postgres 9.0 install on Windows, using the command line interface to try to import:

psql EveOnline eve < cruc101-pgsql9-v1.sql

The import succeeds, but there appear to be no primary keys defined, or any other constraints. Is that normal? I don't remember having this problem with previous conversions (I think the last one I used was Incursion).

Anyone able to help me out?


As I'm currently learning to do DB conversions, some issues will arise.
Updated Postgres conversion with PK's.
12Next page