For some failed repairs in the Repair Bay, the system shows the repair as impossible, but flags up that a part needs to be purchased.
This affects systems and body locations where the repair has failed and the part is reported as destroyed. the flag "impossible" gets left set, but the part cannot be scrapped
In this case the XML has the Gyro in question listed as:
<part id="57236" type="mekhq.campaign.parts.MissingMekGyro">
<id>57236</id>
<name>Standard Gyro</name>
<unitTonnage>45</unitTonnage>
<hits>0</hits>
<difficulty>0</difficulty>
<time>200</time>
<timeSpent>0</timeSpent>
<mode>3</mode>
<skillMin>5</skillMin>
<unitId>d9673661-51f7-4367-9823-b8980c3dadf0</unitId>
<salvaging>false</salvaging>
<workingOvertime>false</workingOvertime>
<shorthandedMod>0</shorthandedMod>
<refitId>null</refitId>
<daysToArrival>0</daysToArrival>
<brandNew>false</brandNew>
<checkedToday>false</checkedToday>
<type>0</type>
<gyroTonnage>2.0</gyroTonnage>
</part>
the unit shows:
<unit id="user-content-d9673661-51f7-4367-9823-b8980c3dadf0" type="mekhq.campaign.Unit">
<entity chassis="Vindicator" model="VND-3L" type="Biped" commander="false" externalid="d9673661-51f7-4367-9823-b8980c3dadf0">
<location index="1"> Center Torso
<slot index="4" type="System" ishit="true" isrepairable="false" isdestroyed="true">
<slot index="5" type="System" ishit="true" isrepairable="false" isdestroyed="true">
<slot index="6" type="System" ishit="true" isrepairable="false" isdestroyed="true">
<slot index="7" type="System" ishit="true" isrepairable="false" isdestroyed="true">
</slot></slot></slot></slot></location></entity></unit>
The way to resolve this currently is to purchase the part (via acquisitions tab), then scrap the part, delete the transaction from the finance tab, and then got to Purchase Parts to get a part you can actually then install.
Picture attached
I see the problem but not how you got there. Failed repairs should never destroy equipment. Do you mean that a failed replacement did not reset the skill level needed to Green?
Note Bug 3536727 has been submitted for the underlying cause of this. Tis bug remains a separate bounds checking issue on the incorrect result of the other bug,
Bug 3536727 (or [#244]) in the new system has now been fixed so I am closing this one as well.
Related
Bugs:
#244