Purge RELEASE_NOTES
This commit is contained in:
Ignacio R. Morelle
parent
c638385223
commit
1dfa690d73
1 changed files with 2 additions and 373 deletions
375
RELEASE_NOTES
375
RELEASE_NOTES
|
|
@ -14,380 +14,9 @@ The release team should empty this file after each release.
|
|||
CHANGES
|
||||
=======
|
||||
|
||||
[section="Example section header"]
|
||||
[rasection="Example section title"]
|
||||
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 that UMC add-ons 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 add-on 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 other hand 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]
|
||||
[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]
|
||||
x = 25
|
||||
y = 20
|
||||
text = "Lua map generator"
|
||||
[/label]
|
||||
[/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="Compatibility 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 compatibility-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 compatibility, 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]
|
||||
|
||||
Additionally, you can use "log-debug=scripting/lua" at command line, and all lua print commands will be routed to the debug log.
|
||||
|
||||
[*] map_generation= syntax in [multiplayer] was changed to match the meaing of map_generation= in campaigns, this means map_generation= will only generate the map and preserve anything bug map_data while scenario_generation= can be used to generate the complete scenario.
|
||||
[/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 synchronize 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 specific results in a mp game.
|
||||
[*] [elseif] inside [if] simplifies wml program flow.
|
||||
[*] [do_command] allows to execute attacks, moves, recalls, recruits .. from wml having the same effect as if a player had ordered them.
|
||||
[*] [put_to_recall_list]
|
||||
[*] [store_relative_direction]
|
||||
[*] [remove_event]
|
||||
[/list]
|
||||
[/section]
|
||||
[section="New lua functions"]
|
||||
[list]
|
||||
[*] [b]wesnoth.synchonize_choice[/b] is now able to query information form another side than the currently playing one.
|
||||
[*] [b]wesnoth.get_all_vars[/b] allows get get a copy of the whole wml variables set.
|
||||
[*] [b]wesnoth.wml_conditionals[/b] is not a function, but a table, similar to wesnoth.wml_actions. It can be used to define new conditional WML.
|
||||
|
||||
For instance after running this lua code,
|
||||
|
||||
[spoiler]
|
||||
[code]
|
||||
function wesnoth.wml_conditionals.can_make_archon(cfg)
|
||||
local x = cfg.x or error("[can_make_archon] missing x")
|
||||
local y = cfg.y or error("[can_make_archon] missing y")
|
||||
|
||||
local adj = wesnoth.get_units( { x = x,
|
||||
y = y,
|
||||
type = "Spearman",
|
||||
side = wesnoth.current.side,
|
||||
{ "filter_adjacent" ,
|
||||
{
|
||||
side = wesnoth.current.side ,
|
||||
type = "Spearman"
|
||||
}
|
||||
}
|
||||
} )
|
||||
|
||||
if #adj == 0 then
|
||||
return false
|
||||
end
|
||||
|
||||
return true
|
||||
end
|
||||
|
||||
function wesnoth.wml_actions.make_archon(cfg)
|
||||
local x = cfg.x or error("[make_archon] missing x")
|
||||
local y = cfg.y or error("[make_archon] missing y")
|
||||
|
||||
local u = wesnoth.get_unit(x,y)
|
||||
local adj = wesnoth.get_units( { type = "Spearman",
|
||||
side = wesnoth.current.side,
|
||||
{ "filter_adjacent" ,
|
||||
{
|
||||
side = wesnoth.current.side ,
|
||||
type = "Spearman",
|
||||
x = x,
|
||||
y = y
|
||||
}
|
||||
}
|
||||
} )
|
||||
|
||||
if not u or not adj or #adj == 0 then
|
||||
return
|
||||
end
|
||||
|
||||
a = adj[1]
|
||||
|
||||
if not a then
|
||||
error("That's wierd")
|
||||
end
|
||||
|
||||
u.hitpoints = u.hitpoints + a.hitpoints
|
||||
u.name = u.name .. ' + ' .. a.name
|
||||
|
||||
wesnoth.put_unit(a.x, a.y, nil) -- kill the unit that was absorbed
|
||||
end
|
||||
[/code]
|
||||
[/spoiler]
|
||||
the following becomes a valid wml menu item definition:
|
||||
|
||||
[code]
|
||||
[set_menu_item]
|
||||
id = make_archon
|
||||
description = "Make a Spearman Archon"
|
||||
[show_if]
|
||||
[can_make_archon]
|
||||
x = $x1
|
||||
y = $y1
|
||||
[/can_make_archon]
|
||||
[/show_if]
|
||||
|
||||
[command]
|
||||
[make_archon]
|
||||
x = $x1
|
||||
y = $y1
|
||||
[/make_archon]
|
||||
[/command]
|
||||
[/set_menu_item]
|
||||
[/code]
|
||||
|
||||
[/list]
|
||||
[/section]
|
||||
|
||||
[section="Example section 2"]
|
||||
Example contents 2.
|
||||
[/section]
|
||||
|
||||
[section="Lua bit32 library (bitwise operations)"]
|
||||
The [tt]bit32[/tt] library, which was added in Lua 5.2, is now enabled. This means that your Lua scripts can now perform bitwise operations, if needed.
|
||||
For more informations about this library please go to [url]http://www.lua.org/manual/5.2/manual.html#6.7[/url].
|
||||
[/section]
|
||||
|
||||
[section="New ImagePathWML functions"]
|
||||
[list]
|
||||
[*] ~SEPIA() gives to the image a sepia tone, like the one found in old pictures.
|
||||
[*] ~NEG() negates the RGB values of the image, giving it an effect similar to a photographic negative.
|
||||
[/list]
|
||||
[/section]
|
||||
|
||||
[section="Automatically download User-made content from the multiplayer lobby"]
|
||||
In previous versions of wesnoth, if a game is hosted in the mp server which requires an add-on to play, a player must determine what add-on is necessary (not always obvious from the server entry), then log out of the mp lobby and navigate to the add-on manager, search for these add-ons by name or author, download these add-ons, and rejoin the server.
|
||||
|
||||
Now, a player can simply double click on the game entry and they will be prompted to download all of the necessary add-ons and their dependencies.
|
||||
[/section]
|
||||
|
||||
[section="Better Multiplayer add-on Versioning"]
|
||||
In previous versions of wesnoth, if a game is hosted in the mp server which requires an add-on to play, the lobby UI will gray-out the game entry and prevent you from joining a game which will be broken if you attempt to play it. However, if you have the add-on but it is out-of-date, the UI will not help you and you will generally speaking wander into a minefield of OOS errors, unless you diligently update your add-ons. This situation discourages the less diligent players from playing UMC mp content, and thereby discourages this content generally.
|
||||
|
||||
In current versions, all games carry metadata which documents which add-ons are needed to play them, and at what versions. UMC authors may specify for each [era] or [modification] what the minimum add-on version is with which this content is backwards compatible, by adding "addon_min_version" attributes to these tags, which should be verion strings e.g. "1.2.3" to be compared with the add-on version string in the .pbl file of the add-on. [b] If no minimum version is specified, it is assumed that there is no backwards compatibility! [/b] Wesnoth clients will take all this information into account, and when a user tries to join a game with UMC content, will request to automatically update the relevant add-ons if it will make it possible to play the game. Wesnoth clients will also warn the user when the host has out-of-date add-ons, a situation which cannot be resolved unless the host updates.
|
||||
[/section]
|
||||
|
||||
[section="FriBiDi"]
|
||||
Support for ancient versions of FriBiDi was dropped. The minimum for both CMake as well as scons is building with fribidi >= 0.10.9. Building with the latest versions might cause some warnings about deprecated functions. If you encounter these, please build either with strict compilation turned off or without FriBiDi support.
|
||||
[/section]
|
||||
[/rasection]
|
||||
|
||||
==========
|
||||
KNOWN BUGS
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue