Oolite Bulletins

This oxp has been retired due to the fact that enough oxp stations has been upgraded to use the populator in 1.80 letting the core game to restore markets.
---
Hello.

I caught myself heavily exploiting BlOomberg and Oolite's behaviour of resetting quantities and prices of other than main station market when loading. Since I don't possess the self discipline required to stop myself, I wrote a small oxp, that does it .

This oxp notes which stations the player has visited in-system and saves the prices and quantities of those stations when saving. After loading and visiting a station again, the market is restored from save. When jumping to a new system stations visited earlier are naturally forgotten.

In-System Market Restore OXP ver 1.2 (27.6.2013)

Author: spara (Mika Spåra)

_Overview_

In the core game, only main station prices and quantities are carried over saves. Other station prices and quantities are initialized when the station is added to the game. The save/load works as a market resetter. Sometimes that feature can be disappointing and sometimes it can be exploited.

This oxp changes that behaviour. When saving and loading, it saves and restores the prices and quantities of the current system's stations.

_Requirements_

* Oolite version 1.77.

_Installing_

Install the OXP by copying In-System_Market_Restore.oxp to your AddOns-folder.

Does it work properly if a system has several stations of the same type, say three hoopy casinos?

Wildeblood wrote:

Does it work properly if a system has several stations of the same type, say three hoopy casinos?

Well, I thought it would, but it had a bug . Version 1.0.1 should work correctly with multiple stations .

Here's the logic:

* For each visited non main station, a datakey and market (prices and quantities) are saved upon save.
* After load, when visiting a station with a datakey found from the saves, market is restored once. Then the station is marked as visited and no more restoring is done on that particular station.

So if there are three casinos and they are all visited, all are marked for restore. Restoring happens quite randomly, depending on which save is pulled up first (as they are all seen as generic casinos).

There are most likely some glitches, but hopefully nothing drastic.

This OXP seems like a good idea! Downloading.

I was playing the game and watched a Thargoid invasion wipe away ConStore. After the show, I docked to the main station and saved the game. Next time I resumed the game, the ConStore was there . That behaviour started to annoy me, so I had to do something about it and here it is .

I have added into this oxp a feature that will keep those destroyed stations destroyed for 30 days. After that they will appear again.

spara wrote:

I have added into this oxp a feature that will keep those destroyed stations destroyed for 30 days. After that they will appear again.

Oh,oh - smells like trouble...

Edit: After taking a look - it is causing trouble. So why not turning this feature into an API? Participating OXPs could hook in and your script simply returns a boolean. The OXPs wouldn't spawn the entity if it's false. This wouldn't break anything as the mechanism only does it for OXPs which are prepared for it.

Svengali wrote:

spara wrote:

I have added into this oxp a feature that will keep those destroyed stations destroyed for 30 days. After that they will appear again.

Oh,oh - smells like trouble...

Edit: After taking a look - it is causing trouble.

What trouble is it causing?

Wildeblood wrote:

What trouble is it causing?

.remove(true) is a convenient way for stuff under your direct control (usually in your own OXPs), but always a bad idea if you are dealing with other OXPs content. It may even cause crashes (unrooted timers and framecallbacks). This is why I suggested to turn it into an API. I'm aware that this requires other OXPers to use it (and this may need some time), but it's the only clean way for global mechanisms.

I've just took buoyRepair, docked at this station, launched and destroyed it via Q-Mine. Then jumped to the next system and returned to the buoyRepair system. buoyRepair spawned it's station and set a value in its worldScript. Before the ships scripts are getting their destination In-System Market Restore has removed the station silently, resulting in errors in these scripts. Other OXPs will run into trouble as well. We need to be careful with 'global' mechanisms with >500 OXPs out there.

Svengali wrote:

spara wrote:

I have added into this oxp a feature that will keep those destroyed stations destroyed for 30 days. After that they will appear again.

Oh,oh - smells like trouble...

Edit: After taking a look - it is causing trouble. So why not turning this feature into an API? Participating OXPs could hook in and your script simply returns a boolean. The OXPs wouldn't spawn the entity if it's false. This wouldn't break anything as the mechanism only does it for OXPs which are prepared for it.

Sorry guys, should have warned big time... Yes, it is very likely to cause trouble. The feat removes the entity from existence after it has been spawn, as if it should never have been spawn. Maybe I should just move them to the dark side of the sun and remove their beacon? Api would otherwise be a good idea, but I find it hard to believe it would ever be used . Especially with the older station oxps, like ConStores.

I understand that this is a game, but stations popping back in just eats away immersion in a big way. I find this behavior to be very very wrong. And the reason for it is very fundamental. Oxp-makers have so many toys to play with and there's no greater scale cooperation happening. I don't know if there is any way to avoid this, as long as oxp-makers are allowed to spawn stations whenever they want and other's are allowed to destroy them when ever they want. To make this work would require such a cooperation I don't think will ever happen.

Maybe this should be debated a bit. Is it just me who is annoyed by this behavior? What could be done about it? Let me take one example out of many to stir conversation:

Thargoid Carrier comes and blasts away Sothis Station. You jump out just in time and jump back. No more Carrier and Sothis is shining again. What could be done about it? Easiest thing is not to install Thargoid Carrier , but that would be boring. KW has not been around for a while, so Sothis is hardly gonna get an update that will put a destruction timer in it.

Sorry, a bit of a long rant and I will revert the oxp back to 1.0.1 to not cause trouble from my side. But there is trouble in the air with all these oxps interacting with each other (Like Svengali just posted).

Edit: Reverted to 1.0.1. Sorry for the hassle

Edit2: @Svengali: How about simulating the destruction of an entity by removing the entity and sending a shipDied event to it (or other way around)? Would it work? Would that still cause trouble?

spara wrote:

Edit2: @Svengali: How about simulating the destruction of an entity by removing the entity and sending a shipDied event to it (or other way around)? Would it work? Would that still cause trouble?

Removing an entity automatically sends a shipDied event to it. The problem is that the to-be-removed entity has to act on that event, which is of course not the case in any existing script whose author didn't anticipate a semi-permanent removal. Or, even worse, other independent entities have to act on it (like the ships that are trying to head towards the Buoy Repair Station in Svengali's example), which is even less likely to be foreseen in old scripts.

Commander McLane wrote:

Removing an entity automatically sends a shipDied event to it. The problem is that the to-be-removed entity has to act on that event, which is of course not the case in any existing script whose author didn't anticipate a semi-permanent removal. Or, even worse, other independent entities have to act on it (like the ships that are trying to head towards the Buoy Repair Station in Svengali's example), which is even less likely to be foreseen in old scripts.

Ok. Not a good idea to do it that way either then as there might be others that react on the shipDied event. I did it without triggering the event and that on the other hand left some entities to think it still was there. Looks like a dead end. I'll try to find a better solution as discussed here.

Thanks guys for setting me straight.

spara wrote:

Thanks guys for setting me straight.

Oumpf, sorry. This wasn't the intention.

btw: I've made the same 'mistake' a whole while ago with the OXPShipRegulator. A dead-end as well

New version 1.0.2

* Changed the logic from dataKeys to roles as ConStores did not work properly earlier.

New version (1.2)

* Now fully compatible with the Market inquirer oxp. Now saves and restores all stationary markets of a system. Previously only saved the ones visited.

This is a great idea! I have installed the In-System_Market_Restore_1.2.oxp but it doesn't work 100% with commodity markets. In particular I have:

- marketObserver_2.2.2.oxp
- mO-Commodity_Markets_1.1.oxp

What seems to happen is that the base price is stored and doesn't change, but the adjustment for the buy & sell is re-generated when the game is loaded. So this is a humble feature request..