De-Sync and Crash Test

This page is dedicated to keep records of tests revolving around the IPX server use, de-syncs and crashes when playing Star Trek: Armada.

This term stands for desynchronization of game states. These are most likely either problems with communication (tracking game states across all players games via P2P connection) or random occurrences not taken care of properly by the game. The phenomenon shows it self quite plainly by the game static it having discovered discrepancies of the game states of the different peers/players. (And advising to stop the game, as in essence the different players are already playing different matches.)

Most likely the game notices at least one peer giving commands, that cannot have been issued by the peer according to the game state of other peers game states. E.g. a unit that does not exist at player A's match is sent somewhere by player B, indicating that the unit exists in game state B but not in A. This is a clear indication, that something is wrong with the match.

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.

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 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). 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.
• Different OS: This one has not been tested systematically, yet. The suspicion is, that when using Windows 10 and Windows 11 as operating system, matches based on both OS in the player base tend to go de-sync.

This one has so far only one systematic test to show for, regarding the Transwarp Drive.

Even when transferring 8 groups of 8 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.

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.

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

• 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

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.

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.

Here are some observations, of things probably or certainly causing crashes of the game:

• ALT + TAB: 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.

This one is very well confirmed.

Do not use ALT + TAB during a running match, regardless whether it is an Instand Action Match or an actual 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.

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.

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.

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

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.

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.

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.

At this time, no recommendation can be give, except that maybe further testing is required.

While the Transwarp Gate most certainly causes crashes in certain circumstances, the others rather certainly do not. Test matches were conducted with player Capt.Cedaris(V), testing Temporal Stasis Field, Rift Creator and Shockwave. Neither of the three did cause a single crash when used or after, even after some 50 attempts in a single match and even when doing stress-tests by issuing many of them at the same time. The game just went on.

Just use them, except for the Transwarp Gate.

By default the game worked via three multi-player connections:

1. The WON, which got shut down, so is not usable any longer.
2. TCP, which only works on the same network, making VPN use mandatory for matches via the internet.
3. IPX, similar to TCP but not available natively from Windows Vista on. See Using IPX.

There are currently efforts made to determine how reliable the IPX-via-UDP wrapping method in conjunction with Daniel Collins' wrapper and A Perl RFC 1234 IPX server is.

The desired long-term solution would be to convince GOG to run their own IPX server and deliver A1 with the latest version of the Wrapper and default-settings pointing to their server. That way no third-party tools and/or VPNs would be required any longer.

• Multiple 2-4 player matches were played, without any incidences with the unaltered variation of the Perl server.
• At least two matches cross-Atlantic were conducted, with no obvious problems.
• Something could also be observed via LAN already, is the game looking for open matches immediately when using IPX, while when using TCP the game seemingly skips the first attempt at looking for open matches, making them appear only after 40 seconds (the interval the game waits between attempts of finding open games). So essentially IPX allows for a faster discovery for open games.

• Larger matches: At best with some 8 full players, to cause maximum load for the server and peers.
• Multiple running matches in parallel.
• Combination of the two: Having at least two full matches playing out.
• Latency-Variation: Players of different origin, causing different latency times, e.g. a player in EU, one in US, and maybe even one in AU.