TODO: Price table all items

[jpcsupplies]

Need a lookup file created which assigns a buy and sell value to all raw, refined, and assembled items. This file should be generated if it does not exist in the storage folder to allow admins to tweak prices

[jpcsupplies]

Toby, you able to insert that global item table you built on your reference code in here ?

[jpcsupplies]

Looking good.. we may need to blacklist some items tho - some are not used or not implemented yet - ill see what i can find and post here: (excuse the wack formatting github markup seems to be having fits)

<MarketStruct>
  <TypeId>MyObjectBuilder_Component</TypeId>
  <SubtypeName>Construction</SubtypeName>
  <Quantity>0</Quantity>
  <SellPrice>1</SellPrice>
  <BuyPrice>1</BuyPrice>
</MarketStruct>
<MarketStruct>
  <TypeId>MyObjectBuilder_Ore</TypeId>
  <SubtypeName>Organic</SubtypeName>
  <Quantity>0</Quantity>
  <SellPrice>1</SellPrice>
  <BuyPrice>1</BuyPrice>
</MarketStruct>

dups? or just named funny by keen?

MyObjectBuilder_Ore Stone 0 1 1

<MarketStruct>
  <TypeId>MyObjectBuilder_Ingot</TypeId>
  <SubtypeName>Stone</SubtypeName>
  <Quantity>0</Quantity>
  <SellPrice>1</SellPrice>
  <BuyPrice>1</BuyPrice>
</MarketStruct>

<MarketStruct>
  <TypeId>MyObjectBuilder_Ore</TypeId>
  <SubtypeName>Scrap</SubtypeName>
  <Quantity>0</Quantity>
  <SellPrice>1</SellPrice>
  <BuyPrice>1</BuyPrice>
</MarketStruct>
<MarketStruct>
  <TypeId>MyObjectBuilder_Ingot</TypeId>
  <SubtypeName>Scrap</SubtypeName>
  <Quantity>0</Quantity>
  <SellPrice>1</SellPrice>
  <BuyPrice>1</BuyPrice>
</MarketStruct>

[jpcsupplies]

i think the second stone is the bag of gravel object, we may need to pull the localisation string too :/ owch

Scrap is weird, it appears to have an ingot form, but it converts to iron in game so you never see it..

the organic is interesting appears someone in keen was playing with idea of food maybe or trees or both..wonder what that will lead to..

[midspace]

Keen made a change to the Scrap a few months ago. ingot is the old implementation which they have retained for compatibility for games that still have that item.

Stone is as you have guessed. Organic is part of planets. Grass, trees, etc are mined into organic. I don't know what they have planned for it as yet.

[midspace]

I have one concern, it is the quantity. Understandably it has to be decimal, as ore and ingots can be in part Kg, unlike components and tools which are whole numbers.

My concern is people trading very small quantities and also micro transactions. Ie, /pay bill 0.0000000000001 explorer ship I think we need to establish a minimum decimal place and possibly truncate the rest of the value.

[SaltPepp]

Have you been able to look at my get buy and sell code yet @midspace

[midspace]

I have. I'd like to see some of this eventually in the mod code. Unfortunately in game items cannot be identified simply by Name. All components and parts in game have two parts to identify it. When it comes to displaying the name, localization will come in. This is something I've been thinking about for the last 48 hours.

[jpcsupplies]

For currency no more than 8 decimal places (that allows conformaty with all fiat and crypto currencies worldwide)

For items.. realistically however I cant see any need for more than 4 to 6 decimal places on items.. however it all depends on the expected maximum unit price we may see -

we need to work out what the most expensive unit commodity is (eg gold, magnesium, cobalt, uranium etc) and the most rare.. and take an educated guess what the maximum someone might bid for a unit in a global market might be.. and use that to decide on the maximum rounding.

On a heavy PVP server i would see magnesium as becoming the most expensive as it is only used for ammunition.. assuming a strong trade community and high turnover of things like iron.. players could quite easily get into the 100,000 to millions on finances... The biggest will most likely be the biggest combat targets, so we could say magnesium could reach unit prices of say.. 100 lets multiply that by 5 for a worst case.. so that gives us 1 magnesium = 500 / if we use crypto as a benchmark, bitcoin hit 1500 at one point so we could say in a high turnover market prices could get that high too.. so that gives us 1 magnesium = 1500 if a player has only just started, they will most likely be heavily selling commons, like gravel and iron.. so the prices there will crash, lets say a unit price of 0.0005 Players can sell thousands of these in a single transaction as it is easy to mine, and they may cooperate (especially if we can work out some faction bank arrangement). so 0.0005 times 100,000 is 50, so new players will be stockpiling money at a rate of roughly 50 per trade so that puts their funds around 500 early on..

So we have early buyers hoarding magnesium with 100 to 500 of leverage against a market up to 1500 a unit.. that means they will be doing at worst microtransactions of 100 out of 1500 or 6.667% of 1. 6.667% of 1 is 0.1499992500000 etc

total cheapskates may try to buy price 1 against 1500 which is 0.0667% of 1. which is like 0.0667 of ore. Is Space engineers even that precise itself on ore quantities?
That gives us 4 decimal precision.

On the flip side buying 1 currency unit of iron at 0.0005 equals 2000 iron. 0.5 = 1000 iron, 0.25 = 500, 0.125 = 250, 0.0005 = 1 iron. Once again we get 4 decimal places.

So I call 4 decimal places, plus one more for a buffer zone, giving us maximum item precision of 5 decimal places on ore quantities.

That sound reasonable ?

[jpcsupplies]

In regard to localisation - does that come into play server side at all ? I can see it becoming an issue client side, if we have a major pvp and trade server going, it may attract players from non-english places (including the game makers themself to try it out) Even if it does come into play server side, (or even if it doesnt) we have the potential issue that a client is requesting an item name the server's localisation prevents it from recognising..
or vice versa.. you would probably hit the same issue in your invadd command on admin mod.. is it possible to request the sub ids in all the different localised languages i wonder, but do we want to, the performance loss would be horrendous ? What we may need to do here is some first run logic, that builds a conversion table of all the potential localised sub-id spellings.. and use that to map back to our actual item id ?

Next we need to decide do we just run the market in english, or also have market price lists converted based on client localisation..

I think the best strategy here is, leave enough flexibility in the code to slot in localisation later, but focus mainly on the assumption of it being in english both client/server side.

Also maybe allow for the possibility of matching non-english client/server item names in non-english hosting.. so server matches client and the point is moot..

that just leaves mixed client environments to worry about down the line; a much less troublesome milestone, since mixed clients will simply adopt the hosting localisation spelling for commodities, and once again issue is nearly moot

[midspace]

The Admin mod works with localization currently. /drop, /invadd, and /invins all use the localized names of components.

It's only the display name however. The identifiers which are most important, are still TypeId and SubtypeName. As long as we store both of those, it doesn't matter what language it appears in.

The server hopefully will only have to deal minimally with localization. I added more here on it: https://github.com/jpcsupplies/Economy_mod/issues/40

Mixed client environments should work. Again, we'll be passing the TypeId and SubtypeName where possible, not the display name.

[midspace]

We'll need to investigate the smallest quantity that SE handles in regards to Ore and Ingots, to make sure we aren't short changing anyone. It acts a little weirdly with small values, using "<" as a prefix to values.

[jpcsupplies]

re in-game investigation:
containers show 2 decimal places, moving ore shows 3 decimal places trying to move invalid amounts gives warnings in 6 decimal places

Conclusion: game is working in 6 decimal places, when moving ores it rounds to 3 decimal places, when displaying ores it rounds to 2 decimal places.

[jpcsupplies]

Also re: OP we can definately consider the price table sorted too

[midspace]

Sorting should only be done when displaying. As display names are localized, it can only really be sorted when displaying. There is a Linq expression for sorting items, which basically gos Items.OrderBy(e => e.DisplayName)

[jpcsupplies]

Sorry when i say sorted i mean this issue has been done to the satisfaction of the desired aims of the original post LOL In other words I was saying you nailed it, unless you can think of any more tweaks, close the issue you got it right :)

[midspace]

:laughing:

[jpcsupplies]

Going to close this, the OP issue is done; we have a product table to work with for the next stage.. on the decimal issue ill copy that to a new issue post