Oolite Bulletins

Hard agree also from this side here.

The zip is created automatically by GitHub when a release is published. It is generated whether we like it or not. The bz2 is the tarball created by us and is the one you should download if you want to build from source.

Όχι. 

What does the following line do in the Makefile for the test and debug targets? I don't use the AddOns folder after building, the flatpak only copies the oolite.app folder. As far as I can tell everything works fine, is there something subtle that breaks? mkdir -p AddOns && rm -rf AddOns/Ba...

May I kindly ask for the 1.91 flatpak file to be uploaded somewhere for additional testing?

How much work would it really be to expand the 8 galaxies? Is it easily do-able - or would it constitute a major vandalisation of everything, breaking OXPs right, left and centre, and causing all sorts of unforeseen upsets? In an ideal world it should have been easy. Change a number from 256 to wha...

This is really great, congrats for reviving the Linux port.

I cannot comment on the pack itself as I am not using Linux, but probably one or more of our Linux users will be able to verify the functionality and contents of the package.

Looking forward to seeing it on flathub.

I thought display_name in shipdata was... I can't find the exact word, redundant, maybe. I thought displayName on a ship object was created from shipClassName + shipUniqueName (possibly via some rule in descriptions.plist). I honestly cannot remember if, how and when this happened, but display_name...

I am not sure it is a bug. OOShipRegistry.m in the source code contains the following inside the - (NSMutableDictionary *) mergeShip:(NSDictionary *)child withParent:(NSDictionary *)parent method: // Certain properties cannot be inherited. if ([child oo_stringForKey:@"display_name"] == nil...

Starting a new game works fine and the shipdata-overrides can be something as simple as Throw this shipdata-overrides.plist inside a Config folder in AddOns and that should do it.

display_name works for me on 1.91

Mixing tone mappers in the same scene is not a good idea, neither using thresholds. Thresholds in general tend to create artifacts, except in some rare cases and your proposal is no exception, unfortunately. Running your above code, the planet city lights with RGB value 0.0, 0.0, 3.9 look like this ...

And in what cases does something like this prove useful? When you are close to the sun? It is the one of the main ways used in cinema, photography and games to showcase very bright lights. As light source intensity increases, color tends to desaturate to white. This can be useful mainly for effects...

Thanks, now I get the point. Then the question arises: is it not possible to compensate for low saturation in SDR? Then sdr and hdr output images will be as close as possible to the original srgb image. Try this: Find the oolite-final.fragment shader inside oolite.app/Resources/Shaders and open it ...