Oolite Bulletins

Hi,

I had this argument in another thread. But I think it is time to separate this topic from the other thread.

Sometimes especially trying to write a mission OXP, you may find out if the player has some OXP's installed, your mission plot does not make sense. You may inform the player via the Read_me file and ask the player to remove the clashing OXP's with your mission OXP. But I don't think this is an elegant solution.

If the OXP uses a special equipment, you can easily remove it by code. But if the OXP is using timers to check for a certain condition you will need to implement timers to remove unwanted entities. Which may cause performance problems.

So for the opening post, I will propose a suspend property to be implemented by the OXP's so that in one stage, another OXP can change it through worldScripts quite easily and set it to true. To set that property back to false must be responsibility of the OXP author. I would not use a mission variable for that, because mission variables are saved with the save files. If the OXP does not reset it to the normal mode, loading a saved file will do.

We may find the right way to implement this very soon.

The following is my proposal,
I would like to see progressive replies that our game will benefit from this.

Regards,

Scripting configurable OXPs is a good thing and gives users and/or OXPs options.

Just Brain storming,

The OXP load order is not predictable as far as I can see from other posts.

What can be done about that?

Edit: Svengali Thanks for the reply, but I believe that issue must be solved in the core game some how in future releases.

Sure, it's better to avoid the problems at all from the very first beginning of writing a new OXP.

'Fixing' the problems afterwards via OXP mechanism is no walk in the park and has limits and the loading order is only one of the problems. Dependencies, script interactions, removing/readding OXPs, outdated OXPs, etc. are pretty much a showstopper for a OXP solution. To overcome the problems it would need a pretty complex approach, combining properties, missionVariables and script_info keys and even this wouldn't solve all possible problems. A lot of fun is waiting... .-)

So, it's really a good thing to give other OXPs at least the possibility to disable specific features if they are likely to clash.

Edit: Before I forget. A few weeks ago I've started to put the offline docs for my OXPs in a new Category OXPDoc which is a subcategory of Oolite scripting.
It's probably not a bad idea to place other docs for OXPs there too.

I went so far as to consolidate a few "simple" stations and a couple objects into a single OXP's single .JS script. That way it can in order check which one/s get spawned and under what conditions. I was wanting only 1 large secondary station near the main station...be it a SuperHub, Globe, Nuit, or Sothis depending on the system's tech level, economy, and goverment type. This started out because I was frustrated with SuperHub not being consistently present even at TL 13-15 Rich Industrial systems. Low-end systems (Poor Agri. Anarchies for instance) get none of those. Other secondary stations (Black Monks Monastery, Hoopy Casino, Buoy Repair, Free Trade Zone, Space Bar) only get added based on other criteria. I even added a catch-all to add 1 Rock Hermit or Pirate Cove if NO other stations of any kind are found in-system -- including other Rock Hermits or Pirate Coves! Considering the 1 added RH or PC will not be in the middle of the standard shipping lane or may even be badly off-center of the planet-sun route, the system will still probably feel empty. If you have Rock Hermit Locator OXP, you can still find that easily.

Intentionally absent (though easily included) is Con Stores from Your Ad Here! OXP. These brutalize my game's framerate too badly with those stations + billboards + various active scripts...or whatever they do. Plus, they have prices too badly disconnected from normal ranges for me to enjoy them.

I also use Dictators and Commies! which I figured in when to add other stations. Communist systems for instance would probably not allow such gross capitalism or grand displays of personal wealth as secondary stations beyond what they already produce. Dictators would have their own limits.

I also consolidated all these stations' commodities files into 1 file using the more compact form. (OpenStep?) This puts most price ranges similar to the main station, often vastly changing the original OXPs intents. Some were originally quite crazy, such as 0.4 credits for an item that normally sells for >20 credits! Strangely, there's limited coupling in prices -- the main station may be high on 1 item while a (nearby?) secondary station may be low even if using duplicate commodity lists!

I think using a standard callback may be an idea. I had a look over to Cabal common library and to keep an array of objects registered with makes sense. There are two ways of achieving this task, either to use primitive way of encapsulation(which is copy and paste ) or have a standard OXP which can be used from other OXP's.

I made some progress in this topic. The reason I had to do was a [WIP] mission OXP was clashing with my OresratiChalenge OXP.

I changed the script of OresratiChalenge as follows.
So the other OXP who wants to suspend OresratiChalenge just needs to write a function used as a callback, and register it with OresratiChalenge as follows. Please comment on this approach and if it is acceptable by most of you we can find a way to solve that problem.


Edited: Moved registering the call back to startUp.

Having looked through your code, Okti, I will say that this method is looking rather good. I have an unfinished OXP called Visas which uses a single entry in an array (one for each visa) that says whether the visa is enabled or not. This has the issue that one OXP can suspend the visa and another could override it. This type of solution would solve that issue. (OK doesn't stop OXP's deleting other OXP's callbacks but you can't stop everything.)

The only concern and I am not sure how much of a real issue it would be (as I cannot think of a scenario where it would occur) is startUp issues. This could be an issue if the OXP to be suspended does something that would need to be suspended during its startUp function. In your OXP you only have suspended code in the two events shipSpawned and shipWillDockWithStation so there are no startUp issues. For an OXP that does do something that requires suspending in its startUp, whether it would be suspended would be dependent on load order and if the suspending OXP's startUp get called later than the one to be suspended then it would be too late.

I have considered whether a solution like the one I put in the wiki for OXP dependencies would solve that (see here) but it wouldn't as dependencies require the dependent OXP's startUps to be called first where as the suspended OXP needs to run last (or rather after the last suspending OXP) which isn't possible to arrange.

The only solution is that code that would need suspending can not be included or called from its startUp function. As I said earlier I am not really sure that this would be major issue.

Phantor Gorth

Regarding the last solution, I tested all the possible situations, and it worked fine. Only with one exception.

When I loaded a save file in the mission trying to suspend OresratiChallange, in Oresrati I found that the OXP is not suspended. That may be because of the load order.

As far as I can understand startUp function of an OXP depends on the load order.

But I think we made some progress on that.

Thanks Phantor Gorth for responding and that issue can be solved by the developers quite easily. If they are interested I will post the log files.

Edit: This is only valid for suspending a mission, but suspending an unwanted behavior after the player ship is launched is not a problem

I doubt that is a load order issue. I think this is because when you load from save you are already in Oresrati and the ship will have already spawned. The player will be in the station and so the shipWillLaunchFromStation hasn't been called and consequently the addToCallbacks won't have been called. You need to add a function that deletes all the appropriate ships and call that just before launch only if you are in Oresrati.

Just tried to add code to correct this. but the bits from log are below


19:43:33.883 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (OtherOXP-Main 0.1.13): TypeError: this.suspendCallbacks is undefined
19:43:33.883 [script.javaScript.exception.unexpectedType]: ../AddOns/OresratiChalenge v0.1.oxp/Scripts/oresratichalange_main.js, line 22.

"this" object is a fickle beast in Javascript. I suggest you add "this.suspendCallbacks = [];" to the root of your script (one nested layer above that function). In fact you can probably do without your startUp unless you use it something else as the root vars and this variables get re-initialised on load and restarts too.

PhantorGorth wrote:

""this" object is a fickle beast in Javascript. I suggest you add "this.suspendCallbacks = [];" to the root of your script (one nested layer above that function). In fact you can probably do without your startUp unless you use it something else as the root vars and this variables get re-initialised on load and restarts too.

Hurray that solved the problem. So we do have a proposed solution to mission clashes.

Thanks.
Okti

Edit: Talking in IRC helped a lot as well. I will try to release new version of OresratiChallenge tomorow and update the code proposed tomorow.

It was my pleasure, Okti