wesnoth/RELEASE_NOTES
2015-03-07 21:29:19 -05:00

275 lines
12 KiB
Plaintext

This file is here to allow devs to easily add stuff in the release notes for the next release, it allows easy syncing with the release team, since you don't have to be around when the release takes place...
Just dump whatever you want to have mentioned in the release notes here. Please take care that it is in a way that allows copy&paste to the release notes. That is making sure that spelling/grammar/whatever is usable and that you are using complete sentences, not just single words. Please do use forum syntax and do *NOT* split lines after 80 chars!
Stuff that belongs in here:
* groundbreaking changes (new campaigns, extremely new feature, ...)
* changed dependencies (new things, version bumps, stuff that was removed)
* known bugs
The release team should empty this file after each release.
=======
CHANGES
=======
[section="Example section header"]
Example contents.
[/section]
[section="fearless/healthy [effect]s"]
instead of checking whether the trait id equals fearless/healthy we now have fearless/heathy [effect]s
this means especialy that umcaddons that use their own fearless/healthy traits have to add those [effect]s in them.
[/section]
[section="play single move button in replay mode"]
A button that allows playing one move at a time in replay mode has been added. Thanks to Zappaman for this.
[/section]
[section="Multiplayer Alerts"]
The multiplayer alerts, i.e. the sounds and desktop notifications such as related to mp lobby events and chat messages, can now be configured under Preferences > Multiplayer > Alerts. Individual events, such as players joining or leaving, private messages, messages from friends, etc. may now prompt a sound or notification, and may be handled differently in the lobby vs. in game. The advanced preferences "lobby sounds" and "desktop notifications" have been removed, having been subsumed by this new screen. The particular sound files which are played for each of these types of events, may now be easily reconfigured by changing some attributes in data/game_config.cfg.
[/section]
[section="Hyperlinks"]
Added support for hyperlinks to GUI2. This means that the chat log and also the addon descriptions pages should now support rendering and clicking on hyperlinks.
[/section]
[section="New Filesystem Code"]
Revised dependencies:
[list]
[*]SDL_mixer version ticked to 1.2.12
[*]Boost filesystem (new)
[*]Boost locale (new)
[*]Libintl no longer required.
[/list]
Boost locale is only available at boost version 1.48, so that is now the minimum boost version for the project
The boost filesystem & locale dep may be disabled, if compiling with scons, by passing it an argument. Then it will compile using the legacy filesystem code, and use libintl. (This may not be maintained in the long term, however.)
The new SDL_mixer requirement can be similarly disabled by simply using the older version, and the C++ will detect this and use the old code. However this will result in a mix of old and new filesystem code being compiled, so be warned.
For those of you compiling Wesnoth on OS X using Xcode, this means that you need to download a new version of wesnoth_compile_mac_1.13.zip.
[/section]
[section="Help Browser"]
Many new features, see changelog.
[/section]
[section="--render-image command line argument"]
A new command-line argument "--render-image" has been added. It is similar to --screenshot, but instead of a map, it takes a wesnoth imagepath and generates at bitmap with the filters applied.
Example usage:
[code]
wesnoth --render-image "units/undead-skeletal/banebow-bow-attack-1.png~SCALE(144,144)" "banebow.bmp"
[/code]
will generate a scaled image of a banebow attack sprite.
[/section]
[section="Boost random"]
Wesnoth's random generator has been upgraded, instead of using the C `rand` function from the 80s, we now use the modern Meresenne Twister generator distributed by boost. The server (and your local client) also generates seeds using /dev/urandom, or platform equivalent (handled by boost random device). The boost random library is now a build requirement.
This means that the WML rand= function should now be much more random and seeded properly. lua on the otherhand still uses the C `rand` function, so it is advised not to use that anymore.
[/section]
[section="Optional Dependency on libpng"]
(Note that it's a bit misleading, you *must* have libpng support in your SDL_image or obviously there's no way you can run the game. However, if you also have libpng available when compiling and running the wesnoth binary, you get something more.)
Wesnoth can now save images as png files. This includes screenshots, map screenshots (taken at command line), and also the new "--render-image" feature. png vs bmp saving is now decided based on the extension of the filename you are trying to save to. If it's bmp, wesnoth saves a bmp. Otherwise if possible wesnoth will save a png.
[/section]
[section="lua random map generator"]
Wesnoth now supports a new random map generator type, "lua". To use it, select either [tt]map_generation="lua"[/tt] or [tt]scenario_generation="lua"[/tt] in your scenario. You should then have a generator tag which includes attributes either "create_map" or "create_scenario", which should be set equal to a lua script which will generate a map / scenario.
Here is a trivial example:
[code]
[label]
x = {X}
y = {Y}
text = {STRING}
[/label]
[multiplayer]
id=lua_map_gen
name= _ "Lua Map Gen Test Scenario"
description= _ "test test test of lua map gen"
map_generation="lua"
[generator]
id="test"
config_name="Test Lua Map Generator"
create_map = << local rng = Rng:create()
print(rng:draw())
print(rng:draw())
print(rng:draw())
local w = 50
local h = 40
map=""
for y=1,h do
local r = rng:draw() % 2
for x=1,w do
if x == 10 and y == 10 then
map = map .. " 1 "
end
if x == (w-10) and y == (h-10) then
map = map .. " 2 "
end
if ((x + y) % 2) == r then
map = map .. "Gg"
else
map = map .. "Md"
end
if x ~= w then
map = map .. ","
end
end
map = map .. "\n"
end
return map
>>
[/generator]
id = foo
random_start_time=yes
{DEFAULT_SCHEDULE}
[event]
name=prestart
{LABEL 25 20 ("Lua map generator")}
[/event]
[side]
[ai]
villages_per_scout=8
[/ai]
id=RBY_Side1
side=1
save_id=RBY_Side1
persistent=yes
color=red
team_name=Red
user_team_name= _ "teamname^Red"
controller=human
canrecruit=yes
shroud=no
fog=no
gold=1000000
[/side]
[side]
[ai]
villages_per_scout=8
[/ai]
id=RBY_Side2
side=2
save_id=RBY_Side2
persistent=yes
color=blue
team_name=Blue
user_team_name= _ "teamname^Blue"
controller=human
canrecruit=yes
shroud=no
fog=no
gold=1000000
[/side]
[/multiplayer]
[/code]
Note that:
[list]
[*] For map generation, simply return a string containing the map data. For scenario generation, return the entire WML for the scenario as a lua table. (see [wiki]LuaWML[/wiki]
[*] You cannot use any of the "wesnoth." api, because you are not in a game at the time that this script is running. The script runs in an entirely separate lua environment from the one used in game, and from every other map generator script.
[*] You can instantiate wesnoth's high-quality random generator (mt19937, much better than the "rand" used by lua's math.random) by using the table [tt]Rng[/tt] to create an rng object, with [tt]seed[/tt] and [tt]draw[/tt] methods.
[/list]
[/section]
[section="Fonts"]
Wesnoth now ships with Bold and Oblique forms of its default font, Deja Vu Sans, and these are used in many menus and in the in-game help for styling text where previously we used SDL_ttf's runtime font styling, which was inferior. Fixes bug #22376.
[/section]
[section="Lua interpreter console"]
As a debugging aide, a lua interpreter console has been added to the game. At time of writing it is accessible from a button the gamestate inspector, also it may be brought up using hotkey '`' by default.
The lua interpreter console supports command-line history, backed up by the GNU readline library. This is an optional dependency, but if you don't have it you won't be able to use the feature.
[/section]
[section="Compatability breaking changes"]
[list]
[*] By default, all lua in wesnoth is now run using "strict globals". This means that you must assign a value to a global variable before using it, or it is a runtime error. Even assigning "nil" is acceptable. While this is strictly speaking a compatability-breaking change, it is quite uncommon that you would require the default behavior for your script to work, and this change greatly improves the maintainability of lua in add-ons, by giving an error message in case of a programmer typo, rather than pretending that everything is fine. This change also improves the behavior of the lua interpreter console.
The implementation is based on a module called "ilua" (interactive lua) available here: http://lua-users.org/files/wiki_insecure/users/steved/ilua.lua
If you must, you can disable the feature in one of the following ways:
[list]
[*] [code] setmetatable(_G, nil) [/code] to disable, and [code] ilua.set_strict() [/code] to re-enable.
[*] [code] result, err = pcall ( possible_global_var ~= nil ) [/code]
[*] [code] result = rawget(_G, "possible_global_var") [/code]
[/list]
Note that this change already revealed a bug in our core WML API as soon as it was implemented.
https://github.com/wesnoth/wesnoth/commit/d31253f585bd1e111705f59bdc37012ff6675f38
[*] In lua, the "print" function no longer writes to "standard out", and its output will not appear in the log files generated by the game. Instead its output only appears in the logs accessible via the in-game lua console.
For backwards compatability, the old print function (which comes with lua) has been renamed as "std_print" rather than being deleted. So if you need to print to standard out you can use that one. You also have the option of course to undo the change with
[code]
print = std_print
[/code]
but then the lua console log won't work.
Another option is to combine them using a closure:
[code]
function make_print()
local new_print = print
local old_print = std_print
return function(...)
old_print(...)
new_print(...)
end
end
print = make_print()
[/code]
[/list]
[/section]
[section="Variable name checking"]
The use of incorrect variable names like 'my_array[1][5].my_value', 'my_array..my_value' or 'my_array[].my_value' will now result in an error.
[/section]
[section="New wml tags"]
[list]
[*] [sync_variable] allows to synchonize a variable between, multiple clients in a mp game. This can for example be a variable that was previously set in a select or a preload event.
[*] [result] inside [endlevel] allows to give side spcific results in a mp game.
[*] [elseif] inside [if] simplifires wml programm flow.
[*] [do_command] allows to execute attacks, moves, recalls, recuits .. from wml having the same effect as if a player had ordered them.
[*] [put_to_recall_list]
[*] [store_relative_dir]
[*] [remove_event]
[/list]
[/section]
[section="New lua functions"]
[list]
[*] wesnoth.synchonize_variable is now able to query information form another side than the currently playing one.
[*] wesnoth.get_all_vars allows get get a copy of the whole wml variables set.
[/list]
[/section]
[section="Example section 2"]
Example contents 2.
[/section]
==========
KNOWN BUGS
==========
[list][*] The mp server has trouble with "Local" player types in campaigns. We have decided to postpone dealing with this. In the meantime, you might try assigning such sides to the host, or running multiple instances of wesnoth. https://gna.org/bugs/?21965
[*] Text for entry2.
[/list]