Makers mark

You are making some very bold assertions. Let me point some of them out:

Here you are implying that the database does not exist in the real world. So, first the Drakes don’t exist, and now, the entire database is “not real”.

Items that do not exist need to all have the same data to be stacked?

I stack unpackaged items in EVE all the time. I just have to repackage them, first. Also, we might consider the entire database to be a “stack”, and so unique items are indeed “stacked” all the time. It just requires different/more functionality to do so. Just because the items are represented polymorphically doesn’t mean they are not items. All the same information exists, just in a more compact form (or lack thereof).

The item isn’t “new”. It inherits most of its attributes from the old item. It is already unique. It becomes MORE unique, i.e. Drakes → A Drake → The Drake

You are trying to answer the “how” without first answering the “why”?

At this point it’s obvious that you are either obtuse, or trolling.

Why can’t I be both?

Holy ■■■■. I think you two just aren’t communicating properly.

A stack is an Object and a multiplier. It is, literally, one reference to the Drake Object (which is not a ship) and a multiplier, which reaches to the signed integers maximum, which you may look up yourself. Unless they’ve changed it, each stack has a signed doubleword as maximum amount. That’s the most efficient way to store an arbitrary number of the same objects.

Your hangar is:

([Pointer to reference Object Drake] [AmountofDrakesOnStack])

In 32bit Python, that’s two doublewords aka eight bytes.

When you pull a drake from the stack and assemble it, your hangar turns into:

([Pointer to reference Object Drake] [AmountofDrakesOnStack])
([Pointer to newly created Drake Object])

At no point in time is there a way to link the owner to the newly created Drake Object. If CCP saved the owner for every item in the stack, it would have to keep track of each item’s owner seperately, which effectively multiplies the data at least by

([AmountofDrakesOnStack] x [PointersToOwners])

As stacks don’t allow this, because they’re just a number and a pointer to a reference object, CCP would have to kill stacks completely.

So, for every item with OwnerTag, we’d have an additional four bytes of storage space used, plus additional memory accesses, or worse, database accesses when the Owner is not cached locally on the node, which also affects network bandwidth. It would be unreasonable to cache the OwnerTags locally pre demand, because it’s unknown how high the numbers might be.

Per pilot, per Node!

He’s right saying that the Drakes don’t exist until they’re assembled. Until then, they’re just a number on a PostIt for the reference object Drake. Anything else would be nuts due to the sheer amount of ships, or objects in general.

I hope that helped.

2 Likes

Problem: THERE ARE too many DRAKES. (<- See the problem?)

Solution: Stack them in a compressed form.

Implementation: Normalize all THE DRAKES into one data type and iterate on EACH DRAKE as needed.

I’ll ask again: are there Drakes or are there no Drakes?

P.S. I appreciate your guys’ patience and clarity in dealing with this complicated and difficult topic. I am genuinely trying to understand your point of view.

You’re not a programmer, incapable of understanding the problem and thus have no ground to speak on.

If you were a programmer, you’d either explain your solution like a programmer, or realize that what you want makes no sense.

I’ll address this one last time: One can not iterate through the Drakes. For that to happen, each stacked Drake would either need to exist, or be created specifically at access, and then removed again if it’s not being assembled.

In any case does it not change the very fact, that CCP would still need to keep track of each Drake’s creator, which is not compressable, because they’re pointers to random memory locations. Not even talking about the CPU, memory, storage and bandwidth wasted! Times tens of thousands of times, because there’s tens of thousands of players online at any point in time except close around downtime.

I suggest:

I also suggest:

http://www.cs.virginia.edu/~evans/cs216/guides/x86.html

http://agner.org/optimize/#manuals

You kind of remind me of that one guy who had ideas for lowsec, and openly admitted not only that he doesn’t play there, but also that it doesn’t matter.

It. ■■■■■■■. Does.

PS: i’ve realized i used Owner, but meant Creator/builder. Whatever, it’s past midnight here. :stuck_out_tongue: i don’t mean to be mean, but you need to learn things yourself. Start with Python. i apologize for my rude tone, and head to sleep instead of posting. maybe tomorrow, if someone else can’t teach you.

Yes. Exactly.

Take this image of Bart writing lines on a whiteboard:

bart-1

We don’t need to read every sentence to know what they say, since they are all identical. So, if Bart was trying to be efficient, he might just write the sentence once and then include how many times it can be written out on the board:

bart-2

So much room (memory) is saved by just writing it once, rather than duplicating the very same thing over and over and over, simply because there’s nothing unique about any of the sentences. They are all the same thing.

But it can still go further then that, because Bart get’s lines a lot, there’s probably a few sentences he might have the write and there’s a chance that some one else (eg. Nelson) might have to write out the same sentence too.

So instead of Nelson’s board also containing a copy of the same sentence, the sentence itself can be moved out to a separate place and just a number used to reference it:

bart-3

That way, there’s just one copy of the sentence and since it is the same for everyone, they can all use that same number to refer to that sentence (each of them of course, with their own quantity). No matter how many people need that same sentence, they can just reference it with a number and store how many of them they have:

bart-4

You can think of the chalkboard as being like your inventory. It has a list of all the items you have and how many of each type.

While the items are the same thing, there is nothing unique about them and they can all refer to the same information.

So in your inventory, packaged items are like that. They contain a typeID (reference to the type of object) and how many you have.

There is no ability to store the maker of each item, because the items don’t exist when they are packaged. It’s just a reference to the item so that when you assemble it, the correct item gets assembled.

However, when you assemble a ship, it has the potential to be different to every other Drake in the game (even other Drakes you own).

It can have:

  • unique name
  • SKIN applied
  • owner
  • damage
  • fitting
  • stuff in its cargo
  • etc.

All these things (and others) make an assembled Drake unique, so the assembled ship then needs its own separate database entry.

That’s the only time the ship can store unique information about itself and it knows no history of itself existing before it was assembled.

So it is kind of impossible, given the way the database is designed, to store unique information about the maker, because even Drakes that roll off the production line are not actual Drake’s with their own database entry. They are also just a reference to a Drake object in an inventory. Nothing unique about them, so the information comes from a single locations that all Drake’s use, not an individual database entry for each item (not until they are assembled).

This is a far more efficient use of memory and database design than duplicating the same information over and over tens of thousands of times.

When a Drake gets assembled, then the number of packaged Drakes you have in your inventory goes down by 1 and a reference to the item ID in the database for that specific drake is then added to your inventory. At that point, the Drake then exists as its own unique item, with its own entry in a separate table in the database, as all the unique information about it needs to persist, whether you are online or not.

Of course, CCP could change their design, but the amount of effort required for the little benefit gained makes it extremely unlikely.

3 Likes

Brilliant!

bart-1

^ Do these sentences exist?

So you really are just trolling. My bad.

K.I.S.S. <- do you remember this fundamental design principle? You have done nothing but obfuscate to avoid having to answer a very simple question. All you had to do was say, “I don’t want to answer that question.” That is your uncontestable right.

Your solution to having to answer my question violates the above mentioned principle.

■■■■■■■■. I did answer your question. In detail.

But, if you didn’t understand it, then there isn’t much more to try. Perhaps you’re just stupid.

The design outlined above is simple. It’s also efficient.

1 Like

You cannot define a solution until you have defined the problem. What problem are you trying to solve?

Your lack of understanding.

1 Like

Scipio, your patience is both admirable and hilarious, especially when it pops. :grin:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.