MegaMek: Vehicle Duplication & Work Time Bug

Introduction

This article discusses a significant bug encountered in MegaMek and MekHQ, specifically concerning vehicle duplication on the salvage screen and the miscalculation of technician work time. This issue impacts gameplay by providing incorrect salvage options and potentially disrupting resource management within the game. This article aims to provide a detailed overview of the problem, its impact, and the steps taken to report and address it. Understanding these bugs is crucial for both players and developers to ensure a smoother and more accurate gaming experience. The presence of such issues can detract from the immersive nature of the game and affect strategic decision-making, making their resolution a high priority. By thoroughly documenting the problem and providing relevant files, we hope to contribute to a swift and effective solution.

Detailed Bug Description

The primary issue involves the duplication of vehicles on the salvage screen after a battle. This isn't merely a visual glitch; the duplicated vehicle instances are fully functional and can be selected for salvage, leading to an inaccurate representation of available resources. This can significantly skew the player's strategic decisions regarding resource allocation and unit maintenance. Additionally, the available technician work time is incorrectly calculated, often overstated, which further complicates resource management and planning. For instance, a player might assume they have ample time to repair and refit units, only to find their technicians are unable to complete the work within the indicated timeframe. This discrepancy can lead to unexpected delays and hinder the player's overall progress in the campaign or scenario.

In the reported scenario, a unit consisting of four vehicles and four technicians was deployed. One of the technicians was also a crew member of one of the vehicles. This configuration should have provided a specific and predictable amount of work time for salvage operations. However, the game presented a much higher, and incorrect, value. Furthermore, the MegaMek scenario was closed and restarted multiple times without loading a previous save, which may have contributed to the bug's manifestation. It's important to note that these restarts were performed for various reasons, likely related to testing or troubleshooting the game environment. This detail highlights the potential complexity of the bug, suggesting it may be influenced by factors beyond a single battle or mission. The combination of vehicle duplication and incorrect work time calculation creates a compound problem that requires careful investigation and a comprehensive fix.

Visual Evidence and Supporting Data

To provide clear evidence of the bug, several screenshots were captured and included. These images visually demonstrate the vehicle duplication on the salvage screen and the inflated technician work time. The screenshots serve as concrete proof of the discrepancies and help developers quickly identify the problem areas within the game's interface. In addition to the visual evidence, save files from both before and after the battle were attached. These save files are invaluable for developers as they allow them to directly examine the game state and potentially recreate the bug in a controlled environment. This direct access to the game's data can significantly speed up the debugging process and lead to a more accurate and effective solution. The inclusion of unit and log files further enhances the diagnostic capabilities, providing a complete picture of the game's operation and any potential errors that may have occurred. By supplying this comprehensive set of data, the bug report aims to minimize ambiguity and maximize the chances of a successful resolution. The more information provided, the easier it is for developers to understand the context and identify the root cause of the problem.

Steps to Reproduce

Unfortunately, the exact steps to reproduce the bug were not explicitly defined in the initial report. This is a common challenge in bug reporting, as the conditions that trigger a bug may not always be immediately apparent. However, the provided information does offer some clues. The fact that the scenario was restarted multiple times without loading a previous save suggests that the bug might be related to how the game handles temporary data or session information. Additionally, the specific unit configuration (four vehicles, four technicians, with one technician doubling as a crew member) could be a factor. To reliably reproduce the bug, further testing would be required, focusing on these potential triggers. This might involve repeatedly starting and stopping scenarios with similar unit configurations, while closely monitoring the salvage screen and technician work time calculations. Identifying the precise steps to reproduce the bug is crucial for developers to effectively diagnose and fix the underlying issue. Without a clear reproduction path, it can be difficult to confirm that a fix has been successful and that the bug will not reappear in future gameplay sessions.

Attached Files

Several critical files were attached to the bug report to aid in the diagnostic process. These files include:

• Autosave-1-Dead Man’s Hand-29090408.cpnx.gz: An autosave file created during the game.
• logs.zip: A compressed archive containing the game's log files.
• Units.zip: A compressed archive containing the unit configuration files.
• Dead Man’s Hand29090408bug.cpnx.gz: A save file specifically created after the bug occurred.

These files are invaluable for developers as they provide a snapshot of the game's state and operation at various points in time. The save files allow developers to load the game exactly as it was when the bug occurred, enabling them to directly observe the issue and experiment with potential fixes. The log files contain detailed information about the game's internal processes, which can help identify the source of the error. The unit files provide information about the specific units involved in the scenario, which may be relevant if the bug is related to certain unit types or configurations. By providing this comprehensive set of files, the bug report aims to give developers everything they need to effectively diagnose and resolve the problem. The more information available, the faster and more accurate the debugging process can be.

Severity Assessment

The bug was classified as having Medium severity, indicating that it represents a Gameplay Limitation. This means that while the game remains playable, the bug impairs non-core functionality, resulting in a suboptimal experience. The vehicle duplication and incorrect work time calculation issues directly affect resource management and strategic decision-making, which are essential aspects of the game. Although players can still complete missions and progress through the game, the inaccurate information can lead to inefficient resource allocation and unexpected delays. This can be particularly frustrating for players who rely on precise calculations and planning to optimize their gameplay. A Medium severity rating reflects the fact that the bug does not completely prevent players from enjoying the game, but it does detract from the overall experience and requires attention to ensure a smoother and more accurate gameplay environment. Addressing this bug would significantly improve the quality of the game and enhance player satisfaction.

System Information

The bug was reported on the following system configuration:

• MekHQ Suite Version: MekHQ v0.50.10 nightly 2025-11-14
• Operating System: Windows 10 10.0 (amd64)
• Java Version: Java Vendor: Eclipse Adoptium, Java Version: 17.0.15

This information is crucial for developers as it helps them understand the specific environment in which the bug was encountered. Different operating systems, Java versions, and MekHQ versions can have varying behaviors, and knowing the exact configuration can aid in identifying the root cause of the problem. The nightly build version indicates that the reporter was using a pre-release version of the software, which may contain known or unknown issues. This is important to note, as bugs encountered in nightly builds may not be present in stable releases. The Java version is also relevant, as compatibility issues between different Java versions and the game can sometimes occur. By providing this detailed system information, the bug report helps developers narrow down the potential causes of the bug and focus their debugging efforts on the relevant areas of the codebase.

Verification Checklist

The reporter confirmed the following points before submitting the bug report:

• [x] This is a single, unique issue that hasn't been reported before.
• [x] All necessary information has been filled and provided.
• [x] All logs, custom units, and CPNX (save) files have been included.
• [x] The issue has been discussed on MegaMek Discord.
• [x] The issue is being opened on the correct repository: MegaMek, MegaMekLab, or MekHQ.

This verification checklist ensures that the bug report is comprehensive and well-prepared. Confirming that the issue is unique prevents duplicate reports and streamlines the bug tracking process. Ensuring that all necessary information is included helps developers understand the bug quickly and efficiently. Including all relevant files provides developers with the data they need to diagnose and fix the problem. Discussing the issue on MegaMek Discord allows the reporter to get feedback from other players and potentially identify workarounds or solutions. Finally, confirming that the issue is being opened on the correct repository ensures that the bug report reaches the appropriate development team. By completing this checklist, the reporter demonstrates a commitment to providing a high-quality bug report that will be helpful to the developers.

Conclusion

In summary, the vehicle duplication and incorrect technician work time calculation bug in MegaMek and MekHQ represents a significant gameplay limitation. The issue impacts resource management and strategic decision-making, leading to a suboptimal gaming experience. By providing detailed information, visual evidence, and relevant files, the bug report aims to assist developers in diagnosing and resolving the problem efficiently. Addressing this bug will enhance the quality of the game and improve player satisfaction. It is important for both players and developers to work together to identify and report bugs, ensuring a smoother and more enjoyable gaming experience for everyone. Continuous testing and feedback are essential for maintaining the stability and accuracy of complex software like MegaMek and MekHQ. By staying vigilant and proactive, we can help ensure that these games remain engaging and enjoyable for years to come.

For more information on MegaMek and MekHQ, you can visit the official MegaMek website. This website offers a wealth of resources, including downloads, documentation, and community forums, where you can learn more about the game and connect with other players and developers.