Pages: 1 2 [3] 4 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 17 post(s) |
Desmont McCallock
604
|
Posted - 2016.04.28 10:56:47 -
[61] - Quote
Bug report for data format inconsistency in invFlags table. |
Hel O'Ween
Men On A Mission
159
|
Posted - 2016.04.28 15:33:48 -
[62] - Quote
I've skimmed through the patch notes, but didn't find it mentioned somewhere, so I ask it here:
1) Which API provides the citadel's location? Would those be included in ConquerableStationList?
2) What "magic number(s)" - if any, is necessary for calculating the citadel's solar system from an asset's locationID?
EVEWalletAware - an offline wallet manager.
|
Pete Butcher
KarmaFleet Goonswarm Federation
326
|
Posted - 2016.04.28 15:42:43 -
[63] - Quote
Hel O'Ween wrote:I've skimmed through the patch notes, but didn't find it mentioned somewhere, so I ask it here: 1) Which API provides the citadel's location? Would those be included in ConquerableStationList? 2) What " magic number(s)" - if any, is necessary for calculating the citadel's solar system from an asset's locationID?
https://forums.eveonline.com/default.aspx?g=posts&m=6456723#post6456723
http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool + Trade Advisor
|
Hel O'Ween
Men On A Mission
159
|
Posted - 2016.04.28 16:55:38 -
[64] - Quote
Yeah, saw your thread, Pete, but as it hasn't got an answer, I thought I might menion it elsewhere (here) again.
Or are you implying with your post that the locations are indeed in crest.industry.facilities, as Mr. mac suggested there? If so, that would totally break EWA ... :-(
EVEWalletAware - an offline wallet manager.
|
Pete Butcher
KarmaFleet Goonswarm Federation
326
|
Posted - 2016.04.28 17:02:06 -
[65] - Quote
Hel O'Ween wrote:Yeah, saw your thread, Pete, but as it hasn't got an answer, I thought I might menion it elsewhere (here) again.
Or are you implying with your post that the locations are indeed in crest.industry.facilities, as Mr. mac suggested there? If so, that would totally break EWA ... :-(
Nah, I didn't know you've seen that topic. I still have no idea how to handle citadels.
http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool + Trade Advisor
|
Desmont McCallock
604
|
Posted - 2016.04.29 08:13:57 -
[66] - Quote
@CCP Tellus region.staticdata for each region is missing the radius. Are we supposed to calculate that from the given info? constallation and solarsystem staticdata files include that info however. |
|
CCP Tellus
C C P C C P Alliance
60
|
Posted - 2016.04.29 10:05:17 -
[67] - Quote
Desmont McCallock wrote:region.staticdata for each region is missing the radius. Are we supposed to calculate that from the given info? constallation and solarsystem staticdata files include that info however. You'll need to calculate the radius. It should be the Euclidean distance between the region's 'min' and 'max', divided by the square root of two.
|
|
Desmont McCallock
604
|
Posted - 2016.04.29 10:35:29 -
[68] - Quote
CCP Tellus wrote:Desmont McCallock wrote:region.staticdata for each region is missing the radius. Are we supposed to calculate that from the given info? constallation and solarsystem staticdata files include that info however. You'll need to calculate the radius. It should be the Euclidean distance between the region's 'min' and 'max', divided by the square root of two. Shouldn't the formula be radius = GêÜ((xMax - x)^2 + (yMax - y)^2 + (zMax - z)^2) ?
|
|
CCP Tellus
C C P C C P Alliance
60
|
Posted - 2016.04.29 10:44:23 -
[69] - Quote
Desmont McCallock wrote:Shouldn't the formula be radius = GêÜ((xMax - x)^2 + (yMax - y)^2 + (zMax - z)^2) ? The distance between 'min' and 'max' is the diameter. You should divide that by two to get the radius, but someone messed it up by putting the division by two inside the square root for each field. The end result is that you divide the diameter with the square root of two instead.
This is based on my understanding of quickly looking through the source that used to build the universe SQLite file. If the numbers don't check out, I'll take another stab at it for you. :) |
|
Desmont McCallock
604
|
Posted - 2016.04.29 10:55:27 -
[70] - Quote
CCP Tellus wrote:Desmont McCallock wrote:Shouldn't the formula be radius = GêÜ((xMax - x)^2 + (yMax - y)^2 + (zMax - z)^2) ? The distance between 'min' and 'max' is the diameter. You should divide that by two to get the radius, but someone messed it up by putting the division by two inside the square root for each field. The end result is that you divide the diameter with the square root of two instead. This is based on my understanding of quickly looking through the source that used to build the universe SQLite file. If the numbers don't check out, I'll take another stab at it for you. :) OK. I assumed that a region is a sphere so I had to calculate the distance from the center, which apparently is incorrect.
Fiddling around the formula becomes radius = (GêÜ((xMax - xMin)^2 + (yMax - yMin)^2 + (zMax - zMin)^2)) / 2. This gives me fairly the same numbers as the old universe format. Still need to figure out some rounding. |
|
Desmont McCallock
604
|
Posted - 2016.04.29 13:17:48 -
[71] - Quote
@CCP Tellus I'm afraid that there is something fundamentally wrong with the formula you use to calculate the radius.
According to known maths the radius of a sphere centered at the point (x0,y0,z0) derives from the following formula.
r^2 = (x-x0)^2+(y-y0)^2+(z-z0)^2 which is equivalent to r = GêÜ((x-x0)^2+(y-y0)^2+(z-z0)^2) From my understanding 'min' coordinates are the coordinates of the celestial closest to the center and 'max' coordinates are the coordinates of the celestial farthest to the center.
Using radius = (GêÜ((xMax - xMin)^2 + (yMax - yMin)^2 + (zMax - zMin)^2)) / 2 or even radius = (GêÜ(((xMax - xMin)^2 / 2) + ((yMax - yMin)^2 / 2) + ((zMax - zMin)^2 / 2))) / GêÜ2 (which is the formula you say you use) as the formula to calculate the radius seems wrong to me in two points.
1. The used formula is incorrect 2. The radius should be calculated from the center and not from the closest point to the center.
Am I wrong in my assumptions? |
|
CCP Tellus
C C P C C P Alliance
60
|
Posted - 2016.04.29 15:33:43 -
[72] - Quote
Desmont McCallock wrote:I'm afraid that there is something fundamentally wrong with the formula you use to calculate the radius. Sorry for all the confusion. Took a stab at this and this is what I get:
From the universe data SQLite file, we have that the radius is 5.57645447335415e+16.
sqlite> select regionID, regionName, radius from mapRegions where regionName = 'A821-A'; regionID regionName radius ---------- ---------- -------------------- 10000019 A821-A 5.57645447335415e+16
By letting x1, y1, and z1 be the region's 'max' coordinates, and x2, y2, and z2 be the region's 'min' coordinates, we get:
>>> math.sqrt((x1 - x2)**2 + (y1 - y2)**2 + (z1 - z2)**2) / 2 5.576454473354151e+16
This matches the radius of the region in the legacy SDE. It also turns out I was wrong about dividing by the square root of two. Terribly sorry. I should test code before reaching a conclusion. :(
Hope this helps. |
|
Desmont McCallock
606
|
Posted - 2016.04.29 15:48:50 -
[73] - Quote
My bad, it's indeed 5.57645447335415E+16 . My head was spinning and I posted the radius of Derelik. Will give it a try. |
Masao Kurata
Perkone Caldari State
485
|
Posted - 2016.04.29 15:56:08 -
[74] - Quote
That's a really strange definition of a "radius". That's half the diagonal of a cube. |
Desmont McCallock
606
|
Posted - 2016.04.29 15:56:26 -
[75] - Quote
Still I believe the formula is wrong.
math.sqrt((x1 - x2)**2 + (y1 - y2)**2 + (z1 - z2)**2) IS the Euclidean distance which IS the radius for a sphere. It shouldn't be divided by two and x2,y2,z2 should be the center coordinates and not the min ones.
Someone confused distance with diameter.
Never the less, even if it's wrong I guess it won't be fixed as it's been set to stones for years, right? |
|
CCP Tellus
C C P C C P Alliance
60
|
Posted - 2016.04.29 16:22:01 -
[76] - Quote
Desmont McCallock wrote:Never the less, even if it's wrong I guess it won't be fixed as it's been set to stone for years in the SDE, right? Pretty much.
|
|
Desmont McCallock
606
|
Posted - 2016.04.29 16:56:13 -
[77] - Quote
@ CCP Tellus
I can't match the numbers that the SDE had for the region radius. Probably because of the coordinates rounding or .NET has different implementation for math.sqrt than Python. Is it to much to ask to include the region radius info in the universe yaml file (region.staticdata)? It doesn't have to be this one. The next one maybe? |
Desmont McCallock
606
|
Posted - 2016.05.01 14:19:42 -
[78] - Quote
After 5 long days battling with the new SDE format I'm finally done. CCP Tellus I know I have become a pain in your bud but you had it coming (joking).
Here are my findings:
Errors - provide 'radius' info in region.staticdata for each region (already been discussed in this thread why it should be provided) - landmarks are missing landmarkName, description (instead their ID counterparts are provided) - constellation 'Tranquility' in Curse is named 'Tranquillity' (notice the double 'l') - constellation 'G-C00324' in G-R00031 is named 'G-C00311' (which is correct?) - solar system 'J170376' in 'C-R00015 > C-C00146' is named 'J140208' (which is correct?) - provide 'orbitIndex' info in order to be able to produce the correct itemName for mapDenormalize (mainly for asteroid belts and moons) - provide the special name of a celestial (sun, planet, moon etc) if exists (i.e. Uplingur IV (Ndoria), New Caldari I (Matigu), New Caldari III (Orieku), New Caldari V (Oniteseru)) - provide the npcStations name in order to be able to produce the correct itemName for mapDenormalize (please don't tell me that it can be found in staStations, legacy sde provided that without needing statStations)
Positive points - Landmarks iconID can be now placed in the correct column (in legacy SDE it's falsely placed in radius column) - mapCelestialStatistics 'pressure' info are more precise (it's truncated in legacy) - A lot more data is available in new SDE format (but I'll stick on providing what was in legacy for EVESDEToSQL, at least for now)
Questions - In legacy mapDenormilize table stargates and NPCStations have a number in radius. Where do we find that in the new SDE format? |
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
5984
|
Posted - 2016.05.01 18:12:13 -
[79] - Quote
All names are in invNames, so you can look them up, and insert them. This is for asteroid belts, moons, planets, stars, stations.
Radius and orbit index are, indeed, a bit of a pain. Though both can be calculated. (I need to work in the radius calculation)
Landmark descriptions are in trnTranslations now. (side effect of how the files are generated.)
The stargate Radius, I suspect, comes from typeIDs.yaml
I'm running again for CSM 11, and I'd appreciate your vote.
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
Desmont McCallock
607
|
Posted - 2016.05.01 18:27:43 -
[80] - Quote
Steve Ronuken wrote:All names are in invNames, so you can look them up, and insert them. This is for asteroid belts, moons, planets, stars, stations. Steve, sorry man but you don't get it. Universe data need to be independent as they always were. Use case? If someone wants to import only the universe data back to a DB, he ends up with missing data.Steve Ronuken wrote:Radius and orbit index are, indeed, a bit of a pain. Though both can be calculated. (I need to work in the radius calculation) About region radius we already discussed that in length with CCP Tellus in this thread (read previous posts). Numbers only match if you use Python. As for orbitIndex, it's because I tried to calculate them, I'm asking about that info to be included. The index order isn't the same for all celestials and it gets all messed up.Steve Ronuken wrote:Landmark descriptions are in trnTranslations now. (side effect of how the files are generated.) Same case as with celestial names.Steve Ronuken wrote:The stargate Radius, I suspect, comes from typeIDs.yaml Still same case as celestial names. Independency. |
|
Carbon Alabel
The Alabaster Albatross Sev3rance
11
|
Posted - 2016.05.01 18:50:14 -
[81] - Quote
Desmont McCallock wrote:Universe data need to be independent as they always were. As far as I know, the SDE was always distributed in the form of a single archive file, so how exactly was it independent? |
Desmont McCallock
607
|
Posted - 2016.05.01 19:40:52 -
[82] - Quote
Carbon Alabel wrote:Desmont McCallock wrote:Universe data need to be independent as they always were. As far as I know, the SDE was always distributed in the form of a single archive file, so how exactly was it independent? In the form that you didn't need to do a lookup on another table. itemName in mapDenormalize was always provided. You didn't had to do a lookup on another table to get the data.
|
Desmont McCallock
609
|
Posted - 2016.05.03 10:02:14 -
[83] - Quote
Something interesting I found while working with re-importing the new SDE files back into a DB is that the 'mapSolarSystemJumps', 'mapConstellationJumps', 'mapRegionJumps' tables can be easily created with a query on 'mapJumps' and 'mapDenormalize' tables.
You may say "Pfff, no big deal...", but here they are for future reference.
/* mapSolarSystemJumps */ SELECT denorm1.regionID as fromRegionID, denorm1.constellationID as fromConstellationID, denorm1.solarSystemID as fromSolarSystemID, denorm2.solarSystemID as toSolarSystemID, denorm2.constellationID as toConstellationID, denorm2.regionID as toRegionID FROM mapJumps as jumps JOIN mapDenormalize as denorm1 on jumps.stargateID = denorm1.itemID JOIN mapDenormalize as denorm2 on jumps.celestialID = denorm2.itemID ORDER BY denorm1.solarSystemID, denorm2.solarSystemID
/* mapConstellationJumps */ SELECT denorm1.regionID as fromRegionID, denorm1.constellationID as fromConstellationID, denorm2.constellationID as toConstellationID, denorm2.regionID as toRegionID FROM mapJumps as jumps JOIN mapDenormalize as denorm1 on jumps.stargateID = denorm1.itemID JOIN mapDenormalize as denorm2 on jumps.celestialID = denorm2.itemID WHERE denorm1.constellationID != denorm2.constellationID GROUP BY denorm1.regionID, denorm1.constellationID, denorm2.constellationID, denorm2.regionID ORDER BY denorm1.constellationID, denorm2.constellationID
/* mapRegionJumps */ SELECT denorm1.regionID as fromRegionID, denorm2.regionID as toRegionID FROM mapJumps as jumps JOIN mapDenormalize as denorm1 on jumps.stargateID = denorm1.itemID JOIN mapDenormalize as denorm2 on jumps.celestialID = denorm2.itemID WHERE denorm1.regionID != denorm2.regionID GROUP BY denorm1.regionID, denorm2.regionID ORDER BY denorm1.regionID, denorm2.regionID |
Desmont McCallock
609
|
Posted - 2016.05.06 14:19:22 -
[84] - Quote
Steve Ronuken wrote:All names are in invNames, so you can look them up, and insert them. This is for asteroid belts, moons, planets, stars, stations. Just out of curiosity I wanted to give this a try, so I did some checking via
select invNames.itemID, invNames.itemName as InvNames_itemName, mapDenormalize.itemName as MapDenormalize_itemName from dbo.invNames as invNames join dbo.mapDenormalize as mapDenormalize on invNames.itemID = mapDenormalize.itemID where invNames.itemName <> mapDenormalize.itemName The result comes back with 122 rows, proving another data inconsistency in SDE.
This is getting nowhere. |
Desmont McCallock
614
|
Posted - 2016.05.08 09:14:07 -
[85] - Quote
Yet another data inconsistency with names.
select invNames.itemID, invNames.itemName as InvNames_itemName, invUniqueNames.itemName as InvUniqueNames_itemName from dbo.invNames as invNames join dbo.invUniqueNames as invUniqueNames on invNames.itemID = invUniqueNames.itemID where invNames.itemName <> invUniqueNames.itemName collate Latin1_General_BIN
This time the query returns 6994 rows. |
Hurt Kion
Hurt Kion's Inc.
0
|
Posted - 2016.05.14 23:00:03 -
[86] - Quote
Some blueprints materials in SDK (blueprints.yaml normal and legacy) do not match Tranquility.
For example: CONCORD Capital Shield Extender Blueprint in SDK:
41603: activities: manufacturing: materials: - quantity: 1 typeID: 40354 [ Capital Shield Extender I ] - quantity: 8 typeID: 41267 [ Compact Compounds ] - quantity: 12 typeID: 41308 [ Restrained Compounds ] - quantity: 41 typeID: 41268 [ Compact Conductors ] - quantity: 44 typeID: 41266 [ Compact Electronics ] - quantity: 47 typeID: 41309 [ Restrained Conductors ] - quantity: 50 typeID: 41307 [ Restrained Electronics ] products: - quantity: 1 typeID: 41459 skills: - level: 1 typeID: 3380 - level: 1 typeID: 22242 time: 36000 blueprintTypeID: 41603 maxProductionLimit: 5
in game:
1 x Capital Shield Extender II 13 x Broadcast Node 20 x Sterile Conduits 10 x Wetware Mainframe
Same with: CONCORD 25000mm Steel Plates Blueprint CONCORD Capital Armor Repairer Blueprint
maybe others...
|
Jai Blaze
Honor Forge Joint Operation Involving Nobodys
0
|
Posted - 2016.05.17 04:21:48 -
[87] - Quote
Please more JSON files!! I've tried converting typeIDs.yaml into JSON and it refuses to validate. It's the single most important file for my own use, blueprints converted nicely and a lot of the others are small enough I can excel the crap out of it and reform it into a JSON file manually, but typeIDs is too big and when I try to convert manually it crashes. And nothing I've found so far will accept it and return a JSON file.
MOAR JSON!
please :) |
Myme Temet'Nosce
New Horizon Entreprise Le Consortium Horizon
0
|
Posted - 2016.05.22 12:51:36 -
[88] - Quote
Can someone explain clearly why getting rid of a standardized, very fast and very efficient format as sql to use yaml, which is not as good by far ?
What did I miss ? |
Pete Butcher
KarmaFleet Goonswarm Federation
332
|
Posted - 2016.05.22 13:09:40 -
[89] - Quote
Myme Temet'Nosce wrote:Can someone explain clearly why getting rid of a standardized, very fast and very efficient format as sql to use yaml, which is not as good by far ?
What did I miss ?
Sql is neither standardized, very fast or efficient. Just trowing my 2 cents there.
http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool + Trade Advisor
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
5995
|
Posted - 2016.05.22 14:50:55 -
[90] - Quote
Myme Temet'Nosce wrote:Can someone explain clearly why getting rid of a standardized, very fast and very efficient format as sql to use yaml, which is not as good by far ?
What did I miss ?
Try version controlling a database. Then you'll realise why. Total PITA. And what works in one database, doesn't always work in another. (And Eve uses at least three. SQL Server on the server, sqlite and a custom format on the client.)
What we're getting now, is a the output from their version control system, rather than some multi step process, which is a pain in the ass for them to manage, and a pain in the ass for people to convert to other database formats.
For me, having it all moved into yaml is a godsend, as I can write a single script, which takes the yaml, and dumps in to whatever database I want it to. Rather than the multi step process which I needed to run through before. It's significantly easier, requiring a lot less attention.
Woo! CSM XI!
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
|
|
|
|
Pages: 1 2 [3] 4 :: one page |
First page | Previous page | Next page | Last page |