-
-
Notifications
You must be signed in to change notification settings - Fork 988
/
RELEASE_NOTES
223 lines (179 loc) · 9.87 KB
/
RELEASE_NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
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="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]
[/list]
[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]