Oolite Bulletins

You could perhaps go for a round-robin approach instead.. once the array is full, each new entry causes the oldest entry to be dropped. It's basically like a circular buffer that never gets larger over time.

Version 1.1 has now been released. Link added to first post. New in this version:
- Scrolling by message, rather than by line (can be changed to line by line if you change a setting)
- Better handling of local variables
- Fixed the name of the MFD used to be consistent with the OXP name
- Log is kept between launches (can be changed to clear on launch if you change a setting)
- Log size limit added
- Added "Launch" and "Dock" messages to the comms log to help delineate between message sections
- Corrected the readme file license link to match with the license specified in "comms_mfd.js"
- Adjusted the width setting to leave more of a margin on the right side of the box

Thanks to Norby for the suggestions.
I'd still like to add a "reset" feature, but I'll need a bit of guidance on how to make that work.

Diziet Sma wrote:

You could perhaps go for a round-robin approach instead.. once the array is full, each new entry causes the oldest entry to be dropped. It's basically like a circular buffer that never gets larger over time.

That's essentially what I'm doing with the log size limit. It drops messages off as new ones are added, once the log limit is reached. I was hoping to find a simple way to just dump the log completely.

I suspect you may have to change the functions of the 'b' and 'n' key.. so that 'b' (mode) cycled between "scroll forward", "scroll backwards" and "clear log", with 'n' then used to activate that function.

Hmmm... interesting. It would complicate the log function a touch, but perhaps with these options:
Modes:
1. Scroll back (default when scroller is primed)
2. Scroll forward
3. Return to current
4. View oldest
5. Clear log

Plus, if I put a timer in after (for example) 2 minutes, if no further scroll functions executed then automatically return to the current message. What do you think?

That sounds fairly comprehensive.

Very nice work, phkb!

I suggest two new items into Modes: go to Previous and Next launch.

A performance tip: use the worldScripts keyword as few as possible, like this: The parser do a long search after worldScripts first time but then the local variables are 100 times faster and the code lines are shorter.

You should call this.$commsMFD_updateview(); at the end of startUp() to do not leave it uninitialized which cause in NumericHUD this MFD is bring up later than others at first launch.

Norby wrote:

The parser do a long search after worldScripts first time but then the local variables are 100 times faster and the code lines are shorter.

Does this also apply to references to other entities like manifest? e.g. If I'm referring to the manifest a lot, would I see a performance increase if I assign manifest.list to a variable, and refer to that throughout the rest of the function?

- Neelix

Grabbed it, thanks, I love seeing how much stuff can be done via MFDs!

Neelix wrote:

Does this also apply to references to other entities like manifest? e.g. If I'm referring to the manifest a lot, would I see a performance increase if I assign manifest.list to a variable, and refer to that throughout the rest of the function?

Generally, yes. Processing time is faster, and it also saves on memory allocation which is fairly important in JS.

However, note that depending on what you're referencing, you should be careful with this. With five TC of food and nothing else onboard. but

cim wrote:

Generally, yes. Processing time is faster, and it also saves on memory allocation which is fairly important in JS.

How does it save on memory allocation? I kind of get the faster processing time but not the memory saving. Aren't you effectively duplicating the object in memory by assigning it to the local variable?

cim wrote:

However, note that depending on what you're referencing, you should be careful with this.

Noted. Thanks for the clear example.

- Neelix

Neelix wrote:

Aren't you effectively duplicating the object in memory by assigning it to the local variable?

Essentially no, not any more than you already had to for Javascript to be able to use it at all. (Rest of post contains technical details of memory management and may be skipped)

The manifest object exists - for practical purposes permanently - within the main Oolite memory space. You don't need to care about that (really, the only time you need to care about that space is when deciding how big to make your texture files)

When you do "manifest.list" a copy of the "list" property of the manifest is created within the (much much smaller) Javascript memory space. You can't avoid that happening once if you want to use it. If you ask for it again, another copy gets created, also taking up space in JS memory - whereas if you use the one you already had, it only copies it once. Assigning to a local variable when you ask for that copy doesn't make it take up noticeably more space.

Most of the time the difference in memory usage is so small it's not worth worrying about, but if this function gets called a lot (e.g. frame callbacks, repeating rapid timers, and some parts of the priority AI system) then every time you call the function it has to give it that memory in the JS space.

The way our JS engine works for giving the memory back again is essentially that it waits until it's used almost all of the 32Mb available, then looks for all the allocations that are no longer attached to an active variable (which your function local variables become once the function ends). Then, it cleans them all up and marks the memory free again. A full cleanup takes a bit over a second on my fairly fast CPU; it could take four or five on slower processors [1].

So if you have a very frequently called function, it's really worth trying to optimise the number of variables it uses - both local and requested from Oolite. There are various ways to do this which I can talk about elsewhere rather than derailing this thread further, if people really want to know. Many of them are used here and there in the Priority AI library.

[1] We work around this in Oolite a bit by forcing cleanups even if there's plenty of space left on docking and on witchspace jumps - a partial cleanup when there's only 8-10Mb been allocated so far is much quicker, and it's one of the few times where a smallish pause is acceptable anyway. If you hang around just flying around the same system for 45 minutes or so (perhaps less depending on OXPs) you'll eventually see a brief pause, though, because it can't wait any longer.

My apologies to phkb for the derailment. (perhaps this conversation should be split off to a new thread?)

@cim: Thanks for that explanation. It's given me a a fair bit to consider about to to handle some things in the function I'm writing, and I'll probably be making some changes to it.

I think javascript optimisation techniques for OXP writers would be a worthy topic to pursue in its own thread actually. For those of us who are learning just enough of the language to make do as we go along it would probably be a valuable resource.

- Neelix

To Neelix: no harm done, and as this is my first oxp the technical info is quite useful.

Thanks also to Norby for the suggestions. I have a new version almost ready to go. It should be ready by the end of the weekend.

Version 1.2 is now released. Download link in first post.

- Mode selection now changes scroll function between scroll back, scroll forward, scroll to previous launch, scroll to next launch, view current, view oldest, and clear log.
- If log is scrolled and left for 90 seconds, log will automatically revert to viewing the current message
- updated license reference in manifest.plist to match with the license specified in "comms_mfd.js"
- split up the js files, putting the MFD code in one, and the scroller code in another.
- fixed case when first line of first message might not be viewable in some circumstances
- improved speed and memory management

Some usability functions have been applied. If the "scroll forward" function is selected, and then activated, the next mode will be "scroll back". This allows easier scrolling backwards and forwards. Same with the scroll to next launch and scroll to previous launch.

When "view current" is activated, the mode will be automatically switched to "scroll back". When "view oldest" is activated, the mode will automatically switched to "scroll forward".

Thanks to everyone for the feedback and suggestions.