BGS - The BackgroundSet

[Diziet Sma]

the only thing which cause to working in most cases is the alphabet: placed below than the main BGS in the expansion list so usually downloaded later than the BGS and in this case filesystems usually place later into the directory list,

A workaround if the customsounds.plist or at least the clashing lines are separated from BGS into a "BGS Sounds" oxz, so BGS leave the default sounds untouched without this and surely got the another soundset if BGS and "BGS Soundset by P.A. Groove" is installed but "BGS Sounds" is not.

In this way other sound oxzs are possible like "Soundset by streb2001 with silent engines".

That works on Windows, and perhaps Macs, but on Linux, if the filesystem is Ext3 or Ext4, it is purely down to luck as to which OXP gets an earlier entry in the directory hash-tree. (See https://ext4.wiki.kernel.org/index.php/ ... irectories for the gory details)

Basically, for Ext3 and Ext4 filesystems, there is no "directory list", merely a binary tree of hashes.

The name of the file or directory is run through an algorithm to produce a "hash" or unique number. The value of this hash then determines which branch and leaf the entry for that file/directory will appear in. No matter how much fiddling around is attempted by working things alphabetically, OXPs will load in lowest-to-highest order of their hashes. See the discussion I linked to earlier for more details.

[Svengali]

Then it's worth to think about cims post.

If it's just for your personal use, OXPs or OXZs you place in the AddOns folder will always load later than OXZs placed in the ManagedAddOns folder by Oolite.

[Norby]

it is purely down to luck

Thanks for the details, I mean the same under the problem.

How about a new "loading number" field in manifest? The default value can be 100 if this field is missing so a new "patch" oxz can load before or after than an existing oxz if needed.

[streb2001]

OK, either I am thick or this is assumed knowledge since I can't find how to do this.

Svengali wrote

If you are using a custom script for your player.ship declare the properties bgs_engine, bgs_engineUp and bgs_engineDown

How do I create a custom script for player.ship that declares these properties?

[Wildeblood]

OK, either I am thick or this is assumed knowledge since I can't find how to do this.

If you are using a custom script for your player.ship declare the properties bgs_engine, bgs_engineUp and bgs_engineDown

How do I create a custom script for player.ship that declares these properties?

The player ship always has a script. Can't you just add

Code: Select all

player.ship.script.bgs_engine = ...

to any world script?

[streb2001]

This is what I am asking. So player.ship has a hidden internal "script" inside Oolite that is not defined as a flat file in Resources? I can simply add properties and methods like this:

player.ship.script.myProperty = "some_data";

My programming ideas must be so last century! A "script" to me is a flat text file containing a list of instructions that is interpreted on-the-fly rather than compiled into a binary.

[Wildeblood]

This is what I am asking. So player.ship has a hidden internal "script" inside Oolite that is not defined as a flat file in Resources?

In Resources/Scripts you'll find a default player ship script file (which is empty, but exists), that's why I said it always exists. You can edit that directly if you know what you're doing. (Watch for the howls of protest.)

I can simply add properties and methods like this:

player.ship.script.myProperty = "some_data";

I think so.

[streb2001]

It works! In my own script I have declared

Code: Select all

	//override BGS engine sounds
	player.ship.script.bgs_engine = "sprSilence.ogg"
	player.ship.script.bgs_engineUp = "sprSilence.ogg"
	player.ship.script.bgs_engineDown = "sprSilence.ogg"

and the BGS engine sounds are gone. If this is now independent of OXP loading order then I am most of the way towards a releasable OXP.

What would be great is if the other BGS sounds could be treated in the same way.

Thanks Wildeblood.

ed. Have I got this right? A JavaScript (.js) file is really a list of properties and methods that are bolted onto the end of Oolite at runtime? One script can insert properties into the runtime instance of a different script? Is this the same as "late binding" in C++. If so then I get it.

[Lone_Wolf]

One script can insert properties into the runtime instance of a different script?

yes, it can.
All worldscripts are properties of an oolite global object (can't remember which one, sorry).

here's an example of using properties from another script (taken from my ShieldCycler next 1.10.2 oxp):

code snippet from SC_Shipscript_Events.js

Code: Select all

    if ( worldScripts["Shield Cycler"]._sc_settings.sc.manual_version != worldScripts["Shield Cycler"]._sc_const.none ) 
      { 
	worldScripts["Shield Cycler"]._sc_change_configuration(3, true);
	player.ship.removeEquipment("EQ_SC_MANUAL_CONFIGURATOR_INTERNAL");
	worldScripts["Shield Cycler"]._sc_settings.sc.manual_version  = worldScripts["Shield Cycler"]._sc_const.none;
	worldScripts["Shield Cycler"]._sc_settings.sc.cycler_mask  = 0x00f;
      };

[Diziet Sma]

In Resources/Scripts you'll find a default player ship script file (which is empty, but exists), that's why I said it always exists. You can edit that directly if you know what you're doing. (Watch for the howls of protest.)

Howls of protest? That's a bit strong..

@streb2001 - What Wildeblood is poking fun at, is that the recommended method of editing default configuration files and scripts is to leave the originals intact, and instead make a copy, placed in AddOns/Config or AddOns/Scripts, then edit the copy as desired. All such files in AddOns will over-ride/append the default files. This has the added advantage that your changes will not be overwritten if/when you execute the oolite-update or oolite-trunk-update scripts.

[Svengali]

It works! In my own script I have declared
<snip>
If this is now independent of OXP loading order then I am most of the way towards a releasable OXP.

It is independent from loading order now, but neither safe nor efficient.

Inefficient because BGS still executes the engine scriptpart and sound channels are waisted by playing silence. The script in BGS is simply not prepared for a complete takeover of the engine sound handling. Unsafe because if any other OXP sets the properties too then you have even more fun with script execution order - which is not the same as the loading order fun - and it's completely unpredictable, although scripts can coordinate their work on startUp. I have used this 'chained' startUp approach in a few OXPs and it has advantages, but the more scripts are involved the required work grows rapidly and often causes ripple effects.

This is why I've said before that it's better to implement a switch in BGS-M.js. One possible way to allow other OXPs taking over functionality for specific tasks in BGS is to implement a method that simply sets flags and writes a message to the logfile. Logging is required as most of these tasks have user settings and entry points for other OXPs - and users should know where to complain :-)

It also raises some other questions - it will be interesting to hear what Tricky thinks.

[Tricky]

Sorry that I have been quiet for a while. My mother has just been in hospital for a hip replacement so I have other things on my mind at the moment.

I am keeping up with the current conversation and there are some interesting things to ponder over.

[Tricky]

Small fix for new torus speeds over the old maximum of 32 * max ship speed.

Download 1.10.7 from the in game OXZ update manager or from:

• BGS-A 1.10.7 (OXP)
• BGS-A 1.10.7 (OXZ)

[spud42]

thanks Tricky, hope your Mum is recovering quickly...

[Tricky]

thanks Tricky, hope your Mum is recovering quickly...

She is a lot better thank you.

Edit: BTW, if anyone one wants to checkout (literally) the current progress of BGS-A, it is on GitHub...
BGS-A on GitHub