Player Features and Ideas Discussion

Challenge accepted.

I've been programming for 15 years. It's going to be a piece of cake.

I understand that. However, no matter what, we would have a column that keeps track of the number of items that are stacked correct? I'm saying add an extra column to the table that keeps track of this integer. This extra column would be an array type which keeps track of playerIDs that built said ship(s). When they are unpackaged the playerIDs would be redistributed to said ships.

Read the post above you.

How would you handle splitting of stacks? Would ships split from a stack pick a random builderID, pick from the top, pick from the bottom, etc.? Keep in mind, this action is extra compute time.

How would you handle the increased throughput requirements for adding an array equal in size to the stack size for every single packaged ship in the game? If someone had a stack of 1000 Rifters, you've just multiplied the size of the database entry for that stack by a thousand-fold.

Why are you limiting this to only ships? Surely people would be interested in knowing who built their modules, implants, ammunition, etc, right?



See where I'm going here? Any way you cut this, it's a performance nightmare for something that doesn't add to gameplay.

It would be a simple array shift or pop. I can't see it making a difference. A stack of 1000 Rifters would still be a single array of playerIDs that built the ship. I don't really care about the mods but it would be nice to have. If CCP designed their database to handle mods, ships, items in a generic way, adding this to ships would automatically provide the same feature to all items in the game.

You can also make it a totally separate table and join tables...

I give up.

It's tough when people can't deduce or conclude the obvious solutions themselves from evidence and reasoning rather than from explicit statements.

Fly safe.

The problem isn't that it would be particularly difficult to do. An extra database column would handle the data, as you rightly point out. Actually you'd need two - one in stacks table, and one in the items table that holds the assembled ships. That second one could just be a foreign key to the character table though, so it's really not that important in the grand scheme of things - it's the first column that's the tricky one.

The issue is what handling that extra column in the way you're suggesting code wise in a system like Eve's would cost from a performance standpoint. People create, split, merge and delete stacks all the time. I mean literally all the time. In their cargo, in their inventory, at POSes, in jet cans, inside containers. And all of those stacks have to be tracked, including where they are, who owns them, and what they are a stack of. You basically want to add an extra column to that, in VARCHAR format, to track who created what.

Now, I happen to know that CCP is a Microsoft SQL Server shop (Get Oracle you fools!) from some articles I've read in the past. I know, from looking at the MS SQL variable types, that the maximum length of a VARCHAR field is 8,000 characters. I would assume that each of our character IDs is something like 10-12 digits long (assuming CCP is planning ahead and using Big Decimals). We'll say 10.

A stack can have at least 1,000 items in it (if not many more - ammo, obviously has tens or hundreds of thousands, as do minerals, but I'm not sure if they use a separate table for "bulk" type items). That means that, in order to accomodate the 1,000 items, I need at least 10,000 characters, so VARCHAR isn't going to do it (and that doesn't even account for some kind of spacer between the entries). Under Oracle, we'd have to use a BLOB to store the data - under MSSQL, you basically have to write the data to a text file, and then store that in the database as a binary file stream.

And you have to do it thousands of times a minute.

And all of that just to point ou that we can't even associate which entry in the stack matches which entry in the player id array (thus defeating the purpose of this suggestion) without adding even more psuedo indexing data to the table in the form of yet another blob (or expandiong the scope of the one we're using).

So yes, when people say "IT'S THE PERFORMANCE" it's not a cop out in this case. While what you want to add isn't necessarily complex from an idea standpoint, trying to add it to a high volume system without introducing a slow down in that system for what is, essentially, a vanity name plate is beyond ridiculous. It serves no point, and in no way can it do anything except harm the overall system.

can't imagine why they didn't accept your offer to contribute some code to eve you sure seem like a guy who thinks things through all the way

would be funny if you wouldn't have a team and a few years

First off NO to the idea in the OP. It is data not needed in the game and most would probably not want it published anyway.

The other thing I find interesting are the programmers like you who come to the forums and talk about how easy xyz would be to change when they have no clue how it was all set up to begin with. Besides if this is all so easy why not go write your own online pixel spaceships game? It should be easy for a programming genius like you to handle, you could have it all your way and you could become rich and famous.