NOTICE: Regarding Pennsylvania Zoner Pilots Exploit

[jammi]

Wouldn't it simply be better to switch back to the original vanilla system of economy/commodities? All that fancy buy/sell price stuff is overcomplicating things now that the POBs have factories anyway, so there is no real need for that. And as it seems it is prone to errors. Better use your time and energy to flesh out the economy and create some real linear prices based on availability/demand/distance from producer. And I guess all that scripting is more power/server-hungry than the vanilla prices that are just written into each NPC base/planet.

The way the economy is calculated is a bit opaque so I'll try to give a brief summary.

In vanilla, each commodity had a base value, which is the default price stations will buy it for. Actual prices are then set for each station through a market ini file. This price isn't written out as the actual buy value - say for example $63, but a multiplier of the base value. So, if a base value was 50, and I wanted a station to buy the thing for $63, the modifier was 1.26. Base value and these modifiers are defined in separate files which meant reading a market file was not human readable without a lot of cross referencing.

Here's an excerpt from market_commodities.ini to show you what this data format currently looks like:

Code:

[BaseGood]
base = li18_03_base
MarketGood = commodity_pharm, 0, -1, 9, 1, 0, 1.0000111111111112
MarketGood = commodity_robotic_hardware, 0, -1, 24, 0, 0, 3.0000125
MarketGood = commodity_bluediamonds, 0, -1, 203, 0, 1, 2.030001
MarketGood = commodity_casualties, 0, -1, 1, 1, 0, 2.42240002
MarketGood = commodity_catalysts, 0, -1, 79, 0, 1, 9.8750125
MarketGood = commodity_gin, 0, -1, 60, 0, 0, 3.529417647058824

Now, before the current system, managing prices was largely the job of Xoria who kept an enormous database of each commodity, base, and interlinked route. All of these prices had to be manually adjusted and painstakingly tested using the game's shortest path file timings to tweak prices so the routes were neither overpowered or non-viable. The problem is, whenever jump connections were adjusted, travel times changed, or new stations were added, this would necessitate massive overhauls to this pricing network, because you're never adjusting two parameters in isolation.

This took forever and frequently resulted in bases being added with no economy data at all, because it simply couldn't be done in a timely manner. For reference, market_commodities.ini currently contains 22,307 lines of text. Managing this file manually was an incredibly burdensome task that also required an extremely high minimum floor of skill, which put up a huge barrier to entry for people looking to help with econ dev work.

Haste created an automated pricing calculator that can do this price setting based on a config file econ devs fill out. I tried to attach a copy of this file so people can see what it looks like, but the forum apparently doesn't like the file extension (we shared this during the last round of econ dev recruitment too). Here's the entirety of the base entry for the above example, rather than just a small excerpt:

Code:

[Base]
nickname = li18_03_base
type = resort_station
consumes = bundle_alcohol
consumes = bundle_contraband_drug
consumes = bundle_contraband_luxury
consumes = bundle_luxuries
consumes = bundle_manufacturing_general
consumes = bundle_necessities
consumes = bundle_passengers_luxury
consumes = bundle_repair
consumes = bundle_sirius_fuel
consumes = bundle_treatment, demand = 1.15
consumes = commodity_biodome
resells = commodity_casualties
consumes = commodity_gc_drug
produces = commodity_pharm
resells = commodity_crew
resells = commodity_luxury_consumer_goods
resells = commodity_medstasis
resells = commodity_passengers_li
resells = commodity_scientists
resells = commodity_stabiline

This is much simpler because we only need to assign commodities (or groups of commodities) to bases depending on whether they are producers (exports commodity at base value), consumers (price based on proximity to the closest producer, doesn't export) or resellers (same as consumers, but also exports the commodity). We can then add demand modifiers to add a bonus or penalty to the price, either using the base's assigned type, or individually to a particular commodity. The skill floor for getting involved is now much, much, much lower.

Haste then runs the calculator based on the config files and it sets up the prices. This isn't something that is constantly running, eating up server power - it's a utility that's run once whenever price data needs refreshing. The prices are calculated using a desired csuv rating (credits per second per unit of volume), which is what governs how many credits you will make in an hour trading that commodity. There are two main pricing curves - High Risk Commodities and all other commodities.

Regular commodities increase price in a linear manner at a constant csuv from the closest producer. High Risk Commodities have a csuv that increases on a curve up to a cap. This means the main draw of HRCs is that not only does the price increase in absolute terms with distance, the rate of profit also increases. Shipping a HRC locally might give you 7csu, while going across the map would give you 11csu for example.

As for split prices, these still serve an extremely important function, regardless of POBs having refineries and factories. Namely, we want as many routes as possible to be viable by being able to hit that "optimal" csuv value. Because of the way bases spread out like a giant web, having a single buy/sell price simply means that some bases would never have viable prices because it would create broken short routes linked to other nearby producers/consumers.

Instead, we can now pay different amounts for imports and exports to allow these bases to still economically function. It also allows us to use resell points for HRCs. Previously these were difficult because of the way their csuv scales with distance, meaning you would always earn more per hour by trading from a reseller closer to the destination, unless the export price was considerably higher to offset this.

The problem then being, the much higher price meant it was now far better to ship from the production point to that reseller than all the way to the intended destination consumer. Before we had split prices, we worked around this by having bases refuse to buy back any HRC they also sold using the "dealer not interested" audio, which was an incredibly frustrating mechanic that also jebaited a lot of people who thought they'd found an amazing route on FLC. Splitting the prices avoids that whole mess.

Anyway, needless to say, simply importing the vanilla price data into modern Discovery would be so horrendously busted that I don't think any trade route, anywhere would actually be functional.

Sorry, this wasn't brief.

---

News article library, feedback and content requests.