EVE Technology Lab

The invItems table seems to be incomplete (I hope). There are no asteroids in the table anymore.

This is from Incarna:
Select top 10 invTypes.typeName, invGroups.groupName
from invTypes, invItems, invGroups
where invTypes.typeID = invItems.typeID
and invTypes.groupID = invGroups.groupID
and invGroups.categoryID = 25
group by invGroups.groupName, invTypes.typeName

Returns:

Fiery Kernite Kernite
Pyroxeres Pyroxeres
Solid Pyroxeres Pyroxeres
Veldspar Veldspar
Condensed Scordite Scordite
Kernite Kernite
Viscous Pyroxeres Pyroxeres
Concentrated Veldspar Veldspar
Dense Veldspar Veldspar
Scordite Scordite

Same query in Crucible returns no rows.

I can only use sqlite export...

tried this one, and new t2 modules' material requirements are not the same as the ones shown in game for t2 bpo.

No, we sanitized a lot of stuff out of invItems, asteroids included.


Not very hot on releasing anything about our own internal structure of things. Not that obscurity is security but transparency isn't either.



I thought the changelog had mentioned that eveNames and eveOwners were now invNames and invUniqueNames as well as that eveLocations is now invPositions.

The dogma attributes missing names is probably due to our new translation system, will look at that.

Nah, I was linking this to the map tables by the location id in invitems to find out where certain asteroids spawned. So this was just a partial query.

I am talking about basic requirements like tritanium etc. besides t1 base module.

is it also modified to include t1's requirements? so I have to subtract i.e. tritanium needed for t1 module from t2's count?

I can understand the idea of not wanting to release internal structure details, and I don't THINK MS-SQL will export true SQL statements in any form, a simple VB script that connects, reads the table data you define, then exports sanitized SQL code isn't that hard to do. Many bonuses to doing it this way.

A> I don't have to have MS SQL installed anywhere.
B> Script kiddies writers can take the SQL code and modify it to whatever their DB preferences are
C> When you upgrade to the next version of MS SQL, we won't have to either
D> You can limit what tables are exported
E> If so inclined, any table that hasn't been changed doesn't need to be included in a new dump.

Downsides:
A> Table locking while data is exported - This'll hurt on larger tables, but this could be done on and mirrored server. However, if option E above is done and assuming the bigger tables may not be touched that often, may be a moot point.
B> Large export of data that has to live somewhere until its compressed

ok here is the example.

the new t2 gang links, according to the game, have the following common requirements:

106 tritanium
8 transmitter
0.5 RAM Electronics
6 nocxium -- except for skirmish
4 morphite
1 megacyte
13 isogen
1 hypersynaptic fibers
1 link I
3 nanotransistors
8 X microprocessor

These numbers might be a little off since they're possibly from invented BPC but they give the picture.

now let's see what we get form the export. I am using sqlite version so it might be outdated or wrong...

select (select typeName from invTypes where typeID=materialTypeID),quantity from invTypeMaterials where typeID=(select typeID from invTypes where typeName="Armored Warfare Link - Damage Control II" and published)
=> [(u'Tritanium', 939), (u'Isogen', 110), (u'Nocxium', 55), (u'Megacyte', 11), (u'Morphite', 3), (u'Nanotransistors', 22), (u'Hypersynaptic Fibers', 11)]

I am aware of the way RAMs are represented but they are not relevant here.

can someone check the output on the MSSQL with the recent export?

so the correct way is to subtract any matching t1 materials from t2 materials, in case there is a t1 consumed item in RAM list?

ok, thanks for the hint and sorry if it's an off topic.

Listen to Lutz. He has a PhD on the subject.

Any ETA for fixed SDE?