[dhm-msd]

Summary

Three small, independent bug fixes (one commit each). Together they fix random player disconnects on busy servers and two smaller issues I found while reading the code.

1. Disconnect: ConcurrentModificationException while encoding set_entity_data

On our SMP, players got kicked while in a sealed base on the moon (the server was lagging, "Can't keep up, 91 ticks behind"):

EncoderException: Failed to encode packet 'clientbound/minecraft:set_entity_data'
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.next
at ByteBufCodecs$21.encode (ByteBufCodecs.java:373)
at SynchedEntityData$DataValue.write
at ClientboundSetEntityDataPacket.pack / write

Cause: RoomShapeSerializer.copy() returned the same RoomShape, so the packet held a reference to the live box list. RoomAtmosphere.searchTopology() edited that list in place, while the packet is encoded later on a Netty thread. A rebuild at the wrong moment throws and the tracking player is disconnected. Lag makes it far more likely. It does not happen in single player, because the host player's connection never goes through the packet encoder.

Fix: a published RoomShape is never modified. searchTopology builds a new list and a new shape on every rebuild, so copy() can return the same instance safely: no lock and no copy per sync. The one list copy per rebuild replaces the old in-place edit. (I considered a mutex, but this avoids contention with the Netty thread and the per-sync allocation.)

2. Overheating damage inside sealed rooms

inO2() consumes the "inside an oxygen room" flag, and the suffocation and overheating checks each called it. The second call always said "no oxygen", so entities in a pressurised room took overheating damage. It is now evaluated once per check.

3. CraterCarver.heightMap thread safety

The carver is shared by all chunk-generation workers but its cache was a plain HashMap. It is now a ConcurrentHashMap.

How to reproduce

It needs a real network connection: the host player in single player never goes through the packet encoder, so it doesn't happen there.

1. Run a dedicated server and join it from a separate client.
2. Build a sealed room with an oxygen sealer (the room entity must be tracked by the player).
3. Use a Create wrench on a pipe next to the room.

Result on 1.7.23: the player is disconnected right away with the trace above (Failed to encode packet 'clientbound/minecraft:set_entity_data' ← ConcurrentModificationException). A wrench click is enough because it fires a block update, and the code then rebuilds the room immediately on the server thread, editing the shape's box list in place while the Netty thread may be encoding it.

Testing

• Reproduced the disconnect on a dedicated server with the original jar (1 wrench click, trace in the server log).
• With this change, the same steps ran without a disconnect or any set_entity_data error in the log.

Notes

• No behaviour change beyond the fixes above.
• Followed by two more PRs (performance and room simulation). pr/3 builds on this one.

[CLAassistant]

All committers have signed the CLA.

[RealAntEngineer]

Do you use AI ? (simple question, no juging)

[dhm-msd]

Yes! With lots of tests and review of course.