Progress

[cim]

Now for something a bit different:


There are now five new HUD selectors. The first, drawSurround:, is the obvious generalisation of drawYellowSurround: and drawGreenSurround: - it draws a surround, and looks at the color attribute to see what colour it should be.

The other four allow OXPers a lot more flexibility with their HUDs.
* drawCustomBar: (bar indicator, number 0..1)
* drawCustomIndicator: ("roll/pitch" style indicator, number -1..1)
* drawCustomLight: ("status light" style indicator, colour specifier)
* drawCustomText: (variable text display, string)

Each of these has a "data_source" attribute which contains the name of a custom HUD data key, and then you use player.ship.setCustomHUDDial(key, value) to set the current value of the dial.

The picture above has four drawCustomBar: dials being fed the four laser temperature values. Here's the hud.plist entry for one of them

Code: Select all

	{	// weapon temperature bar
		height		= 4;
		selector	= "drawCustomBar:";
		width		= 60;
		x		= 0;
		y		= 40;
		color_high = "redColor";
		color_medium = "yellowColor";
		color_low = "greenColor";
		data_source = "local_weaponForward";
		viewscreen_only = 1;
	},

and the short JS routine to update them

Code: Select all

	this.$fcb = addFrameCallback(function() {
		if (!player.ship.docked)
		{
			player.ship.setCustomHUDDial("local_weaponForward",player.ship.laserHeatLevelForward);
			player.ship.setCustomHUDDial("local_weaponAft",player.ship.laserHeatLevelAft);
			player.ship.setCustomHUDDial("local_weaponPort",player.ship.laserHeatLevelPort);
			player.ship.setCustomHUDDial("local_weaponStarboard",player.ship.laserHeatLevelStarboard);
		}
	});

There's also a new "viewscreen_only" boolean attribute which can be applied to any HUD dial or legend. If it's true, it hides the HUD dial if a GUI screen is being displayed, which should again reduce the need for switching HUDs using JS to stop dials outside the traditional HUD region being overlaid on GUI text.

[Zireael]

As I said on GitHub, all those changes make me extremely happy! Step by step we're making Oolite the best free space sim there is (not that it wasn't the best already )

[Smivs]

+1
Thank you

[cim]

A slight tweak to the addon manager - but one which might allow a whole new type of OXP. You can now mark an OXP as only to be loaded in a scenario (I mentioned last month that you can now mark scenarios as only allowing a restricted set of OXPs)

What this lets you do is set up OXPs or groups of OXPs which make a major difference to gameplay - a standalone mission that wouldn't necessarily "work" with a long-running player bringing their own ship; a variation where some major assumption of the basic game that other OXPs rely on is challenged (e.g. one with a different galaxy seed, or one where a third of the systems are already under Thargoid control and what remains of the Cooperative is fighting for survival); or even a completely new game using the Oolite engine - without those OXPs being loaded in normal game play at all.

[Diziet Sma]

Now that, is seriously cool..

[Pleb]

A slight tweak to the addon manager - but one which might allow a whole new type of OXP. You can now mark an OXP as only to be loaded in a scenario (I mentioned last month that you can now mark scenarios as only allowing a restricted set of OXPs)

What this lets you do is set up OXPs or groups of OXPs which make a major difference to gameplay - a standalone mission that wouldn't necessarily "work" with a long-running player bringing their own ship; a variation where some major assumption of the basic game that other OXPs rely on is challenged (e.g. one with a different galaxy seed, or one where a third of the systems are already under Thargoid control and what remains of the Cooperative is fighting for survival); or even a completely new game using the Oolite engine - without those OXPs being loaded in normal game play at all.

Wow this sounds great. Is it in the trunk already?

[cim]

Is it in the trunk already?

Yes - see the OXP restrictions section of [wiki]scenarios.plist[/wiki]

[cim]

The changes to trade good handling are now in the main branch ready to be in tonight's nightly build. If you're playing without OXPs you shouldn't notice a lot of difference at the main stations - a few commodities are slightly different because the new pricing algorithm doesn't have "overflow". Rock hermit markets (as with all secondary markets) do work slightly differently to before in that there's a closer link between the hermit's prices and the system's prices, but again mostly shouldn't be much different.

If you're wanting to write OXPs with this the key documentation page is [wiki]trade-goods.plist[/wiki] and the various pages it links to. You can do some very powerful things with the trade good scripts if you want a commodity that doesn't obey the normal "economy and nothing else" pricing rules.

Trading info OXPs will probably find the extra methods on the manifest object useful.

...

Also in is the first bit of the extra help for OXP developers with additional logging for deprecated functions and other errors. There'll be more on this - and especially more features for the OXP verifier - as development continues.

[Cody]

The changes to trade good handling are now in the main branch ready to be in tonight's nightly build. If you're playing without OXPs you shouldn't notice a lot of difference at the main stations... Rock hermit markets do work slightly differently to before...

I was going to re-install Risk-Based_Economy_1.0.oxp for a much-delayed voyage - any clashes with the above?

[cim]

For various reasons, risk-based economy won't work with these changes. It should be fairly easy to rewrite so that it works again, though - I might see if I have time to do that tomorrow as a demonstration of the new market scripts.

[Cody]

For various reasons, risk-based economy won't work with these changes. It should be fairly easy to rewrite so that it works again, though - I might see if I have time to do that tomorrow as a demonstration of the new market scripts.

Cool - I can't start my voyage for a few days yet anyway.

[Wildeblood]

the key documentation page is [wiki]trade-goods.plist[/wiki] and the various pages it links to.

I can see no mention of any way to set a different market definition for either a system or indvidual station. The entire oniverse gets stuck with the same market?

There's a key misleadingly called market_definition for stations' shipdata, but "defining rules which modify the prices and quantities from the main station market". That should be called market_variation or similar.

What's the equivalet of being able to set market="myoxp-market" in planetinfo.plist, so that different systems will use different market definitions?

[Pleb]

I haven't tested it yet but check out Secondary Market Definitions as I think this section will explain. However I may be wrong, I usually am!

[cim]

What's the equivalet of being able to set market="myoxp-market" in planetinfo.plist, so that different systems will use different market definitions?

market_script = "myoxp-market.js" in planetinfo.plist and do whatever pricing rules you want in there, whether that's a variation on normal prices or throwing them all out and starting over.

Documentation for Market Scripts

You can't add a static file to modify pricing rules, because you don't know any more when you're writing the OXP what commodities are going to be available at run time.

[another_commander]

In tonight's nightly, Windows users will have the chance to test Oolite's improved support for multiple monitors.

Although multi-monitor support has been in Oolite for quite a while now, it has mostly been primary-display oriented. That is, in the case of multiple monitors, the game always launches on the primary one and, until now, switching to full screen always brought the window to the primary monitor, then switched it to full screen. Even if you moved the window to the secondary monitor, it would always launch full screen on the primary.

From tonight on, Oolite should have somewhat better situational awareness. The game still launches on the primary screen, but now it has full knowledge of where its main window is at all times. So, if you bring it to the secondary screen and go full screen from there, it will switch on the screen it currently runs on. If the game senses that its window has moved to a non-primary display, it will freeze the resolution option selection to the native resolution of that non-primary screen. So, for example, if you move from a primary screen of 1366x768 to a secondary one of 1920x1080, the resolution for full screen will be locked to 1920x1080 for as long as the game window stays on that screen. This is done for technical reasons, but mainly in order to avoid complexity. Moving the game window back to the primary display will re-enable the selection of alternative resolutions for that screen.

To those with multiple monitor displays, feel free to test and spot bugs; hopefully there won't be too many.