Oolite Bulletins

I'm quite happy with the effect of this experimental oxp, so I have added it to the manager.

In the core game the primary market of a system is being reset every time the player hyper jumps to the system. Even if the actual game time when leaving the system and re-entering it is calculated in hours. I see this behavior as a relic from the original Elite.

This oxp remembers the market when the player leaves a system and on re-entering the system again alters the prices to be somewhere between the old quantities and the new core calculated quantities. The calculation is done gradually so that the sooner (fewer jumps) the player returns the market quantities are closer to the old market. After five jumps the cooldown effect fades away.

In effect this means that if you're zipping between two systems, buying furs from one and computers from the other, the markets of those commodities in those systems pretty much dry out in one system and saturate in the other system.

This hopefully makes trading a bit more interesting and encourages to find longer trade routes rather than simply zipping between two adjacent opposite eco systems.

Ah nice! I always feel a bit guilty of using an exploit when doing this.

Is it possible to change updateGeneralCommodityDefinition() to updateLocalCommodityDefinition() so that it is applied to all stations in the system?

Also, could it be an opportunity to merge your script that fixes the market definitions of older OXPs (https://bb.oolite.space/viewtopic.php?f=4&t=17621)?

Astrobe wrote:

Is it possible to change updateGeneralCommodityDefinition() to updateLocalCommodityDefinition() so that it is applied to all stations in the system?

I don't think it works like that. I'm altering the primary market for the goods by using updateGeneralCommodityDefinition() in a market_script defined in trade-goods.plist. With the new style market definitions, the alterations should be reflected to the secondary markets too because the secondary markets are calculated from the primary market.

UpdateLocalCommodityDefinition() on the other hand would need to be added to the system's market_script and it works pretty much like updateGeneralCommodityDefinition(), except it's run after that.

With the old style markets, simply converted with the script I provided long time ago, there's not much to be done . The best approach would be to define those markets again with the new method.

Astrobe wrote:

Also, could it be an opportunity to merge your script that fixes the market definitions of older OXPs (https://bb.oolite.space/viewtopic.php?f=4&t=17621)?

Alas, that's not really possible. I wrote the script to help getting those stations up and running again. Someone really should re-imagine those markets with the new style market definitions.

I like a lot the idea but it seems it's incompatible with Smugglers - The Galactic Underworld, if I start a new game with both OXPs (and nothing else) Smugglers won't work correctly.

As an experimental oxp like this it's highly likely there are conflicts. It was originally written to test the conceptual idea of more persistent markets and since I found it to work well with a basically oxp free game, I decided to release it into the wild for others to test and possibly play with. Smuggler's oxp probably uses market_script in trader-goods.plist causing conflict.

If there's enough interest for it, I might take it further and try to resolve the possible conflicts. And maybe even find a way to somehow cope with oldish style secondary stations. But for now there's no guarantee it would not clash with other OXPs. Be warned. Now how's that for a disclaimer?

From my part there's definite interest, it would make economy much more interesting already. Unfortunately for that reason alone I had to remove it from my list.

I don't know how the economy system works right now, but were it possible to tie prices to available quantities? Eg, an agricultural world would restock a certain quantity of food/furs/etc every day, then the prices would be calculated on the base of the available quantity. If the player buys all computers in a system and comes back too soon, would find none in stock and the prices increased.
This would also solve the issue that basically you don't need to buy cheap commodities, you always buy the most expensive ones because they grant the most profit (very unrealistic).

spara wrote:

Smuggler's oxp probably uses market_script in trader-goods.plist

Yes it does! I think the work-arounds are likely to get ugly-- my first thought is that we'd create some form of meta-oxp that does the job of adding a market script to trade goods, and which also exposes a function that allows third-parties to hook into it, with similar inputs and outputs of updateGeneralCommodityDefinition. Then both Smugglers and Market Cooldown could both hook into this script and apply their prices at the same time. This exposed function would keep a list of all OXP's it needs to call and process them in turn.

I'm sure their are probably holes in this concept, so it would need a little work.

[Edit] And yes, there are holes. I think the earliest we could register 3rd party scripts would be this.startUp, and I think it's already too late by then - all the commodity prices have been defined. So scratch that idea.

Ross154 wrote:

I don't know how the economy system works right now, but were it possible to tie prices to available quantities?...

Everything is basically possible, Oolite is very flexible. The bigger problem is creating a working and balanced system that cannot be easily exploited. The main challenge with altering the prices based on quantities is naturally eliminating the player impact. Once upon a time there was a space trading game called FOFT (Federation of free traders). I was very exited about at that time since it had reacting markets and other stuff that Elite did not have. Too bad you never had to leave the station since the prices started climbing when you bought goods. Then you just sold them back at higher price, waited for the prices to drop again and so on. Fun for the first time, killed the game for me afterwards. I just could not not exploit the flaw.

phkb wrote:

I think the earliest we could register 3rd party scripts would be this.startUp, and I think it's already too late by then - all the commodity prices have been defined. So scratch that idea.

From my experience, on the first run (meaning startUp), the quantities and prices are restored from the save file rather than defined from the trade-goods.plist. In other words, the solution should work since the first time there is a need to define prices is after the first hyper jump.

Ross154 wrote:

I don't know how the economy system works right now, but were it possible to tie prices to available quantities?

In fact this OXP doesn't come out of the blue. There is a discussion thread where people were talking about various things including how to make markets more interesting.

One of the ideas that came up in this thread is that 'interesting' doesn't necessary means 'more profitable'. Hence the idea to play with quantities rather than prices. Interestingly, Smugglers does that too: if you don't use the "smuggling" features, its effect is making commodities unavailable by introducing random bans.

spara wrote:

Ross154 wrote:

I don't know how the economy system works right now, but were it possible to tie prices to available quantities?...

Everything is basically possible, Oolite is very flexible. The bigger problem is creating a working and balanced system that cannot be easily exploited. The main challenge with altering the prices based on quantities is naturally eliminating the player impact. Once upon a time there was a space trading game called FOFT (Federation of free traders). I was very exited about at that time since it had reacting markets and other stuff that Elite did not have. Too bad you never had to leave the station since the prices started climbing when you bought goods. Then you just sold them back at higher price, waited for the prices to drop again and so on. Fun for the first time, killed the game for me afterwards. I just could not not exploit the flaw.

Yes it's true, I didn't think about that, but there could be 'antidotes'.. Maybe a 'safety stock', that is a minimum quantity in stock under which the price increases. So if you buy and bring the quantity to this threshold, price would be higher for subsequent quantities bought. If you sell and stocks are under the 'safety' value, only the first tonnes you sell would get a very good price, after that price would be normalized. When you buy/sell all with 'enter' key, this should be taken into account (automatically buys/sells all until price change, then you can evaluate the situation). Right now, it's a bit weird for example how poor agricultural planets eat all those computers you sell them at high prices. I understand they could need some if their stocks are empty, but not if they have enough already for their needs. So even in importer planets, prices would normalize after that 'safety stock' is reached.
The station market could also 'remember' if you bought something from them recently, and forbid you to sell them back the same ware too soon. So you could 'keep buying', but not 'buy and sell' repeatedly the same ware at the same station in a given amount of time.

I think an economy rebalance can be done at different levels.
A basic level would be your OXP, if it's safe and simple maybe phkb could integrate it in his Smuggling OXP?

A second level would be keeping the current trade goods/planet types system but introducing more elaborate price calculations based on quantities, planet types etc. Looking at the trader-goods.plist, I realized that the base system doesn't allow for much flexibility
This basically makes it so, that there are only two kinds of economy. Being able to set the import/export value for each trade good and for each economy type would be a big improvement.

The third level would be to change radically the system, a bit along these lines, making it more similar to Frontier Elite 2, with more trade goods, but different imports/exports for each planet (similarly to what Smugglers OXP does for illegal goods), that would be a lot of work though.

I think that one of the key elements of the original Elite was a seemingly complex economy system that in fact was really simple. You could find those juicy planet pairs and just milk them. That was an exploration element.

Making things more complex brings challenge and interest, but is quite laborous to create. And by that I mean, it requires lots of testing. And it still might not work.

And I'm in favor of all attempts to make a more interesting markets, but so far there has not been much success. Which I think means that it's a really difficult task. Not programming it, but designing such a system.

This OXP keeps the original system in place, but tries to make the easiest and the most obvious trading scheme a bit less profitable. And I think it achieves that well. But is the game more interesting and possibly more fun with it? That's the big question.

After a bit of pondering, I think that the sane way to make this work with all those other OXPs out there would be to make this one to work as a centralized market saver that the other OXPs can query for quantities. Assuming they want to, of course.

Basically this OXP would save the primary market and the secondary markets on system exit, and keep it's counters running. And it would do nothing more. There would be a public function than can be queried by other OXPs. When a system is revisited, then the OXP responsible for the system market sends the goodDefinition it gets from the core game to this OXP and this OXP would return it with altered quantity.

This OXP would need to be split into two, the market saver part and the system modifier part. The market saver part would be compatible with everything as it just saves the market data, runs the cooldown counters and houses the public function for quantity cooldown. The other OXP would be in conflict with every other OXP out there that want to use the market_scripts in trade-goods.plist.

With this scheme and Smuggler's..., the market altering component would be left uninstalled and Smuggler's... would just call the quantity altering function from the market saver function.

How's that sound? Is it worth trying?

spara wrote:

How's that sound? Is it worth trying?

I think so, I would like to use it to control quantities of my custom commodity, so even if you don't I'd like to try to integrate the code into my market_script.

Stormrider wrote:

spara wrote:

How's that sound? Is it worth trying?

I think so, I would like to use it to control quantities of my custom commodity, so even if you don't I'd like to try to integrate the code into my market_script.

I'm happy if my code is of some use. I'll make it more generic (currently it only saves the system market), and easier to use. Should not be too hard.

spara wrote:

Should not be too hard.

Thanks, I'm thinking of creating more custom commodities and this will be invaluable for preventing exploitation.