The Ultimate Site of Worms Armageddon

All About TUS => Announcements => Topic started by: Deadcode on July 16, 2020, 07:44 PM

Title: Worms Armageddon v3.8 Released
Post by: Deadcode on July 16, 2020, 07:44 PM

Seven years in the making, the long-awaited 3.8 update is finally here!

Highlights of v3.8 (https://worms2d.info/Worms_Armageddon_3.8_Features)

CD-ROM Edition: Download Here (https://worms2d.info/files/WA_update-3.8_%5BCD%5D_Installer.exe)
Steam Edition: Update automatically through Steam.
GOG Edition: Please read this to avoid losing your team data. (https://tinyurl.com/WA38GOG)

SHA-256 sum:
c93765fe0fd6ab6a106cb124a9aba3ba3c134f8de365313a8c70d4a48aae1089 *WA_update-3.8_[CD]_Installer.exe

v3.8 Update (built 2020-06-21, released 2020-07-16)

Fixes

[DC] Bug introduced in v3.7.2.1: Opening a team for editing, in which an animated gravestone (numbered 1-6) was selected, and then clicking OK to save the team (even if nothing was changed), would reset the grave to Gravestone 1.
[DC] Bug introduced in v3.6.28.0: When the Map Editor was in Preview mode for a .BIT or .LEV type map, and preview was updated while the water level was set high enough to force there to be fewer than 18 Placement Holes, right-clicking the Placement Holes button caused the displayed number to be updated to a value lower than 18, even though there was (and still is) no support for changing the number of placement holes in a .BIT or .LEV map. Subsequently lowering the water level would result in the displayed preview disagreeing from what would be seen in-game (because there were now too few placement holes in the preview). Note, this bug became easier to reproduce by accident in v3.7.2.1, due to the fix that forced the preview to update when the water level was changed.
[DC] Bug in a feature introduced in v3.6.28.0: In the Map Editor, the water level was previewed as if the map were of standard height, and could be shown incorrectly if the map was of custom height.
[DC] In v3.6.26.4, a feature was added to the Map Editor in which Ctrl-clicking the Terrain Texture button toggles v3.0 terrain emulation (mainly in the application of grass).
- [DC] When loading a .BIT or .LEV map with a date stamp earlier than 2002.08.08 (the approximate release date of 3.5 Beta 1), the file was supposed to be treated by default as if it had been designed for W:A v3.0. However, this feature was non-operational.
- [DC] There was no indication of whether this mode was in effect, other than the effect seen on the map when in Preview mode. Now, a "3.0" indicator will be displayed on top of the Terrain Texture button when this mode is enabled.
[DC] Bug in a feature introduced in v3.6.24.1: When "Playback at...", or restarting from a marked location, was used to skip to a point in a replay in which a looped sound effect (such as the Super Sheep flying sound, or the Dynamite fuse) should have been playing, the sound would not be heard.
[DC] Bug in a feature introduced in v3.6.26.4: When "Playback at...", or restarting from a marked location, was used on a replay extracted from a network log, it did not begin fast-forwarding until the loading stage had finished (i.e., until the first frame of game time had passed, it played back network time at normal speed).
The French, Spanish, and Russian translations have been updated by LTK, OutofOrder, and StepS, respectively, encompassing all new strings added since v3.7.2.1 and some corrections and improvements to existing strings. Some corrections have also been made to existing English strings.
The Portuguese translation has been updated and improved by Kaleu. All strings added/changed in the updates are now translated.
The German translation has been updated and improved by schaf. All strings added/changed in the updates are now translated.
The Swedish translation has been updated and improved by Olle Settergren. All strings added/changed in the updates are now translated.
[DC] The Dutch, German, Portuguese, Spanish, and Swedish translations had a complete absence of paragraph breaks in the descriptions of some missions (MISSION_DETAIL_*). These descriptions have now been given paragraph breaks directly corresponding to their English versions.
[DC] Bug in a feature introduced in v3.6.26.4: The translated language name of Portuguese (displayed in the language drop-down of the Options menu) has been fixed.
[DC] The spelling has been corrected in some string names. To make a user-made language file which was written for an earlier version of W:A compatible with the latest version, please see the list of "rename" entries in the DATA\User\Languages\localisation.log file. Make sure to put user-made language files in the appropriate subdirectory of User\Languages, not DATA\User\Languages.
[DC] Cheat Options dialog box, as accessed by a client who joined an online game
- [DC] Bug introduced in v3.6.30.0: The buttons in this dialog box (corresponding to options enabled by the host) appeared to be changed by being clicked, even though a client who joins a game cannot change its scheme options. (The changes were not in fact saved, however; this was a cosmetic bug only.)
- [DC] Even before v3.6.30.0, there was a minor bug in this dialog box; clicking the buttons gave a sound effect implying a successful click, when it should have given the "can't click here" sound effect.
[DC] Bug in a feature introduced in v3.6.30.0: When Home Lock was in effect (activated by pressing Ctrl+Home), this mode should have been temporarily overridden while aiming a cursor or controlling a Super/Aqua Sheep, but was not. Also, Home lost its old function, which has now been restored, of snapping the cursor to the current worm.
[CS] In certain circumstances, W:A would crash when it attempted to play a music track, and the respective file was missing.
[DC] In the team statistics viewer, "Overall Team Rank" was incorrectly calculated, and had a maximum of 85% instead of 100%.
[CS,DC] Bug introduced in v3.7.0.0: At in-game resolutions with a width not evenly divisible by 64 pixels, when playing on maps that force a custom gradient to be dithered, the background gradient would not be drawn all the way to the bottom of the screen, causing a strip at the bottom of the screen (with a height of ScreenHeight*(ScreenWidth%64)/ScreenWidth) to have artefacts due to being drawn but never erased.
[CS] A logic condition was improved when using a DirectDraw graphics API. The condition was used to determine when it is safe to resume the game after it was minimised and restored. The fix was required for hardware rendering, but may improve compatibility in certain hypothetical circumstances.
[DC] Flaw introduced in v3.6.31.0: The message "<team> (<player>) forced out by possible message injection" was almost always a false positive, and furthermore the message itself was too easily misinterpreted. This message has been replaced with "<team> (<player>) forced out by an unknown cause", using the new string NET_UNKNOWN_CAUSE.
[DC] Bug introduced in v3.7.0.0: If the camera tried to centre on an object that reached the top of the coordinate system, the game would crash. This could happen, for example, when flying a Super Sheep as high as it would go, or selecting a cursor-aimed weapon while flying at maximum height with the Jet Pack.
[DC] Bug in a feature introduced in v3.7.2.1: When hosting a LAN game, the 5 minute notification would be shown (inappropriately), and attempting the /open command would cause a crash.
[DC] Bug introduced in v3.6.30.0: If a client was editing a team or viewing the current scheme's Options or Weapons, and during this was kicked by the host or disconnected, then upon exiting back to the Join screen there would be no sign of having been kicked, and the game would behave as if it were still connected to the host (although it would not be).
[DC] Bug introduced in v3.6.29.0: When a new localised string, NET_LOC_HOSTER, was added to distinguish between the verb "to host" and the noun "person who is hosting", it was accidentally left as "Hoster" in English, even though both strings should be "Host".
[DC] Bugs in the interaction between the map thumbnail and intrinsic maps
- [DC] Bugs introduced in v3.6.30.0 and v3.7.0.0: When an intrinsic map was the current map upon entering a screen that displayed the map thumbnail, it was (incorrectly) possible to right-click the map thumbnail to enter the Map Editor, which would then generate a random map; upon exiting the editor the name of the intrinsic map was not cleared.
  - Starting in v3.6.30.0, this bug was introduced to the online hosting screens, and could be triggered by starting a New Match or entering the Next Round stage.
  - Starting in v3.7.0.0, this bug was introduced to the offline multiplayer screens, and could be triggered by starting a new game from the Main Menu, starting a New Match, or entering the Next Round stage.
- [DC] Bug introduced in v3.7.0.0: In the offline multiplayer Next Round screen, clicking the map thumbnail (to generate a new random map) when the current map was intrinsic did not clear the name of the intrinsic map.
[DC] Bug in a feature introduced in v3.6.31.0: When W:A forced the current map to be randomly generated, it would ignore the setting of the map complexity slider. The circumstances under which this could happen include:
- Hosting an online game when the current map is a .BIT or .PNG.
- Hosting a game on a third-party WormNET server in a channel that enables ranking.
- Starting an online or offline game when the "current.thm" file is corrupt or nonexistent.
[DC] It was impossible to successfully join a password-protected game having a 16 character password (except by using a URL to join), because a user-entered 16 character password was truncated to 15 characters.
[DC] Bug introduced in v3.6.30.0: When someone with a 16 character player name hosted a game, their player name was truncated to 15 characters in an inconsistent way. This resulted in the following bugs:
- In the host's front end chat history, the 16 character version of the host's name would appear, but in all other places on the host's end, the 15 character version would appear.
- For all clients, only the 15 character version of the host's name would be seen.
- When clients tried to send a private message to the host in the front end, the host would not see the message, regardless of whether the 15 character or 16 character version of the host's nickname was used.
[DC] Some potential security vulnerabilities have been fixed.
[DC] In the Network screen, the TCP/IP - IPX/SPX toggle button would initially only allow an installed protocol to be selected (i.e., in most cases, only TCP/IP), but after entering and leaving either the LAN screen, WormNET, or Direct TCP/IP, both TCP/IP and IPX/SPX would be selectable, even if one of these was not installed.
[DC] Bug introduced in v3.6.20.1: IPX/SPX support was almost completely broken. The player list was empty, and whereas hosted games could be seen under certain conditions, they could not be joined.
[DC] Bug introduced in v3.6.30.0: In the LAN lobby, lines of chat could be received but not sent.
[DC] The registry tweaks TimerWorkaround_*.reg (introduced in v3.6.20.1) and RegisterAssociations_*.reg (introduced in v3.6.30.0) were in Unicode format, making them incompatible with Windows 98.
[DC] Bug in features introduced in v3.6.29.0 and v3.6.30.0: Export Log did not count the self-kill and self-damage of a Kamikaze upon the worm that used it.
[DC] Bug in a feature introduced in v3.6.28.0: The M key, which creates a "bookmark" if pressed during playback, functions both during replay file playback and during instant replays. Previously, when pressed during an instant replay, the mark created could not be removed or used, and would be displayed uselessly for the entire remainder of the game. Now, the mark disappears at the end of the instant replay.
[DC] Bug in a feature introduced in v3.6.23.0: Once an end-game fadeout began during playback of a replay file, it was too late to press R to restart the replay. Pressing it would restart playback, but the fadeout would continue, finish, and close the playback session.
[DC] The instant replay countdown timer was displayed in the format 00:00:00, with the last two digits indicating hundredths of a second, making the second colon misleading. The second colon has been replaced with a decimal point, yielding the format 00:00.00.
[DC] If, within the same WA.exe instance, a WormNET game was hosted with an N digit Game ID, and later was hosted with a Game ID having N-2 digits or fewer (without a game being hosted in-between with N-1 digits), anybody attempting to join the later game would fail, seeing the error "Incorrect Game ID.". This could happen either by disconnecting from one WormNET server and connecting to another one that uses smaller Game IDs, or if within the same WA.exe instance a single WormNET server reset its Game ID counter.
[DC] Bug in a feature introduced in v3.6.23.0: Restarting playback with the R key did not respect camera lock (enabled by turning on Scroll Lock or holding down the left mouse button).
[DC] Some in-game "Morse code" messages in languages other than English were too long to be fully displayed at 640×480. They are now wrapped to two lines. Note, user translations that are too long to fit in 1280 pixels of total width or too long to fit in two lines will still not be fully displayed.
[DC] Since v3.5 Beta 1, W:A correctly recognized and hid IRC operator status (instead of incorrectly interpreting the nickname as beginning with the "@" character), but did not do so for other IRC user modes (voice, half-op, admin, and owner). This was not a problem on the official WormNET server, but could have been on third-party servers.
[DC] Once the IRC error "Nickname is already in use" popped up once, it was ignored subsequent times within the same instance of W:A.
[DC] Bug introduced in v3.6.26.4: When connected to a host who was using a version earlier than v3.5 Beta 3pre4, the game start command was ignored (when the remote host clicked Start, nothing happened locally).
[DC] Bug in a feature introduced in v3.6.19.7: When a player in an online game, who has at least one team that has not surrendered, disconnects after the last turn has finished, but before the "game over" sequence has finished, then the message GAME_NET_FAIL ("<team> - forced out due to network failure!") was displayed during the live game, but not during playback of the replay file. It is now shown in both circumstances.
[DC] When a team name or worm name began with the "!" character, game comments (such as those shown when a worm drowns – GAME_WATER_DEATH_COMMENTS, or when a team receives reinforcements when a weapon's delay expires – GAME_REINFORCEMENTS_COMMENTS) could potentially begin with "!", and that would be interpreted by the game as a command to show the comment immediately instead of queuing it (also resulting in the "!" prefix being trimmed away). This bug was fixed in v3.7.0.0, but the fix was done without realising that the bug had existed, and as a result emulation of the bug was not implemented. So, when an older version was emulated, if the bug occurred it could potentially result in desynchronisation. The bug is now fully emulated (except for the trimming of the "!" prefix).
[DC] W:A would crash if an in-game ambient music track failed to play.
[DC] The v3.7.2.1 fix, "The game would crash if a CPU Worm, while enumerating possible places to which to walk, reached its maximum search depth at a point in its path where it would fall and retain control. (See Footnote 2.)", treated some situations as a crash that would not have crashed. The game is now allowed to continue in most of those situations. It still errs on the side of caution, but less so than with the initial fix.
[DC] Bug in fixes introduced in v3.6.21.1, v3.6.24.1, and v3.6.30.0: When doing Export Log on a Mission replay with WinningCondition=2 (Survive), the mission would falsely be logged as "Mission Successful" if the replay file was truncated, had invalid data, or had one of the types of crashes or endless loops that are emulated by halting playback.
[DC] Bug introduced in v3.6.30.0: When doing playback or Export Log on a replay of an online game created by v3.6.19.15-v3.6.29.24 (i.e., a version that did not record the time between turns) a trio of errors was incorrectly printed following certain types of player disconnections.
[DC] When doing playback / Export Log of an online game replay file created by versions earlier than v3.6.29.24, disconnection of players/teams was in some cases not correctly interpreted. Most notably, in a game with at least three players, the automatic disconnection of other clients caused by the disconnection of the host, as seen by a client, was incorrectly interpreted.
[DC] When doing playback / Export Log of an online game replay file created by v3.6.19.4-13, disconnection messages were completely ignored, instead of printing "unknown user is quitting" as was supposed to happen.
[DC] When doing playback / Export Log of an online game replay file created by v3.6.29.24 or later, in which game logic <v3.6.19 was emulated, playback would cut off right after any player quit, with the message "Invalid file data".
[DC] In the Team Editor, pressing Delete while editing a team or worm name that had spaces in front of it would delete the spaces and move the cursor to match its previous spatial position. Pressing Delete while editing a team or worm name that started with the "[" character would cause the entire name to be erased.

Title: Re: Worms Armageddon v3.8 Released
Post by: Deadcode on July 16, 2020, 07:45 PM

[DC] Under certain conditions, the bug fixed in v3.6.24.1, "A replay file which ended abruptly (due to a crash or Alt+F4 during recording, or a recording still being made), when played back, would continue indefinitely after the point at which the file ended, with the human-controlled worms doing nothing and CPU worms (if any) moving like normal" would still occur. This was quite rare, but completely deterministic; if it happened when playing back a particular replay file, it would always happen with that file.
[DC] The background debris in the front end had a 80 pixel empty area on the bottom upon being initialised. This was a very minor flaw; the gap would quickly be filled as the debris moved from its initial position.
[DC] Bug in a feature introduced in v3.6.30.0: When doing playback or Export Log on a replay of an online game created by a version that recorded the time between turns, events following Round Finish (such as player chat, and auto-acknowledgement of round finish) all were shown with the same timestamp, even though the replay had enough information to show the actual timestamps at which the events happened. (Essentially, during Export Log, the game timer stood still following Round Finish.)
[DC] Bug in a feature introduced in v3.6.28.0: When attempting to load a land*.dat file in the Map Editor that had an incorrect file format, the file would fail to load (correctly) but some memory would be leaked, corresponding directly to the size of the land*.dat file.
[DC] Bug in a feature introduced in v3.7.0.0: Every time a game round was ended (including live games, playback, and Export Log), W:A leaked approximately 15 KB of memory (to be precise, 2 bytes of memory for every string in the language file being used).
[DC] If a player in an online game pressed Delete to change the Info level while the player with the current turn was idle (i.e., not moving in any way except using the mouse to aim a weapon) for 10 seconds, causing Hello.wav or ComeOnThen.wav to be played, and then that current player did not move (except for moving the mouse) for the rest of their turn, it would cause a desynchronisation the next time a weapon was used (or any other checksum-triggering event occurred). This was due to the cycling of the Info level cancelling Hello/ComeOnThen from being played only for the person who pressed Delete, and not for other players. If all players happened to have changed their Info level during the same period, it would not result in a desynchronisation, but would still result in checksum errors upon playback of the replay (unless the user pressed Delete during the same time period in playback) and upon Export Log.
[DC] Bug introduced in v3.6.30.0 and v3.6.31.0: In playback / Export Log, it was possible in certain circumstances for "Checksum Missing in Frame 0" to be shown followed by "Checksum Spurious in Frame 0 / 0". This would happen on an offline replay in which PageDown was held while the game started in order to "chat" (enter a replay annotation) at the very beginning, and would also happen under certain circumstances if a remote player disconnected while the local player's game was still loading.
[DC] Bug introduced in v3.7.0.0: When using a BattyRope (not TestStuff) logic version in the range BattyRope5-9, the BattyRope version was decremented, resulting in BattyRope4-8. This could result in a desynchronisation in any online game with a mixture of players having <v3.7.0.0 and >=v3.7.0.0, or when doing playback / Export Log on a replay file created by a version earlier than v3.7.0.0. It also resulted in the latest BattyRope fix, "With BattyRope enabled, if a worm was still on the Bungee upon winning the game, its bungee would be detached (to do the victory dance); as a result it would fall down and possibly lose the game instead of winning" only being enabled in TestStuff9, not in BattyRope9.
[DC] Bug in a feature introduced in v3.6.19.7: It was possible for a custom .WAM file (mission/training script) to contain out-of-range integer values for boolean settings (such as PlaceWeapon_OnGround) that would result in desynchronisation when playing back a replay file recorded when playing the corresponding mission/training level.
[DC] It was possible, though quite rare, for uninitialised memory to result in setting a Target in a Training level as "Vital", with a flashing red element distinguishing it as thus. With the introduction of replay file recording in v3.6.19.7, an additional bug resulted in a replay file being created in this situation that would have checksum mismatches when played back later.
[DC] Latent bug in a feature introduced in v3.6.19.7: When playing back a replay file, any situation in which a checksum was generated while a parachuting crate was falling would result in a Checksum Mismatch. Normally this could never happen, due to the v3.5 Beta 1 change that automatically made crates fall fast, but with RubberWorm's crateshower option enabled, it always happened.
[DC] Bug in a feature introduced in v3.6.29.0: When Export Log encountered a fatal error attempting to parse a replay file, the error message written into the .log file had an incorrect character encoding.
[DC] Bug in a feature introduced in v3.6.22.0: If Gfx0.dir or Gfx1.dir was used (which always happens unless they are both deleted), and <v3.6.22.0 was emulated, and a map with >96 non-black colours was played on, then checksums would be incorrectly calculated, in a way incompatible with <v3.6.22.0. An Export Log on the replay would show checksum mismatches, but playback would not. (Note that normally, a >96 colour map could never be played on simultaneously with <v3.6.22.0 emulation, but a third-party mod such as RubberWorm, which has an option to change the logic version, could actually allow this to occur. Otherwise, this would have been a purely latent bug.)
[DC] Bug in a feature introduced in v3.6.30.0: The feature "Export Log will no longer fall into an endless loop when emulating the BattyRope Jet Pack bug." was implemented too aggressively. It would halt the Export Log operation even in situations where an endless loop did not actually occur, due to an explosion hitting the worm on the Jet Pack after it had gone into what would have otherwise been an endless loop.
[DC] Latent bug in a feature introduced in v3.6.23.0: If R was pressed to restart playback at a time which, during live play (as if the game had been played offline), would have been part of a potential instant replay, and a Mine was triggered before the first turn started, a "Checksum Spurious" error would incorrectly be detected. This was a latent bug because normally, it is impossible for a mine to be triggered before the first turn. However, third-party modules such as RubberWorm, which has an option for "black hole" style gravity, could set up a situation in which a mine would fall towards a worm before the first turn started, causing this bug to manifest.
[CS] Bug introduced in v3.7.0.0: Error messages, and possibly other computed strings, were sometimes calculated incorrectly. This bug caused some error messages, e.g. "Graphics initialisation error", to repeat their title in the message box text, instead of providing details about the encountered error.
[CS] Bug in an improvement introduced in v3.7.0.0: Graphics API initialisation error messages simply contained the GRAPHICS_INIT_FAILURE string ("Couldn't initialise graphics") instead of providing more detail as they were supposed to.
[CS] Handling of lost devices in Direct3D 9 has been overhauled. W:A should no longer crash or get stuck on a black screen when devices are lost other than due to minimisation (e.g. switching the Windows desktop/session by pressing Ctrl+Alt+Del or Win+L), or get stuck in a flickering loop on multi-monitor Windows 7 systems.
- Thus, W:A will no longer warn Windows 7 users with multiple monitors when attempting to select a Direct3D 9 renderer.
[DC] If a Worm currently overlapping with terrain used Teleport (to a location not completely obstructed by terrain or other objects, i.e. a location that could be teleported to normally), then a desynchronisation would result. Locally, the worm would be moved to the target one frame earlier than it should be, resulting in a desynchronisation from remote players in an online game, or upon playback / Export Log of the replay file later. In practice, such a situation could only occur in relatively obscure situations. The known ones are:
- In "Weapon use doesn't end turn" mode (see Footnote 7), the worm placed a Girder overlapping with itself (which can only happen when emulating older versions), causing it to fall into the terrain, and then triggered Teleport while inside the terrain.
- In RubberWorm's "black hole" mode, the worm fell into the black hole, making it fall at high speed towards the ocean — straight through all kinds of obstacles including terrain. While inside the terrain, it then triggered Teleport.
[DC] Loading a .LEV or .BIT map into the Map Editor that had been hex-edited to have a Bridges or Objects percentage higher than 100% would crash W:A.
[DC] Bug in a feature introduced in v3.7.0.0: In Export Log, the team colour words in the list of teams at the beginning of the log had their first letter capitalized in such a way that garbled any non-alphabetical characters or characters not in the Windows-1252 character set.
[DC] Bug in a feature introduced in v3.7.0.0: In Export Log, the list of teams aligned spectators improperly when localised to a language other than English, due to using a hard-coded length for the string "Spectator" instead of measuring the length of the LOG_SPECTATOR string.
[DC] In the WormNET screens, the strings NET_GAMENAME, NET_PLAYERNAME, and NET_NEW_CHANNEL, and the name of the current channel, were displayed with the bottom one or two pixels missing (affecting letters like "g" and "y").
[DC] Bug in a feature introduced in v3.6.19.7: The .IMG file support in the Map Editor was hard-coded to assume the images were of the standard size (1920×696). If the total size in pixels was larger than 1336320 (1920×696), it would crash; otherwise it would load the data as if it were 1920×696, which in most cases would garble the map.
[DC] Bug in a feature introduced in v3.6.28.0: It was possible for the targeted weapon mouse cursor to wrap from the right edge to the left edge in super-wide maps.
[CS] Upon returning from the Team Editor to the Options screen after editing a team, the selection in the team list box was reset to the first team, instead of remembering the current team selected.
[DC] Sea bubbles made by sinking objects are randomly created with a size in the range 1-3 or 1-4, depending on the type of object (which has not been changed). However, ambient sea bubbles (created constantly at all times, rising from below the ocean bottom), due to a bug, were only created with a size of 1 or 3, and never 2. Due to the potential distraction of having size 4 sea bubbles appear when they never did before (and also justifiable in that a near-surface disturbance like a sinking object would be more likely to have its large bubbles reach the surface, whereas large bubbles created deep in the sea would likely break up before reaching the surface), this has been fixed by allowing ambient sea bubbles to be created in the size range of 1-3.
[DC] Bug in a feature introduced in v3.7.0.0: W:A would always save its install path into the registry automatically upon being launched, even if "Auto-register associations" was disabled. Now it only does so when either registering associations, or if the path value doesn't exist and needs to be created.
[DC] The Spanish and French translations of the names of some CPU teams and worms in mission campaigns were longer than 16 characters, and were being truncated. These names have been replaced with ones that fit in the allotted space.
[DC] Bug in a feature introduced in v3.6.24.1: When using the Export Video feature, the start time (if set to anything nonzero) would be shown in red above the game time indicator, as if it were a bookmark created by pressing the M key or using the "Playback at..." feature.
[DC] The in-game background debris had a parallax and z-order which disagreed. In z-order it was behind the background layer, but in parallax it was at the same depth as the map. This has been fixed by giving the background debris a parallax that places it farther away than the background layer.
[DC] Under Wine, pressing A in the Main Menu would make the W:A window go black and silence sound. W:A would then have to be closed (e.g. with Alt+F4), as nothing would restore it at that point. The handling of this key has now been removed. (Note, it was meant to be a minimise hotkey, but it never actually worked due to not receiving keyboard focus in anything other than Wine.)
[DC] Bug in features introduced starting at v3.6.19.7: When W:A was launched with command-line parameters from a current working directory other than the main W:A directory, using any non-absolute path in a filename parameter would result in W:A failing to open the correct file, because it would try to access that relative path from the main W:A directory.
[DC] Bug in features introduced in v3.6.26.5 and v3.6.30.0: The Sanitize and Repair context-menu operations (/sanitize and /repair on the command line) crashed when failing to open or create the file, instead of showing an error message.
[DC] Bug in a feature introduced in v3.6.30.0: The pinned chat panel is intended never to be larger than the unpinned chat panel, but it was possible for this to break down. If such a condition arose, with the pinned chat panel larger than the unpinned one, then enlarging the unpinned chat using a single press of Ctrl+Down would cause it to jump in size to be as big as the pinned chat panel. This condition could arise if the unpinned chat panel was decreased to minimum size, and then the game was exited (causing the size of the chat panels to be saved into the registry); then the next time a game session was started, the pinned chat panel would be reset to its default size (or larger), resulting in a pinned chat panel larger than the unpinned one.
[DC] Bug in a feature introduced in v3.6.26.4: The feature introduced in v3.6.19.7, where holding Shift while clicking or right-clicking the terrain texture button in the Map Editor would cycle only between textures that minimally "eat into" the terrain (thus being suitable to BattleRace-type .BIT maps), was not adapted to the new feature where holding Ctrl while clicking the same button would toggle v3.0 style terrain texture thinning. In the v3.0 texture thinning mode, it should have cycled only between Hospital and Manhattan, but cycled between -Beach, Cheese, Hospital, Manhattan, and Pirate, three of which eat into the texture in v3.0 style terrain texture thinning mode.
[DC] During automatic camera motion, the mouse had to be moved at least 16 pixels within a single frame (1/50 second time interval) in order to temporarily unlock the camera (yielding manual camera control via the mouse). However, the formula used for this added the absolute value of the x and y deltas, meaning 45 degree diagonal motion only had to be faster than 11.3 pixels per frame instead of 16. The formula used is now the Pythagorean theorem, meaning the speed threshold is now applied equally in all directions. See also Features (the speed threshold is now a configurable option).
[DC] If two or more players tried to team in with the same team name at the same time, only one would be successfully teamed in, and the other would remain in a "team pending" state, unable to either cancel the team-in or team in with a different name (without first exiting and rejoining).
[DC] In the WormNET channel list screen, double-clicking the empty space or border of the channel list would join the currently highlighted channel.
[DC] Bug introduced in v3.6.23.0: W:A did not work properly with WormNET servers set up to use a custom HTTP port (i.e. one other than port 80). The initial connection to the server would work, but then W:A would send subsequent requests to port 80 instead of the custom port, making it impossible even to join a channel.
[DC] Bug in a feature introduced in v3.6.30.0: If the /afk or /away command was used in-game, and wasn't previously active in the front end, and the user was still Away upon the return to the front end, then the Away state would not be visually indicated in the front end; it would still be in effect, however, and could not be cancelled in the normal way — the only way to cancel it was to either enter the command again and then cancel it, or wait until a new game round was started and cancel it in-game.
[DC] The v3.6.20.1 fix, "It is no longer possible for a host to start the game on your end if you have not lit up on your end to signal readiness. If the host attempts this, your Ready light bulb will flash; click it to go ahead and start." was improperly implemented.
- [DC] It was possible for the game to accidentally start unattended while the light bulb was flashing.
- [DC] If the second round was started with this flashing light bulb behaviour in effect, then a desynchronisation would happen in the third round, in which the client to which the bug happened would locally start the game immediately when the light bulb was clicked, but the host would continue to wait for that client to be ready to start.

Title: Re: Worms Armageddon v3.8 Released
Post by: Deadcode on July 16, 2020, 07:45 PM

[DC] The maximum host address length of a hosted game that W:A is able to connect to has been changed in the past, but longer lengths were never properly handled. In early versions, a length that was too long would cause a crash, or would result in garbage characters being printed. In later versions, hosted games with host addresses too long would simply not be shown in the list. Now, these games are shown in the list, but an attempt to join them will show the message "Can't connect. Host Address too long." Also, the maximum host address length of a hosted game that W:A is able to connect to has been changed from 39 to 49 characters.
[DC] Bugs introduced in v3.6.19.7 and v3.7.0.0: Holding the Space Bar resulted in strange behaviour in the front end. If a button or checkbox had the current keyboard focus, then moving the mouse while holding Space highlighted the button, leaving it highlighted until Space was released. In versions earlier than v3.7.0.0, the bug still existed, but in a reduced form; the button or checkbox would only become highlighted when the mouse passed over the button while Space was being held, but would then remain highlighted until Space was released, regardless of where the mouse was subsequently moved. Now, the Space Bar acts more like it does on standard Windows buttons; holding it down presses the currently focused button/checkbox, and releasing it triggers that button/checkbox. Pressing any key other than Space while still holding it down cancels the press; Space can then be released without triggering the button/checkbox.
[DC] When launching certain replay files, a NONSTANDARD_POWER_LEVELS dialog box would pop up underneath the SHELL_LOADING box, requiring the dialog box to be dismissed before launching would continue.
[DC] Bug in a feature introduced in v3.7.0.0: The Direct3D 9 renderers did not work properly under Wine.
[DC] Bug in a feature introduced in v3.6.23.0: The in-game dialog box (ESC) and chat (PageDown/PageUp) transitions were supposed to occur at a framerate-independent speed, but instead increased in speed as the frame rate increased.
[DC] Bug in a feature introduced in v3.5 Beta 1: When running W:A under Vista or later with UAC enabled, after minimising in-game, the game could not be restored by clicking its taskbar button. The only way to restore it was to open its system menu (in Vista or earlier, by right-clicking its taskbar button; in Windows 7 or later, by Shift+right-clicking its taskbar button, or right-clicking its taskbar thumbnail) and click Restore or Maximize — and this method only worked in W:A v3.6.30.0 and later, since earlier versions did not support opening the system menu.
[DC] When using 8-bit DirectDraw under Windows 8.x/10, restoring after minimising in-game resulted in severe graphical glitching. It was previously necessary to use a Windows Application Compatibility setting (Layer_ForceDirectDrawEmulation) to avoid this bug, but that is no longer necessary.
[DC] When using DirectDraw or Direct3D 7 under Windows 8.x/10:
- [DC] Restoring after minimising in the front end resulted in a white screen. Even using the Layer_ForceDirectDrawEmulation compatibility setting was only a partial workaround for this problem, making it disappear after a few seconds or less but not necessarily preventing it from appearing in the first place.
- [DC] With "Wait for vertical sync" enabled, the frame rate was very poor.
[DC] Bug introduced in v3.6.30.0: Under Windows Vista and Windows 7, in any front end screen that had its default focus on an edit box, after giving the focus to a different control (e.g. by pressing Tab or by clicking on the other control), minimising, and then restoring by clicking the taskbar button, the input focus would be strangely divided. The default edit box would receive input, but without showing any caret, text selection, or highlighting — and the control that had focus before minimising would be highlighted.
[DC] Bug in a feature introduced in v3.5 Beta 1: Under Windows Vista and Windows 7, W:A did not appear in the Alt+Tab list when minimised, except when launched from a replay file.
[DC] The "Close" menu option in the Windows 7+ taskbar button context menu (as opposed to the system menu) did not have the desired effect. It would either do nothing, or in some circumstances in v3.7.0.0 and later when in-game, would restore the game from a minimised state.
[DC] The buttons in the Scheme Options editor's "cheat" menu were not highlighted on mouseover.
[DC] The front end had quite a bit of latency in its response to input. It is now much faster.
[DC] Bug introduced in v3.7.0.0: The front end's background gradient was rendered 20 times per frame, negatively impacting the overall frame rate (depending on other factors; having vertical sync enabled, for example, could hide this problem).
[DC] Map Editor keyboard repeat bugs (applies to features introduced in v3.5 Beta 1)
- [DC] Holding down the Alt key to improve drawing precision could result in jerky mouse motion due to the hardware keyboard repeat of the Alt key.
- [DC] Holding down the Ctrl key to constrain drawing motion into one axis could result in jerky mouse motion due to the hardware keyboard repeat of the Ctrl key.
[DC] The Constrain function in the Map Editor (used by holding the Ctrl key while drawing) was biased towards horizontal motion — any perfectly diagonal motion would be constrained into the horizontal axis. The constraint direction resulting from perfect diagonal motion is now chosen randomly.
[DC] Bugs in features introduced in v3.6.19.7 and v3.7.0.0: Closing a drop-down list by clicking an item in it or pressing the ESC key did not restore input focus to the listbox control (unless that control had default focus in its parent dialog, because the bug was that focus was changed to the default control of the parent dialog). Note that this bug was present only in drop-down listboxes, not combo boxes.
[DC] Bug in a feature introduced in v3.6.30.0: Opening a combo box by pressing Up/Down/PageUp/PageDown copied the name of the first item into the combo box's edit box. This happened even if the first item was a directory name (with surrounding angle brackets).
[DC] Ctrl+Break is meant to be a synonym for ESC in Windows dialog boxes, but did not work in all dialogs/screens of the W:A front end. Now it acts exactly like ESC.
[DC] Bug in a feature introduced in v3.7.0.0: It was possible on some systems for the Direct3D 7 renderer to get a lower-resolution surface than requested, for example getting a 1024×1024 surface when it requested a 1280×960 one. When this happened, it would show only the leftmost and/or topmost portion of the game viewport, filling the rest with black. Now it will fall back to a lower resolution if this happens.
[DC] Bug introduced in v3.6.23.0: The amount of time the phone icon stayed on-screen before sliding away depended on the rendered frame rate, not the passage of real time. For example, on a 60 Hz monitor it disappeared a little bit too soon (showing for only 83% of the time it should), and on a 120 Hz monitor it disappeared far too soon (showing for only 42% of the time it should). With vertical sync disabled it disappeared even faster.
[DC] Bug in a feature introduced in v3.7.0.0: Hardware mouse cursors did not work under Windows 98/Me.
[DC] Bug in a feature introduced in v3.7.0.0: When hardware cursors had been active and then disabled in the same instance of WA.exe, every time the front end cursor state changed it was possible for a crash to happen. In practice, the crash is only known to have happened under Windows 98.
[DC] Bug in a feature introduced in v3.5 Beta 1: If W:A was minimised while a game was being started (while the dialog box "Please wait... working..." was shown) it would enter a buggy state. In v3.6.31.2b and later, it might be playable for a while, but would eventually enter an unplayable state or crash. In earlier versions it would instantly enter an unplayable state. Either way, it would eventually either crash or require the "WA.exe" process to be killed externally.
[DC] Bug introduced in v3.6.28.0: After mousing over a control in the Network Choice screen (causing help text to appear), and out into empty space (which makes the help text disappear), mousing back over the previous control didn't show the help text. Only mousing over a different control than the last one caused help text to appear again.
[DC] Bug in a feature introduced in v3.5 Beta 1: If the WormNET screen changed modes while minimised, in most cases it would be visually garbled when restored. This could happen when one initiated connecting to WormNET, joining a channel, or parting from a channel, and then immediately minimised before the action was finished.
[DC] Bug in a feature introduced in v3.5 Beta 1: If W:A was minimised during the process of connecting to an online game, then it would crash upon being restored.
[DC] Bug in a feature introduced in v3.7.0.0: The automatic resizing of message boxes and confirmation boxes could potentially go into an infinite loop if the title text was very long, which could happen if a dialog box title string was edited in the language file. If the title text was just moderately long (and not long enough to trigger the infinite loop), it would cause the dialog box to expand vertically as well as horizontally, resulting in lots of empty vertical space in most cases.
[DC] Latent bugs exposed by a feature in v3.7.0.0: When using Direct3D renderers, after W:A lost and regained focus (by minimising and restoring), certain graphical glitches would manifest until exiting from the current front end screen. (The fix to these glitches has been applied to all front end controls, so even ones that had a similar but unreported glitch will now be fixed.)
- [DC] In any front end screen with message history controls, giving focus to one of the message history controls (or taking focus from it) would cause a horizontal dotted line to flash near its top.
- [DC] Resizing the player list (in the Host lobby) would cause it to flash solid white.
[DC] Latent bug exposed by a feature in v3.7.0.0: When using Direct3D renderers, upon opening any confirmation dialog box or Deathmatch win/loss dialog box, the two text regions would flash a 3D rectangular border. When entering the Mission screen, Host/Join screen, or offline or online next-round screen, the map thumbnail would flash a 3D rectangular border. (The fix to these glitches has been applied to all front end controls, so even ones that had a similar but unreported glitch will now be fixed.)
[DC] Under Windows 2000/XP, occasionally some buttons/images in the front end would load as black 13×13 squares. It was also possible for the background debris to occasionally load as transparent emptiness, making it invisible. Both of these bugs would usually disappear upon minimising and restoring the game (although either of them could also appear after doing so).
[DC] Bug introduced in v3.6.28.0: Compatibility with Windows 95 was broken and has now been restored.
[DC] When using 8-bit DirectDraw with hardware rendering under VMware on Windows NT-based guests, certain front end controls had a skew/slant glitch in their fonts.
[DC] In Windows Vista or later, with DPI set to higher than 100%, and either "Use Windows XP style DPI scaling" enabled, or "Disable display scaling on high DPI settings" enabled in the Compatibility settings for W:A's EXE/shortcut, the Map Editor's Import dialog box would be created without a visible scrollbar, leaving empty blackness in place of where the scrollbar should be.
[DC] Bug in a feature introduced in v3.5 Beta 1: When minimising in-game, if any keys were held down at the moment of minimisation, the game would continue to act as if the keys were held down, until being restored (at which point, the fix in v3.7.2.1 would come into play, and refresh the game's keyboard state from the state of the actual keyboard). This would only have an actual effect during an online game, because minimising an offline game automatically pauses it.
[DC] Bug in a feature introduced in v3.5 Beta 1: If W:A was minimised while the mouse was on a list header (e.g. "Team Name" or "Points" in the Multiplayer screen's team list), then upon restoring, the header would still be highlighted in white, and the only way to cancel the highlighting would be to move the mouse over an empty header, if any empty region existed. Similarly, if the left mouse button was pressed and held on a list header, and W:A was minimised while still holding the mouse button, then upon restoring, the header would still be highlighted in yellow, and the only way to cancel the highlighting would be to click on a header.
[DC] Bug introduced in v3.7.0.0: The landscape mini-thumbnails in the Map Editor would highlight upon mouseover of their clickable rectangle, but then unhighlight only upon exiting a rectangle that was 2 pixels larger in every direction. (This is similar to a bug that was fixed in v3.6.28.0, in which the mini-thumbnails were highlighted and unhighlighted upon entering and exiting a rectangle 2 pixels smaller in every direction than the clickable rectangle.)
[DC] Bug introduced in v3.7.0.0: When the Map Editor's file combo box was open, after mousing over and highlighting the landscape mini-thumbnail on the right that it partially covered, the mouse could then be moved onto the combo box's scrollbar without unhighlighting the mini-thumbnail.
[DC] Mouse-over help text in the Map Editor, LAN Lobby, Network Options screen, and WormNET were glitchy and less responsive than the help text in the rest of the W:A front end. The help text in these screens is now just as instant as that in the rest of W:A and follows the same rules.
[DC] After the mouse cursor changed to a hand upon mousing over a hypertext link, it would not always switch properly back to the default arrow cursor. This would happen when single-clicking on the link and moving it out of the hypertext window fast enough, when "dragging" the link out of the hypertext window, or when minimising and restoring, if the cursor was outside the hypertext window upon restoring.
[DC] Bug introduced in v3.6.30.0: The Direct IP hosting dialog box refused to accept a game name if it was exactly 1 character long.
[DC] Bug introduced in v3.5 Beta 1: Certain actions in the front end resulted in temporary mouse capture (see below for list of actions that did this). While in this state, right-clicks would be ignored. A left-click would be ignored, but would cancel the mouse capture (so that subsequent clicks would work). Also, moving the mouse at least one pixel in any direction would cancel the mouse capture.
- Double-clicking a nickname in the list of nicknames on WormNET, to /msg them.
- In the Host/Join/Next Round lobby, right-clicking a nickname in the list of players, to /msg them.
- Using line memory, by pressing Up / Down / PageUp / PageDown in any edit box supporting it.
[DC] Bug in a feature introduced in v3.6.28.0: If a chat message was received while the pinned chat was visible (i.e., if Ctrl+PageDown and PageUp had been pressed), then if the pinned chat was dismissed soon enough (by pressing Ctrl+PageUp), the phone icon would be visible, even though it shouldn't be after a chat message has been visibly shown on-screen.
[DC] Upon leaving a WormNET channel, the PART command was followed by too many LIST and WHO commands (only one of each is necessary). This may have somewhat slowed down the process of leaving a channel.
[DC] The IRC message 333 (which always follows 332, indicating the topic of a joined channel) was incorrectly being shown as green text.
[DC] The IRC welcome message (001) was not being displayed as green text, when it should have been.
[DC] Bug in a feature introduced in v3.6.28.0: The host/join chat log of the current session, stored in User\Logs, was not properly closed in all circumstances under which an online game session could be ended. This prevented the log file from being deleted, renamed, or moved, until exiting W:A.
- [DC] When quitting from the Next Round screen as a host
- [DC] When losing connection to the host while in-game, as a client
- [DC] Bug in a feature introduced in v3.6.30.0: When quitting W:A while in an online game by clicking Close in its taskbar button's system menu. The file was closed immediately anyway, but LOG_SESSION_ENDED was not entered into the log.
[DC] Bug in features introduced starting in v3.6.19.7: When starting WA.exe with either "Auto-register associations" enabled or the /register parameter, if a relative path was specified for WA.exe, or a path containing forward slashes instead of backslashes, the associations would be incorrectly registered.
[DC] UDP ports 17010 and 17012 are used for the LAN mode protocol, but W:A initialised them even when entering WormNET mode, and broadcast on UDP port 17012 when hosting WormNET games. W:A no longer uses these ports in WormNET mode.
[DC] Bug in a feature introduced in v3.5 Beta 1: When scrolling a message history box with text selected inside it, if the selected text reached the top or bottom edge, the solid white selection rectangle would be drawn outside its proper bounds. Starting in v3.7.0.0, this bug was made worse, leaving a permanent trail 1 pixel thick on the top and/or bottom edge.

Title: Re: Worms Armageddon v3.8 Released
Post by: Deadcode on July 16, 2020, 07:45 PM

[DC] Bug introduced in v3.5 Beta 1: Upon using the /away command in WormNET (IRC) with no parameters to clear your away message, NET_AWAY_CLEARED was not printed (nor was any other feedback).
[DC] If the network packet for "Play Again" or "New Match" was immediately followed by subsequent packet(s) changing the scheme, number of worms, or alliance colours, then those subsequent packets would be ignored, leading to a desynchronisation when the new match was started. (This could theoretically could happen in situations of extreme network congestion, when the host very quickly made those changes after clicking "Play Again" or confirming "New Match".)
[DC] Bug in a feature introduced in v3.6.19.7: In the combo box for browsing scheme/map subfolders and files, clicking on a folder which could not be entered (due to access rights restrictions or illegal filename characters) collapsed the combo box, preventing it from being restored until exiting the current screen.
[CS] Bug introduced in v3.7.0.0: Internet URLs starting with www. (no protocol) were recognized (underlined and double-clickable), however double-clicking them displayed an Invalid URL error message.
[DC] After an instant replay occurred, the default girder rotation state and strike direction would be reset for all teams. Any team that subsequently selected Girder or Girder Starter-Pack would have "stop-sign" as the default state, and any team that selected a Strike weapon would have "right" as the default direction. In v3.5 Beta 1 and later, this resulted in not being able to fire a Strike weapon on the same turn after an instant replay in which the turn didn't end, unless a Girder was selected first and rotated to a position other than the stop-sign.
[DC] Bug in a feature introduced in v3.6.29.0: With stereo effects enabled, upon worm placement, the YesSir sound was always played from the centre of the map instead of the current cursor position.
[DC] In the game lobby for a joined player, if the host disconnected at a point when the user had entered text into the chat edit box, then pressing Enter would behave as if the edit box had not been hidden.
[DC] When applying the "built-in game time limit" logic as it existed before being removed (see v3.6.30.0 changes affecting game logic), if the total turn time (not counting retreat) fell between 2.00 and 4.98 seconds inclusive, or the total game time (up to the end of the fade-out) fell between 2.00 and 14.98 seconds inclusive, the following bugs could or would happen:
- [DC] The offline multiplayer next-round screen didn't properly indicate that a draw had happened.
- [DC] The end-of-round report in the online and offline next-round screens didn't properly indicate that a draw had happened.
- [DC] In a match with six teams, a portion of the sixth team's flag or grave palette was interpreted as non-palette data, and could either force a named team's allied group to get a point as if it won the round (even reaching or exceeding the number of points needed to win without ending the match), or force the match to end.
[DC] Bug in a feature introduced in v3.7.0.0: In the online hosting next-round screen, if the last remote player left the game, the "ready to start" sound would be played instead of the "twang" sound, due to the feature allowing an offline game to be started from the online hosting screens without using the light bulb button. The "ready to start" sound would also play upon entering the screen if there were already no clients (i.e. when continuing to the next round of an offline game started from the Host screen).
[DC] Under Windows Vista / 7, if Windows 95 or 98 compatibility was (unnecessarily) enabled in the WA.exe file's properties, a crash would occur when opening the Team Editor.
[DC] In the Team Editor, all soundbanks (voice banks) with a "." anywhere in their name, or a name one character in length, would be excluded from the list of choosable soundbanks.
[DC] Bug introduced in v3.6.19.17: In the Team Editor, fanfares with filenames longer than 32 characters should have been excluded from the list of choosable fanfares, but were not. Choosing a fanfare with a filename too long could corrupt one's team file.
[DC] Bug in a feature introduced in v3.6.28.0: Ever since wa:// and wa:host links were introduced, it was possible to start W:A by following the link wa: (with nothing following the colon), but the warning message box “Ignoring unrecognised command-line parameter ("wa:")” was displayed. This message box is no longer displayed, as long as nothing unrecognized follows the colon.
[DC] Bug in a feature introduced in v3.6.28.0: Links of the form wa:host?Parameters would also work with a ":" or "/" character replacing the "?", however, any other character in that position would be silently accepted, but with the remaining characters following it being ignored (instead of being treated as parameters for the hosted game).
[DC] Bug in a feature introduced in v3.6.29.0: The /quiet (or /q) command-line option would be ignored in the case that Export Log failed to create a log file, showing the error in a message box regardless.
[DC] Bug introduced in v3.6.31.2b: When prompted (with LARGE_MAP_WARNING_DIALOG or IDS_LARGE_MAP_WARNING) as to whether to load a large map, the displayed in-game memory usage was too small by a large margin. This memory usage is dependent on whether hardware or software rendering is being used; more memory is used in the latter configuration.
[DC] Bug introduced in v3.6.28.0 and v3.6.30.0: The peak usage was actually different in the two respective situations in which the LARGE_MAP_WARNING_DIALOG and IDS_LARGE_MAP_WARNING large map prompts are shown, but the same value was displayed in both prompts. In IDS_LARGE_MAP_WARNING, the peak memory usage was too large by a significant margin. The value was close to being correct for LARGE_MAP_WARNING_DIALOG, but was slightly too small. [Note: This fix is now obsolete; the peak memory usage is now the same as the base memory usage.]
[DC] When loading a .PNG map to display a thumbnail in the front end, an unnecessarily large amount of memory was temporarily allocated.
[DC] The Map Editor's detail slider did not respond properly to PageDown and PageUp keypress events.
- The left and right sliders were allowed to go one step beyond their minimum and maximum, respectively.
- Any change made using only PageDown or PageUp would result in a visual change to the slider control, and update the tooltip, but the actual detail range used in generating maps was not updated, and the change would be forgotten upon exiting the Map Editor.
[DC] The exclamation mark icon in the upper-left of front end message boxes (such as the Alt+F4 quit confirmation box in full-screen mode) had its palette distorted in a different way in almost every front end screen.
[DC] Bug in a feature introduced in v3.6.19.7: If the current Scheme or Map subfolder was deleted from outside of W:A, and then an attempt was made to open the File Chooser combo box using the Down arrow key, W:A would crash. (This version of the bug was introduced in v3.6.29.0, but in earlier versions, the crash could still be triggered by attempting to enter a subfolder that had been deleted from outside of W:A, after W:A had listed its contents.)
[DC] Bug introduced in v3.6.30.0: If W:A was minimized in the Scheme Options editor with the "Cheats" dialog box open, upon restoring, the four buttons in the "Cheats" dialog would be replaced by blackness, until redrawing was triggered by mouseover or the dialog box was closed.
[DC] Clicking or right-clicking on the Map Editor's Preview button did not update the tooltip; it was only updated if the mouse was subsequently moved.
[DC] After beating the final mission, the Mission screen would enter a glitchy state, in which whenever the final mission was selected as the current one, the "Next" button would be enabled; if clicked, it would wrap around to the first mission ("Pumpkin Problems"). This was an asymmetrical state of affairs; the first mission did not have the "Previous" button enabled. This state was only temporary, lasting as long as your team was entered in as the current team in the Mission screen; any action that removed it as the current selected team would result in any subsequent re-entry of that team, or any other, leading to the normal, non-glitchy state (until the last mission was again beaten). This bug has been fixed by preventing the "Next" button from ever being enabled on the last mission (as opposed to enabling wraparound in both directions).
[DC] Bug introduced in v3.6.30.0: Under certain conditions, the dynamically dithered background gradient (in maps with more than 96 colours or of non-standard height) would have pixels of clashing colour dithered into its bottom-most region. This bug also resulted in the bottom of the non-dithered gradient displaying incorrectly.
[DC] Bug introduced in v3.6.28.0: When hosting a game with a colour map, clients running W:A v3.6.24.2 or earlier would not be sent the map in a properly backwards-compatible way. The message "Please wait while the level file loads" would be displayed on their end, and the game would desynchronise when started.
[DC] Bug introduced in v3.6.30.0: The field "SpecialBuild" in WA.EXE's version-information resource (displayed as "Special Build Description" in File Properties under Windows XP and below) was corrupt. In v3.7.0.0 and later, this bug was only seen in the Steam builds.
[CS] Fixed a crash that could occur during start-up if the installed bitmap font files were from an older version of W:A.
[DC] The "worm selection order", "worm placement mode", "number of oil drums / mines", "stockpiling mode", "sudden death mode", and "anchored worms" buttons made two simultaneous sounds when changed with a mouse click. In the Scheme Options screen, this had always happened; in the Offline Multiplayer and Network Hosting screens, it was introduced in v3.6.19.7.
[DC] If the proxy settings were changed in the Network Configuration screen, W:A needed to be restarted for the change to properly take effect.
[DC] Bug in a feature introduced in v3.6.19.7: During playback, when a CPU team collected a crate, the weapon-collection notice (i.e., the text showing the contents of the crate) was not shown at the top of the screen.
[DC] Bug in a feature introduced in v3.5 Beta 1: When exiting certain front end screens, there would be a short flash of incorrect palette. Some versions of this bug had already been fixed in past versions of W:A, but this fix should be universal.
[CS] While loading the team file (WG.WGT), when encountering a flag for which the custom flag image file was no longer present, the game would reset it by assigning a locale-dependent default flag. Since all relevant flag information is already stored in the team file, this behaviour has been disabled.
[CS,DC] Bug introduced in v3.6.28.0: When loading a PNG image lacking W:A-specific map metadata into the Map Editor, it was always treated as an island map, instead of autodetecting island or cavern status from the contents of the map. The previous autodetection logic has been restored.
[DC] During instant replays, the X marker for homing weapons and strikes was not shown.
[DC] When a mouse-targeted weapon was clicked such as not to cause instant firing (i.e. any homing weapon, or Girder/Teleport clicked while the worm is jumping/falling/landing), the mouse cursor was hidden locally (from the perspective of the player using it) but not remotely (by other players in a network game) or in playback. This has been fixed; now, remotely and in playback, the cursor will be seen to disappear, under the same conditions that it disappears locally, regardless of game logic version.
[DC] In the Map Editor, switching to a new map in one of the map thumbnails, right-clicking that thumbnail while not in Preview mode, then entering Preview mode, and right-clicking that map thumbnail again, would result in switching to a different random seed on the same map, resulting in objects, bridges, and placement holes (if any) being generated differently.
[DC] Bug in a feature introduced in v3.6.30.0: If the host in an online game committed changes to the Weapons scheme options while a client was in the Weapons screen, and then that client pressed Escape and chose the "Yes" option to exit and discard changes, this would result in a desynchronised state, potentially resulting in a desynchronisation upon game start.
[DC] Bug in a feature introduced in v3.6.19.7: Replay file playback would desynchronise in online games if the Indian Nuclear Test delay was set to 99 in the scheme, unless the Indestructible Border was enabled. This is because during the live game, the delay was overridden to 0, but in playback it remained at 99.
[DC] Bug in a feature introduced in v3.6.29.0: No logic version restriction was enforced when setting the "number victories to win the match" scheme option to zero (in which a match lasts exactly one round even in the event of a draw). Thus, if hosting with that scheme option enabled, and a mixture of players were present, some using versions prior to the introduction of the feature and some after, desynchronisation would result if the round ended in a draw.
[DC] Pressing Enter in any front end screen with a chat text-entry edit box (i.e., the WormNET lobby, LAN lobby, or Host/Join/Next Round/End of Match lobby) entered what was currently typed in the edit box regardless of whether the edit box had the current input focus.
[DC] Bug introduced in v3.7.0.0: If there was more than one player's name in the list following the message "ERROR: Cannot start game due to features unsupported by", then there would be no space between the word "and" and the last player's name.
[DC] Bug in a feature introduced in v3.6.19.7: Chat history carried over from the host/join or end-of-match screen to the Next Round screen was cut off on the right side, due to the chat history box being narrower in that screen. This has been fixed by rearranging the online countinued-round screen so that its chat history box is the same width as that of the host/join and end-of-match screens.
[DC] The online Next Round screen listed "players" (actually individual computers in a network game) rather than teams. If two or more people were playing on one computer, and had differently-coloured (differently-allied) teams, only one of those team colours and number of wins would be displayed in the countined-round screen. This has been fixed by splitting the player list into a player list and a team list, like the host/join screen.
[DC] In any front end screen, if the mouse cursor was moved from a control with help text to an edit box or text box / message history box (by moving the mouse fast enough that it would skip over the empty space between the controls), the displayed help text would not be erased.
[DC] Flaw introduced in v3.6.19.7: The help text for the player name edit box in the Network Choice screen was not displayed.
[DC] In the "View team statistics" screen, the Deathmatch rank was misaligned with the text "Deathmatch Rank", and if it occupied two lines (for example with "Highly distinguished"), the bottom 3 pixels of the second line were truncated.
[DC] In the offline end-of-match screen, there was no help text for the Winner box.
[DC] Bug introduced in v3.6.28.0: Attempting to use the Export Log feature without the W:A CD-ROM present resulted in the creation of an empty log file.
[DC] Bug in a feature introduced in v3.5 Beta 1: After minimising in-game, if any mouse button(s) were held down at the moment of minimisation, then after being restored, the game would continue to act as if the mouse button(s) were held down, until either the mouse was moved, or those button(s) were pressed and released (i.e., if the mouse was not first moved, the first press of each of those button(s) would be ignored). One of the effects of this was that from v3.6.19.18 onward, if the ESC dialog box's "Minimize Game" menu option was used, and after restoring the game, an attempt was made to click "Minimize Game" again without first moving the mouse, the first click would be ignored.
[DC] Bug in a feature introduced in v3.6.30.0: An "Exit without saving changes?" dialog box was shown when exiting the Options menu after editing the current scheme. Before v3.6.30.0, the current scheme was always reset to the Intermediate intrinsic scheme upon return to the main menu, so the exit from the Options menu really was done without saving changes to the scheme. However, from v3.6.30.0, this same "Exit without saving changes?" dialog no longer did what it claimed to do; when exiting the Options menu by responding "Yes" to this dialog, the scheme changes were in fact saved. This has been fixed by disabling the confirmation dialog completely, and, as was already done before, always saving changes when exiting the Options menu.
[DC] Flaw introduced in 3.6.19.7: Under Wine, moving the mouse away from a front end button that was highlighted by mouseover, to empty space (or anything other than a highlighted control), would only unhighlight the previously highlighted button after a significant delay. This was due to Wine's laggy implementation of WM_MOUSELEAVE via the Windows API call TrackMouseEvent(). Due to this, W:A now uses its own emulation of TrackMouseEvent when under Wine (as it also does under Windows 95, because _TrackMouseEvent() exhibits the same problem).