What went wrong
Any save game written before Player's six numMf* minefield counters became the minefieldCounts array fails to load, and the failure looks like a network fault rather than a load failure.
Player.minefieldCounts takes its default from a field initialiser:
private int[] minefieldCounts = new int[Minefield.TYPE_SIZE];
XStream builds the object without running field initialisers, so a save with no <minefieldCounts> element leaves the field null. The first thing the server does after loading is copy each player for the connect packet, and Player.copy dereferences it:
copy.minefieldCounts = Arrays.copyOf(minefieldCounts, Minefield.TYPE_SIZE);
What you expected instead
An older save either loads, with the counters defaulting to zero, or is rejected with a message that says the save is too old. Not a NullPointerException from the connect path.
Steps to reproduce
- Take a save written before the minefield counters were replaced by the array.
- Load it on a current build.
- Watch the log as the client connects.
Relevant log lines
ERROR [megamek.server.Server] {Connection 3}
java.lang.NullPointerException: Cannot read the array length because "original" is null
at megamek.common.Player.copy(Player.java:1119)
at megamek.server.Server.redactedCopyFor(Server.java:1217)
at megamek.server.Server.createPlayerConnectPacket(Server.java:1201)
at megamek.server.Server.transmitPlayerConnect(Server.java:1179)
at megamek.server.Server.sendCurrentInfo(Server.java:798)
at megamek.server.Server.receivePlayerName(Server.java:755)
Note that the trace names Server and a connection, with nothing pointing at the loader or at the save. That is what makes this hard to recognise for what it is.
MegaMek Suite Version
0.51.01
Operating System
Windows 11
Java Version
21.0.11
Proposed fix
Give Player a readResolve that fills in anything XStream left null, rather than patching this one field at the point of use. The same trap catches the next field that gets reshaped, and there is no warning when it happens.
A hand-edited save confirms the diagnosis: adding an eight-element <minefieldCounts> block to each player in an affected save is enough to make it load.
Background
Found while editing a reporter's save so it would load for testing #8899. Two other removed fields had to be stripped first, and this one had to be added, before the file would open at all.
The wider question is worth deciding at the same time: whether the save loader should tolerate fields that no longer exist, so that removing a field does not silently break every save that predates the removal.
What went wrong
Any save game written before
Player's sixnumMf*minefield counters became theminefieldCountsarray fails to load, and the failure looks like a network fault rather than a load failure.Player.minefieldCountstakes its default from a field initialiser:XStream builds the object without running field initialisers, so a save with no
<minefieldCounts>element leaves the field null. The first thing the server does after loading is copy each player for the connect packet, andPlayer.copydereferences it:What you expected instead
An older save either loads, with the counters defaulting to zero, or is rejected with a message that says the save is too old. Not a NullPointerException from the connect path.
Steps to reproduce
Relevant log lines
Note that the trace names
Serverand a connection, with nothing pointing at the loader or at the save. That is what makes this hard to recognise for what it is.MegaMek Suite Version
0.51.01
Operating System
Windows 11
Java Version
21.0.11
Proposed fix
Give
PlayerareadResolvethat fills in anything XStream left null, rather than patching this one field at the point of use. The same trap catches the next field that gets reshaped, and there is no warning when it happens.A hand-edited save confirms the diagnosis: adding an eight-element
<minefieldCounts>block to each player in an affected save is enough to make it load.Background
Found while editing a reporter's save so it would load for testing #8899. Two other removed fields had to be stripped first, and this one had to be added, before the file would open at all.
The wider question is worth deciding at the same time: whether the save loader should tolerate fields that no longer exist, so that removing a field does not silently break every save that predates the removal.