Suggestion: to add item cost in inventory on mouse over
Applies for trading and industry purposes. Unless you keep spreadsheets upon spreadsheets it’s super hard to keep track of what the item is worth to you, and setting the selling price sometimes is guesswork.
But this should be relatively straight forward for the most part:
mined or looted items - cost is zero
purchased on market - what you paid
stacking items in inventory - all items get the weighted average cost
manufactured - takes cost of materials plus fees. Ideally should also include the cost of the blueprint used divided by available runs, so you add only the pro-rated cost (e.g. 1 of 10 runs).
BPC cost is just the copying fee, since BPOs have infinite runs. Plus cost of cores and decryptor multiplied by chance at the time of production.
contracts… tricky for multi-items, maybe blanket them at zero
This should lower the barrier of entry and make markets more efficient
Not even close.
If I tell you you have 50 green apples that’s easy to write down right, you just have to write green apples: 50. And when you get 5 more you just change 50 to 55.
What you are proposing you have to track each apple individually, because for each apple you have to know how you got it, how much it cost you to get, and how to tell it apart from the other green apples
This proposal has the same underlying issue as the ‘manufacturer’s name on object’ proposal: storing unique data on non-unique objects. That is fundamentally not possible with the current database configuration, and would require such a massive overhaul with a minimal return on value for the majority of players as to be a literal net loss in development.
I disagree with the concept of tracking each item individually.
Database schema: player - location - item - count - avg cost
So all you need to add is just one column.
So you had 50 apples at a station at avg cost 10, total cost 500.
Add 5 apples from ship at cost 20, total cost 100.
Hence now you have in-station inventory 55 apples at cost 600, or avg cost 10.91.
If you move 5 back to your ship, both your ship and station still keep avg cost of 10.91.
The same principle applies in irl stock brokerage. Nobody tracks each individual share cost separetely but you have avg cost if you keep buying more at different prices and then sell.
The database cannot tell what it cost you to obtain each unit in any given stack of objects. It doesn’t view them as independent objects, which would be necessary to log that data. It treats them as a count of instances of a single core object. When an object is unpackaged it is granted additional data storage elements for use when doing things like applying heat damage to modules - but they become incapable of stacking at that point, as they are now unique objects instead of instances of a single object.
I still don’t see a problem.
If it’s an independent object (e.g. fitted and has damage), then it has one additional attribute of cost.
If it’s a packaged object (reference, stackable) the same way the count is associated with a character and locataion, the same way you have cost for that group of objects. When you merge two packaged groups, you calculate new count and new avg cost.
But you are clearly more familiar with EVE’s database architecture and its intricacies - I am lacking knowledge to see the technical difficulty you are trying to convey.
But now you aren’t selling items for a cost, just an average cost. So some items you make a loss on. And we can just use estimated value instead, which already exists, and is close enough usually.
The estimated value is basically the current market value - yes, it is helpful.
The point is to also show the cost of acquisition, so you know at a glance if you’re making money with the current market prices or not.
That’s exactly the point. When you buy stocks in real life, or keep contributing to your pension plan, you brokerage also converts everything immediately to the average cost. Some individual shares could be winners, some losers, all could have different prices originally, but nobody reports that or cares. All that is tracked and reported is just your average cost (aka book value). When you sell, it’s not like you choose which specific shares to sell, but cost is your average cost of shares - and that’s what capital gains are calculated from.
quit comparing EVE to RL!!! you are trying to overcomplicate things… if you really wanna look at what it cost for you to pick something up, salvage or loot or buy or whatever the hell, make a spreadsheet about it…
you are trying to ovecomplicate something that doesn’t need to be
some things are better left OUT of game, and done with an app or spreadsheet outside of the game… this is one of them.
Geo Eclipse Oksaras - your argument is self-defeating. My proposal is for the game to stay in-game, making it easier to play. Bringing spreadsheets is the definition of overcomplicating and bringing RL into the game.
The examples were provided to show that technical implementation is actually much simpler and not computationally expensive as others thought it to be.
But from the likes to the posts I gather people like using spreadsheets. Oh well, seems to be such is the majority vote.
and CCP has stated that some things are better left OUT of the game and letting 3rd Party devs create content. This is one of those details. Which is why websites like Fuzzworks and many others exist.
Again, the overhaul you are talking about is not simple - it requires dramatic changes to how the game identifies and stores objects. It’s not simply adding a new column to an inventory record, because that’s not how the inventory functions to begin with. There is an object database that describes repackaged objects, and an entirely separate asset database (split across shards for the various systems, as far as I can tell) that describes what objects are stored within each system, and if unpackaged, what their unique characteristics are. Each packaged object is a tiny consumer of computational power as it doesn’t re-create the object locally - it strictly references the master object database. Unpackaged objects are far more expensive on the servers, both in storage and processing, as they have unique data elements that have to be rendered when the inventory is called.
There is nowhere to store unique data on stacked (repackaged) objects, without entirely overhauling how those function at a fundamental level and losing all of the benefits of repackaged objects from a data and performance efficiency perspective.