Progress

[Astrobe]

I totally agree a much lower ambient level is the right default, but I'm having trouble with the way you do it.

Changing the interpretation of values is something I would suggest to Redspear for the rescaling experiment in order to retain compatibility (for instance ship [and missiles!] max speeds, that have to be divided by 2), so that players won't have to change manually the max speed of their favorite OXP ships.

But using this method in this context has the opposite effect: OXPs that change ambiant_level won't work as intended.

It seems to me that using ambiant_level=0.25 in the stock planet_info.plist has the same effect and doesn't trouble those who've already customized it, or am I missing something?

[another_commander]

We should try to avoid adding entries in the universal chapter of the core planetinfo.plist as much as we can. Putting any entry there in the core means that OXPs can override it only at the global level.

In our case, adding ambient_level=0.25 to the core planetinfo's universal section means that we can no longer set ambient_level on a per-planet basis, unless we involve scripts. This is because universal overrides anything local. For a quick example, try adding name = "Lave" to univeral and see what happens. By not having ambient_level set in unversal, we allow OXPs to play with ambient level on a per-system basis.

The best way to lower ambient level if we wanted to go with planetinfo would probably be to add an ambient_level entry on each system, for all 2048 systems. That will allow other OXPs to override ambient levels individually for each planet (unless they also use the universal section, in which case the ambient level setting will again apply golobally - but at least it won't be the core doing that). Thankfully, it has not been too difficult writing a little program to add the ambient_level line in planetinfo (no way this was going to be done by hand), so I guess I'll go ahead and restore the original ambient level calibration for 1.0 and reduce the ambient level on all systems without affecting it universally.

[Astrobe]

Ah, got it. adding ambient_level in universal is what OXPs do, the stock config file doesn't have it.

I'm a bit surprised by the overriding rules. I would have thought that the more specific would apply, that is the values of the keys for systems would have precedence over the universal/interstellar section.

[another_commander]

The precendence behaviour of planetinfo is a bit upside down compared to the other plists and this is most likely due to the changes that took place between 1.80 and 1.82. Consider that before 1.82, all planet data was generated procedurally, so having just a "universal" planetinfo section that chagned parameters globally with system-specific changes overriding the default procedural data made sense. This changed when the static planetinfo capability was introduced. Because of the way the new planetinfo is structured (all - or almost all - system keys are present for each system individually), changing the behaviour to match other plists would not make much sense; it would effectively cancel out the functionality of "universal". For example, if you wanted to change all planet names to "Lave", you wouldn't be able to do it through the universal key, because each system in planetinfo has now the full set of keys defined locally for it, including the planet name. "unversal" would become meaningless. Plus, by then, many OXPs were using the universal thing, so changing the way it works would probably mean changes for those OXPs as well.

For this reason, I think it's sensible to leave things as they are for now in planetinfo. Maybe a planetinfo overrides plist could become useful, but that may make some OXP rewrites necessary too. I think the way we have it right now with the ambient level changes applied to each system is the least intrusive way. The main thing to keep from this is that adding entries in the universal section of planetinfo should be done only after careful consideration of other OXP interactions and should probably not be done from within the core planetinfo.plist, unless absolutely necessary.


Edit: OK, I may have not been doing my homework properly. After some tests, it looks like OXPs can change per-system parameters without problem. Just adding this in an OXP's planetinfo.plist:

Code: Select all

{
	"0 7" =
	{
		ambient_level = 1.25;
		name = "Bright Lave";
	};
}

will override the name and ambient lighting of Lave, regardless of what is written inside the core planetinfo's universal section. So that's one hassele less. I still think that the core should not be messing around too heavily with universal planetinfo settings though.

[cim]

Yes, as a_c says, making the changes between 1.80 and 1.82 while keeping backward compatibility with existing OXPs and making sure that OXP changes disappeared if you uninstalled the OXP was a little tricky.

The key point is http://wiki.alioth.net/index.php/Planet ... ist#Layers

Core game entries are overridden by universal entries are overridden by plist entries are overridden by Javascript changes
(By default - both plist entries and JS entries can be applied at different layers to the default - which is how the core ones come below universal)

So the "correct" way to make a core game change to a planetinfo setting is to apply it across all the systems, not to put it in "universal" - as this makes it then easier for OXPs to change it later.

(That doesn't apply in this case where the change is changing the effect of the scale, not the values on it, of course)

[phkb]

In the latest Oolite build a new feature has been added which allows OXP authors to change the way things are displayed on the F7 system information page.

Each line of the display is allocated a separate line in descriptions.plist:

Code: Select all

	"sysdata-line-1"				= "[sysdata-eco]\t[economy_desc]";
	"sysdata-line-2"				= "";
	"sysdata-line-3"				= "[sysdata-govt]\t[government_desc]";
	"sysdata-line-4"				= "";
	"sysdata-line-5"				= "[sysdata-tl]\t[sysdata-tl-value]";
	"sysdata-line-6"				= "";
	"sysdata-line-7"				= "[sysdata-pop]\t[populationDesc]";
	"sysdata-line-8"				= "\t([inhabitants])";
	"sysdata-line-9"				= "";
	"sysdata-line-10"				= "[sysdata-prod]\t\t[sysdata-prod-value]";
	"sysdata-line-11"				= "";
	"sysdata-line-12"				= "[sysdata-radius]\t\t[sysdata-radius-value]";
	"sysdata-line-13"				= "";
	"sysdata-line-14"				= "[sysdata-distance]\t[distanceInfo]";
	"sysdata-line-15"				= "";
	"sysdata-line-16"				= "";

Also, a new worldScript event has been added, infoSystemWillChange, which will fire just before information is updated, so that OXP's can have a chance to change details before the page is rendered.

As an example of what can now be achieved with this (with a bit of fiddling with Explorers Club and Distant Stars)...



I've also created a small configuration OXP to act as a kind of traffic cop for OXP's, so it's possible to know what OXP is currently use what line of the display.
SystemDataConfig_0.4.oxp.zip
I've created a separate thread for discussion of this OXP in the Expansions Pack section.

[Cody]

Any progress on the Perlin3D lag? Those P3D textures are interesting enough to tear me away from Povray, even with the lag.

[another_commander]

I'm afraid no change till now. A question to anyone who has tried P3D: Would you consider the generation delay game breaking? I understand it largely depends on system specs, but would you accept the delay as is? Note, this does not mean that P3D is considered without firther performance improvements, just asking out of curiosity to see where about we stand with that.

[Cody]

Would you consider the generation delay game breaking?

Short answer: no! That said, I'm accustomed to a little lag during hyperspace due to BGS anyway. The lag on F7 is annoying, but one gets used to it.


Thing is, if P3D becomes the default, that lag is still apparent when using Povray.

[gizmo]

Would you consider the generation delay game breaking?

No, the delay is (on my system) far too short to be a game breaker.

[Stormrider]

Would you consider the generation delay game breaking?

My desktop is definitely a little slower at rendering than my laptop even though it has a pretty good GPU, still not much more than a second, and it seems to vary. Fps is all over the place with that thing, it will be 35-50 when I start out, jump to 80-90 when I dock, then jump to 150 -170 when I launch again, eventually after a few jumps it stabilizes somewhat. I think that is most likely due to the poor AMD driver for linux, though.
It doesn't really bother me and it doesn't affect gameplay in such a way that will make the player loose a battle or anything like that. I think it would be OK.
Desktop specs:

Code: Select all

CPU:       Quad core AMD FX-4350 (-MCP-) cache: 8192 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 33527.8 
           Clock Speeds: 1: 1400.00 MHz 2: 3600.00 MHz 3: 2000.00 MHz 4: 1400.00 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Pitcairn PRO [Radeon  R7 265 ] bus-ID: 01:00.0 
           X.Org: 1.15.1 drivers: ati,fglrx (unloaded: fbdev,vesa,radeon) Resolution: [email protected] 
           GLX Renderer: AMD Radeon R7 200 Series GLX Version: 4.5.13399 - CPC 15.201.1151 Direct Rendering: Yes

[another_commander]

As per feature request on github, we now have some more freedom with HUD text output. More specifically:

• The key rgb_color can now be used for the Weapons Offline and FPS counter texts in hud.plist. The key sets the desired color of the text for these two hud elements.
• Hud message gui: text_color key for setting the standard message text color. Default is yellow.
• Hud message gui: text_comms_color key for setting the incoming comms message text color. Default is green.
• Hud message gui: background_automatic. This is a boolean key that determines the behaviour of the message gui background, if that has been set. The default value is yes, which means that the message gui background pops up and fades out together with the messages as they appear on screen. A value of no will make this background persistent, meaning it will be visible at all times in the external view screens and fade out once a gui screen has been entered. If the message_gui entry in hud.plist has the "permanent" key set, then the background, if set, will appear everywhere. This key is ignored if no message gui background has been set.
• The JS player.ship read/write properties messageGuiTextColor and messageGuiTextCommsColor enable control of hud messages color by scripts and those colors can be changed dynamically.

[gsagostinho]

Would you consider the generation delay game breaking?

On my computer I am hardly noticing any extra delay with Perlin 3D planets.

Thing is, if P3D becomes the default, that lag is still apparent when using Povray.

Someone correct me if I am wrong, but if P3D would become default then I believe one can simply add the simple parameter perlin_3d = "NO" to a new "universal" section in Povray's planetinfo.plist in order to disable Perlin 3D. (similarly how one enables it right now)

[phkb]

In the next nightly build, it will be possible to use the page up/page down keys on screens that have multiple pages. While this won't make a lot of difference to most screens (as the arrow left/right already does this function), on the F8 Market screen it should make a considerable difference if you have any additional commodities defined. Navigating though the list should now be very simple.

[phkb]

In tonights build is the ability to change the display color of equipment items, which means you could do this:



(Eek! My head is spinning!)

But as a favour to everyone it's probably best that you don't! Please use responsibly.

You can add colour in two different ways:
(1) Via equipment.plist files, by adding a "display_color" property to your equipment definition. eg

Code: Select all

			"display_color" = "whiteColor";

(2) Via Javascript, by doing the following:

Code: Select all

	EquipmentInfo.infoForKey("EQ_MY_EQUIPMENT").displayColor = "whiteColor";

Note that changes to color made in JS do not get saved in the save game file.