[0.50.01-SNAPSHOT] Severe DropShips draw problems on low-alttitude maps.

[Tzahr]

Prerequisites and Pre-Issue Checklist

• I'm reporting the issue to the correct repository:

• MegaMek

• MegaMekLab

• MekHQ

• I've tested the issue against at least the latest MILESTONE version

• I've asked on the MegaMek Discord about the error

• I've reviewed the BattleTech rules and MegaMek documentation, and I've confirmed that something isn't working as intended.

• I've searched the Github tracker and haven't found the issue listed

Severity *

High (Major Disruption): A major feature is broken or incorrect, but a workaround exists.

Brief Description *

When deploying DropShips (aerodyne or spheroid) in low-alttitude maps, the following occurs:

• When deploying an owned DropShip, the deployment zone is restricted as if the DropShip was landed (needs a clear 5-hex 'circle' to deploy), despite DropShips needing only one hex to deploy when flying.
• Hostile DropShips will show their 'landed' graphic at the point where they deployed.
• In subsequent movements, the DropShip graphic and label will remain there, while the actual unit flies are invisibly.
• Should the DropShip turn, the graphic will scramble itself.

This does not occur on space maps.

My suspicion is that this was caused by the recent ability that allows Aerospace and DropShip units to determine alttitude when deploying. The game incorrectly seems to believe these DropShips deploy in a landed state, and then fails to transition them into the correct airborne method.

The log provides the following error:

02:10:30,946 ERROR [megamek.client.ui.Messages] {AWT-EventQueue-0}
megamek.client.ui.Messages.getString(Messages.java:46) - Missing i18n entry: MovementDisplay.moveCallSupport
java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key MovementDisplay.moveCallSupport
at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:567)
at java.base/java.util.ResourceBundle.getObject(ResourceBundle.java:561)
at java.base/java.util.ResourceBundle.getString(ResourceBundle.java:523)
at megamek.client.ui.Messages.getString(Messages.java:44)
at megamek.client.ui.swing.StatusBarPhaseDisplay.createButton(StatusBarPhaseDisplay.java:171)
at megamek.client.ui.swing.MovementDisplay.setButtons(MovementDisplay.java:385)
at megamek.client.ui.swing.MovementDisplay.(MovementDisplay.java:369)
at megamek.client.ui.swing.ClientGUI.initializePanel(ClientGUI.java:1321)
at megamek.client.ui.swing.ClientGUI.switchPanel(ClientGUI.java:1156)
at megamek.client.ui.swing.ClientGUI$1.gamePhaseChange(ClientGUI.java:2218)
at megamek.common.event.GamePhaseChangeEvent.fireEvent(GamePhaseChangeEvent.java:68)
at megamek.common.AbstractGame.fireGameEvent(AbstractGame.java:196)
at megamek.common.Game.processGameEvent(Game.java:750)
at megamek.common.Game.setPhase(Game.java:746)
at megamek.common.IGame.receivePhase(IGame.java:128)
at megamek.client.AbstractClient.changePhase(AbstractClient.java:501)
at megamek.client.Client.changePhase(Client.java:188)
at megamek.client.AbstractClient.handleGameIndependentPacket(AbstractClient.java:470)
at megamek.client.AbstractClient.handlePacket(AbstractClient.java:379)
at megamek.client.AbstractClient$1.lambda$packetReceived$0(AbstractClient.java:552)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Steps to Reproduce

This replicates on any MegaMek low-alttitude map that involves DropShips. They may fail to deploy if the deployment zone is obscured by obstructions (e.g. it cannot find a 5-ex area to deploy as if it was landed).

Operating System *

Windows 11

Java Version *

21.0.3

MegaMek Suite Version *

Free Text (type manually)

Custom MegaMek Version

Nightly v0.50.1-SNAPSHOT - Rev. a53044e

Attach Files

megamek.log

Final Checklist

• I've checked to make sure that this issue has not already been filed
• I'm reporting only one issue in this ticket for clarity and focus

[SJuliez]

Fixed by #6071

[Tzahr]

Still present as of revision: 976204bfa54b995b2d45159b080d13dba8a16ee5

[IllianiCBT]

Unfortunately, this still seems to be present. Reopening.

[SJuliez]

I think this should be fixed now w.r.t. Princess deploying at altitude 0 on atmo maps.