A few ideas have shown up recently relating to custom missions (here and here for two examples) that would seem to point towards a need for a standardised bulletin board system that OXP's can take advantage of, otherwise each OXP has to create its own interface screen to offer these missions to the player. ocz has been working on something similar, so perhaps there can be a fusion of ideas here. I'd be happy to collaborate on this!

What I've got so far looks kind of like this (and these shots show that this OXP is still a little rough around the edges!):

Interface entry, showing number of available missions, plus the number of active missions.

Mission list, showing all active missions at the top, and all other available missions underneath.

Mission detail for active mission, showing percentage completed, and giving the player the option of cancelling the mission if they don't want to continue with it. When the mission is 100% complete, the player can select "Complete mission" to receive their monetary reward.

Mission detail for available mission.

Manifest screen, showing active missions and percentage complete.

Adding a new mission to the list is done with a call to a single function, passing an object with the following structure:

Code:

description one line short description of the mission (used on the main BB list)
manifestText text to use on the manifest display
source system ID where mission is available
destination system ID where mission must be completed
details expanded description of the mission
expiry the time the mission must be completed by
payment how much the player will be paid on completion of the mission
penalty how much the player will be penalised for not completing the mission
initiateCallback function name to callback when contract is accepted
completedCallback function name to callback when the player flags the mission as completed
terminateCallback function name to callback when the player gives up on the mission
worldScript name of worldscript containing the callback function

The are also function calls to update a mission (changing the percent completed value), and to remove a mission from the list. When a mission is added it returns an ID value that the calling worldScript can use to update and remove the mission.

I guess my first question is, is there any interest in this? Would any OXP author want to use a system like this, or should we just continue to create our own interface screens for offering missions to players?

If there is interest, is there anything missing in the definition and callbacks that would help a mission OXP keep track of things?

Edit: You can download the Bulletin Board System v1.0 from this link: BulletinBoardSystem.zip (extract the OXP folder into your AddIns folder). OXZ version available via the download manager.

Cool. Like it was in Frontier. Make the interface entry to be something like "Station bulletin board" and I could try to modify in-system taxi, rescue stations or random hits to use it. Ideally I would like to see core contracts in it, but that would require quite a lot of work.

Arrgg. Sorry to answer that late. The game doesn't want to, like I want it to behave.

As far as I understand your idea, it is not the same as mine. But there are common grounds.

You create a script that contains references to different kind of missions, with at least some common properties and a group of mission screens to refer to and manage those missions. If an OXP developer creates her/his own missions, she/he could (and definitely should!) use your "board" as GUI instead of writing her/his own, which would fight over dominance with other OXP GUIs. In your board they play nice with each other as they use the common framework provided by it.

I want to create something very similar, but still different. I want to create a script file, that can be loaded as a world script (As part of other OXPs or in it's own OXP. As I do not want to change it afterwards if not necessary, every OXP's version should do the same as they are identical and have the same name! Only one will be loaded!).
Its first function should be: It should contain an index that contains references to another world script and one of its functions per reference. This function should contain a mission screen call. In other words, by reading a reference of the index, you end up with the data needed, to call a function that creates a mission screen.
Its second function is: The index is arranged in a certain way, so the script can place(call) those mission screens in between other Gui Screens.
For example: Instead of:regional starchart(F6) -> large starchart(F6F6) -> regional starchart(F6) -> ...
more screens are added:regional starchart(F6) -> large starchart(F6F6) -> thargoid invasion starchart(F6F6F6) -> Witchdrive configuration menu(F6F6F6F6) -> regional starchart(F6) -> ...

You write an OXP and want to squeeze your own screen in between standard screens. If someone else has the same idea, your OXPs will fight over it. If my idea of this script comes to fruition, both OXPs can use it, their screens get there position in the index and are called, when it's there turn.
The script would also contain a method to add a function to the index.

Both ideas should create more order and compatibility between OXPs. Yours focuses on missions and a detailed overview and management of them, mine wants to provide a safe method to place screens in between standard screens and keep that as open and simple as possible.

I saw you placed your bulletin board in the station menu. How does a position F5F5F5 in-flight sound?

Sadly, I'm running against a wall. (This is the reason it took so long to answer and why there is no sugar left in my brain to write a decent posting.) I thought the worldScripts management part would be tricky, but it turned out very well. The simple guiScreenChanged method is what's killing me! Turned out it isn't simple.

Can you upload a preview version of your OXP? Maybe I find something that helps me or I might be able to make suggestions for the worldScripts part of yours.

One point of introducing station interfaces was to get rid of all sorts of mission screens between standard screens. It was getting a little chaotic with different combination triggering different screens.

In-flight mission screens are also considered to be problematic, that's why we have MFDs.

You write an OXP and want to squeeze your own screen in between standard screens. If someone else has the same idea, your OXPs will fight over it. If my idea of this script comes to fruition, both OXPs can use it, their screens get there position in the index and are called, when it's there turn.

Well, I think I have an initial version ready to test/poke/prod/pull apart. You can download the Bulletin Board System v0.2 from this link: BulletinBoardSystem.zip

The goal of this OXP is to make it possible, and more importantly, simple, for OXP authors to create custom mission scripts. By avoiding all the hassle of user interfaces and manifest displays, authors can (hopefully) concentrate on the logic for their missions. The mission display is (I think) fully customisable, with background, overlay and ship model options. You can have really long details, including line breaks, and the system will automatically add a "Next/Previous Page" commands if there's more than one page of information.

If you download and install this, you initially won't see anything different. This is a service utility that other OXP's can take advantage of. If you want to see it in action, go into the "Resources" folder inside the OXP, and copy the "AsteroidHunter.OXP" into your AddOns folder, and restart Oolite while holding the shift key down.

I was going to post a series of screenshots showing the board in action, but the shots aren't much different to the ones I've already posted. Bit of clean up, filing off rough edges, that sort of thing. One difference is that I've had to create a "Bulletin Board Missions" section on the F5F5 manifest screen, rather than just add text onto the "Missions" section, because I need to add multiple lines (if multiple missions are active), and I wanted to do word wrapping (so long entries don't overlay the notional edge of the display).

The readme.txt file in the OXP package has sample code, details of all the calls, hopefully in a form that's understandable. Let me know if something doesn't make sense, though. Documentation is not my strong suit! Particularly let me know if I've missed something obvious. I've tried to think of all the possible ways this OXP could be used, but undoubtedly I'll have missed something.

Very nice work! I tried and no bugs so far.
I think the included mission worth a standalone oxp in the manager, this is the best motivation to make another using BB.
A minor polishment: I would like to see the new mission text (showing the number of remaining asteroids) in a console messge instead of a simple "mission goal updated" to see where I am and when I completed it without frequent F5F5.

As for the standalone oxp, I was planning to make one using most of that code, but making it limited to certain systems and only for players with low ratings, kind of an early game mission. The sample is stripped down in many respects.

I've just released version 0.3 of the BB system, which fixes a couple of bugs and adds a couple of features.

Fixed Javascript reference error when displaying mission details.

Fixed issue where setting course for the destination system wasn't actually setting the course.

Bulletin Board was not reseting itself correctly between views.

Fixed issue where the space between accepted and available missions was not appearing if there were only 1 of each type in the list.

Added a confirmation screen to the terminate mission process.

Added a "Set course for" option to the mission briefing page.

Added the "confirmCompleteCallback" callback function, so that secondary steps can be confirmed before a mission can be accepted as complete. This would be useful if there is a possibility that something might have changed between completing the required steps of a mission, and getting to a dock to enter the "Complete Mission" response (eg loosing or selling cargo).

Download via the manager, or via link above (for the OXP in a zip version).

A question for those more familiar with Bulletin Board missions in other games: If the mission is to destroy 10 pirate vessels within 8 hours, and return to the originating station for payment, do you have to get back to the originating station to hand in your mission within the 8 hours? Or does the clock essentially stop once the tenth pirate is killed, mean you can take a leisurely trip back to the originating station to hand in your mission? Or could both options be in use for different situations?