EVE Universe Static Data Export | EVE Online

EVE Universe Static Data Export

2014-02-14 - By CCP Nobody

“The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.” – Douglas Adams, The Restaurant at the End of the Universe

All systems have to be maintained, including the Universe – in this case the EVE Universe data. As was announced here in late January this change is now upon us.

What does this mean for the regular pod pilot? Players should not notice any difference what-so-ever. Well, except that the Starmap now loads up almost 2x faster than before. Code touching or using the EVE Universe data is everywhere, and a lot of that code has been refactored as a part of this move which brings joy to the Universe!

What does this mean for the 3rd party developers that have been using DATADUMPs from the old system? Well, no data has been changed, added or removed, so technically 3rd party developers don’t have to do anything right away. Some tables have been moved from the MS-SQL file to another file.

Why are you spending time on this? In the old systems this data was authored directly in the Database and most of the data only existed in the Database. In the new system the data is authored in files in our source control system together with our game code. Most of the data is then inserted again into the Database, when the server is updated. This gives us much more flexibility for changing EVE Universe data. This also gives us an opportunity to build the data correctly and not rely on authoring data that should be generated.

The new SDE can be found here.

The Gory Details

Certain tables have been removed from the static data export DATADUMP and moved into an sqlite database file called universeDataDx.db.

The changes are as follows:

dbo.mapDenormalize

Dropped from the DATADUMP and added into universeDataDx.db as mapDenormalize. This table has the same structure as before.

Major changes are:

  • The orbitIndex is now calculated based on the distance from the orbit object (instead of being authored by hand).
  • The orbitIndex change will result in name changes for objects that had incorrect orbit indices (e.g. Onsooh IX - Asteroid Belt 1 is now Onsooh IX - Asteroid Belt 3)
  • There might be some changes in the position data (x, y, z) but they should be small.
  • Test stations will no longer accidentally be added to the SDE :)
  • All items have a radius

dbo.mapRegions

  • Dropped from the DATADUMP and added into universeDataDx.db as mapRegions. This table has the same structure as before.

Major changes are:

  • There might be some changes in the position data (x,y, z and max and min) but they should be small.
  • There will be changes in the radius data since that data is now calculated from the min and max position values instead of being authored by hand.

dbo. mapConstellations

Dropped from the DATADUMP and added into universeDataDx.db as mapConstellations. This table has the same structure as before.

Major changes are:

  • The factionIDs are now propagated from the parent
  • There might be some changes in the position data (x, y, z and max and min) but they should be small.
  • There will be changes in the radius data since that data is now calculated from the min and max position values instead of being authored by hand.

dbo. mapSolarSystems

  • Dropped from the DATADUMP and added into universeDataDx.db as mapSolarSystems. This table has the same structure as before.

Major changes are:

  • The factionIDs are now propagated from the parent
  • There might be some changes in the position data (x, y, z and max and min) but they should be small.
  • There will be changes in the radius data since that data is now calculated from the min and max position values instead of being authored by hand.

dbo. mapLocationScenes

  • Dropped from the DATADUMP and added into universeDataDx.db as mapLocationScenes. This table has the same structure as before. Data is exactly the same.

dbo. mapLocationWormholeClasses

  • Dropped from the DATADUMP and added into universeDataDx.db as mapLocationWormholeClasses. This table has the same structure as before. Data is exactly the same.

dbo. mapCelestialStatistics

  • Dropped from the DATADUMP and added into universeDataDx.db as mapCelestialStatistics. This table has the same structure as before. Data is exactly the same.

dbo. mapJumps

  • Has been dropped from the DATADUMP and added into universeDataDx.db as mapJumps. This table has the same structure as before. Data is exactly the same.

dbo. mapSolarSystemJumps

  • Has been dropped from the DATADUMP and added into universeDataDx.db as mapSolarSystemJumps. This table has the same structure as before. Data is exactly the same.

dbo. mapConstellationJumps

  • Has been dropped from the DATADUMP and added into universeDataDx.db as mapConstellationJumps. This table has the same structure as before. Data is exactly the same.

dbo. mapRegionJumps

  • Has been dropped from the DATADUMP and added into universeDataDx.db as mapRegionJumps. This table has the same structure as before.  Data is exactly the same.

dbo. mapLandmarks

  • Has been dropped from the DATADUMP and added into universeDataDx.db as mapLandmarks.

The structure of this table has changed from having the following columns:

                landmarkID | landmarkName | description | locationID | x | y | z | radius | iconID | importance

Into having these columns:

                landmarkID | landmarkName | description | locationID | x | y | z | iconID

The reason for this change is that the radius and importance columns were only used for landmark authoring.

The most important thing to remember is you have plenty of time to change your tools because there is no new data in the universe dump!

That is all for now,

CCP Nobody