open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Srsly, which one is the original?
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2] 3

Author Topic

Ms Freak
Amarr
Immortalis Inc.
Shadow Cartel
Posted - 2011.05.31 17:56:00 - [31]
 

Question:

If you had a "typeId" column (assuming this makes an DBRow a Blueprint or a Ship or a Gun (etc)) - Why not just add another type "BLUEPRINT_COPY" and reference that?

I obviously missed something in the dev blog, which was very interesting btw, and was wondering why the change took so many changes and effort?

SokoleOko
Minmatar
Death Wish.
Posted - 2011.05.31 18:06:00 - [32]
 

Edited by: SokoleOko on 31/05/2011 18:05:55
Quality tech p0rn :)

Personally I have no clue about programming and DBs, but I've enjoyed reading that blog... not to mention, understand it :)

Mashie Saldana
Minmatar
Veto Corp
Posted - 2011.05.31 18:26:00 - [33]
 

So now when you have a sexy way to to the differentiation on the DB, maybe use that lookup to do one more thing than just changing the icon, have it append the item description text with either " - copy" or " - original" and it would be even better as we will get even sexier killmails then (and suicide gankers won't end up killing innocent people flying around with T2 BPC's).

Arrius Okaski
Posted - 2011.05.31 18:58:00 - [34]
 

From the Blog post it sounds like the definitions of the blueprint copies were related to the original. (Not the instances of copies)

Could you have created the blueprint copies as their own item type instead of adding a relational link to the definition of the originals?

Have I misunderstood the nature of the relationship between the copies and originals?

Would be cool to get a response :)

Lirinas
Posted - 2011.05.31 19:33:00 - [35]
 

While this is a welcome change, I hope that this is also a precursor to future improvements to industry. Industry as a whole has changed very little in EVE over the course of it's existence. Some numbers tweaked here, some patchwork systems introduced there, but that's about it.

The part of me that focuses mostly on Industry has grown rather bored with Industry as a whole. I keep hoping to see an overhaul to the whole Industry system, something to shake things up a bit. Will something like this ever happen?

Enthral
Posted - 2011.05.31 19:41:00 - [36]
 

Originally by: Elsa Nietchize
Edited by: Elsa Nietchize on 31/05/2011 17:22:41
Quote:
So, saving DB space and bandwidth, these two got merged into an integer 'quantity' column with the new semantic that negative quantities implied a singleton. We just mass-updated the inventory table turning all 'singleton==1' items into 'quantity=-1'.


So the quantity value is an integer...
And the maximum value of an integer is 2,147,483,646(signed)
so what happens if i have a stack of ammo greater than this value?


Max size of a 64-bit integer in SQL Server (which I believe they are using) is (signed) 9,223,372,036,854,775,807. CCP may be capping the max size of a stack to something else, but the database isn't the limiting factor. To put that number into perspective, if you added one item to your stack every thousandth of a second, it would take you 106.8 billion YEARS to reach the limit. The Sun only has about 5.4 billion years left in its life, and the entire universe is thought to be around 13.75 billion years old.

I do have a question for the developers. Have you done any performance metrics on your change? It has been my experience, that using a virtual column isn't always faster than just doing a join. This is because that function can be called on every row in the table. You might not see a performance issue on your test servers, but as soon as you scale it up to tranquility...

Celebris Nexterra
Gallente
Jupiter Force
Posted - 2011.05.31 20:25:00 - [37]
 

This devblog was freakin TIGHT.

Thanks for the work in fixing such an annoying reality, and the work in writing a blog about it!!

o7

yani dumyat
Minmatar
Pixie Cats
Posted - 2011.05.31 20:37:00 - [38]
 

Thank You, a much much appreciated change. Very Happy

Nova Lux
Gallente
TalCorp Enterprises
TalCorp United Federation
Posted - 2011.05.31 22:39:00 - [39]
 

I enjoy these tech blogs, as always: keep them coming.

Glyken Touchon
Gallente
Independent Alchemists
Posted - 2011.05.31 23:29:00 - [40]
 

Originally by: Arrius Okaski
From the Blog post it sounds like the definitions of the blueprint copies were related to the original. (Not the instances of copies)

Could you have created the blueprint copies as their own item type instead of adding a relational link to the definition of the originals?

Have I misunderstood the nature of the relationship between the copies and originals?

Would be cool to get a response :)
IIRC, one of the reasons they didn't just duplicate all the BPOs and rename them BPCs was that the manufacturing/refining streams could only cope with
1xBP<->1xItem, and not 2xBP<->1xItem

Luke S
Zeta Corp.
Posted - 2011.05.31 23:38:00 - [41]
 

so in other words:

our old database system couldn't handle the types of blueprints because it would have filled it up. Now that we have more room for items IDs we can have different types of the same items.

I get that. Trying to understand what took a bit of time to change over the new system.

CCP Explorer

Posted - 2011.05.31 23:49:00 - [42]
 

Originally by: Daedalus II
Given all those extra ids you got from the 64 bit conversion, wouldn't it have been easiest to just give the blueprint copies their very own item ids?

Given, you would have to figure out which item id a copy should have given an original with a different id, but this must be easy to add as an attribute to the original?

This would then work universally in cargo holds, in hangars and in the LP store.
Each individual blueprint copy already had its own item ID, just like any other item in the game. It's not the item ID that defines an item but rather the type ID. Blueprint originals and blueprint copies have the same type ID, which is linked to the type ID of the item they produce.

Havak Kouvo
Posted - 2011.05.31 23:51:00 - [43]
 

It stories like these that make me realize why I have to take so many math classes.

CCP Explorer

Posted - 2011.05.31 23:55:00 - [44]
 

Originally by: fgft Athonille
when are you a*sholes going to fix lag?!
We are drafting a dev blog on the latest optimisations we made.

CCP Explorer

Posted - 2011.06.01 00:04:00 - [45]
 

Originally by: Ms Freak
Question:

If you had a "typeId" column (assuming this makes an DBRow a Blueprint or a Ship or a Gun (etc)) - Why not just add another type "BLUEPRINT_COPY" and reference that?

I obviously missed something in the dev blog, which was very interesting btw, and was wondering why the change took so many changes and effort?
Having BPOs and BPCs being different types is another route we could have taken. We would have had to introduce special casing into the content authoring system so when authoring blueprints the system would behind the scenes create two different types and copy all attributes on both. The solution we selected instead has the added benefit of being very general: Any kind of context specific singleton information can be encoded with the system; BPOs vs. BPCs is just one example of such a usage.

CCP Explorer

Posted - 2011.06.01 00:06:00 - [46]
 

Originally by: Arrius Okaski
From the Blog post it sounds like the definitions of the blueprint copies were related to the original. (Not the instances of copies)

Could you have created the blueprint copies as their own item type instead of adding a relational link to the definition of the originals?

Have I misunderstood the nature of the relationship between the copies and originals?

Would be cool to get a response :)
See here.

CCP Explorer

Posted - 2011.06.01 00:09:00 - [47]
 

Originally by: Enthral
Originally by: Elsa Nietchize
Edited by: Elsa Nietchize on 31/05/2011 17:22:41
Quote:
So, saving DB space and bandwidth, these two got merged into an integer 'quantity' column with the new semantic that negative quantities implied a singleton. We just mass-updated the inventory table turning all 'singleton==1' items into 'quantity=-1'.


So the quantity value is an integer...
And the maximum value of an integer is 2,147,483,646(signed)
so what happens if i have a stack of ammo greater than this value?


Max size of a 64-bit integer in SQL Server (which I believe they are using) is (signed) 9,223,372,036,854,775,807. CCP may be capping the max size of a stack to something else, but the database isn't the limiting factor. To put that number into perspective, if you added one item to your stack every thousandth of a second, it would take you 106.8 billion YEARS to reach the limit. The Sun only has about 5.4 billion years left in its life, and the entire universe is thought to be around 13.75 billion years old.

I do have a question for the developers. Have you done any performance metrics on your change? It has been my experience, that using a virtual column isn't always faster than just doing a join. This is because that function can be called on every row in the table. You might not see a performance issue on your test servers, but as soon as you scale it up to tranquility...
The max stack size is dictated by the 32 bit integer in Python.

Performance metrics for the underlying framework change, yes we have them here. Look for the "Inventory Setification" part.

This scales incredibly well since the virtual column code is executed by the client, not the cluster. The DB and the server just hand the data off to the client and the client takes care of calculating the value of the virtual column when the UI needs to know what value it contains. Very Happy

Patyrn Runner
Posted - 2011.06.01 00:50:00 - [48]
 

Edited by: Patyrn Runner on 01/06/2011 00:52:56
Edit: RTFA and my question was answered... Embarassed

Jagga Spikes
Minmatar
Spikes Chop Shop
Posted - 2011.06.01 06:38:00 - [49]
 

a delivery? well done.

Ms Freak
Amarr
Immortalis Inc.
Shadow Cartel
Posted - 2011.06.01 07:49:00 - [50]
 

Edited by: Ms Freak on 01/06/2011 07:49:59
Originally by: CCP Explorer
Originally by: Ms Freak
Question:

If you had a "typeId" column (assuming this makes an DBRow a Blueprint or a Ship or a Gun (etc)) - Why not just add another type "BLUEPRINT_COPY" and reference that?

I obviously missed something in the dev blog, which was very interesting btw, and was wondering why the change took so many changes and effort?
Having BPOs and BPCs being different types is another route we could have taken. We would have had to introduce special casing into the content authoring system so when authoring blueprints the system would behind the scenes create two different types and copy all attributes on both. The solution we selected instead has the added benefit of being very general: Any kind of context specific singleton information can be encoded with the system; BPOs vs. BPCs is just one example of such a usage.


Ok so the choice was do something to retain the "BLUEPRINT" type and diffreniate using another method which allows you to retain the generic show info etc OR add the second type then cater for it specifically.

Nice! And thanks for the reply - most informative.

Aineko Macx
Posted - 2011.06.01 08:20:00 - [51]
 

Originally by: CCP Explorer
Originally by: Ms Freak
Question:
If you had a "typeId" column (assuming this makes an DBRow a Blueprint or a Ship or a Gun (etc)) - Why not just add another type "BLUEPRINT_COPY" and reference that?
I obviously missed something in the dev blog, which was very interesting btw, and was wondering why the change took so many changes and effort?
Having BPOs and BPCs being different types is another route we could have taken. We would have had to introduce special casing into the content authoring system so when authoring blueprints the system would behind the scenes create two different types and copy all attributes on both. The solution we selected instead has the added benefit of being very general: Any kind of context specific singleton information can be encoded with the system; BPOs vs. BPCs is just one example of such a usage.

I'd have gone the differing type ID route. Having special case code ran depending on metadata encoded in a generic column gets ugly the more such special cases you have. Am I correct in assuming this also effects the API?

Still, thanks for making this possible.

CCP Prism X


Gallente
C C P
C C P Alliance
Posted - 2011.06.01 08:54:00 - [52]
 

Edited by: CCP Prism X on 01/06/2011 08:55:32
Originally by: Wollari
Will this singleton flag change (1/2) be readable via API aswell? That would help lots of people with managing their industry and assets externally.

Haven't checked the API yet.


As we speak the API simply casts any negative quantity into 1 to avoid screwing with any summing of quantities. When I saw this post yesterday I created a defect on the new API developer that replaced me but I cannot promise when he'll get to that. But he's busy enough with development so I'm posting (also I love posting).. so soon™?

I'm not sure how Elerhino (The new API developer.. who is also the old one that I replaced. We're a tag team.) will go about solving this, but I doubt he'll actually change the quantity from displaying 1 unit for any singleton as it will be completely incompatible with any application using the current form of the call. But we're aware of the need for the actual quantity, and the need to keep legacy app arithmetic functioning. Wink

Grady Eltoren
Minmatar
Aviation Professionals for EVE
Posted - 2011.06.01 12:12:00 - [53]
 

Originally by: Meissa Anunthiel
Many thanks to you and the teams involved Explorer.

I now found where a few of my BPOs were hidden in my BPC containers. :-)


Ha Ha - same here. Sorry it took so long for you guys to implement but it was well needed in game. Thanks. I especially appreciate the keeping of tags on the items like faction, t2, etc.

Lutz Major
Posted - 2011.06.01 13:02:00 - [54]
 

Originally by: CCP Prism X
Edited by: CCP Prism X on 01/06/2011 08:55:32
Originally by: Wollari
Will this singleton flag change (1/2) be readable via API aswell? That would help lots of people with managing their industry and assets externally.

Haven't checked the API yet.


As we speak the API simply casts any negative quantity into 1 to avoid screwing with any summing of quantities. When I saw this post yesterday I created a defect on the new API developer that replaced me but I cannot promise when he'll get to that. But he's busy enough with development so I'm posting (also I love posting).. so soon™?

I'm not sure how Elerhino (The new API developer.. who is also the old one that I replaced. We're a tag team.) will go about solving this, but I doubt he'll actually change the quantity from displaying 1 unit for any singleton as it will be completely incompatible with any application using the current form of the call. But we're aware of the need for the actual quantity, and the need to keep legacy app arithmetic functioning. Wink

How about introducing a complete new blueprint API? BlueprintAssetList.xml.aspx for example? With just a list of itemIDs, typeIDs, MEs, PEs, run levels and a flag for isCopy? (the flag could be replaced by run level > 0?!?).

Then you don't have to mess with the old asset list, which would still indicate where the blueprint location is.

Pierced Brosmen
Priory Of The Lemon
Posted - 2011.06.01 13:57:00 - [55]
 

Awesome blog, and a very welcome feature when it was put on TQ.

Now, with the CarbonUI having been deployed to TQ and the possibilities that introduces, here's a project for you:

Make an overlay for all the BPO and BPC icons, that will display the ME-level, PE-level and for BPC's, the remaining runs Cool

I understand this can put a lot of unwanted work on the servers, so it could be done with a syncronization solution. So the first time you open a hangar or can with, let's say, more then 10 blueprints in it, the client informs that it's syncronizing and values will be updated when finished, and then makes low-priority calls to the server to fetch the information and storing that information localy (tied to item ID's ofc, and not to the hangar/can so client understands if an item has been moved), so next time you look up the same blueprints, the client just asks the server "what's changed since <insert date and time>?"

Just a thought... I'm not a programmer or anything, knowing what workload such an addition would mean. But it would have been an absolutely awesome addition to the game. Especially when you have lots and lots of BPC's and want to continue manufacturing from the ones you last used (to prevent having lots of half-used prints). And not having to do Show Info on all of them to find wich ones they are.

Le Ming
Posted - 2011.06.01 18:45:00 - [56]
 

+1 cake \o/

4N631
Posted - 2011.06.01 22:42:00 - [57]
 

late but still good

SmokinFighter
Gallente
Federal Navy Academy
Posted - 2011.06.02 00:08:00 - [58]
 

Originally by: Uncanny Valley
Thank you CCP! Greatest change ever! Now I can kill off the numerous containers I use to split everything.

Speaking of which, can we get a container that ONLY holds blueprints and is really tiny? Like a blueprint wallet or some such? Having so many BPOs and BPCs makes them impossible to transport from place to place. I keep running into the item count cap FAR before I hit the cargo hold capacity, and you cant load expanded tiny containers into haulers anymore.


Kinda like a BPO/C Portfolio, come on in the future they have no way of organizing paper work? lol

Klytie Ulloriaq
Posted - 2011.06.02 01:05:00 - [59]
 

Entire EVE community: About ******* time!

Deinococcus Radiodurans
Posted - 2011.06.02 09:57:00 - [60]
 

Nice piece of work and an interesting explanation of what was, under the circumstances, quite an elegant solution! It never ceases to amaze me how you guys manage to plan, implement and roll out changes to a system of this complexity with minimal impact on the users and despite all the legacy code which is ...less than ideal.

Cheers,


Pages: 1 [2] 3

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