Trunk nightly

[spara]

I'm working on Market Observer oxp that uses it's own hud in market screen. The hud has overall_alpha set to 1. Switching seems to be working fine except for one special case. If I'm watching any contract (the map screen) and then switch to market (F8), the hud is translucent with something that looks like overall_alpha set to 0.7. F8 again and the hud is opaque as I want it to be.

[Cody]

Probably a daft one: after shift-starting Oolite, my log reports the flush entry three times:

Code: Select all

23:38:22.192 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.

23:38:22.889 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
23:38:22.890 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.

[cim]

Probably a daft one: after shift-starting Oolite, my log reports the flush entry three times:

Code: Select all

23:38:22.192 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.

23:38:22.889 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
23:38:22.890 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.

There are some 1.82 updates which require the cache to be checked for validity more often than previously - it probably should clear the "shift key" after it's flushed once, though. Thanks.

I might leave that one for after 1.82 is out rather than poke around at something that fundamental, though.

[Cody]

It's not trunk, but I'll post it here anyway:

Code: Select all

15:06:30.652 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (Oolite Escort AI 1.82): TypeError: this.ship.dockingInstructions is null

Do we need a new thread for 1.82 Deployment reports?

[another_commander]

Do we need a new thread for 1.82 Deployment reports?

I think that, for the released version, a thread for each bug encountered would be preferrable.

[Cody]

Do we need a new thread for 1.82 Deployment reports?

I think that, for the released version, a thread for each bug encountered would be preferrable.

<nods>

[Getafix]

Sending today's nightly to oolite.org fails for Linux and Windows.
To get the latest nightly, for the time being, either build it from source or
Linux users execute the oolite-trunk-update script and
Windows users use rsync as per this post.

[Norby]

The allow_big_gui should extend the gui when docked only - I turned off the gauges in Coluber HUD in dock but the F5 equipment list is big during flight also and clash with the gauges if I have more than about 10 eqs.

[cim]

This is working as designed.

If you want different behaviour when docked and when in flight then you will need to switch HUDs.

[Mazur]

In an attempt to help along oolite portability and sheer excellence, I downloaded trunk and attempted to make it, which faltered at this hurdle:
System is running Fedora 21.

Code: Select all

 Linking objc_program oolite ...
/bin/ld: /usr/local/lib/libjs_static.a(putil.o): undefined reference to symbol 'dlopen@@GLIBC_2.1'

After a little thought, I added -ldl to both LIBJS_BUILD_FLAGS in libjs.make. This led to:

Code: Select all

 Linking objc_program oolite ...
/bin/ld: /usr/local/lib/libjs_static.a(putil.o): undefined reference to symbol 'dlopen@@GLIBC_2.1'
/usr/lib/libdl.so.2: error adding symbols: DSO missing from command line

At this point I'm stuck, I've no idea how or where to fix this.

[Norby]

You can spend a lot of time to find and install missing files, or use the nightly build.
My fav is the included oolite-trunk-update script what I patched on my machine to put back my modified keyconfig.plist after update.

[Mazur]

You can spend a lot of time to find and install missing files, or use the nightly build.
My fav is the included oolite-trunk-update script what I patched on my machine to put back my modified keyconfig.plist after update.

Yes, I tried, but I currently seem to be unable to download it untruncated. After download it's 26498880 bytes long, but I don't seem to have run out of space, either. I'd need oolite-trunk-1.83.0.5bc299c-dev.linux-x86.tgz

Is the file in that link complete? Because if it is, there must be an error on my side, and I simply have to make a choice in what to throw away to make more room to be certain.

Code: Select all

root@laptop [Mon, 22 Jun 2015, 20:21:59] /tmp                                   # tar tzvf oolite-trunk-1.83.0.5bc299c-dev.linux-x86.tgz
-rwxr-xr-x getafix/getafix 104716464 2015-06-19 05:40 oolite-trunk-1.83.0.5bc299c-dev.linux-x86.run

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
root@laptop [Mon, 22 Jun 2015, 20:25:55] /tmp                                   # 

[another_commander]

I think that there is currently a problem with terrastorage sending the nightly builds to oolite.org. All builds except the Mac one appear to be 25MB long, which is the wrong file size (should be about 97-98MB).

Edit: Check out Getafix's last message here, six posts above this one.

[Mazur]

I think that there is currently a problem with terrastorage sending the nightly builds to oolite.org. All builds except the Mac one appear to be 25MB long, which is the wrong file size (should be about 97-98MB).

Edit: Check out Getafix's last message here, six posts above this one.

Yes, that would be easier, if said script was either included in the Fedora Oolite package, or downloadable from an easily found source.
As it seems to be neither of those, I'm trying:

Code: Select all

rsync -rlvz --progress rsync://terrastorage.no-ip.info/oolite-trunk-linux oolite

instead, and see after it finishes where that leaves me.

{Edit} That, apparently, works. But there is no oolite-trunk-update script in there, either.
Just FYI.

[Getafix]

We know exactly what the issue is, between terrastorage and oolite.org, but no root-cause is there yet.

In the meantime, I have updated the nightly process and the Oolite Nightly pages for Windows and Linux now link to binaries hosted by Google Drive.