eternallands:stable_snap_build

Last commit made on 2022-03-14
Get this branch:
git clone -b stable_snap_build https://git.launchpad.net/eternallands

Branch merges

Branch information

Name:
stable_snap_build
Repository:
lp:eternallands

Recent commits

8e20c3e... by Paul Broadhead

Merge branch 'master' into stable_snap_build

89324a0... by Paul Broadhead

Update version and CHANGES for 1.9.6.1 release.

b3fe7b7... by Paul Broadhead

Updated snap build for 1.9.6.1 release.

3504b11... by Paul Broadhead

Updated deb file for 1.9.6.1 release.

db05954... by Ben Doughty <email address hidden>

Remove the now defunct Mac-specific elglext.h.

e5a9493... by Ben Doughty <email address hidden>

Update the macOS build so it'll use the common glext.h shared by other platforms, rather than the old bodged version from the macosx folder. This fixes problems caused by the recent water shader work.

7991d98... by Ben Doughty <email address hidden>

Added a portable copy of khrplatform.h for Mac users (because of course Apple doesn't provide one by default).

0ae8941... by Paul Broadhead

Follow rfc3986 and allow "~" in URLs as before.

75ddf71... by Paul Broadhead

Fix trade issue where items would not be sent to storage as expected.
The storage or inventory destination is included in the ACCEPT_TRADE
message from the client. It was previously, only sent after the client
had received acknowledgement from the server that the first accept
had been received. If a player clicked the accept button the second time
very quickly, before the receipt, the destination would not be included in
the message. - nor would the trade log get set.
This fix sends the destination information with all ACCEPT_TRADE
messages, and also sets the trade log. All ACCEPT_TRADE messages always
included the bytes but just did not set them unless it had had the receipt.
I did try a different fix that prevented sending the second
ACCEPT_TRADE message until the receipt was received, it was just overly
complex due to the vast range of possible states and messages.

ecff412... by =?utf-8?q?G=C3=A9_Vissers?= <email address hidden>

Fix map editor build

Two fixes to make the map editor compile again after the new water shader changes:
* The eye candy code sets position information about eye candy lights for the new shader. Don't do this when
  compiling the map editor, since the map editor does not use the new water shader yet.
* get_extensions_string() checks the OpenGL context version to determine how to retrieve the extension strings from
  the OpenGL implementation. Make this context version available in the map editor as well.