Progress

[cim]

"Tag is ..."

"Keyword is ..." includes searching the tags (title, description, tags, category), but I could add a separate one that only searched tags if that would be useful.

EDIT:

Speaking of the expansion pack manager; I'd like to see the left and right arrow keys on the expansion pack manager page forwards / backwards regardless of what line is currently highlighted

Good point - I'll sort this out.

[cim]

The OXZ manager tweaks above are now in.

Also in is the ability to set laser properties from [wiki]equipment.plist[/wiki], including defining new laser weapons. You do so by adding a weapon_info property to the equipment. Here's the current one for the beam laser.

Code: Select all

weapon_info = {
	range = 15000;
	energy = 0.5;
	damage = 6.0;
	recharge_rate = 0.1;
	shot_temperature = 3.2;
	color = "yellowColor";
	threat_assessment = 0.5;
};

You'll notice that the properties here are not quite the same as in 1.80 - this build will also include, experimentally, some adjusted laser parameters to try to fix the combat balance issues.

[Redspear]

Also in is the ability to set laser properties from [wiki]equipment.plist[/wiki], including defining new laser weapons.

Brilliant! Thanks cim

[Wildeblood]

Also in is the ability to set laser properties from [wiki]equipment.plist[/wiki], including defining new laser weapons.

Are these arbitrary weapon definitions associated with their own cross-hairs? Once I define the Dipolarized Laser, Interphasic Laser & Phlogistonic Trans-Laser in equipment.plist can I define unique cross-hairs for each in crosshaIrs.plist, or do they all get treated as "OTHER"?

[cim]

Are these arbitrary weapon definitions associated with their own cross-hairs?

Yes. The cross-hairs code makes no distinction between a weapon defined by OXP and a weapon defined by the core equipment.plist

[cim]

The planetinfo modifications are mostly ready to be put into the nightly builds. They're working well, from normal use all the way up to building new galaxies.

A few extra features at the same time:
- atmosphere rotation rate for planets now works again
- there's a percent_ice property to control the size of the polar ice caps.

- there are now optional government_description, economy_description, and population_description entries which override the display on the F7 screen, so you can do things like

Code: Select all

    government = 3; // dictatorship
    government_description = "Monarchy";

This will probably go in over the weekend unless serious bugs are found, which has implications for those of you testing the nightly builds. A save game generated in a nightly build once this is merged in will not load in 1.80 at all - not just the "lose your cargo and lasers" that happens at the moment, it literally doesn't contain some of the essential values for 1.80 and earlier's way of generating the galaxy.

All 1.80 savegames should of course load fine in the nightly build, unless you're playing with an alternative galaxy seed - if that's the case, you will need to prepare a planetinfo.plist file that contains at the very least the system coordinates you are using. If you find other loading errors please report them.

[cim]

The planetinfo changes are now merged in and should be in tonight's builds. If you're following the nightly builds, back up your save game before upgrading.

I'll update the documentation with the new stuff in the next few days.

[Cody]

Before I tinker, does the star_count_multiplier work in the new planetinfo.plist (if inserted, that is)?

[another_commander]

Before I tinker, does the star_count_multiplier work in the new planetinfo.plist (if inserted, that is)?

Yes.

[Cody]

Before I tinker, does the star_count_multiplier work in the new planetinfo.plist (if inserted, that is)?

Yes.

A trifle prolix, Admiral - but I think I get your drift! It is a somewhat different beast now.

[cim]

Though the use of star_count_multiplier has changed slightly.

In 1.80, star_count_multiplier multiplies the randomly-generated number of stars (which may be 0) by itself, unless sky_n_stars is set, in which case that value is used without multiplication.

In 1.81, if you have both sky_n_stars and star_count_multiplier applied to a system, the values are multiplied together and used. Because of the base planetinfo, this is effectively all systems - random values around 6,000 for sky_n_stars, and fixed value of 1 for star_count_multiplier - both can be overridden on a per-system or universal basis as before.

Similar changes have been made to nebula_count_multiplier

[Cody]

<nods> This is why I've had to reduce my star_count_multiplier value from 1.80 levels, yes?

[cim]

Yes, the average number of in-system stars is higher under the new random algorithm than it was under the old one, and the variation between systems is considerably less.

[Cody]

Is the sun_distance more varied now too? If so, does that affect using the sun_distance_modifier in any way?

[cim]

Sun distance is slightly more complex too.

The normal system values are identical to those in 1.80, and set with the sun_distance property.

sun_distance_modifier, if set, should work exactly as before and set the sun's distance from the planet to that many times the planet's radius, ignoring sun_distance.

There is also a new sun_distance_multiplier property, which if there is no modifier property set, just multiplies the base sun_distance.

So, you can either do:
sun_distance_modifier = 80; and set every sun to be 80 radii from its planet
or
sun_distance_multiplier = 4; and set every sun to be 4 times as far from its planet as previously (for an average of 80, still)