(WIP) F4 Interface Restructure

[phkb]

This is a very experimental OXP. What it does is change the way the F4 Interfaces screen works. Instead of having potentially several pages of interfaces in one long list, it breaks up the page into the various categories. You select the category, and the interfaces for that category are then shown. Here's a quick screenshot of a possible list of categories, with the "Ship Systems" category selected:

Pressing enter on that item would display this:


Basically, the goal of this mod is to make the F4 screen a little easier to work with when there are a lot of interfaces added.

This isn't perfect or even complete yet. I haven't put the "summary" for each interface somewhere on the page, and I have yet to add paging mechanics to the screens, so if your suite of mods adds more that a screen's worth of categories, or there is more than a screen's worth of interfaces in a particular category, there will probably be issues. There are also a couple of OXP's that don't get along with this one, and given what I'm attempting to do I'm sure there will be others I haven't found yet.

The first one is Library PAD. A version of Library with the fix applied can be downloaded here: Library_1.8.5.oxz

The other OXP (that I know of) that also has a bit of a problem is Explorer's Club. The fix is quite simple. In version 1.4.6, in the "script.js" file, on line 182, find this snippet of code (which is at the end of a long line of code):

Code: Select all

this._xc_choice

and change it to this:

Code: Select all

this._xc_choice.bind(this)

Anyway, feedback welcome. You can download the initial version (0.1) here: InterfaceRestructure.oxz
And feel free to put forward your suggestions for a better name.

[cbr]

I find all contracts under deliveries?

Would it be possible to select 3 favorable ones placed before the categories?
(Example I would like (the) Gallery on one of these positions)

Seems like a good idea for oxp hoarders...

[DGill]

I have a slight issue with how the restructure affects Runscreen pages.

Probably a bit too obscure for you to comment upon but any thoughts on the matter would be appreciated.

WITHOUT InterfaceRestructure on landing on a planet I get the screen:



pressing F4 I get:



Selecting the highlighted option then gives a series of screens e.g.



then:



etc.

WITH InterfaceRestructure on landing on a planet I get the same initial screen:



pressing F4 I get:



which gives:


BUT instead of the sequence continuing it stops. Pressing F4 just brings me back to:

[Wildeblood]

What it does is change the way the F4 Interfaces screen works... Basically, the goal of this mod is to make the F4 screen a little easier to work with when there are a lot of interfaces added.

Without even a glance at the OXP, I have enough information. I denounceth thee: well-intentioned, but misguided. Your effort would be better spent editing those OXPs that created all those unique categories (if it's unique, it's not a category) to use the actual standard categories defined in descriptions.plist.

The other OXP (that I know of) that also has a bit of a problem is Explorer's Club. The fix is quite simple. In version 1.4.6, in the "script.js" file, on line 182, find this snippet of code (which is at the end of a long line of code):

Code: Select all

this._xc_choice

and change it to this:

Code: Select all

this._xc_choice.bind(this)

Done.

[DGill]

I have a slight issue with how the restructure affects Runscreen pages.

Don't know if the following error messages have anything to do with the issue:

15:27:16.556 [Feudal_PlanetFall2]: Monkey-patching shipWillEnterWitchspace, shipWillLaunchFromStation, and shipWillExitWitchspace functions of Feudal states PlanetFall script
15:29:05.429 [script.javaScript.exception.ooliteDefined]: ***** JavaScript exception (InterfaceRestructure 0.1): Error: mission.runScreen: Invalid arguments (undefined) -- expected function.
15:29:13.333 [script.javaScript.exception.ooliteDefined]: ***** JavaScript exception (InterfaceRestructure 0.1): Error: mission.runScreen: Invalid arguments (undefined) -- expected function.
15:29:15.380 [exit.context]: Exiting: Shift-escape pressed.
15:29:15.390 [gameController.exitApp]: .GNUstepDefaults synchronized.

[Cholmondely]

The problem is the categories. You will put something in one, I'll put it in another. So there is not so much consistency.

I saw this with the "Systems OXP" category. When I discovered Oolite, the only Systems OXPs seemed to be ones in political systems (Anarchies, Feudals etc). Plus Rescue Stations which I couldn't then get my head around.

So I used to get shirty with Redspear classifying all sorts of things as "Systems OXPs". And then a couple of months ago I came across an ancient post by Cim proposing the "Systems category" which explained what Redspear had done. I'd not seen that definition of "Systems" anywhere else.

And despite my vast number of OXPs, it only takes 4 key-presses to get from one end of the F4 screen to the other. Maybe I just need a taller monitor?

And there is always Alnivel's  Interface Reordering OXP for regrouping things on the F4 screen.

[Wildeblood]

The problem is the categories. You will put something in one, I'll put it in another. So there is not so much consistency.

As I've said before, more than once, if people just make up new, unique "categories" to make their entry stand out in the list, it's not a category. Some people just need to be bashed over the head with a dictionary.

I saw this with the "Systems OXP" category. When I discovered Oolite, the only Systems OXPs seemed to be ones in political systems (Anarchies, Feudals etc). Plus Rescue Stations which I couldn't then get my head around.

Categories of OXPs (outside the game) has - or at least should have - nothing to do with categories of station-to-ship interfaces available dockside (inside the game).

And despite my vast number of OXPs, it only takes 4 key-presses to get from one end of the F4 screen to the other.

Quite so. This is attempting to solve a non-existent problem. Paging through a short list is infinitely preferable to trying to find something lost in tree with too many branches.

The expansions manager, on the other hand, now requires 80 key-presses to page through the whole list, but has not suffered runaway new-category creation. That would benefit from being changed from a list to a tree.

[Cholmondely]

Categories of OXPs (outside the game) has - or at least should have - nothing to do with categories of station-to-ship interfaces available dockside (inside the game).

Both consist of categories which are self-selected by individuals without any moderation by others. In neither case is a definition readily available.

The differences are that (i) with the F4 screen it's easy to invent new categories and (ii) there are not 1,200 entries on the F4 screen (yet!).

[Wildeblood]

Categories of OXPs (outside the game) has - or at least should have - nothing to do with categories of station-to-ship interfaces available dockside (inside the game).

Both consist of categories which are self-selected by individuals without any moderation by others. In neither case is a definition readily available.

The problem (being discussed now) is not the self-selection*, it is the gratuitous creation of new "categories". Stop being obtuse.

The differences are that (i) with the F4 screen it's easy to invent new categories and (ii) there are not 1,200 entries on the F4 screen (yet!).

I believe that's what I said. Although, it's worth noting that it is just as easy to invent new categories for the expansion manager; it is not necessarily the case that just because something can be abused, it will be. The problem with the F4 screen is that you've all just accepted this poor behaviour.

* And the "definition" herring is offensively red; as I said in my previous message, consult a dictionary.

[phkb]

OK, that was different.

Before we burn me at the stake for trying to fix something that doesn't need fixing, some context might be useful. Over on Discord, I'm attempting to help a blind gamer interact with Oolite. They have already created their own OXP to help them "see" various screens, but the F4 screen, when read by a screen reader, ends up being read out in all sorts of weird ways. By converting all the content into a mission screen, I can control how it is read, making it far more useful.

I find all contracts under deliveries?

I'm just working with the categories in use. I'm not attempting to change or remove any of them. Although, that being said, I *could* force categories onto all interfaces, so anything that isn't one of the built in ones gets put in "Miscellaneous" or something. Hmm....

I have a slight issue with how the restructure affects Runscreen pages.

This was what I was alluding to when I said some screens don't work well with this. It's generally a case of adding ".bind(this)" to the choices callback for the mission screen. I'll run some tests on Feudal States and let you know if I find anything else.

As I've said before, more than once, if people just make up new, unique "categories" to make their entry stand out in the list, it's not a category.

If all this does is highlight some bad OXP dev practices and encourages a clean up, I'll take that as a win.

Don't know if the following error messages have anything to do with the issue:

Very likely. I'll investigate the Feudal states screens this evening. Not sure where the problem lies at the moment.

[Wildeblood]

The other OXP (that I know of) that also has a bit of a problem is Explorer's Club. The fix is quite simple...

Done.

Ahem! Still showing as 1.4.6 in the downloadifier, which is not actually downloadable.

[phkb]

Ahem! Still showing as 1.4.6 in the downloadifier, which is not actually downloadable.

I’ve kicked off the update process. Should be completed shortly

[phkb]

Don't know if the following error messages have anything to do with the issue:

The error highlights the issue.

The issue is all about context. I'm trying to give the calling script the current context, and for the initial call to the callback function, my tests show that each one does get the correct context. The problem is at the next stage, where the mission screen wants to execute the choice callback. For some reason (which I haven't gotten to the bottom of) the context reverts back to my script, unless the callback is bound to the correct script using ".bind(this)".

This will only impact on mission screens called from an item on the F4 Interfaces screen. Normal mission screens (initiated from "missionScreenOpportunity") should be unaffected.

The fix is in a couple of places in the "feudal-mission.js" file. And while there are a mix of normal mission screens and F4 Interface callbacks, it would be pretty hard to split out the unnecessary ones, so the easiest way (given the number of instances) is to do a search/replace:

Search for

Code: Select all

this.choiceEvaluation)

(the bracket at the end is important) and replace with this:

Code: Select all

this.choiceEvaluation.bind(this))

(again, the double bracket is important).

Search for

Code: Select all

this.choiceInterogation)

and replace with this:

Code: Select all

this.choiceInterogation.bind(this))

Search for

Code: Select all

this.choiceFlitterChancery)

and replace with this:

Code: Select all

this.choiceFlitterChancery.bind(this))

Search for

Code: Select all

this.choiceCommieEvaluation)

and replace with this:

Code: Select all

this.choiceCommieEvaluation.bind(this))

Search for

Code: Select all

this.feudalRescueChoice)

and replace with this:

Code: Select all

this.feudalRescueChoice.bind(this))

With that done, the issue should be resolved.

[DGill]

Ok, thanks. I'll give it a go.

[DGill]

The fix is in a couple of places in the "feudal-mission.js" file.

Yeh! Great stuff - the fix works well.