Pages: 1 [2] 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 9 post(s) |
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 D00M.
|
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 Lowsec Static
|
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 Tribal Liberation Force
|
Posted - 2011.05.31 20:37:00 -
[38]
Thank You, a much much appreciated change.
|
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 ______
Originally by: CCP Veritas In other words, I believe Dogma is doing stupid things, and I intend to beat the stupid out of it before considering giving it rocket boots.
|
|
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.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
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.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
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.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
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.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
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.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
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...
|
Jagga Spikes
Minmatar Sebiestor Tribe
|
Posted - 2011.06.01 06:38:00 -
[49]
a delivery? well done. ________________________________ : Forum Bore 'Em : Foamy The Squirrel - [jedi handwave] "There is no spoon." |
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: Where fixing bugs is a luxury, not an obligation. |
|
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.
~ CCP Prism X EVE Database Developer If anything in this post was informative or could be considered as 'good news' to you - chances are you've misread it. |
|
Grady Eltoren
Minmatar Sebiestor Tribe
|
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.
Aviation Professionals for EVE (APEVE)
|
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.
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
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 :: one page |
First page | Previous page | Next page | Last page |