The stacks are probably identified by universal database fields, as a layman I would take a guess at something like stack_id as opposed to item_id.
It’s certainly doable by appending extra fields to database entries, however it’s not just 1 or 2 extra fields, it’s hundreds of thousands of extra fields.
I doubt the database admins or the hardware would be happy about it.
There are no famous car dealers. You won’t be a ship manufacturer in the sense of creating your own ship, or version of a ship; all you’ll do is stamp your logo on a Raven battleship that’s absolutely identical to everyone else’s. How can you possibly get famous for that?
That’s why the idea isn’t good.
Now, what may work and make you famous would be your own SKINS. You see, CCP could put in the work to implement a Raven skin incorporating YOUR logo and YOUR color combinations, and sell the LICENSE to duplicate and market (in-game) that skin to you (for a lot of dollars, of course, because you’re buying “a brand”).
And then you’d be the only one in EVE able to offer that particular SKIN to other players. Become famous (if the design looks good). Everyone would know your name and would want to buy your skins, and because you have the LICENSE with CCP, nobody else would be able to copy / duplicate your particular colors or shape, because CCP would of course reject designs that are too similar to yours.
So they make money selling you a LICENSE, and you make ISK selling a hot logo / colors in-game. Win - Win. In effect, you’re hiring CCP’s artists directly to put in a few hours to design your logo, colors, hanging flags, rainbow engine trails, whatever, and you pay them $$ for their time. Then feel free to market the result in-game and become famous.
Even unpackaged ships need to have the owner saved somewhere, otherwise there would be no way of knowing which ship was built by whom. we’re talking about millions of ships here.
The thing with all of those attributes is that they are easily generated/read at the time the ship is assembled and they then are stored.
However, a packaged ship is just a TypeID and volume. There’s no history for each item, nor much other data stored, since that would require a separate database entry for every single ship, whether assembled or not.
The game doesn’t treat packaged items the same as it does assembled ones and from everything CCP has written in the past, making that fundamental change to how the items are treated would be a huge task for not much gain.
The type definition (presumably a class) for the item contains a bunch of information about what the item can be, but the stack definition contains MORE information than the type definition. So, while a single Drake item only contains information about 1 Drake, a Stack-of-Drakes item contains information about AT LEAST 1 Drake. Often more. That may seem trivial since it is duplicate data, but it isn’t quite duplicate data.
In a stack of 3 Drakes, one Drake comes first. Another one comes next. And one of them is last. Well, one of them could also be #3857374767.
This isn’t correct. Packaged items don’t contain any individualised information.
It’s not until an item is assembled that it has its own database entry.
The information held for a stack of items probably consists of the location id, the owners character id, the item id and how many of them there are; nothing more is required as it can all be referenced from elsewhere.
Individualized information? You mean, like . . . where it is and whose it is and how big it is and how many shield hitpoints it has and what it refines into and what it’s called . . . ? Are you saying that isn’t “individualized information” or are you saying a stack doesn’t know how many Drakea are in it or even what a Drake IS?
Quote where I stated otherwise.
Correct.
Information about inventory sits with the character and other locations (eg. Market orders, contracts, possibly station, etc.), but until the item is assembled it has no individual database entry.
It doesn’t store its hit points, damage, profile, etc.
All of that is only added when the item is assembled and then each item has its list of attributes.
So packaged items are little more than a typeID while packaged (not 100% accurate, but just in general).
CCP discussed this a couple of years ago when some questions came up about how many items there are in EVE and CCP explained that it isn’t as simple as looking at the last entry ID in the database, because the IDs are recycled.
It may have even been a Fanfest presentation by CCP Quant, but I don’t recall exactly.
It has to know where to reference the other information or the handling function does, but whatever the case, that information already exists. It can’t be a stack of Drakes without knowing, in some sense, what a Drake is. And then it has to know some more things on top of that.
It’s not just 4 integers. And even if it was, why can’t it be 5?
Came here expecting a discussion on bourbon, left disappointed 
Because not every ship in the stack is going to have the same 5th integer (manufacturer)
When they are unpackaged it’s fine, more individual information can be stored about each unique ship. And they are treated as unique items within the database.
Once they get repackaged, all non-generic info about them gets stripped down. So instead of having 100 drakes as 100 different items, you have a single item called “drake*100”
Very good.
So the question is “how much more information and processing would it require?”
A stack of brand new Drakes would only require 4 integers plus 1 more to signify their maker, but a stack of 100 Drakes from 100 different makers would require the 4 generic integers and 100 more integers, 1 for each “unique” Drake.
Well, actually, the first stack might require 6 integers, 4 generic, 1 maker’s i.d., and 1 to signify that the entire stack has the same maker.
On the other end, maybe 50 of the 100 Drakes have the same maker. That means that that stack consists of 4 generic values and 51 maker’s i.d.
The representation of a homogenous stack and a heterogenous seem to be converging. So, how close do they get and how much more overhead is a heterogenous representation versus a homogeneous representation?
I certainly can’t answer these questions, but the answer to whether it is “worth doing” depends on them.
I’m disappointed.
This thread needs more bourbon.
I was expecting bourbon.
Yes, it can and that’s exactly what it is. All it needs is the typeID, which then is an identifier to obtain all of the other information needed to show in game.
A packaged Drake for example, is more a reference to a Drake, not a Drake itself. By having the typeID (24698 in the case of a Drake), all of the other information can be obtained, without that specific packaged item storing any any information about itself, other than the type it will become.
The typeIDs yaml file for example contains a heap of information on a Drake, referenced by typeID:
The packaged ship doesn’t need to have any of that information in it’s own instance or in a relational database entry. The types yaml is in memory on the server and can be referenced from the typeID of the packaged ship.
If it needs to know what the base attributes of a Drake are, then the typeID allows that information to be obtained from elsewhere. etc.
There is no history of a ship, no attributes, no fitting, etc. while it is packaged. It’s just a reference**, via the typeID, to the object it will become.
** reference meaning in the general sense, not in terms of a value at a memory address.
This exactly. And yes, it would be quite trivial to add a line of code to the yaml file for the drake in order to add who had manufactured it. But then EVERY drake that gets assembled and references 24698 would come back with the same manufacturer.
So to prevent that, a drake produced by me for example would need to be item ID 24698a the next person to build one would be 24698b etc etc.
Yes once a ship is assembled it might be given I’d 24698yournameA and a unique database slot to store more detailed information. But as soon as that ship gets repackaged all of that specific information gets stripped, and it’s database entry deleted which frees up space. Maintaining any of that unique information would make it unstackable. And would prevent it’s old database entry from being cleared.
Might not seem like such a big deal. Until you think about how many millions of ships exist in game.
So, there are no Drakes in the stack . . . of Drakes. Is that what you are saying?
As far as the database is concerned. No, there are not. The stack of drakes is a “stackofdrakes” with however many “stackofdrakes” you have and minimal information beyond who owns the “stackofdrakes” where it is, the volume of each “stackofdrakes” item. And instructions that when “assemble ship” is pressed, to -1 “stackofdrakes” and ref 24698 to spawn an assembled drake item with full stats.
This is why damaged ships cannot be repackaged (to prevent getting free repairs) and why things like killmarks, dirt, etc get destroyed when a ship gets repackaged.
I was kind of hoping you would say that. 
Okay, so, what you have essentially said is: “There are no trees in the forest, only wood and leaves configured into tall, relatively slender forms that appear to exhibit growth, decay, and death . . .” The problem with this way of thinking is that without individualized Drakes, there is nothing to stack, and if there is nothing to stack, there is no need for a stack, letalone a stacking mechanism, letalone a thread in the forums about a stacking mechanism.
Drakes do need a stacking mechanism.
Not Drakes do not need a stacking mechanism. (They also don’t need a database and even if they did, how would a database of nothing even work?)
It boils down to this: If a Drake explodes in low sec and no one is around to witness it, does it generate a kill report?
in the real world yes, in the case of a database however that isn’t how things are calculated and stored.
In the case of an eve like database. Item ID: forest would not contain any trees that grow, decay etc. only item ID tree has those stats applied to it.
so it would look like
ID:forest
quantity: 100
Mass: 10m3
loc: yukon
owner: earth
When action “remove tree” is applied, -1 quantity, create item “earths tree” refID “tree”
ID:Tree
mass 11m3
loc: yukon
owner: earth
age: 2 years
leaves: 2000
height: 10 meters
etc:
etc:
when command “replace tree” is issued, destroy item, create item “forest” in current location/ownership.
the same thing happens with your drake, when you repackage it, the old drake item gets completely removed from the game, and a new item “packaged drake” with minimal unique information is created, in order for it to be stacked, all items in the stack need to have the exact same data. otherwise they get treated as unique items. this is why unpackaged ships cannot be stacked, each one is being treated as a unique entity. this is also why when you unpackage a ship, very briefly it disappears from your inventory, and a moment later a new assembled ship is added. and why when you repackage an item, it doesn’t go directly into the stack. because in essence a “new item” has been created to replace the old one.
