Difference between revisions of "Worms Armageddon ReadMe (English)/v3.6.26.4 Beta Update"

From Worms Knowledge Base

Jump to: navigation, search
m
m
Line 6: Line 6:
 
| style="font-size: 90%;" |
 
| style="font-size: 90%;" |
  
<!-- INSERT FIXES HERE -->
+
* 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.
 +
 
  
 
|}
 
|}

Revision as of 15:46, 26 June 2008

Personal tools