Use status >= STATUS_AUTHORIZED as the state criteria for all cases
where updates about other clients are sent.
This avoids the case where a client is informed that another client
has joined but not informed when it later quits, resulting in
stale entries in the client list window.
Clamping each sample value to half the available range could cause
unnecessary premature clipping with lots of sounds playing. This change
does not affect the actual volume level.
Debian now provides a default soundfont for FluidSynth via its alternatives system.
In short, FluidSynth is configured to look for `/usr/share/sounds/sf3/default-GM.sf3` as its default soundfont, and each soundfront package (FluidR3, OPL-3, MuseScore...) may provide or override this symlink. By default, FluidSynth is installed on Debian with the `TimGM6mb` soundfont by default due to its limited size.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929185 for further details.
The 6th is "is-stable-tag", but it is currently broken in meaning.
Betas and RCs are considered "stable", but final releases are not.
This is the reason it was working for RC1, but not for the final
release.
english (us): 23 changes by 2TallTyler
luxembourgish: 63 changes by phreeze83
ukrainian: 72 changes by StepanIvasyn
catalan: 5 changes by J0anJosep
turkish: 5 changes by nullaf
english (us): 7 changes by HAJDog247
czech: 18 changes by PatrikSamuelTauchim
luxembourgish: 99 changes by phreeze83
serbian: 4 changes by nkrs
catalan: 20 changes by J0anJosep
french: 1 change by arikover
portuguese: 30 changes by azulcosta
swedish: 30 changes by kustridaren
spanish (mexican): 1 change by absay
japanese: 13 changes by Azusa257
vietnamese: 1 change by KhoiCanDev
estonian: 12 changes by siimsoni
czech: 6 changes by PatrikSamuelTauchim, 2 changes by tomas-vl
chinese (simplified): 88 changes by clzls
arabic (egypt): 16 changes by AviationGamerX
luxembourgish: 4 changes by phreeze83
korean: 34 changes by telk5093
italian: 16 changes by AlphaJack
german: 1 change by danidoedel, 1 change by Wuzzy2
slovak: 30 changes by FuryPapaya
catalan: 35 changes by J0anJosep
tamil: 16 changes by Aswn
dutch: 32 changes by Afoklala
portuguese (brazilian): 14 changes by Greavez, 5 changes by jpsl00
Before this commit, it scaled to map-height-limit. Recently this
could also be set to "auto", meaning players don't really know
or care about this value.
This also means that if a player exported a heightmap and wanted
to import it again, looking like the exact same map, he did not
know what value for "highest peak" to use.
This opens up the true power of the TGP terrain generator, as it
is no longer constrainted by an arbitrary low map height limit,
especially for extreme terrain types.
In other words: on a 1kx1k map with "Alpinist" terrain type, the
map is now really hilly with default settings.
People can still manually limit the map height if they so wish,
and after the terrain generation the limit is stored in the
savegame as if the user set it.
Cheats still allow you to change this value.
This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.
Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.
Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.
This setting influence the max heightlevel, and not as the name
suggests: the height of the generated map.
How ever you slice it, it is a very weird place to add this
setting, and it is better off being only in the settings menu.
Commits following this commit also make it more useful, so users
no longer have to care about it.
Wim Leflere