Differences

This shows you the differences between two versions of the page.

--- en:games:star_trek_armada_1:de-sync_and_crash_test [2024-02-24-15-01] – [Using Transwarp Gate (Semi-Confirmed)] 7saturn
+++ en:games:star_trek_armada_1:de-sync_and_crash_test [2024-03-03-09-25] (current) – [IPX Server] 7saturn
@@ Line 9: / Line 9: @@
 Over time these discrepancies can amount to vastly different game states, up to the point where one player may already finish the match by destroying all opposing units and stations, while for another the game continues very much, as there are still units or stations left. This is also the reason why the game advices to stop the match. There is actually little point in continuing, as all players are potentially already in essentially their own single-player games.
 ==== Suspected Causes of De-Syncs ====
-Over time people suspected a number of reasons why a game may go de-sync. Most of the are basically only anecdotal in nature:
+Over time people suspected a number of reasons why a game may go de-sync. Most of them are basically only anecdotal in nature:
-  * De-constructing ships in yards: It could be observed, even when playing the same match via LAN, so being able to observe both game states live, next to one another, that sometimes the deconstruction of a ship does not take place at all sites. This of course is an obvious difference in game states, when one unit (or more) still exist(s) on game state A, while being gone in game state B. The implication also follows, that the resources returned by de-construction, can then be used to build other units. As the amount of resources is not available in every game state, units may in turn appear, that could not have appeared in other game states, for a lack of resources to produce them.
+  * De-constructing ships in yards: It could be observed while playing via LAN (being able to observe both game states live, next to one another), that sometimes the deconstruction of a ship does not take place at all sites. This of course is an obvious difference in game states, when one unit (or more) still exist(s) on game state A, while being gone in game state B. The implication also follows, that the resources returned by de-construction, can then be used to build other units. As the amount of resources is not available in every game state, units may in turn appear, that could not have appeared in other game states, for a lack of resources to produce them.
   * Using [[Transwarp Drive]]: It was reported, that making heavy use of Transwarp Drive may also produce de-syncs. These reports could not be reproduced yet (see [[#Test_Results_De-Sync|Test Results De-Sync]]). But they may very well be the root cause for de-syncs, if there are some irregularities how the game places transferred units. If there is enough discrepancy in that, it may very well make units go different paths on the map or come in contact with units in one game state, whereas this does not happen in another.
   * Using super weapons: This one could not be confirmed, yet. While there is strong evidence, that using the [[Transwarp Gate]] in games with AI players causes [[#Crashes]], de-syncs are not a problem of any of the available super weapons.
@@ Line 16: / Line 16: @@
 ==== Test Results De-Sync ====
 This one has so far only one systematic test to show for, regarding the Transwarp Drive.
-=== De-Syncs by Transwarp Drive ==
+=== De-Syncs by Transwarp Drive ===
-Even when transferring 8 groups of 8 [[Interceptor|Interceptors]] at once, the game went on stably. Also re-doing that over and over did not cause problems in a test match with player //Defiant//.
+Even when transferring 8 groups of 8 [[Interceptor|Interceptors]] one directly after another, the game went on stably. Also re-doing that over and over did not cause problems in a test match with player //Defiant//.
+Also in other matches when making not as excessive use of them, the matches went on just fine.
+== Recommendation ==
+This definitely needs further testing involving other players, that have reported the problem (notably //Michael//). Maybe the actual root cause is something differently, e.g. slightly altered games, or different OS being used.
 === De-Syncs by Deconstruction ===
 This one has not been tested systematically, but was observed at least once, after de-constructing a [[Diamond]] class ship. In one game state the unit still sat at the last location prior to de-construction while in another it was properly deconstructed (at the site of the player controlling the unit it persisted).
 == Suspicions Deconstruction De-Sync ==
   * The order just got lost via network.
   * This may also only occur in subsequent matches. Meaning, in the first match everything works just fine, while in later matches, that are conducted without having restarted the game, the problem may occur. This definitely needs further testing and observations
+== Recommendations Regarding De-Construction ==
+As this is an integral part of the game (just imagine Borg being forced to not de-construct captured ships), **further testing is urgently needed**. Not using de-construction is kind of a no-option. But having at least an idea if the problem is real and/or can be avoided would be valuable.
 ===== Crashes =====
 The game is known to crash for certain causes, that can occur random, but can also kind of be provoked. So there is a systematic component behind them. These crashes happen without an advanced warning or an error message. The game just suddenly shuts down, bringing the player back to their desktop.
 ==== Suspected Causes of Crashes ====
 Here are some observations, of things probably or certainly causing crashes of the game:
-  * <key>ALT</key> + <key>TAB</key>: One thing that very certainly causes Crashes, but not and every instance is switching to another application with this short cut. Sometimes it goes well, sometimes when trying to re-enter the game, it just crashes. Side-Note: While in the menus (e.g. setting up a match) using the short cut is very well known to also cause buttons to be blacked out. Meaning, the button exists very much, but is not shown any more, until the mouse pointer enters its surface.
+  * <key>ALT</key> + <key>TAB</key>: One thing that very certainly causes Crashes, but not in every instance, is switching to another application with this short cut. Sometimes it goes well, sometimes when trying to re-enter the game, it just crashes. Side-Note: While in the menus (e.g. setting up a match) using the short cut is very well known to also cause buttons to be blacked out. Meaning, the button exists very much, but is not shown any more, until the mouse pointer enters its surface.
   * Using [[Transwarp Gate]]: This one is a little bit peculiar, as it does not happen right away and not always. Once a player uses the TWG, the game still continues. But at some point it just crashes. This may also happen at the very moment a TWG is used, but it is not a necessity.
+  * Using a lot of [[Ultritium Burst]] cast at the same time (e.g. an entire 8 Diamond squad) is reported to cause crashes, but not always.
+  * [[Self-Destruct]] used after getting affected by [[Holo-Emitter]] is said to cause crashes (source is player //Nic4747//). At the moment the evidence does not support that, but there is a smaller chance that this is real.
+  * Issuing alert status changes after getting affected by [[Holo-Emitter]] is said to cause crashes (source is player //Nic4747//). At the moment the evidence does not support that, but there is a smaller chance that this is real.
+  * Changing the alert level while being affected by Holo-Emitter is also said to cause crashes (source is player //Nic4747//). This definitely requires some testing as changing alert level after being hit by Holo Emitter is actually a standard move, if the player still controls the affected units.
 ==== Test Results Crashes ====
 === ALT + TAB (Confirmed) ===
@@ Line 36: / Line 45: @@
 Do not use <key>ALT</key> + <key>TAB</key> during a running match, regardless whether it is an //Instand Action// Match or an actual [[en:gaming_theory:multi-player]] match. And even when still in the menu, crashes can happen and it is a well known phenomenon that menu visibility gets messed up when tabbing back into the game.
 === Using Transwarp Gate (Semi-Confirmed) ===
-== Known Facs ==
+== Known Facts TWG ==
-The [[Transwarp Gate]] is a bit of a mystery as of yet. When using it in multi-player games without an AI even after some 10 - 20 uses, the game went on stably until the end. A test match with player //Defiant// on map //klnghell.bzw// (//Kling Hell by rih'goha//) clearly showed that. After clearing out all team 0 units, TWG was used, many times, including other super weapons, such as the [[Phoenix]].
+The [[Transwarp Gate]] is a bit of a mystery as of yet. When using it in multi-player games without an AI even after some 10 - 20 uses, the game went on stably until the end. A test match with player //Defiant// on map //klnghell.bzn// (//Kling Hell by rih'goha//) clearly showed that. After clearing out all team 0 units, TWG was used, many times, including other super weapons, such as the [[Phoenix]].
 But when using it in conjunction with the AI, regardless of being an //Instant Action// match, or an actual multi-player match, the game will crash, even after using the TWG only once. It may take a while, e.g. some 15 minutes, but eventually it will happen. This also means, if the match finishes very shortly after issuing TWG, you may not be hit by a crash. But when making heavy use of it or having a long match, probability is very high, the game will crash.
@@ Line 43: / Line 52: @@
 Obviously somehow the AI seems to be involved. Also it is very peculiar, that the AI never uses the TWG itself, even when having it built. Suspicion: The AI tries to use TWG points, that are no longer open. Technically the TWG points are very similar to worm holes, that are rather static in nature. In multi-player they do not suddenly occur or vanish. But a TWG point lasts not very long. If by any chance the AI does not remove TWG points from its known map objects, then it stands to reason it tries using them, long after they got removed, which may very well lead to crashes.
 == Recommendation TWG ==
-Do not use it, at least not when having AI players participate in the match.
+  * Do not use it, at least not when having AI players participate in the match.
+  * Further test matches on the map //klnghell.bzn// with AI players would be interesting. Maybe the problem is actually tied to maps, not whether the AI is present. Maybe it is the AI, so having it present on the map would be a benchmark.
+=== Using Self-Destruct While Under the Influence of Holo-Emitter (Still Investigated) ===
+== Known Facts SD+HE ==
+A test was conducted on map //2duel.bzn// (//On The Ready Line//), eight [[Negh'Var]] ships were destroyed one by one, by using [[Self-Destruct]]. While the Self-Destruct was already under way, [[Holo-Emitter]] was cast by an opposing ship, leaving the Negh'Vars affected by and destroyed while so. The result was uneventful each time. The Self-Destruct took its normal course of action.
+Another seemingly successful attempt was made by player //nic4747//, as shown in this video: https://www.twitch.tv/videos/2079696018 But this time it was [[Shadow]] vs. [[Cube]] and the Holo-Emitter was issued twice after issuing Self-Destruct.
+**Important notice**: Self-Destruct could not be cast, while already under the influence of Holo-Emitter. So in a normal match, the order can only be like casting Self-Destruct and then being affected by Holo-Emitter. This leaves an interesting edge case that could be a race condition: If the Self-Destruct is issued at the same time while Holo-Emitter is cast, the player using Holo-Emitter might get the information a tad to late, so that from their perspective they issue Holo-Emitter and the opponent still casts Self-Destruct. Maybe this is the cause for the reports of that problem. But this would imply, that this is a rather rare event, as hitting this exact time frame, while casting Self-Desctruct may be a problem, is highly unlikely.
+== Recommendation Self-Destruct While Affected by Holo-Emitter ==
+At this time, no recommendation can be given, except that maybe further testing is required. Test-Suggestion: A clean match, Shadow vs. Cube and the Holo-Emitter gets issued at least twice after issuing Self-Destruct on the Cubes.
+=== Changing Alert Status While Under the Influence of Holo-Emitter (Still Investigated) ===
+== Known Facts AS+HE ==
+A test was conducted on map //2duel.bzn// (//On The Ready Line//), two different [[Negh'Var]] ships were used to change the alert status (into random directions, simply pressing the buttons in a random order) while [[Holo-Emitter]] was already affecting them. The result was uneventful each time. The alert status was simply changed and the match went on.
+== Recommendation Alert Status Change While Affected by Holo-Emitter ==
+At this time, no recommendation can be give, except that maybe further testing is required.
 === Using Other Super Weapons (Rebutted) ===
 == Known Facts Super Weapons ==
@@ Line 54: / Line 79: @@
   - The [[en:gaming_platforms:world_opponent_network|WON]], which got shut down, so is not usable any longer.
   - TCP, which only works on the same network, making [[en:network_terms:VPN]] use mandatory for matches via the internet.
-  - IPX, similar to TCP but not available natively from Windows Vista on. See [[setting_up_matches#Using Ipx|]].
+  - IPX, similar to TCP but not available natively from Windows Vista on. See [[setting_up_matches#Using IPX]].
 There are currently efforts made to determine how reliable the IPX-via-UDP wrapping method in conjunction with [[https://github.com/solemnwarning/ipxwrapper|Daniel Collins']] wrapper and [[https://github.com/steveschnepp/ipxserver|A Perl RFC 1234 IPX server]] is.