Oolite Bulletins

Cholmondely wrote: ↑Sat Feb 25, 2023 6:42 pm

But our earth is irrelevant, no?

I think it's at least a reference; like calibrating white balance on a camera.

Just to clarify, this feature does not aim to fix or calibrate anything. It is just a way of making a scene's colors more vibrant or less vibrant, depending on the user's preference.

I've just pushed into master an update for mission screens. Presently, the only key a mission screen can watch for is the "enter" key, when the player presses it on a choice. This limits what can be done with UI design.

This update corrects this by allowing any key (including function keys or shift/ctrl/alt combinations) to be registered on a mission screen, with the callback function being called when one is pressed. Two changes are needed for a mission screen to make use of this feature.

Add the "registerKeys" property to the options dictionary. This property lists all the desired keys for the mission screen in a dictionary object. For example: Add the "keyPress" parameter to the callback function. This parameter is in addition to the existing "choice" parameter. It will contain the dictionary key name for the registered key. For example: I've put together 3 examples demonstrating the new functionality:
RegsiterKeysDemo1.oxp.zip Uses the arrow keys to enter a 4 digit code.
RegisterKeysDemo2.oxp.zip Allows character entry to search for systems on the chart.
RegisterKeysDemo3.oxp.zip Recreates the F3F3 Shipyard, responding to the arrow up/down keys to change the displayed ship.

Existing mission screens should still work and be unaffected by this change.

This should be in the next nightly build.

phkb wrote: ↑Sun Aug 13, 2023 4:08 am

This should be in the next nightly build.

Great! Well done sir!

Question: how did Svengali (OBM) manage this in Vector OXP/Library OXP:

Cholmondely wrote: ↑Sun Aug 13, 2023 4:24 am

Question: how did Svengali (OBM) manage this in Vector OXP/Library OXP:

You do everything via the list of menu items. Arrow up and down to select an option. Press enter to do that function. The update I've just pushed in would allow for a bunch of keys to function as actions, without needing to press enter constantly. It would allow for a completely different implementation.

Celt wrote: ↑Sat Nov 02, 2013 5:46 am

On the subject of docking and buoys, it would seem that an alternative (and more real-life likely) docking aid would be something like the PAPI system used IRL today at airports, where pilots get a series of red and white lights which change colour depending where the pilot is on the glide slope . . . All red = too low . . . All white = too high . . . Do this in two dimensions and the pilot would be able to lock the centerline much easier and then just has to get the rotation right. aircraft carriers have similar systems called the Optical Landing System, or meatball . . .

Probably very OXPable . . .

http://en.wikipedia.org/wiki/Precision_ ... _indicator
http://en.wikipedia.org/wiki/Optical_landing_system

Apropos of Hiran's comment earlier this week, there should really be several systems, no? One official GalCop version for each Galaxy, one for the Commies (thought police with blinking blotches), one for the Juntas (puffs of smoke from the "chimneys" of the astrofactory), one for the english feudals (squires with flags), one for the korean feudalsetc. Merry havoc could ensue! But gosh! would it look good....

another_commander wrote: ↑Fri Feb 24, 2023 7:26 pm

Just added some intital shader code to control final output color saturation. Right now you have to edit the value at the start of the main function of the final fragment shader to change it, but I believe it would not be very hard to make it a game parameter, either as a defaults file entry or as a game menu option (if we are able to find any space in the options list to insert it, that is).

What this does, you ask? Well, here are two sets of screens to show you. The first screen in each set uses a saturation of 0.5, the second one uses 1.0 (the default value which creates the output we are all used to), the third uses a saturation of 2.0 and the fourth uses 3.0, which is probably too high a value and is used for demonstration of the effect. A saturation of 0.0 will produce a black and white image and the HUD is not affected by default, it is affected when in colorblind mode, though. There is no current limit to the saturation value, but IMO it should be restricted between 0.0 and 2.0, so that it does not producce unreasonable or simply ugly or ridiculous results.

Coming back to this for a second, in today's nightly we will have the ability to set the color saturation by script. To achieve that, two new global methods will be used:
getColorSaturation() and setColorSaturation(desiredColorSaturation). For the second method the range of saturation will be from 0.0 to 2.0, with 0.0. being black and white and 2.0 being full saturation. The current saturation default is 1.0.

In the next nightly, we now have the ability to define extra keys for most GUI screens.

What does that do for us? Well, to use some examples:
1. We can make an OXP like Galactic Registry be accessible from the F6 screen, rather than having to go through F4 pages. Or, we could make Library Config be accessible from the F2 screen.
2. We could perform custom functions on the F8 screen, like "freeing all slaves".

The idea here is to potentially reduce the amount of items that currently have nowhere else to go but the F4 screen.

Also with this change, you can now create mission screens while in flight. You can't use a model on such a screen (like having a spinning Cobra behind your text, and you can't use the "allowInterrupt = false" - the player can always exit your mission screen.

To set up a custom key for a GUI screen, you do the following: This code would callback $myGuiScreenCallback function if the player pressed Ctrl-g on the F5F5 Manifest screen.

As you can see, the definition is very similar to the station.setInterface call.

Not all screens can have extra keys defined. It is essentially GUI_SCREEN_OPTIONS, GUI_SCREEN_EQUIP_SHIP, GUI_SCREEN_SHIPYARD, GUI_SCREEN_INTERFACES, GUI_SCREEN_STATUS, GUI_SCREEN_MANIFEST, GUI_SCREEN_SHORT_RANGE_CHART, GUI_SCREEN_LONG_RANGE_CHART, GUI_SCREEN_SYSTEM_DATA, GUI_SCREEN_MARKET and GUI_SCREEN_MARKETINFO.

You can also clear extra keys with the following code:

phkb wrote: ↑Sat Aug 26, 2023 8:39 am

In the next nightly, we now have the ability to define extra keys for most GUI screens.

This sounds as though it could end up being a major innovation! Well done, sir.

yeah that sounds great! Awesome work

Explosions can now specify a brightness value so that they can be tweaked to appear really bright and impactful. The definitions inside explosions.plist can now contain a "brightness" key, with a float value that has to be higher than or equal to 1.0. The default value is 1.0, which keeps the explosions as we have them till now.

An example explosions.plist from ZygoUgo's explosions OXP is provided below as a showcase of how this is supposed to work. Also, example screenie follows. Note how the brightness of the explosion causes blooming around the ship:


If you do decide to change the brightness of explosions, be aware that the brightness property value is clamped to 1.0, but is not clamped on the other side, so theoretically you can make them stupidly bright. Some caution is advised, though. The sun is supposed to be the brightest thing in the game, so explosions should typically be kept a bit lower.

First build containing this feature: d3c624c

another_commander wrote: ↑Fri Jan 19, 2024 3:40 pm

If you do decide to change the brightness of explosions, be aware that the brightness property value is clamped to 1.0, but is not clamped on the other side, so theoretically you can make them stupidly bright. Some caution is advised, though. The sun is supposed to be the brightest thing in the game, so explosions should typically be kept a bit lower.

How bright is the sun? I've not found anything on the wiki about it. Sky/Nebulae, yes. Suns, no.

Cholmondely wrote: ↑Sat Jan 20, 2024 5:58 pm

How bright is the sun? I've not found anything on the wiki about it. Sky/Nebulae, yes. Suns, no.

It's currently set to 6400 nits absolute brightness, but normal screens will display it with their maximum available brightness, whichever that might be.

A new feature was introduced during the forum's downtime: FXAA. I only posted about it on Discord at that time and forgot about it, but since we have a forum again, here goes for everyone:

In the latest nightly we have support for Fast Approximate Anti-Aliasing, commonly known as FXAA for those who can't use MSAA, the game's default AA method, for whatever reason. It is done by shaders and (for now) can be script-activated by executing postFX=5.

If you have working MSAA in the game you may not need this, but for any setups without MSAA support (Windows HDR I'm looking at you!) this will probably be most helpful. Or you may even prefer what FXAA looks like compared to MSAA, so you have the option to choose now.

The effect's strength can be adjusted in the oolite-final.fragment shader by modifying the line Change the 10. to whatever feels best for you.

There is a slider-based without FXAA/with FXAA comparison image at https://imgsli.com/MjQyNDE2 to assist with better visualizing what this does.

Enjoy!

In the next nightly, I've added a new feature to allow equipment items to specific their default activate and mode keys.

So, for example, you can do this: This would make the default activate key Ctrl+0, and the default mode key Ctrl+9. With our keyboard config screen these defaults can be changed, obviously.

If an equipment item is updated to include these defaults, and you have already purchased the item at least once, you will need to go into the keyboard config screen and reset each of the values, at which point the defaults will be applied. Otherwise, the keys will be attached as soon as you purchase it.

If a conflict is detected with an existing key combination during the game start process, the offending key of the equipment item will be deleted and an error will be reported in the log file. You would then need to remove the conflict by reassigning the key of whatever function was in conflict, and then, when you next start the game, the default will be imported successfully.

What does this allow us to do? For one thing, it will allow for OXP developers to avoid having to inform players about needing to step through the prime-able equipment list to find the correct equipment item. Instead, they can simply say, press Ctrl+9 to change the mode (or whatever the mode action is really doing), and press Ctrl-0 to activate it.

It also allows for OXP devs greater scope to do innovative things. For example, the "Resistance Commander" OXP employs a hack to enable ship-to-ship instructions, essentially subverting the pylon mounts and turning them into instructions. Instead, using this feature, individual keys could be applied to a number of equipment items to instantly send an instruction (rather than cycling through the pylon list) because you can directly activate a single function.