CmdrSvengali
commented
8 years ago An example can be found in Library (Lib_GUI.js) and BGS -> https://app.box.com/s/h9qnmebf7zv96cjr5d90brno3tevwr95 The main reason to unify the handling is that execution order of scripts varies. So we are getting races between AddOns to get their screens shown. Luckily all authors of background-AddOns are still around and already signaled to join.
There is another aspect though - plists and paused games can't be handled by JS, so you may end with an Intro and paused screens from OXP-A and ingame screens from OXP-B. Sure it is the users decision to install AddOns or not, but maybe it could be made consistent by allowing users to set preferences which are exposed to JS?
Opening this issue following the below PM received by Svengali:
---Begin quote I guess we should start with a short summary to get an overview. Correct me if I'm wrong.
Currently we do have a few AddOns which are providing background images, sounds or gui-settings and they are all using different ways to do it. A mixture of plist and JS resulting in style clashes clearly visible for users. The only way to solve it is to declare conflict_oxps in manifest.plist and by adding ways to configure AddOns ingame.
screenbackgrounds.plist, gui.settings.plist and customsounds.plist are read by the game. Their loading order is OS dependant. Windows and Macs seem to load alphabetical, Linux unpredictable. As the keys are overriding each other you may end with a mixture if not all keys are declared in all AddOns. This can't be handled yet.
The JS context is only available after a savedgame has been loaded and the game is not paused. And here we are getting the same in green. Execution order of scripts is not set in stone - it may vary. This can be handled.
A possible approach for a generic handling is to use one library script which does nothing on its own until content has been pushed. The way it works is Set-based, means that at any given time only one Set is active. Rules for missionscreens can be applied as well. If no rule for a screen is declared or disallows changes the script won't do anything.
Background-AddOns simply declare their Sets on .startUp and write to the library-script with an unique identifier. After that point they can forget about it. But it's also possible to declare the Set as script property and just write a reference to allow changes on the fly (e.g. rescaling). AddOns with missionscreens may add their rules at any time, it's optional and the authors choice.
On .startUpComplete the library script starts its job. It will read the stored preference which may be set in the savedgame, or if none is stored use the last Set if any. Then it creates the configuration object which is accessible through the interface.
Does it sound plausible? ---End quote