Oolite Bulletins

Link to download: https://app.box.com/s/rhhtuldcnuubz05ep40h
Link to wiki: http://wiki.alioth.net/index.php/CommsLogMFD
Also available via the Expansions pack list in the game itself.

Version 1.4 now available.
- Comms messages are now viewable in the dockside F4 Communications log, even if the scroller hasn't been purchased.
- Fixed bug where clearing the log while docked would hide the HUD.
- Fixed JS bug when clearing the log in flight.
- F4 comms log options will now show all options, with various items disabled based on the log viewing position and content.
- Code refactoring and cleanup.

Okay, here's what I have so far.
Comms log with a few messages in it. New messages are added to the bottom.


Comms log which has been scrolled back 2 messages


Scroller shown as available for purchase


Showing as primable equipment


Showing on ships interfaces


When ship interface active

I like your solution to the problem of how to get it to scroll.. good idea.

The only thing I'd critique so far:

phkb wrote:

"COMM LOG" really ought to be changed to COMMS LOG".

Is the MFD part of the scroller equipment, or does the MFD still work without the scroller installed, just with no scrolling facility?

The MFD will work without the scroller. It would always display "Current" at the top, and new messages would keep getting appended to the bottom of the list. You'd only need the scroller to, you know, scroll.

And "COMMS LOG" now fixed.

So I now have a working OXZ ready for testing. What's the approved method for distributing these sort of things?

If you're just wanting to test at this stage, uploading it to a file hosting site, such as box.com, then posting the link is easiest and quickest.

To have it available via the Expansion Manager will require you to obtain an OXZ account for oolite.org from cim, and a wiki account from Maik, after which you can go through the process which has been posted here somewhere, and I'll find in a minute for you.

Edit: See this post and the three that follow it:
https://bb.oolite.space/viewtopic.php?p=217518#p217518

OK, here's a Box.com download for the Comms Log MFD.oxz!
https://app.box.com/s/rhhtuldcnuubz05ep40h

I'd appreciate any feedback and comments, bug reports, anything really. And please let me know if I've done things the wrong way internally!

Edit: I did alter the final version of the OXZ. I decided the "Current" header was redundant and just cluttered the display. Now, when the Comms log is unscrolled it just reads "COMMS LOG:" in the header.

Very nice first addon, grats.
My notes:
-There is a 4.0 version from CC-BY-NC-SA license what you can consider.
-I suggest to name your MFD in setMultiFunctionText to "CommsLogMFD" exactly as your worldScript's name. In NumericHUD I use worldScript names to bring up MFDs and must handle separatedly if different.
-In the manifest description you can write "communications" and not "comms" due to the goal of this field is to explain for newbies what is "comms". MFD also.
-In the readme commsMFD.oxp should be CommsLogMFD.oxz .
-In equipment description the B and N key is better in lowercase to avoid pressing these with shift.
-You can use this.$commsMFD_log and similar variables and save to missionVariables in playerWillSaveGame and load in startUp for 60 times better performance. In this case you must use worldScripts.CommsLogMFD.$commsMFD_scroll in activated() and mode() and not this.$commsMFD_scroll due to these are not called within your worldScript but in an equipment script.
-I would like to read my comms from the previous flights also so I do not think you should reset it at every launch, I think a huge max. length is better. Strings in Oolite can grow up to 256MBytes (I measured in a stress-test) which is enough for a while.

Norby wrote:

Strings in Oolite can grow up to 256MBytes (I measured in a stress-test) which is enough for a while.

Except that many low-end computers (and consoles such as Pandora*) running Oolite only have 1GB of RAM. They'd choke to death, long before it got to that point. Better to make it a configurable option, I would suggest.

* RAM-wise, the Pandora only just copes with Oolite as it is..

Ok, but I do not think a string with max. 32kByte length can cause any problems in 1GB.

I suggest to handle the comms not line but message based: count how many messages stored and display in the first line the total messages and the number of lastly displayed one. In this way a keypress can step up a whole message (sometimes 5 lines at once) which help a lot in long scrolls due to no repeat if you hold down the key.

If you comment out not only the whole shipWillLaunchFromStation but the _log and _maxscroll lines from the startUp then the content of comms remain after save and load game.

32kb should be fine - but remember that the Javascript engine does not have access to the full system memory: it gets 32Mb and that's it - and most of that should be kept empty for best performance and to avoid too many inconvenient pauses for garbage collection.

In practice you have to be doing something large to use a significant amount of it, because a lot of the things you're reading and writing (e.g. ships, systems, mission variables) don't permanently count towards that limit: they're just interfaces to data in the main Oolite memory space.

A permanent log of every message ever received probably would cause problems however...

Maybe a limit in stored messages is better than the total length. I suggest the last 1000 comms which is the same order of magnitude than 32kb.

If the log keeps growing, would it be useful to include some form of separator? For instance, each time the player docks and launches, include That way, when you're scroll back through pages of messages, it's clearer where you were when you received those messages.

phkb wrote:

If the log keeps growing, would it be useful to include some form of separator? For instance, each time the player docks and launches, include

Code: Select all

Docked with Lave station.
Launch clearance received from Lave station.

That way, when you're scroll back through pages of messages, it's clearer where you were when you received those messages.

That is a good idea methinks .

If the log keeps growing, it might be useful to offer the option of clearing the log manually. Ideally this would be available in-flight as well as docked. Any suggestions on the best way of achieving this?