Progress

[cim]

Some more visual effects additions:
- they can now be ASC beacons
- they can now have scripts attached to them
and a few small extras around that. Documentation on the Wiki is up to date, and the sunspots demo is updated with some extra example code.

---

Also some extra features for mission screens: these passenger contracts lookalikes are done entirely as mission screens.

You can dynamically set up choices using a 'choices' parameter and a Javascript object. No more need to have twelve near-identical missiontext entries for every possible combination.

You can leave blank lines in the choices menu (create a fake key with the right alphabetical sort order, set its text to be blank)

You can align the choices left, centre, or right, if you need to line things up. (Character \031 can now be used as an alignment control character as it is defined to be very narrow)


And a slight change: background and backgroundSpecial are now separate parameters, so you can have an image background and do

Code: Select all

backgroundSpecial: "LONG_RANGE_CHART"

at the same time.

As a minor bonus, if the HUD is hidden, you get six extra rows for your mission screens, which can come in useful.

[JensAyton]

(Character \031 can now be used as an alignment control character as it is defined to be very narrow)

It’s \037.

This change requires customized oolite-fonts.plists to be updated. In particular, the 32nd entry of the widths table must be changed to 0.1 (it’s generally the last one that’s exactly 6) and the line " " = "\037"; must be added to the substitutions dictionary. (That’s a Unicode “hair space”, not a normal space.) The necessary changes have been made to the encoding template OXPs.

[another_commander]

The Docking Clearance Protocol has been made a game option as of r5314. Stations which already contain a requires_docking_clearance key in their shipdata.plist are not affected by the global setting.

[Griff]

...Also some extra features for mission screens: these passenger contracts lookalikes are done entirely as mission screens....

Wow, this looks really great! Beginings of a 'Fontier' style bulletin board

[cim]

Beginings of a 'Fontier' style bulletin board

Sort of. That and a few other things.

One of the problems with missionScreenOpportunity is that it only really works for cases where you want to push information and choices to the player as soon as they dock. If you want the player to initiate the request, the solution so far has been to have a particular key combination activate the mission screen. (e.g. F7 for Snoopers, F2 F6 for Explorer's Club, etc.) and we're rapidly running out of combinations that just bring up the built-in screen.

So, as of today's build (r5328), in trunk you can define "interfaces". Each station has its own interface list, which contains the "things you can do at this station" plus "things you can do with your ship". The distinction between the two basically determines whether you define the interface just for a specific (type of) station, or for every station the player docks at.

The player can then view the list of interfaces by pressing F4 while docked

read the summaries, and then when they activate one, your specified callback function is called, and then you run the mission screen. See the station.setInterface docs for more details.

The interfaces are categorised and sorted by category. For easier translation and consistency, I'd like to add a few common categories to the core descriptions.plist: suggestions for what they should be are welcome.


So that there's always an interface available to get players used to checking the screen, the long-standing request for parcel delivery contracts has also been implemented.

They don't take up any hold space or need specialist equipment, but to balance this they are fewer in number and don't pay (anywhere near) as well as either passenger or cargo contracts.

Scripting support for parcels is similar to that for passenger and cargo contracts.

Examples of both interface and parcel scripting are in

Code: Select all

Resources/Scripts/oolite-contracts-parcels.js

[Commander McLane]

So, finally the F4-key gets used.

There were a number of requests over the years to use the F4-key for some purpose or another, and none was actually implemented, which always left the freedom for the F4-key to be used for the really most important thing at some time in the future. Now the future becomes present.

To me it makes a lot of sense to use the F4-key for some kind of communication interface, because that's a functionality that has really been missing from Oolite. My question (and possibly request) is whether this interface can also be used in-flight for communication with other ships. So you would target a ship (or station) and press F4 in order to bring up a screen which would allow for some dialogue. (I think the game also ought to be paused—or at least slowed down to the smallest TAF—until exiting this in-flight screen.)

And, just out of interest: was there a debate and decision on the developer back channel to finally implement a use for F4, and that it would be this use?

[Svengali]

There were a number of requests over the years to use the F4-key for some purpose or another, and none was actually implemented, which always left the freedom for the F4-key to be used for the really most important thing at some time in the future. Now the future becomes present.

+1. Muchas gracias, cim.

My question (and possibly request) is whether this interface can also be used in-flight for communication with other ships. So you would target a ship (or station) and press F4 in order to bring up a screen which would allow for some dialogue. (I think the game also ought to be paused—or at least slowed down to the smallest TAF—until exiting this in-flight screen.)

Cabal_Common_Comms provides inflight ship2ship and worldScript2ship communications without using a missionscreen. This way you don't loose control about your ship while communicating.

[cim]

There were a number of requests over the years to use the F4-key for some purpose or another, and none was actually implemented, which always left the freedom for the F4-key to be used for the really most important thing at some time in the future. Now the future becomes present.

Yes. Looking back through them, almost all of the requests for what should go on the F4 screen were either a variation of the interface functionality, OXPable as an interface, or had already been implemented elsewhere, so it turned out to be a fairly easy choice (though I did check that no-one else had other plans for it first, yes).

My question (and possibly request) is whether this interface can also be used in-flight for communication with other ships.

Not easily, since the F4 key already has an in-flight use, and I'm not sure that encouraging mission screens in flight is a good idea.

[Commander McLane]

My question (and possibly request) is whether this interface can also be used in-flight for communication with other ships.

Not easily, since the F4 key already has an in-flight use

Stupid me, of course. I totally forgot.

[Thargoid]

The interface works well, and I like the way we can have the entries in it be quite dynamic.

However I think the example parcel script itself needs a little tweaking, unless you've got a TARDIS...

Those ice tennis videos are going to be quite hard to deliver 47 hours ago

[cim]

However I think the example parcel script itself needs a little tweaking, unless you've got a TARDIS...

Thanks. Fixed in r5329, along with a crash bug in the interface code.

[PhantorGorth]

The interfaces are categorised and sorted by category. For easier translation and consistency, I'd like to add a few common categories to the core descriptions.plist: suggestions for what they should be are welcome.

What categories have you got to start with?

As we have discussed elsewhere I believe that one of the categories should be "Station Places" (or equivalent wording) for mission screens that "take" you to locations within the station such as bars, local police stations, planetary embassies, etc.

[cim]

Thinking about the sorts of OXPs we already have, I'm thinking:
- Bounties
- Deliveries (which the parcels one would move to)
- Employment (sort of a miscellaneous category for missions that don't fit elsewhere)
- Help
- Logs
- News
- Ship Systems
- Station Places
Obviously OXPers could choose their own as well, but I'd like to try to cover most of the common categories.

[Wildeblood]

I would have thought "Organizations" for things like the Explorers' Club config page, Bounty Hunters' message board at seedy space bars, and UPS, Oo-Haul, RRS & ITHA (Escort Contracts OXP) missions. More-or-less for any OXP that will repeatedly offer missions, that you can accept or decline, and puts a "Your reputation with..." string on the manifest page, as distinct from you-beaut Mission OXPs where declining any stage basically defeats the purpose of having the OXP.

[JensAyton]

As per this thread, boring and complicated things have happened to text handling (r5394). If you maintain an OXP which does complicated things with strings, it would be a good idea to test it.