• [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).

• [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.

• [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.
    

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

Highlights of v3.8

CD-ROM Edition: Download Here
Steam Edition: Update automatically through Steam.
GOG Edition: Please read this to avoid losing your team data.

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.

Wow, great job ScaredEwo.

I thought I wouldn't be able to get 9pts again let alone beat it, but finally managed to at least get it again. This time it doesn't depend on the answer to "does hitting the platforms above the box count?".

What counts as hitting a numbered box with a supersheep? Does the sheep's collision mask have to touch the box (in which case, does hitting the platforms above the box count?), or just the sheep's explosion radius?

As for the scoring, since it's not specified in any way, I'm going to assume for now that it's 50 minus the number of sheep used. I wonder if this is the method ScaredEwo used to self-score with 10pts.

Edit: Apparently lower scores rank higher in this, so I'm guessing the score is the number of Super Sheep used. That's what I entered for my score (17 sheep used, 33 remaining).

Also, why are the replays hidden in this challenge? I downloaded ScaredEwo's replay after I got 17pts, because I wanted to know if they too submitted a score equal to the number of sheep used, and it turns out they did (how they knew this, I have no idea) which is a friggin' amazing score given that the minimum score is 7pts, so congratulations ScaredEwo! I didn't watch the replay (in case there's a legitimate reason replays were hidden), only looked at the Export Log output.

Quote from: cuck on January 03, 2019, 03:35 PM
Hello,

First, I think it's great that you're making things for W:A.
But I'm afraid that many members of the community are somewhat disappointed by the changeset featured in the 3.8 update. Even though fixing bugs is important from developer's standpoint, it is not necessarily the best course of action to maintain a healthy community. From my understanding, the sole thing that people anticipated from this update was a set of new and meaningful gameplay features.

From the quick glance of the changeset, most of the changes were directed towards fixing obvious bugs with windows 10 compatibility (yay!) and resolving glitches that were low level and so obscure, that we didn't know they even existed (yay... maybe?). Don't get me wrong, some technical features (ASLR) and fixes were truly necessary, but I bet that most players can live through a sea bubble skipping an animation frame.

The thing that I cannot comprehend at the moment, is why do have to stick with absolutely perfect backwards compatibility across multiple WA versions. Most folks on WormNet stick with 3.7.2.1 (because it's newest* and greatest at the moment), 3.6.31.0 (because of ProjectX) or 3.7.2.2 (because they don't know any better and just use what steam installed by default). Yet, there has been substantial amount of work put into bringing back WA 1.0 to play nicely with 3.8. Too bad, that WA 1.0 is unobtainable at the moment, so the only somewhat viable way of playing 1.0 in the year 2019, was if someone's grandma found an ancient CD and wanted to relive the good ol' days of The Berlin Wall falling down. More of the time could be spent on more meaningful changes if we just decided to drop the compatibility support and print a nice prompt to update the game when somebody joined the party with their 1920 Ford model T. Btw, even if the core game can synchronize with 1.0, the Napoleonic Wars veteran will still be kicked out/desynchronized because he lacks the rubberworm or other modules.

The power of WA is it's great community, that has already proven numerous times that it *can* and *will* bring many new exciting features through the Wormkit. Even better, we are backed by two truly skilled developers with access to the game's source code, so some technical and otherwise unfeasible changes can be done at the source code level. But I'm afraid this update missed the chance to revitalize the game. Of course, nobody expected a full ProjectX reimplementation, but at least a cornerstone of a true Wormkit system could be laid. We all know, that in its current state wormkit is a fancy name for LoadLibraryA wrapper and module developers are left to figure out everything by themselves. As result, every wormkit module implements important stuff in a chaotic way that often does not play out nice with other modules or game features. Of course, now* rubberworm is a part of the core game, so it is bound to behave nicely, but all other modules need to be redone or patched anyway with the same nonexistent API.

The limitation of WA's feature development is the lack of public information (developers need to reverse engineer everything by themselves), lack of true integration between modules and the game, and the way the game's memory structures are laid out and referenced. Most of the game code and structures are easy to find and understand in a single evening's time with a 6 pack of beer. So for example, replacing bazooka's physics and behavior is relatively easy, but extending the weapon roster with that modified bazooka is a hell of a task. Why? Because there is no room. Hacking the game to think that the weapon roster contains 128 entries is easy, but when the game would check the ammunition of red team's weapon #128, it would actually check the blue team's weapon #48 or so. In order to truly add a new weapon to the game, the developer has to copy the entire weapon entry array and ammunition state array to a new area in memory, insert some buffer space between the array entries and force the game to use the new memory area with regards to extended intervals between entries - find and patch hundreds of references to the old memory address and inlined constants. Btw, even if the modder has achieved such task, there are still dozens of arrays and subroutines that need to be altered (loading custom sprites, img's, sounds and localization strings, extending the arrays containing the pointers to loaded data, modifying the weapon box to show more columns, etc.). Each task involves the same or greater amount of work and further changes to other parts of the game. On the other hand, the owner of the source code to do the same task only has to change some constants and recompile the game.

Extending the game with bigger weapon roster (alongside more team, player, sprite and other miscellaneous arrays) will break backwards compatibility (even though some protocol messages actually offer more space than needed), but if we just prompt the outdated player to upgrade the game, we will be just fine.

In regards to lack of documentation and integration between the game and modules, maintainers could develop a basic ProjectX-like environment (let's call it a True Wormkit), allowing for package management across players, dynamic hooking and unhooking api, game protocol access, easy access to game's memory structures, and reading/writing to new scheme format (I hope the new scheme format is a JSON or XML file, so modders can easily extend it to their own needs). And I strongly believe, that releasing (partial) header files of important structures and functions won't cause harm to anyone. With extended buffers and a proper modding API true miracles could be done.

If the community has to make a leap to 3.8 and redevelop most of the modules, please at least make it worthwhile.

You're entitled to your opinion. For the record, I did not delete your post or account. It may have been deleted simply because of your username, or some other reason unrelated to your post's content.

I do W:A development as a labor of love. j0e hit the nail on the head saying "Maybe he'd lose his ambition to continue if he knowingly left imperfections that he knew he could easily fix." I'm in this for the long haul; I want to make W:A as good as it can be. Taking the "quick and dirty" route of implementing features that break compatibility would sour me on the whole thing. I also predict it would result in elevated excitement in the game for a while, but would shorten W:A's life in the long term, making gameplay more ephemeral and fleeting with no permanent reliable record in the form of forward-compatible replay files. Yes, I realize that in the short term this attitude may result in some frustration. But please bear with me on this! The customizability features in 3.8.0 are just the tip of the iceberg, and there is more to come in later releases. I just want to take my time and do it right.

All of the extensions of which you speak can be done while preserving backwards compatibility, it just takes more time.

Quote from: Ytrojan on December 31, 2018, 07:09 PM
Now, I think I'll keep 3.7.2.1 ONLY for replay preservation, but keep 3.6.31, as the former is obsolete, while the latter is still necessary for Project X,  while Rubberworm is basically gonna die, since it's basically been implemented in Vanilla Worms Armageddon.

3.8 is actually better at playing replays recorded by 3.7.2.1 (and all previous versions) than 3.7.2.1 is. There are some cases in which 3.7.2.1 (and other previous versions) would desync playing a valid replay, that 3.8 will play correctly. And also 3.8 plays back replays with tweening, so they'll look better than they did when they were originally played.

Of course, keep 3.7.2.1 if you want, but it's unlikely to be needed except maybe for other game-logic-changing modules besides RubberWorm.

Quote from: Ytrojan on December 31, 2018, 07:09 PM
However, I fear what will happen to those old Rubberworm schemes and games. Will they be converted to the new scheme format? Or will they be lost to history because of an obsolete format?

I considered implementing automatic conversion of RubberWorm schemes into the new format, but there were some complexities involved and I decided to leave it out of 3.8 rather than delay 3.8 further by taking the time to implement this properly. There's a good chance I'll add the feature in a later version (as well as live play interoperability with 3.6.x/3.7.x + RW), but by then perhaps most schemes will have been manually converted anyway.

(Actually, there is a very easy way of implementing built-in conversion. It is rather distasteful in a programming sense, but I suppose I should probably do it, because of the big impact on convenience it would have for all players of RubberWorm schemes, at least in the initial period of time after 3.8's release.)

• [DC,CS] W:A now has a new scheme format, supporting the tweaking of many options that were previously internal. Access to a limited subset of these options was previously opened up by a third-party module called "RubberWorm", and earlier versions of W:A had bundled some subsets of options in the form of the TestStuff, RacingStuff and BoomRacing hosting options, but the options are now all individually accessible. The options come in a range of types, including boolean (true or false), enumeration (a limited range of values that mean different things, accessed via a drop-down list), integer (where the range varies depending on the option), and fixed-point (having an integer part ranging at most from -32768 to +32767, and a fractional part ranging from 0/65536 to 65535/65536 in 1/65536 increments, though the numbers are edited in the UI in decimal form, e.g. 0.00000, 0.00002, 0.00003, ..., 0.99998, 1.00000, ...). Note that although the game engine tends to round fixed-point values down, the choice was made to round to nearest in the extended scheme editor UI; as a result, many default values are 9-padded (such as 0.24 becoming 0.23999).
  
  • Physics
    
    • Wind can be adjusted, either as the maximum strength randomised wind shall have, or as a constant strength the wind shall have on every turn. In randomised wind mode, the wind bias may be adjusted; this determines how much of an effect the horizontal distance from the map's center of the worm receiving a turn has on biasing the wind to blow in the opposite direction.
      
    • Gravity can be adjusted, in fixed-point units, where the default is 0.23999 pixels per frame of acceleration every frame (a frame is 1/50 seconds).
      
    • Terrain friction can be adjusted with high precision, in fixed-point units. The default is 0.95999. A value of 1.00000 yields no friction, and 0.00000 makes objects instantly stop whenever they would normally slide.
      
    • Rope knocking power can be adjusted as a percentage, optionally overriding the channel or offline value. (The units are the same as in the OfflineRopeKnocking registry tweak.)
      
    • Phased Worms – Controls to what extent allied and/or unallied worms move through and cannot affect each other. There are two settings, Phased Friends, which controls worms' effects on their teammates, and Phased Enemies, which controls worms' effects on their opponents. Each of these can be set to one of four values:
      
      • Off – default behaviour; worms block other worms, and their weapons both hit other worms and damage them.
        
      • Worms – worms pass through other worms, but their weapons still hit them and damage them.
        
      • Worms+Weapons – worms pass through other worms; their weapons also pass through other worms, but when a weapon explodes, its damage still effects those other worms.
        
      • Worms+Weapons+Damage – worms have no influence on other worms whatsoever, with some exceptions (see Footnote 6).
        
    • Explosions push all objects (checkbox)
      
    • Pneumatic Drill Modification (checkbox) – controls whether the Drill imparts horizontal velocity to worms it hits.
      
    • Petrol Turn Decay (fixed-point) – precisely controls the per-turn rate at which the persistent flames from a Petrol Bomb shrink and eventually disappear. The resulting number of turns for which flames last can go from 1 to 65535, with all values from 1 to 257 being precisely specifiable (beyond that point there are some gaps).
      
    • Petrol Touch Decay – controls the rate at which persistent flames from a Petrol Bomb shrink and eventually disappear every time a worm touches them (damaging that worm).
      
    • Maximum flamelet count – The maximum number of individual fire objects (from Petrol, Napalm, or certain explosions) that can exist at once. Once this limit is reached, creation of new flamelets will erase older flamelets.
      
    • Maximum projectile speed (fixed-point) – The maximum horizontal and vertical velocity at which an object following projectile physics can move, in pixels per frame. A value of zero disables the limit. The default is 32.
      
    • Maximum rope speed (fixed-point) – The maximum speed at which a worm with a Ninja Rope or Bungee attached can move, in pixels per frame. A value of zero disables the limit. The default is 16.
      
    • Maximum Jet Pack speed (fixed-point) – The maximum horizontal and vertical velocity at which a worm using the Jet Pack can move, in pixels per frame. A value of zero disables the limit. The default is 5.
      
  • Gameplay (note that the distinction between "Physics" and "Gameplay" is a bit arbitrary, and mainly exists to divide the settings into different pages)
    
    • Unrestrict Rope (checkbox) – Allows firing the rope 54 degrees below the horizon, and reduces rope friction/drag. Default off.
      
    • Maximum crate count on map at once – The game will not spawn crates when doing so would exceed this limit. The default is 5.
      
    • Sudden Death disables Worm Select (checkbox) – Normally, Worm Select is unavailable after Sudden Death, but you can disable that behaviour here.
      
    • Sudden Death worm damage per turn – How many health points Worms lose during each turn of Sudden Death.
      
    • Batty Rope (checkbox) – After the end of their turns, worms with a Ninja Rope attached will remain attached, those using Bungee will stay on it, and those using Jet Pack will keep it equipped. Default off.
      
    • Rope-roll drops – Whether dropping weapons (using the Enter key) during a rope roll (in-between Ninja Rope swings or after Bungee detachment) is allowed.
      
      • Disabled – The default. While on the Ninja Rope, weapons can only be triggered while the rope is attached, and not during a rope roll.
        
      • As from rope only – Weapons that would normally be usable while the rope is attached are also usable during a rope roll.
        
      • As from rope or jump – Same as "As from rope only", except that weapons that would normally be usable during a jump are also usable during a rope roll.
        
    • X-Impact loss of control (checkbox) – Whether a horizontal collision (skid or wall hit) at a high horizontal velocity causes loss of control. Default on.
      
    • Keep control after bumping head (checkbox) – Whether control is retained after an upwards vertical collision with terrain during Ninja Rope or Bungee use. Default off.
      
    • Keep control after skimming (checkbox) – Whether control is retained after a skim (collision with water at a high horizontal velocity) during Ninja Rope or Bungee use. Default off.
      
    • Fall damage is triggered by explosions (checkbox) – Normally, Worms thrown by explosions do not experience fall damage, unless they experience horizontal collision(s) before hitting the ground. This setting enables fall damage (in addition to whatever damage caused by the explosion itself) even in the absence of any horizontal collisions.
      
    • Undetermined Crates (checkbox) – Determines the contents of weapon and utility crates at the moment when the crate is picked up (or a player activates Crate Spy), instead of when the crate is created. The default is for this to be determined by the game logic version (disabled for v3.6.28.0 and older, enabled for v3.6.29.0 and newer). It should only be disabled when all players trust each other not to secretly use information-revealing cheats.
      
    • Undetermined Fuses (checkbox) – Determines the fuse of mines (when random mine fuses are enabled) at the moment when the mine is triggered, instead of when the mine is created. The default is for this to be determined by the game logic version (disabled for v3.6.28.0 and older, enabled for v3.6.29.0 and newer). It should only be disabled when all players trust each other not to secretly use information-revealing cheats.
      
    • Pause timer while firing (checkbox) – Whether the timer is paused while a Worm is firing their weapon. Default on.
      
    • Loss of control doesn't end turn (checkbox) – When enabled, events that cause loss of control will still have that effect, but control will eventually be regained without ending the current turn. Default off.
      
    • Weapon use doesn't end turn (checkbox) – Allows weapons to be used multiple times in a single turn. Default off.
      
    • "Weapon use doesn't end turn" doesn't block any weapons (checkbox) – prevents the Earth Quake, Armageddon, and Indian Nuclear Test weapons from being disabled when "Weapon use doesn't end turn" is enabled. Default off.
      
    • Game engine speed (fixed point) – Changes the speed at which all game physics and sound effects occur. Default 1.00000.
      
  • Glitches
    
    • Indian Rope glitch (checkbox) – Whether selecting the Ninja Rope while moving makes it possible to bypass the angle limit and shoot a rope that can even extend straight downwards. The default is for this to be determined by the game logic version (enabled for v1.0 emulation, disabled for all later versions).
      
    • Herd-doubling glitch (checkbox) – Whether jumping at just the right moment makes it possible to release double the number of Mad Cows as the selected herd count, in a single invocation of the Mad Cow weapon. The default is for this to be determined by the game logic version (enabled for v3.0 and earlier, disabled for v3.5 Beta 1 and later).
      
    • Jet Pack Bungee glitch (checkbox) – Whether it is possible to trigger a Bungee from midair using the Jet Pack. Default on.
      
    • Angle cheat glitch (checkbox) – Whether selecting the Longbow or Baseball Bat while moving makes it possible to bypass the angle limit of the respective weapon. Default on.
      
    • Glide glitch (checkbox) – Whether a certain type of leftward collision by a Jumping, post-Drilling, or post-retreat worm can trigger a glitch in which the worm continues moving in the air (with reduced speed) instead of landing. Default on.
      
    • Skip-walking
      
      • Disabled – Prevents it from making walking faster than normal.
        
      • Possible – Makes the skip-walking glitch behave as it historically did. This is the default.
        
      • Facilitated – Makes pressing Up or Down while walking trigger skip-walking (one skip per keypress), similarly to how right-clicking the mouse does this, except that it also works during retreat time, and following Shotgun/Longbow first shots.
        
    • Block roofing (only affects games played on cavern maps)
      
      • Allow roofing – As was historically possible, worms can get above the roof of a cavern map through any of a number of techniques/tricks. This is the default.
        
      • Block above – Blocks worms from getting above the part of the roof that is visible, directly above the map. This works by projecting the roof upwards to infinity from the perspective of Worm collision mechanics, in a way that is ignored by all other types of objects.
        
      • Block everywhere – Same as "Block above", but also blocks worms from getting above the bottom of the roof everywhere to the left and right of the map.
        
    • Floating weapon glitch (checkbox) – Whether it is possible to drop a weapon (that normally would fall or fly) onto a surface, such that if done just right, it sits still until its hidden fuse expires before exploding or homing. Default on.
      
  • Input
    
    • Auto-place worms by ally (checkbox) – When worm placement is automatic, group worms by team colour. May make automatic placement feasible even in Fort-style maps. Default off.
      
    • Circular Aim (checkbox) – When holding the up or down arrow to aim, this will cause the aim to continue moving past the top or bottom, instead of stopping. Intended to make shots at specific angles more challenging. Default off.
      
    • Anti-lock Aim (checkbox) – The aiming angle is not preserved and is reset between turns (to an angle distinct from the last used one). Intended to make repeat shots more challenging. Default off.
      
    • Anti-lock Power (checkbox) – Holding down the space bar to fire will cause the power to begin decreasing after reaching its maximum. Intended to make full-power shots more challenging. Default off.
      
    • Worm Selection doesn't end Hot Seat (checkbox) – With this enabled, using Worm Select does not cause the Hot Seat timer to end and the turn timer to start. Default off.
      
    • Worm Selection is never cancelled (checkbox) – With this enabled, the Tab key can be always used during a turn to switch to another Worm. Default off.
      
    • Girder Radius Assist (checkbox) – Prevents the Girder mouse cursor from being moved to positions that are out of range (as determined by the Girder power) such that a beep would result if an attempt was made to place a girder there. As such, a beep will only be able to happen when an attempt is made to place a Girder where it would intersect with an existing object, and never due to being out of range. Can prevent an awkward end of a turn where a player spends time figuring out an ideal girder placement, just to have it denied by being out of range. Default off.
      
  • Visual
    
    • Blood Level – Amount of blood (as a percentage), or 255 to use the channel / offline setting value. The offline default is 25%; in the WormNET channel #AnythingGoes, the default is 100%, and in #PartyTime, it is 0%. (Note: The other Blood setting, in "Cheats", is independent and controls blood colour.)
      
  • RubberWorm
    
    • Bounciness (fixed point) – Makes worms spring back like a banana (with the respective sound) upon any collision, without any fall damage or loss of control, and sets the strength (coefficient of restitution) of said bounciness. A value of 1.00000 can cause worms to keep bouncing at the same height forever. The ratio of the height of each bounce to the previous one will be the square of this value; as such, a value of 0.5 will cause each successive bounce to reach 1/4 of the height of the previous one, and 0.70711, i.e. √(1/2), will cause each bounce to reach 1/2 the height of the previous one.
      
    • Air Viscosity (fixed point) – Makes objects such as projectiles experience "friction" when flying through the air, and sets the strength of said friction. A value of 0.00000 (the default) results in no air friction, and 1.00000 would result in no motion through the air being possible. As such, the maximum value allowed is 0.25000, which causes objects to lose 25% of their speed every frame (1/50 second), already an impractically huge amount of friction.
      
    • Air Viscosity (Worms) (checkbox) – Whether "Air Viscosity" should also affect Worms.
      
    • Wind Influence (fixed point) – Any nonzero value extends the set of objects that are sensitive to wind, excluding Worms, and sets the level of said sensitivity. A value of 1.00000 gives them the same wind response as Bazooka shells.
      
    • Wind Influence (Worms) (checkbox) – Whether "Wind Influence" should also affect Worms.
      
    • Gravity Type – Controls how certain objects such as Worms and projectiles are affected by gravity.
      
      • Unmodified – The default.
        
      • Standard – Gravity is multiplied normally.
        
      • Black hole (constant) – Objects are pulled to the middle of the map, with a constant force independent of their distance.
        
      • Black hole (linear) – Objects are pulled to the middle of the map, with a force that is inversely proportional their distance from the middle. (This is inverse linear, and not inverse square like the gravity of our universe.)
        
    • Gravity Strength (fixed point) – Controls the extent to which objects such as Worms and projectiles are affected by gravity. With a Gravity Type of "Standard" or "Black hole (constant)", this is specified as a gravity multiplier (with a value of 1.00000 being normal). With a Gravity Type of "Black hole (linear)", this is specified as the distance in pixels at which gravity is of normal strength.
      
    • Crate Rate – Specifies how many crates can potentially spawn simultaneously at the start of the turn (this will be limited by the value of the other setting, "Maximum crate count on map at once"). With crate drop probabilities set to 100%, causes the exact amount specified to spawn.
      
    • Crate Shower – Enables continuous crate drops during the turn, up to the maximum set by "Maximum crate count on map at once".
      
    • Anti-sink – Prevents Worms from drowning when touching the sea (unless done two times in a row). Worms that touch the sea will automatically be teleported to the last piece of land they were standing on.
      
    • Remember weapons – Prevents the last used weapon selection from resetting to a common weapon regardless of its importance (as defined by the game engine). For example, multiple Bananas can be fired in a row without resetting to Grenades after the first shot.
      
    • Extended fuses/herds – Enables the use of numeric keys 0-9 instead of just 1-5 to set timed weapon fuses and animal herd sizes. The 0 key will set 0 seconds for timed weapons, and 10 animals for herds.
      
    • Anti-lock aim – The aiming angle is not preserved and is reset between turns. Compared to the regular Anti-lock Aim option, this always resets the angle to zero degrees in horizontal left or right direction.
      
• [DC] W:A can now emulate RubberWorm game logic without any third-party modules being loaded. There are two ways this can be done:
  
  • Replay files of games played using RubberWorm under previous versions of W:A may now be played back with full emulation. However, since RubberWorm did not tag replay files in any way to indicate its use, W:A must be told whether to enable RubberWorm detection when parsing replay files. To enable it, import EmulateRubberWorm_On.reg (from the Tweaks folder) into your system registry, or use the command line options /rwemu=on or /rwemu=off which will override the registry setting.
    
    • The entire range of RubberWorm versions are emulated. Since emulating the wrong version can potentially cause a desynchronisation, some autodetection is applied. The potential RubberWorm version a particular replay file could have used is first narrowed down according to what version of W:A was used, but for most versions of W:A this doesn't narrow it down to a single RubberWorm version. W:A addresses this issue by using the timestamp of when the replay was originally recorded, and matching this up with the latest RubberWorm version available at the time. This may not always be correct however, either due to users having their system date set incorrectly, or due to their using an outdated RubberWorm version. Thus, the emulated RubberWorm version can be controlled as a Unix time value integer, either by directly setting the registry value EmulateRubberWorm, or by using the /rwemu= command line parameter with an integer in decimal or hexadecimal specifying the desired Unix time override value – for example /rwemu=50EEDF6B or /rwemu=1357832043 will identically set the value to 2013-01-10 15:34:03 GMT, corresponding to RubberWorm v0.0.1.12-13 for W:A v3.7.0.0. For the full list, see 2.0 Supplementary Documentation – Integration and Command-Line Parameters. Note that the detected W:A version will always override this (the version emulated will be rounded off to the oldest or newest RubberWorm corresponding to that W:A version, depending on the direction in which the time override setting is out of range), so for example, it will not be possible to force emulation of a version of RubberWorm made for W:A v3.7.0.0 when playing a replay file recorded with W:A v3.7.2.1.
      
  • The new scheme format includes all of the options that were controllable via RubberWorm. The ones that controlled aspects internally present in the game engine (but previously not exposed as scheme settings) are in general categories, and the ones that introduced new game mechanics are in the RubberWorm category.
    

• [DC] Schemes saved in .WSC format and replay files saved in .WAgame format had different rules for deciding what scheme-version byte value (1 or 2, corresponding to a scheme data size in bytes of 221 or 297, respectively) to use. When saving in .WSC format, the determination was made based on what version of W:A would be needed to correctly interpret all settings in the scheme. When saving into .WAgame format, the determination was made based on which scheme format could contain all the settings used. Both formats are now saved using the latter rules. This may result in some .WSC files that were sized 297 bytes when saved with a W:A version earlier than 3.8.0, but which when loaded and then resaved using W:A v3.8.0 or later, will become 221 bytes in size, losslessly.
  
• [DC] Changes affecting game logic
  
  • [DC] It is now possible to set a weapon/utility to have zero ammo and nonzero delay. Previously, the game would automatically set the delay to zero on anything with zero ammo.
    
    • Note, this changes the behaviour of team special weapons. Previously, any special weapon that was not a particular team's special weapon could appear in a crate on that team's turn. Any team collecting that crate would then be able to use it without delay, if it was not that team's special weapon. Now, the default delays of special weapons apply to all teams, and no special weapon can appear in a crate until its delay has expired.
      

Features

• [DC] All in-game motion and animations are now rendered at the hardware refresh rate, rather than being locked to 50 Hz as before. The game engine still runs at 50 Hz, so "tweening" is used to accomplish this. As a result, most in-game motion that used to appear somewhat jerky will now look quite smooth. (Note, tweening of animations is still limited by the number of pre-rendered frames in Gfx.dir. The difference is that now, the available frames are used as effectively as possible.)
  
  • Note: This feature is not yet 100% finished. There are still several things that are not tweened.
    
• [CS] Hardware rendering is now available for 8-bit DirectDraw. When enabled, graphics performance should be very close to W:A versions before 3.6.31.2b. An additional hardware rendering option, Use VRAM, has also been added.
  
• [DC] It is now possible to save a snapshot of the current map in-game. The map is saved in its current destroyed/augmented state, with the water level set to its precise current level. There are two ways to do this: One is to press Alt+Pause, and the other is to enter /map in the chat panel (synonyms of this command are /mapshot, /snapmap, /savemap, and /getmap).
  
  • Map snapshots are saved in the User\SavedLevels\Capture folder. In order to facilitate using this folder, it is sorted before all other folders.
    
  • In order to save the precise water level while keeping the map format backwards-compatible, the water level is written in such a way that in most cases, versions of W:A prior to v3.8.0 will not be able to preserve the exact water level when opening the file in the Map Editor; however, versions as early as v3.6.28.0 will be able to preserve the exact water level when receiving the map over the network, and when playing back replay files.
    
  • When saving a snapshot of a map in which indestructible borders are enabled, the exact state of the portion of the borders that is currently underwater will not be preserved if the water level has risen since the game round started, due to the fact that the initial water height preserves the submerged borders, but subsequent rising of water erases the borders.
    
• [DC] W:A now handles it more gracefully if Gfx.dir, Gfx0.dir, and/or Gfx1.dir are missing from the DATA\Gfx directory. It will fall back on whichever one exists, in order of preference.
  
• [DC] A file named GfxC-3.0.dir has been added to the DATA\Gfx directory. This is a small file containing only the necessary bitmaps (Longbow arrows, Girders, and masks) for emulating versions earlier than v3.6.22.0 and no earlier than v3.0. It is now possible to delete Gfx.dir without losing any functionality (unless the ability to run old EXEs from the same W:A installation is desired).
  
• [DC] When the /register parameter is combined with /nowk or /wk, this is now incorporated into the command line of the registered associations.
  
• [DC] The R key now functions during instant replays, restarting the replay from its beginning (or the current "bookmark" position, if one was created using the M key during the playback of that instant replay).
  
• [DC] Leading zeroes in the instant replay countdown timer's digital number font are now darkened.
  
• [DC] This version of W:A can now emulate and interoperate with W:A v1.0. It is possible for an online game to have mixture of v1.0 and v3.7.2.20+ users, and it doesn't matter who is hosting.
  
  • A file named GfxC-1.0.dir has been added to the DATA\Gfx directory. This is a small file containing only the necessary bitmaps (Longbow arrows, Girders, and masks) for emulating W:A v1.0 without needing to keep a copy of the entire v1.0 Gfx.dir.
    
  • Note, W:A v1.0 applies terrain textures just like v3.0, but unlike v3.0, it allows the "Tools" texture to be used.
    
  • When loading a .BIT or .LEV with a date stamp earlier than the release date of the W:A v3.0 patch on 1999.04.23, the file will be assumed to have been saved by W:A v1.0.
    
• [DC] Mouse wheel support in the front end has been made comprehensive. All controls that were previously not affected by the mouse wheel, and should have been, now are. Also, mouse wheel input now goes to the control over which the mouse cursor is hovering, rather than to the control that has keyboard focus.
  
• [DC] When doing playback or Export Log on a replay of an online game created by v3.6.19.17-v3.6.25.1a, "Checksum Missing" errors that were caused by a Remote Checksum Mismatch are now noted as such. (Before v3.6.26.1, checksums during remote players' turns were only recorded when the remote checksum agreed with the local checksum.)
  
• [DC] The in-game menu that is opened by pressing Esc now remembers your mouse cursor position after being closed. (It is still reset to a centred position at the beginning of each round, however.)
  
• [DC] When doing playback / Export Log of an online game replay file created by v3.6.29.24 or later, a checksum that was spurious from the perspective of the local player at the time of recording, but is no longer spurious at the time of playback (due to a difference in game logic or initial state), is now printed as such.
  
• [CS,DC] There is now a button on the Advanced Options screen to associate W:A with .WAgame files and the wa:// URL. When appropriate, an elevated WA.exe will be spawned in order to write to protected Windows Registry locations.
  
• [DC] It is now possible to take screenshots with transparency. This can be enabled or disabled using the CaptureTransparentPNGs_On.reg and CaptureTransparentPNGs_Off.reg registry tweaks, respectively. This applies both to screenshots taken using the Pause key and to video frames captured using the Export Video feature. Note that transparent areas only exist when all background detail is turned off.
  
• [DC] The number of pixels the mouse must be moved within a single frame to temporarily unlock the camera (yielding manual camera control until the mouse has been idle for at least 2 seconds of game time) is now configurable via a registry value. It can also be disabled or set to the default value using the CameraUnlockMouseSpeed_Minimum.reg and CameraUnlockMouseSpeed_Default.reg registry tweaks, respectively.
  
• [DC] All options in the Export Video dialog box except for "Start at" and "End at" are now remembered.
  
• [DC] The /open command now optionally allows a host to change the game name and password when reopening the game, by popping up a dialog box allowing them to be changed.
  
• [DC] The Weapon Editor now provides access to editing the ammo and delay of the Damage*2 utility, which until now was inaccessible in the front end and only editable externally.
  
• [DC] A third state has been added to the "Legacy utility key" option (LegacyUtilityKey_Both.reg), in which both keybindings are enabled simultaneously.
  
• [DC] W:A can now be used in windowed mode, with all renderers (except for 8-bit DirectDraw with hardware rendering). (Special thanks to StepS for lots of research and testing contributing to this feature.)
  
  • To enable or disable this, toggle the Windowed mode checkbox in Advanced Options, or use the WindowedMode_On.reg and WindowedMode_Off.reg registry tweaks.
    
  • Note that although 8-bit DirectDraw works in windowed mode, part of its palette will be incorrect.
    
  • When in-game, the mouse can be in either a grabbed or ungrabbed state. In the grabbed state, the Windows mouse cursor is hidden, and the mouse and keyboard control the game as if it were full-screen. In the ungrabbed state, the Windows mouse cursor is visible, and it along with the keyboard can be used to move the window, open the system menu, etc., but not to control the game in any way. To switch from the grabbed state to the ungrabbed state, press Ctrl+G, or do anything that takes focus away from W:A (such as using Alt+Tab to switch to a different application). To go back to the grabbed state, either click inside the client region of the W:A window, or restore focus to W:A from an unfocused state by some means other than clicking directly on it (such as using Alt+Tab or clicking W:A's taskbar button).
    
• [DC] The file open dialog box used by the Map Editor's Import function now allows opening a file by double-clicking it.
  
• [DC] Assisted vertical sync is now supported by all renderers.
  
• [DC] The "browser back" buttons on mice and keyboards will now act like the ESC key in the front end, exiting the current dialog/screen.
  
• [CS,DC] An option has been added to use OpenGL rendering.
  
• [DC] It is now possible to start an offline game with CPU teams only, and no human teams present, pitting the CPU to play against itself.
  
• [DC] It is now possible for transitions between the front end and game play to occur in the background while minimised. Previously (from v3.6.30.0 onward), the game always paused during such a switch if it was minimised, and required the user to manually restore W:A before allowing the switch to happen. (In v3.5 Beta 1 through v3.6.29.0, W:A automatically restored itself, stealing focus.)
  
  • [DC] The AFK (Away From Keyboard) mode (activated by entering /afk or /away in the chat) now works while minimised, and multiple rounds and matches can go by with no user intervention while staying minimised.
    
• [DC] The /url command can now be used by a host who is using WormNAT2. This is accomplished by exporting a function from WA.exe (see Footnote 5).
  
• [DC] Some files are now preallocated on disk to prevent fragmentation, speeding up their access on hard drives. Currently, this is only done for the temporary file containing the current game's decompressed map (data\land.dat).
  
• [DC] In the circumstances where W:A prints to a console window (currently just for /getlog and /repair), it now detects whether stdout is a valid handle, and if it is, it prints to stdout instead of opening a new console window. To make WA.exe behave like a console app from the command line, you can pipe it through "cat" (which must be installed, e.g. from UnxUtils or Cygwin) by appending "|cat" at the end of the command line.
  
• [DC] Flags have been added for Vietnam and Kyrgyzstan, and the flag for Iraq has been updated. The flags for Finland, Colombia, Ecuador, and Venezuela have been edited.
  
• [DC] Every time a .LEV style map is generated, a corresponding SVG (Scalable Vector Graphics) file is now automatically written, with the filename DATA\landgen.svg.
  
• [DC] Six Turkish characters have been added to W:A's font set: ĞğŞşİı
  
• [DC] The game has been fully translated to Finnish by Juho Toivanen.
  
• [CS,DC] An option to display timestamps (in local time) in front end and in-game chat logs has been added. Currently, this can be enabled by using the TimestampFormat_HMS.reg registry tweak for 24-hour time of day timestamps, and disabled using the TimestampFormat_None.reg tweak. The exact format can be customized by editing the TimestampFormat registry option, the syntax of which is that of the C strftime function. Currently, timestamps are only available for live games, and will not be displayed when playing back replay files.
  
• [DC] In the Steam version, W:A will now use the Steam persona name, instead of the system username, as the default nickname.
  
• [DC] It is now possible to play on maps up to the maximum size of 32504×32600 (whereas before, only the width or height could be maximum, but not both), as long as the system supports Large Address Awareness and enough memory is available.
  
• [DC] It is now easily possible to enter automatic turn-skipping mode in an offline game, by entering /afk or /away in the chat. Previously, this could only be done by pressing Enter and PageUp simultaneously after typing the command.
  
• [DC] It is now possible to toggle the displaying of extra information during replay playback that would normally be hidden in a live game. This is toggled by pressing Shift+Alt+Delete in-game.
  
  • Display of the following information is toggled:
    
    • Crate contents
      
    • Hundredths of a second in turn time and retreat time
      
    • Mine fuses and duds
      
    • Full-time, full-precision display of weapon fuses
      
  • Display of the following is not controlled by this toggle:
    
    • Allied chat
      
    • Invisible worms
      
    • Weapon panel for all alliances
      
• [DC] In the Map Editor, it is now possible to automatically view the color preview (or large map thumbnail) while cycling through randomly generated maps via a map thumbnail. To do this, hold the right mouse button while cycling through maps on the map thumbnail (either by clicking, Shift+clicking, or using the mouse wheel, while the mouse is hovering over a map thumbnail). This will have the same effect as right-clicking the map thumbnail immediately after switching to each different map.
  
• [DC] It is now possible to have W:A play sound effects while it is in the background. To set this option, use the "Play audio in background" checkbox in the Advanced Options screen, or use the PlayAudioInBackground_Enable.reg and PlayAudioInBackground_Disable.reg registry tweaks. Even with this option enabled, ambient sounds (front end menu loop and in-game ambient music) will still be disabled while W:A is in the background.
  
• [DC] The number of the currently selected mission is now visible in the Mission screen. So as not to be overly intrusive, it is displayed in the heading of the "Mission Details" box.
  
• [DC] A "Streaming Mode" option has been added. It is intended to be used when broadcasting streaming video of W:A. When enabled, it prevents the IP address from being shown on-screen while joining an online game, and prevents the /url command from displaying the URL on-screen. To set this option, use the StreamingMode_On.reg and StreamingMode_Off.reg registry tweaks prior to starting W:A, or use the /stream command in the WormNET lobby, LAN lobby, or Host/Join/Next Round/End of Match lobby.
  
• [DC] It is now possible for the host in an online game to add CPU teams. The game will only be allowed to start if all clients present support this feature.
  
• [DC] It is now possible to change the "controller" setting (Human / CPU 1-5) when editing a team, whereas before it was only possible to edit this setting when creating a team.
  
• [DC] It is now possible to select and copy text into the clipboard from the next-round and end-of-match screens' Results, Awards, and Details text boxes.
  
• [DC] The exact value of the Hot Seat time is now precisely displayed in the front end and can be fine-tuned. To adjust it in increments of 1 second, hold the Shift key while left- or right-clicking to increase or decrease the value. Without Shift being held, this setting will cycle through the values 0, 5, 10, and 15, the same as it used to.
  
• [CS] WormNET servers can now specify an IRC port for the game to connect to in the <CONNECT> tag. The syntax is <CONNECT HOST:PORT> (for example: <CONNECT 192.168.0.1:9999>). Previous versions of W:A only allowed connecting to the standard IRC port, 6667.

• [DC] Fixes affecting game logic (continued)
  
  • [DC] If a Worm currently overlapping with terrain used Teleport, then it would move to the target location immediately, rather than in the middle of the teleportation animation as it should. (See the explanation of the related desynchronisation, above, for situations in which this could occur.)
    
  • [DC] If a herd of Mad Cows was released from rope, and the last cow was released during a rope roll, then the worm would get land retreat time instead of air retreat time. The same would happen if the worm landed and entered a sliding state while releasing the last cow.
    
  • [DC] With TestStuff enabled, after a weapon was fired during a rope roll, the worm would get land retreat time instead of air retreat time.
    
  • [DC] The v3.7.2.1 fix, "The glitch in which targetable weapons (such as Homing Missile, Air Strike, and Teleport) could be fired without being targeted has been modified. It now only works in the form of pre-targeting, which must be done on the same turn." was incomplete. It was not applied for weapons released from Rope, Bungee, Parachute or Jet Pack.
    
  • [DC] Bug introduced in v3.7.2.1: If a Strike weapon with left/right aiming (such as Air Strike or Mine Strike) was fired without being targeted (using the glitch that allows this to be done), it would be fired with zero horizontal velocity (as opposed to left or right), throwing the game into an infinite loop.
    
  • [DC] Bugs in a feature introduced in v3.6.24.2: One of the features enabled by TestStuff — use of weapons during a rope roll — had two bugs that are now fixed:
    
    • It did not enforce restrictions on placement coordinates when firing Teleport or Girder. It was possible to exploit this to place a girder anywhere, even intersecting with terrain, worms and other objects.
      
    • It did not work correctly with targeted weapons that fire immediately upon mouse click, such as Air Strike, Girder, Teleport, etc. (Strictly speaking this change doesn't affect the game logic, but it is tied to the logic version for fairness.)
      
  • [DC] Despite the wraparound fixes in v3.6.28.0, it was possible for wind-blown flamelets to wrap across from the left edge of the coordinate system to the right edge or vice versa.
    
  • [DC] A fix in v3.6.31.2b was improperly done. As intended, it fixed the total subtraction of poison damage when an Indian Nuclear Test was immediately followed by the onset of Sudden Death at the end of the same turn. However, it created a bug in which, on turns where Sudden Death was pending (with the round timer red due to having counted down to zero, but with Sudden Death being delayed until a randomly chosen team's turn), poison damage was not subtracted from already-poisoned worms. The fix has now been simplified. Instead of queuing the poison-damage subtraction of a consecutive Indian Nuclear Test + Sudden Death until Sudden Death (as the old fix did, subtracting 7 points of poison in one go), it now immediately subtracts the 2 poison points caused by the Indian Nuclear Test, and then subtracts the 5 poison points caused by Sudden Death.
    
  • [DC] In a very tall map, any Mole Squadron mole that did at least 36.02 seconds (but less than 51 seconds) of digging, followed by reaching the ocean, would suddenly spring upwards away from the water at high speed.
    
  • [DC] Weapons/utilities set to infinite delay in the scheme were shown in the weapon panel, even though they could never be used. (Strictly speaking this change doesn't affect the game logic, but it is tied to the logic version so that all players see the same thing.)
    
  • [DC] Some conditions that applied to normal crate drops did not apply to superweapons:
    
    • Any normal weapon/utility which the team getting the next turn had in infinite supply would never fall in a crate, but this rule did not apply to superweapons.
      
    • Only weapons/utilities currently at zero delay would fall in a crate, but this did not apply to superweapons.
      
    • With Sheep Heaven enabled, normal crates were hugely biased towards being sheep only, but superweapon crates were not.
      
  • [DC] Delayed weapons/utilities could never fall in a crate until the turn after the delay expired. This created a discontinuity between the effect of a 0 turn delay setting and a 1 turn delay setting on when a weapon/utility could appear in a crate; the former would result in the possibility of it falling in a crate on the first turn, but the latter would deny it from falling in a crate until the third turn.
    
  • [DC] Bug in a feature introduced in v3.6.30.0: The Delay of Damage*2, unlike other utilities, was not being loaded from the scheme.
    
  • [DC] If an explosion occurred very far (an ortho-distance of 32768 pixels or greater) from fire or skunk gas particles, it could move them with its blast. Note that the 3.6.30.0 "global explosion" fix did not address this, due to the different way in which distances are calculated (orthogonal instead of Pythagorean).
    
  • [DC] If an object (e.g. a rope-knocking worm) that would normally slide up one-pixel increments of terrain, and would normally knock another object (e.g. a worm), collided with both a one-pixel increment of terrain and a knockable object at the same location, it would rebound in the opposite direction, instead of knocking the other object and continuing to slide in the same direction.
    
  • [DC] Neither worms nor animals could collect more than one crate per frame. With Super/Aqua Sheep, this could make it possible to hit a crate and explode instead of collecting it.
    
  • [DC] A moving worm would move for two frames' worth of time in a single frame if one of the following events happened:
    
    • It was in a rope roll, and collided with something, deactivating its ability to shoot another rope.
      
    • It was in a rope roll, and skimmed against water (if a rope attached at the same time, then control would be retained).
      
    • It was on rope or bungee, and a jumping or jetpacking worm collided with it.
      
    • It was on rope, bungee, jetpack, or parachute, or was jumping or frozen, and was hit by a specific type of Longbow arrow collision (the type where the arrow registers its hit when its centre pixel, not its tip, touches the worm's collision mask). (The effect of the bug in this case was usually too subtle to see.)
      
    • It was standing still and was pushed by earthquake force. (The effect of the bug in this case was usually too subtle to see.)
      
  • [DC] Bug incompletely fixed in v3.5 Beta 1: When a valid initial-manual-placement Teleport was forced to fail by changing its coordinate after firing it, it was then possible to select a different weapon and use it. That worm would then be located way up in the sky and untouchable during turns.
    
  • [DC] Bug incompletely fixed in v3.6.19.17: The previous fix, "When placing worms at the beginning of a game, placing directly on land caused an annoying delay of two seconds, whereas letting the worm drop onto land did not create much of a delay. Now, placing directly on land causes virtually no delay (the only delay will be due to network lag)." was incomplete. A long delay still occurred after placing the last worm of the last team directly on land. This delay is now the same as that which occurs after placing the last worm one pixel above land.
    
  • [DC] Bug introduced in v3.5 Beta 1: When Girder or Teleport was clicked at an invalid location while a worm was jumping, falling, or landing, instead of triggering a warning beep as it should, this caused the mouse cursor to disappear, without the accompanying spangle animation that happened when clicking at valid locations. The warning beep would then only happen if Space was subsequently pressed from the ground in an attempt to place the girder or trigger the teleport.
    
  • [DC] If any mouse cursor triggering weapon (homing, strike, girder, or teleport) was used and had the "Remember as Default" property (currently only possible with the RubberWorm "Remember weapons" option enabled, which applies it to all weapons), then after the weapon's use, it would be reselected immediately before retreat time, blocking that retreat time from being effectively used due to the mouse cursor being enabled (which blocks the player's worm from being controlled via the arrow keys and other hotkeys).
    

Changes

• [DC] A DPI-awareness manifest has been added to W:A. On systems running Windows Vista and later, with a custom DPI setting, this prevents W:A's GDI-mode dialog boxes (such as the "Export Video" dialog, and the dialog that acknowledges "Export Log" having finished) from being rendered with a fixed-size font and resampled (which made the text look blurry at DPI settings higher than 100%).
  
• [DC] From v3.6.26.4 onward, when a checksum mismatch occurred in an online game, the local checksum and the incorrect remote checksum were both recorded, such that in playback or Export Log it would appear as a "Remote Checksum Mismatch" error. In the case that upon playback, the remote checksum that was incorrect at the time the game was being played is now correct (according to the instance of W:A used for playback), it was displayed as "Remote Checksum Good", a useful feature for analysing the causes for desynchronisations. In v3.6.30.0 a more comprehensive format for recording remote checksum errors was introduced, however, a simple remote checksum error recorded in this format was no longer printed in an informative way (there was no differentiation between a remote checksum that was good or bad according to the instance of W:A doing playback). It is now printed in the same way as the older format ("Remote Checksum Mismatch" / "Remote Checksum Good").
  
• [CS] The error message displayed upon failing to load a WormKit module has been improved.
  
• [CS] On Windows systems running Windows XP or newer, the default graphics API is now Direct3D 9 (shader), with the alternative fallback renderer being changed to DirectDraw (32-bit). This replaces the first-start suggestion to enable Windows compatibility flags on Windows 8 and newer.
  
• [DC] The Export Video dialog box has been rearranged.
  
• [DC] When hosting a password-protected game, W:A sent the password to the WormNET server using the &Pwd=<string> parameter in the HTTP request, resulting in a potential violation of privacy. Now it simply sends &Pwd=1 instead if the game is password-protected, and no &Pwd= parameter otherwise.
  
• [DC] There was an unnecessary 1 second pause upon showing the "Please wait... working..." dialog, whenever starting a game from the front end.
  
• [DC] W:A no longer shows a warning if it has been run "as administrator", because the bugs that happened in this situation have been fixed.
  
• [DC] In v3.6.19.7, a bug was fixed in which the text cursor of a combo box wasn't properly updated when selecting a different item in the drop-down list. The fix was to always move the cursor to the end of the text in the combo box upon closing the drop-down list. This fix ignored the fact that if the list is opened and closed without selecting a different item, the best behaviour would be to keep the text cursor where it was; this is what is now done.
  
• [DC] Display mode changes are now avoided in some additional cases. If the desktop resolution, front end resolution (640×480), and in-game resolution are all different, then this can potentially prevent the monitor from blanking out for a period of time while changing modes.
  
  • [DC] When starting a game from the front end with a Direct3D 9 renderer in use, W:A no longer switches to the desktop's video mode before switching to the in-game video mode. (Note that with a DirectDraw renderer in use, this was already the behaviour since v3.5 Beta 1.)
    
  • [DC] When exiting from a game and returning to the front end with a DirectDraw or Direct3D 9 renderer in use, W:A no longer switches to the desktop's video mode before switching back to the front end's video mode.
    
• [DC] The Direct3D 9 renderers no longer explicitly release and recreate the Direct3D 9 device upon restoring from a minimised state.
  
• [DC] The DirectDraw renderer no longer has a frame rate limit. (In v3.6.31.2b, a frame rate limitation of 100 fps was added; in v3.7.0.0 the limit was changed to 125 fps. The Direct3D renderers added in v3.7.0.0 never had a frame rate limitation.)
  
• [DC] The Windows Application Compatibility setting (Layer_ForceDirectDrawEmulation) has been removed from the Advanced Options menu, as it is no longer needed to get any renderer to work properly under any version of Windows. For those who had enabled this in previous versions of W:A, it is recommended that you disable it using a version of W:A that still had the option in its interface.
  
• [DC] Double-clicking the chat message history box in the LAN Lobby no longer clears the view of the chat history. This was a confusing and not very useful feature, and interfered with double-clicking on hyperlinks (starting when the feature "Web and E-mail URLs are now automatically parsed and converted to hyperlinks in message histories" was added in v3.6.30.0).
  
• [DC] Controls such as buttons and input forms of pop-up windows (e.g. Export Video and Playback At) will now use the system style instead of being forced to the classic style (Win2000-like). Also, in all Windows versions they now use the default dialog font instead of forcing use of MS Sans Serif.
  
• [DC] The door that covers the special weapons in the Weapon Editor has been repalettised and now looks slightly better than before.
  
• [DC] The country code mappings have been updated to include codes that weren't in the original mapping implemented in v3.6.19.7. This maps the location code in the registry (HKEY_CURRENT_USER\Control Panel\International\Geo, which can be set from Control Panel: Regional and Language Options: Location) to ISO 3166-1 Alpha-2 codes. Note that this change does not mean there are any new country flags displayed by W:A, just that the potential to add country flags for the new locations has been added.
  
• [DC] The "custom.img" temporary file is no longer created or used.
  
• [DC] Address space layout randomisation (ASLR) has been enabled, to mitigate possible undiscovered buffer overflow security vulnerabilities. This option, supported by Windows Vista and later, causes memory layout to be randomised. Some existing WormKit modules may need to be patched/rereleased to account for this.
  
• [DC] The in-game clipboard paste feature, added in v3.6.28.0, blocked keyboard repeat on the paste hotkeys Ctrl+V and Shift+Insert. Keyboard repeat now works on these hotkeys, keeping consistency with the rest of the UI.
  
• [DC] When loading .CUS maps (colour maps that were saved using v3.5 Beta 1/2/3pre1), the cavern roof flag in the header is now obeyed, rather than detecting it from the top 8 pixel rows of the map.
  
• [DC] Commands typed in the in-game chat panel are now case-insensitive; for example, /afk, /AFK, /AfK, /msg, /Msg, and /MSG will all work. (Previously, in-game commands were only accepted in lowercase.)
  
• [DC] The behaviour of the OK / Exit and Cancel buttons, and the Escape key, is now consistent and sensible in the Scheme Options and Weapon Options screens.
  
  • When changes have been made, the Exit button becomes an OK button.
    
  • Pressing Escape presents the user with the option to save changes and exit, discard changes and exit, or cancel the exit. This behaviour had already been present in the Weapons Options screen, but is now in the Scheme Options screen as well, and has been given a message that more intuitively describes what Yes, No, and Cancel do (and as a side effect, the effects of Yes and No have been inverted).
    
  • To a lesser extent, the Options menu, Advanced Options screen, and Team Editor have also been made more consistent. The exceptions are that the Options menu and Team Editor still do not detect whether changes have been made, the Advanced Options screen still does not have a visible Cancel button, and the Escape key behaviour has not been changed in any of these screens to match its new behaviour in the Scheme Options and Weapon Options screens.
    
• [DC] The team list in the Host/Join screen is now sorted the same as it is in the Offline Multiplayer screen.
  
• [DC] The Force Wine virtual desktop option has been removed, as it is no longer needed for running W:A under Wine. If running W:A under a virtual desktop is still desired (e.g. to experiment with using the DirectDraw (8-bit) renderer), it is still possible to do so, either by enabling the "Emulate a virtual desktop" checkbox in winecfg (and closing all instances of wine that were open at the time this setting was changed), or by launching W:A with the command line "wine explorer "/desktop=640x480,Worms Armageddon" [WA.exe's full command-line]" instead of just "wine [WA.exe's full command-line]".
  
• [DC] The centering, alignment, and spacing of front end controls (buttons, text, edit boxes, group-boxes, etc.) have been improved in all dialog boxes and screens.
  
• [CS] The </CENTER> close tag is now correctly handled when parsing HTML.

• [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 desynchronized state, potentially resulting in a desynchronization upon game start.
  
• [DC] Bug in a feature introduced in v3.6.19.7: Replay file playback would desynchronise in online games and offline missions/training, if the Indestructible Border was disabled and Indian Nuclear Test delay was set to 99 in the scheme or .WAM file. 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 feaure and some after, desynchronize 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-colored (differently-allied) teams, only one of those team colors 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] Fixes affecting game logic
  
  • [DC] Weapon delays for an allied team group were not decremented for the first time until after every team in that alliance got a turn, but once that happened, their delays were decremented every time any team in that alliance got a turn. With an uneven match such as 2vs1 or 3vs2, this actually resulted in unfairness, since the alliance with fewer teams in it had their delays decremented earlier in the game. Now, delays are decremented for the first time after every alliance has had one turn.
    
  • [DC] Bug in a feature introduced in v3.6.30.0: In BoomRacing mode, fire (especially from a Petrol Bomb) was influenced by all explosions, when it should have been limited to being influenced by explosions made by the same allied team group that created the fire.
    
  • [DC] A worm that triggered Freeze would be able to collect crates during other teams' turns, while in a frozen state, until unfreezing.
    
  • [DC] The bug introduced in v3.6.30.0 and supposedly fixed in v3.6.31.2b, "If a rope that was not perfectly vertical was allowed to settle into a perfectly vertical resting state, and then a Girder or Longbow Arrow was created inside the rope, the worm dangling from the rope would "accelerate" due to gravity while actually staying still at the end of the rope; when released, the worm would then fall downward at an artificially high initial velocity." was improperly fixed. The bug still happened in 50% of cases, depending on whether the rope settled to a resting state infinitesimally left of vertical or infinitesimally right of vertical.
    
  • [DC] Bug introduced in v3.7.0.0: The Girder Starter-Pack stop sign would only allow itself to be activated over empty space, as if it were a circularly-shaped girder to be placed.
    
  • [DC] Bug introduced in v3.6.22.0: If the Girder Starter-Pack stop sign was used in "Weapons Don't End Turn" mode, the stop sign would "stick" as the default girder (until the turn ended, Girder was selected, or Girder Starter-Pack was reselected and rotated). While the stop sign was the default, all other aimable weapons would ignore the cursor position and instead use the last position where the stop-sign was clicked.

• [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] 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.
  
• [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.

• [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 "Weapons Don't End Turn" mode, 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.
  
• [CS] The Steam edition of the game now stores the player's teams in the file WGUSER.WGT instead of WG.WGT. The file WG.WGT now only serves as a template. This was done to avoid the player's teams being inadvertently reset when the Steam actions Verify integrity of game cache or Delete local game content were activated.
  
• [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.
    
• [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.

Edit: v3.8 has been released!

The long-awaited W:A 3.8.0 is almost ready for release. As a stopgap until then, we'd like to share the Changelog of this release. It hasn't been sorted into categories yet (and thus is still in the mostly-chronological order in which we wrote it), and some details are subject to change before release. With no further ado:

v3.8.0 Update

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 LeTotalKiller, 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.
  
• A minor typo has been corrected in the German translation.
  
• [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 realizing 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.
  
• [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.