FreeOrion

I've added a GenerateSitRepMessage effect. The current version has this format:


Every time this is executed, the empire with ID EMPIRE_ID (which can be a reference to the Source.Owner or Target.Owner, or a hard-coded number) will receive a sitrep message in the stringtable entry STRINGTABLE_ENTRY. This has to be a stringtable reference, and not a human- readable bit of text in the effect definition. The stringtable entry can contain parameters with tag strings like %planet% or %tech% or %empire% which are substitued with values in the parameters. The TAG_STRING# values should be same as those in the stringtable entry, and are used to know what kind of item to substitute in. The VALUE# values are integers or strings, depending on the type of TAG_STRING#, and determine what specific item to substitute. These can be Source or Target references, or hard-coded constants. The whole parameters section can be left out if the stringtable entry that is referenced has no parameters to substitute.

There are some example sitrep-generating effects I've added to some of the starting buildings.

The valid values for the tag string are:
* planet - data should be the ID of the planet to substitute, which will appear as a clickable link in the sitrep entry
* system - data should be the ID of the system
ship - data should be the ID of the ship
* fleet - ... ID of the fleet
* building - ... ID of the building
* empire - ... ID of the empire
* shipdesign - ... ID of the ship design
* tech - data should be the name of the tech
* buildingtype - ... name of the building type
* special - ... name of the special
* shiphull - ... name of the hull
* shippart - ... name of the ship part
* species - ... name of the species
* text - substitutes data as text, not making a clickable link. This isn't likely very useful right now for GenerateSitRepMessage, but exists due to how some other sitreps work internally.

Order of parameters shouldn't matter, since it substitutes based on type. (See limitation below)

There are some limitations:
* The GenerateSitRepMessage will be executed on every target object. This can produce duplicate sitrep entries when this wouldn't be desired. This is a problem if the scope isn't carefully written, such as when a building acts on anything that contains source... this would then act on the planet, and the system, giving a double-sitrep message.
* There's no way to access anything about the whole target set, so you can't do anything like "The Death Star at Endor has destroyed 8 Rebel cruisers!", but you could have 8 separate messages like "The Death Star at endor has destroyed the Rebel ship Home One" for each acted-on target object. In general, this means there's no easy way to generate one sitrep message for a large number of objects being acted on, without writing a separate effectsgroup, which could be tricky to get right and be sure the sitrep message and actual effect are consistent.
* I don't think it's possible to have more than one item in the sitrep message of the same type at the moment. So, you can have parameters that are a tech and a building, but not two systems in the same message. I haven't actually tested this, so it might happen to work, though I doubt it.
* Sitreps are generated on the server, but substitutions for referenced objects are done client-side, so if a player / empire doesn't have visibility of an object, but that object's ID is referenced in a GenerateSitRepMessage on the server, the object won't appear properly in a sitrep message. Currently this will say "ERROR" (or your translation thereof) in place of the object name. The same applies for shipdesign references.

I've added an Apply button to the Video tab of the options screen, and a toggle for switching between fullscreen and windowed. In my testing on Windows 7, these seems to be working, and allow the player to change the resolution and fullscreen setting without restarting the program. The apply button doesn't do anything for bit-depth settings in the fullscreen droplist, though I don't think that's a major problem or something most people would even notice in practice.

Also, when in windowed mode, at least on Windows, the game window can be resized like any normal program, and this change will be detected and some of the UI will update to fit the new size. There are issues with screens like production, research and design, but the main map and title screen work reasonably well. The change will also be retained for the next time the program is run, just as if it had been enerted in the windowed screen size on the options screen video tab.

How much of this will work on Linux or OSX, I don't know.

I've added a new tool for making content definitions: Statistics. This sounds complicated, and it probably is, but it's not too difficult to understand. The basic idea is that instead of referencing some property of the source or target object, a content creator can instead reference a value that is calculated about the game Universe as a whole. Example statistics include:
* the number of objects in the universe that match a condition, such as how many systems, or how many planets owned by an empire within some distance
* the total population on planets controlled by an empire
* the average trade output on planets in systems with Blue stars
* the largest industry rating on planets within 5 starlane jumps

There are a few other options as well, but in general, the statistics mechanism needs three things:
* A sampling condition: This determines which objects are considered when calculating the statistic.
* A property name: This is calculated for each object that matches the sampling condition. These properties are the same as could could be reference on the source or target objects before, like Population, TargetFarming, StarType, including container references like Planet.PlanetSize.
* A statistic type: This is an operation to perform on the property name values. The options include:
** Number: How many objects match the sampling condition. Note that this can be specified without a property, as no property needs to be evalulated, and if a property is specified, it is ignored.
** Sum: The sum of property values of objects matching the sampling condition.
** Mean: The mean (average = sum / number) property value.
** RMS: The square root of the sum of the property values squared.
** Mode: The most common property value. This is most useful for enumerated types like PlanetSize or StarType. This is the only statistic that can be calculated for those enumerated types, as there is no valid or useful "mean" of the planet types (for example), or "number" that has a planet type value. If no objects match the sampling condition, 0 is returned for int or double values, an empty string is returned, or an INVALID_WHATEVER enumerated type is returned.
** Max: The largest property value.
** Min: The smallest property value.
** Spread: The difference between the largest and smallest property values.
** STDEV: The standard deviation of property values. Returns 0 if there is only one matching object.
** Product: The result of multiplying all the property values together. Returns 1 if there is no matching object.

Unless otherwise specified, if no objects match the sampling condition, 0 is returned.

Other statistic types could be added if needed.

A simple (if implausible) example use of this functionality is an effect that adds to the Trade meter an amount equal to the total population in the universe:
"Sum" specifes the statistic to compute on the property values. "Population" is a property name that specifies what property to calculate on each object. "Planet" is a condition specifies what objects to calculate property values on.

Like most content description synatx, there are optional names to these parts, so this could be rewritten:
with the same result.

Also, for the Number statistic, no property is needed:
which sets target trade equal to the number of systems in the universe.

I'd added an observer mode. Observer players see the entire galaxy, but don't control an empire. One can start a multiplayer game and select the Observer player type from the lobby window to enter this mode.

I recently added a new control mechanism for fleets, to mark them as passive or aggressive. This state can be set for a player's fleet by a new icon on the fleet's panel in the fleets window by clicking.

There are also two new effects: SetAggressive and SetPassive. When these act on fleets, they set the passive or aggressive state of the fleet. This is probably mostly useful for controlling monster behaviour, similar to SetDestination.

If a fleet is passive, it won't (shouldn't?) attack enemy fleets or planets in a system, won't block supply lines, and may remain invisible to enemy empires with insufficient detection to see it. If a fleet is aggressive, it will act like fleets did previously: it will block enemy supply lines and it will initiate combat with any enemy fleet or planet in a system.

Having a stealthy passive fleet in a system with an aggressive enemy probably will result in a battle currently, though that should be fixed in future.

While waiting for the v0.4.1 release, I've been working on some changes to help fix the longstanding issue with non-Latin characters in Windows user names that cause FreeOrion to crash when saving a game or options settings. The issue arises from how Windows handles path strings, which isn't really compatible with how much of FreeOrion and various dependencies pass around paths for opening various input and output files. To resolve some of the issues, I've added some special case path conversion code for when handling input pathes, and rewritten some FreeOrion and Gigi code to handle pathes in a more portable way once they're initialized.

I've made a test build installer with these changes, which I've uploaded here: https://sourceforge.net/projects/freeor ... %20builds/ (It's the Windows installer with Non-Latin-Path-Test in the name).

This should / might let FreeOrion run on non-Latin language Windows systems, such as Cyrillic, or when the user name has characters like à or Є in it.

I'd like some reports about whether this works.

A build for OSX using the relevant branch code at http://freeorion.svn.sourceforge.net/vi ... GiGi-Fork/ to see if it still works on OSX would also be good. Most of the changes should be transparent to OSX as they're within preprocessor OS-specific blocks, but I also moved the Gigi code into the FreeOrion repository in that branch, which might do weird things.

It probably won't work if the path where FreeOrion itself is installed has a non-Latin characters. This generally isn't a problem for a default install on Windows, though if someone moves and runs FreeOrion somewhere else, such as if they wanted to have it installed at some non-Latin-character containing path like on a UBC thumb drive or some folder within their username folder like on the desktop, it would likely still crash. Fixing that is much more complicated, due to how more dependencies take raw C++ strings for file names, which would need them to be rewritten somewhat to take a more portable path object.

In additional language support news, the Windows version, and if we're lucky some other OS versions, should now support different keyboard layouts and non-Latin chat and other text-entry. On Windows, the OS setting for keyboard layout is used for interpreting keypresses. I don't know how this will work on Linux or OSX, so I'd like some reports if someone else can test.
There are a couple of issues with this though:

Firstly, the stringtable in use needs to support the non-Latin characters for them to appear when typed. If you set your keyboard layout to russian, but load the english stringtable, the cyrillic font symbols won't be loaded, so you'll just see blank text. When using the russian stringtable, the relevant font symbols are loaded, so typing works.

Secondly, there are issues with entering save file names. The dialog doesn't like non-Latin characters, so if using (for example) a russian layout with cyrillic characters, it rejects any typed-in file name. Also, if there are non-Latin characters in the player and empire name, they'll be left out of the autosave file name (though an autosave will still be generated with a name like FreeOrion__0001.sav).

Thirdly, the infrequently-used in-game hotkeys don't automatically recognize different keyboard layouts, as they are based on which key was pressed, rather than the translated character for that key or key combination. As such, if you have an AZERTY or QWERTZ or similar layout, by default the keypresses will still by interpreted as if they were QWERTY. To get around that, I've also added a test mechanism to remap those keypresses. In keymap.txt, there is a list of key id numbers, which are to indicate the keypress the game detects, and the keypress it should replace that with. I hope to replace those numbers with a more readable symbol for the keys, but they should match up with the ASCII key codes. So, to remap hotkeys for Q to A (for an AZERTY keyboard so that pressing "a" (code 97) acts like pressing "a" instead of like pressing "q" (code 113)), you'd addCurrently only the "TEST" keymap is read and used, though I hope to add a droplist to the GUI to select from one of the others listed in the file (and to have those filled out properly). Note that these ascii codes are case sensitive, so there needs to be separate entries to remap q to a and Q to A. Note also that this key re-mapping doesn't affect text entry such as typing; just hotkey commands.

There are a couple of recent scripting changes that I'd like to highlight for content creators:

1) Functions

Scripts can now access several functions of one or two parameters when specifying numbers in scripts. Not everywhere that expects a number can do this, but most Condition parameters, and the costs and production or research times of techs, buildings, ship hulls, and ship parts can use functions.

The available functions are:

Sin(), Cos(), and Log(), which take one parameter and return the sine, cosine, or base-e logarithm of the parameter's value.

Min(), Max(), and Random(), which take two parameters, separated by a , character. Min returns the smaller of the parameters, Max returns the larger, and Random returns a uniformly distributed number between the two parameter values.

An example use of Random, Sin, and Cos is in the (temporary) spawning of ion storms from Cultural Archives buildings:
2) Variable Costs

The reason that techs, buildings, ship hulls, and ship parts can use functions, as noted above, is that these are now variables, and can be specified depending on the gamestate. For example, Terraforming recently was changed so its cost depends on how far a planet has been terraformed from its original type:
Similarly, the cost of a ship hull can depend on gamestate, like how many ships an empire owns:
To clarify, "Number" here is a statistic, which takes a condition parameter and returns the number of objects in the gamestate that match the condition, which is then used for calculating the math expression it is in.

3) Exponentiation

The ^ operator has been added for exponentiation, and works just like +, -, *, and / operators.

I've implemented a basic means to display a list of combat events on the following turn. The log is accessed by clicking on the link in the sitrep window, and shows a list of attacks and damage, and destroyed objects.

Various statistical info could also be calculated; suggestions for what and how to add to this display are requested.