Worms Armageddon ReadMe (English)/v3.6.26.4 Beta Update

(Up to Worms Armageddon ReadMe (English))

v3.6.26.4 Beta Update (2005.11.22)

Fixes

• With some video cards (e.g. NVIDIA GeForce 6600 GT) and drivers, W:A's front end would have a very slow refresh rate, resulting in extreme unresponsiveness.
• There are many additional checks that will prevent crashes caused by:
  • Attempting to play WAgame files containing invalid data in them
  • Attempting to load .BIT maps containing invalid data
  • Receiving invalid data over the network in an online game
• It used to be possible, using a hacked connection or EXE, for a client connected to a host's game to:
  • Force other players to light up, falsely signifying their readiness to start the game.
  • Remove a team belonging to the host or a different client.
  • Add a new team on behalf of another player.
• When more than 15 kills are made in a single turn, the number of kills is now reported correctly in the game comment displayed at the top of the screen.
• Opening a .LEV or .BIT map in the Map Editor rounded off the percentage of objects and bridges, so that the same map when resaved could be rendered differently.
• If, at the Next Round stage of an online game, the host loaded a map unsupported by one or more players due to their running an older version of W:A, there would be no text warning when everyone lit up, and the game would be allowed to start. When it started, the players for whom the map was unsupported would desync.
• v3.6.19.14 fixed the playback of Deathmatch games that were incorrectly recorded by earlier versions, but this fix was broken in v3.6.23.0. It is fixed again now. (Note that it is only the playback of Deathmatches recorded before v3.6.19.14 that was broken; new ones were recorded fine.)
• If the Export Log function could not create the log file, full screen playback was initiated instead. Now it aborts and pops up an error box.
• The Homing Pigeon sprite was animated at a speed dependent on the video refresh rate, and therefore flapped its wings fast even in Single Step mode. Now it flaps its wings at a rate consistent with everything else.
• When emulating 3.5 Beta 1/2/3pre1, if the bug "Once Worm Selection was disabled by the onset of Sudden Death, it did not come back in following rounds" occurred, this fact was not noted in the recorded game file; as a result, the game could desync when played back.
• When R was pressed to restart a replay, the bottom of the viewport was not reset to reflect the initial water level if it had risen during playback.
• Starting in v3.6.23, the Nuke fade-to-white was incomplete; if backgrounds are turned off, the background in the 1920×696 rectangle occupied by the landscape stayed black throughout the fade. On an island map, this was especially unsightly because the space outside the rectangle did fade while the inside didn't.
• In an online game, if the host had loaded a map causing one or more players' names to be crosshatched in red (signalling version incompatibility), and then proceeded to switch to an intrinsic map (from the pull-down menu below the terrain thumbnail), the name(s) would continue to be crosshatched in red even though the incompatibility no longer existed; the game would also be prevented from starting.
• In an online game, during your turn, your moves are time-delayed before being sent over the network. This is necessary, because otherwise an unnecessary amount of bandwidth would be used. However, the buffering was also being applied to chat messages made during other players' turns! So your first message typed during someone else's turn would be delayed for 2 seconds before being sent, and subsequent messages before the beginning of the next turn would be delayed for 1 second. So, say you tried to give advice during a player's turn, and it was the first message you typed during that turn. By the time the player saw your advise, 4 seconds (plus network latency) of game time would have elapsed relative to the game time on your end when you pressed Enter. Now, chat messages are no longer buffered or delayed during other people's turns (this reduces the minimum relative game/chat lag to 2 seconds). Note that during your own turns, your own chat messages are delayed to synchronise with your actions in the game (which is how it has always been).
• The Export Log feature was incorrectly reporting the Local Player (on whose machine the recording was created) in some cases, and not reporting a local spectator at all.
• After using the Export Log function, the game volume was reset to zero.
• There was a memory leak in the crate drop algorithm for v3.5 Beta 1 and later; every time a crate tried and failed to drop due to insufficient space on the map, 326 kB would be allocated without being freed. If this happened a sufficient number of times, the game would crash. Note that most of the time a crate doesn't fall, it is usually for a different reason. There have been no reports to suggest that this memory leak ever resulted in an actual crash.
• Bug introduced in v3.6.23.0: When playing back a Mission or Training replay that took place in a cavern with an indestructible border on all sides, the map was treated as an cavern with only a top border, resulting in checksum errors and possible desyncing. This issue was supposed to be fixed in 3.6.25.1, but the fix was incomplete.
• A "win" could be triggered in Mission #14 "Super Sheep to the Rescue" by destroying the target crate. The same could be done in this mission and two others by hitting Alt-F4.
• In Mission #26 "Mad Cows", one of the CPU worms was placed randomly due to a mistake in its script. The mistake is now ignored.
• If the drop-down list of files was opened from within the Map Editor, but there were no files in User\SavedLevels, it would become impossible to dismiss the drop-down list without killing the "WA.exe" process. Now, the list will not appear unless there is something to occupy it.
• In v3.6.20.2, it was acknowledged that there are some "nonstandard" weapon power levels which have stable meanings, identical in all W:A versions. These tweaked power levels were given "standardised" status from v3.6.20.2 onward. However, the levels above them had unstable meanings depending on the exact "WA.exe" being used, because they overlapped with random junk in memory; if a scheme exceeded these thresholds, players using different W:A versions could desync, and replay playback could desync as well. For this reason, a warning message was shown when such "overtweaked", deprecated schemes were loaded. However, at least one scheme-maker ignored this warning when making a "board game" scheme.
  • From v3.6.26.4 onward, the overtweaked power levels are standardised. They will all cause a weapon to have "zero power" — no explosive power at all.
  • The random junk from v3.6.22.1, v3.6.24.2 and v3.6.25.1a is emulated. Some of it also corresponded to zero power, but some of it did not.
  • The warning message is still shown when loading an overtweaked scheme online, because it cannot be predicted whether a player will join using an old version without its random junk emulated.
• It was possible for a Mission Attempts counter to overflow past 127 into negative numbers. If a mission was started with "negative" attempts, some objects such as crates would not appear, in some cases causing the mission to be subsequently unwinninable unless the counter was forced to increment up from -128 to zero.
• If, at the Next Round stage of an online game, the host loaded a map that was not supported by a certain player (due to that player running an old version of W:A), the player's name was not crosshatched in red to signal the incompatibility, and the game was allowed to start even though upon starting that player would have desynced. This is now fixed.
• The magenta team colour was refered to in some places as "purple". All occurences (for example the "/purple" allied chat command, and the player list in exported logs) have now been replaced with "magenta", because it describes the colour more accurately.
• Flaws in Emulation
  • There may be situations involving Worms and/or Animals moving and overlapping with other objects, during which a desync could have happened when emulating a version earlier than v3.6.19.16.
  • While an object was still sinking in the water (for example, a mine-knocked or rope-knocked worm, or a drowned Super Sheep), using a weapon or utility, or in certain situations losing control of your Worm or triggering a mine, would cause a desync when emulating a version earlier than v3.6.22.0.
  • These desyncs can still happen in a online game connecting a combination W:A versions in both of the following ranges:
    • Earlier than the threshold version
    • The threshold version or later, but earlier than v3.6.26.4
• Fixes affecting game logic
  • In a scheme with infinite turn time, collecting a Double Time utility crate would cause the turn time indicator to be glitched for the remainder of the turn.
  • In a cavern map with no detected available positions for Worm autoplacement, the attempt at autoplacement would fall into an infinite loop, audible as a string of beeps. However, the game would actually crash after a number of repetitions, due to the memory leak described above. This could happen after starting a game with an empty (or nearly 100% full) colour map with Placement Holes disabled, if the timer was allowed to expire on the forced manual placement or a CPU team was present. The game now automatically drowns the Worm in this case, which is what was intended. (See Footnote 2.)
  • The random crate drop algorithm avoids dropping crates near other objects (worms, mines, oil drums and other crates). For v3.5 Beta 1, the algorithm was rewritten (to fix a bug) with the intention of preserving the same logic for judging proximity. Despite this, it changed; in v3.0, the exclusion area around an object was a diamond with a radius of 64 pixels, but in v3.5 Beta 1 it became a square encompassing the diamond. This means that the new algorithm was twice as strict about placing crates diagonally close to objects. It is now back to how v3.0 was in terms of avoiding proximity to objects.
  • It was possible for a crate to fall on top of a frozen worm, or very close to one. If this happened immediately before the frozen worm's team got its turn, then the crate would be instantly collected. (The fix reported in v3.6.23.2 was ineffective.)
  • If a Worm dismounted a horizontally-stationary Ninja Rope in direct contact with the ground (see Footnote 1), then jumped and attempted to fire the Rope during that jump, it would refuse to fire.
  • The Scales of Justice included dead allies (team colour groups with no remaining worms) when dividing the total worm health by the number of allies to calculate an average. For example, if out of 5 players, 2 had died off, Scales would multiply the total health by 3/5. Another result of this bug was that if at least one ally had died off, and the remaining ones each had one worm with 1 health point, Scales of Justice would kill every worm, drawing the game.
  • The small horizontal girder had two stray dark pixels on its right edge. This could cause a grenade to bounce oddly.
  • Changes affecting sound/speech (strictly speaking these changes don't affect the game logic, but they are tied to the logic version so that all players will hear the same thing)
    • Since v3.6.23.0, when a Worm found itself near a fused weapon about to explode, it would include "Grenade" in its choice of random things to say from its team's speech bank. The problem is that not all fused weapons are grenades, and "Grenade" in some speech banks explicitly includes the word "grenade". So now, a Worm will never say "Grenade" if the weapon does not look like a Grenade or a Holy Hand Grenade.

Features

• The language used for front end and in-game text can now be chosen manually from the Options menu.
• The German translations have been improved and corrected by bonz.
• This version of W:A can now emulate and interoperate with W:A v3.0. It is possible for an online game to have mixture of v3.0 and v3.6.26.1+ users, and it doesn't matter who is hosting.
  • Players using v3.0 will have their names crosshatched in black in the player list. If there is doubt over whether they are using v3.0 or v3.5 Beta 1, their names will be crosshatched in orange, but they will still be assumed to be using v3.0.
  • Terrain Textures
    • W:A v3.0 applied terrain textures differently, resulting in more vertical thinning of the landscape (especially with the Desert and Jungle textures). This must be emulated for v3.0 compatibility. However, since this is an integral property of the map, it is attached to the map data now rather than being automatically matched to the game version being emulated. To toggle v3.0 style terrain texture thinning, hold Ctrl while clicking the Terrain Texture button in the Map Editor; it is helpful to do this while in Preview mode. The texture thinning property is saved along with the map.
    • 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 will be treated as if it had been designed for W:A v3.0.
      • This can be toggled by Ctrl-clicking the Terrain Texture button. When enabled, the map will be rendered exactly as it would have been with W:A v3.0 (or would be with Worms World Party).
      • Enabling this is useful for old Battle Race maps that exhibit blocked passageways when the newer texturing algorithm is applied (which could happen if the map was created for W:A v3.0 and the mapmaker always converted it to Hospital or Manhattan terrain before testing).
      • The old texturing algorithm looks inferior, so if you know it is not needed (i.e. if the map is not a Battle Race or if you have tested it beforehand) you can safely toggle it off.
    • W:A v3.0 had a doubled "Tribal" texture, which was removed in v3.5 Beta 1. As a result of this, the terrain texture index needs to be translated if it is "Tribal" or "Urban", and this is now automatically done in an online host/join session.
  • The main reason for which I implemented W:A v3.0 emulation was to make it possible to play back a WAgame extracted from a network log of an online game played many years ago, before the Beta patch existed. It is now possible to do this, but the feature is not included in the release version of W:A. I would like to know if anyone besides me has kept network logs of their pre-v3.6 games; if you have, perhaps this feature would be useful to you. See the Team17 Forum link near the end of this Readme.
• WAgame files recorded online now include the character @ in front of the name of the player who recorded the game.
• The Tools terrain texture is now accessable through the Map Editor. All players must be using v3.6.26.1+ to be able to play on a map with this texture.
• More error reporting is done while playing back recorded games or extracting logs (before, only checksums errors were reported)
  • The turn-end markers that were added in v3.6.19.15 are checked for proper timing.
• The logic is now more intuitive for handling keys that can either be game control keys or chat editing keys when the chat box is open.
  • Previously, it worked like this: If you had Scroll Lock on or it was someone else's turn, the arrows keys would act as chat editing keys. If Scroll Lock was off and it was your turn, the arrow keys would close the chat box and act as game control keys (e.g. to move your Worm).
  • Now, it works like this: If you have typed anything into the chat bar, the arrow keys will act as chat editing keys. Otherwise, they will act as game control keys (even if it not your turn, they will close the chat box, for consistency).
• With the Scroll Lock key freed from its unintuitive function, it has been assigned to a different task: locking the viewport/camera from being scrolled by anything other than manual mouse movement. (Caps Lock had been assigned to this function in v3.6.21.1, but this was inconvenient because it could result in unintentionally typing all-caps text after watching a replay.) Scroll Lock functions as a camera override at all times except when it is your turn, because locking the camera in some cases could be considered cheating, and could also cause confusion if left on by mistake. (Holding the left mouse button also functions as a camera override, as it has since v3.6.19.17.)
• During replays, a retreat counter is shown in red, with hundredths-of-a-second precision.
• Export Log additions
  • The name and number of a Mission attempt is now detected and printed at the beginning of the log. At the end it is noted whether the attempt was a success or a failure. Note that W:A does not yet detect whether the Mission is genuine; if the person who played it edited the .WAM file, it will still be identified according to the terrain it uses.
  • Bungee use is now noted. (Previously, "fires Bungee" would only be reported when an attempt was made to fire it like a normal weapon.)
• The telephone icon (which shows up in-game when another player chats while the chat panel is retracted on your end) can now be disabled. This option can be controlled by executing the registry script Phone_Disable.reg or Phone_Enable.reg.
• In game, the hotkey Alt-Delete now toggles transparency for labels. Since the palette is shared with the current map, some maps will allow the transparency effect to look good with labels of various colours. If there are many labels displayed at once, the visual refresh rate may slow down with transparency enabled. This setting always defaults to being off at the start of a game; it is not remembered between sessions.
• The precise fuse display (introduced in v3.6.20.1) is now disabled at the minimum Info display level (pressing Delete cycles through Info levels).