There is a bug since 312 which behaves like this...
If the fight and resolution happens during the same MHQ session (almost always)
If the unit is a BattleMech
If any location needs to be replaced and even though all viewable items are salvaged.
You will need to save and reload in order to replace the destroyed location.
It counts for Hip/Shoulder as well as just plain destroyed.
An Engine will appear in the location but doesn't need to be salvaged. You just need to reload.
Last edit: scjazz 2015-05-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I updated all three programs with the latest dev releases last weekend and now I have this bug as well. I think my mekhq was version 3.6 which worked fine and automatically listed parts to salvage before replacing a location while the mech was still listed as "repair" status. Now 3.13 you have to save and reload.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I have been able to load the file and see the problem. I believe this is the same underlying problem as bug [#875] and may be related to bug [#854]. The engine is not showing up as destroyed but in the actual file that unit has a MissingEnginePart associated with it. The engine should be destroyed on loading due to the MissingEnginePart but instead or at least it should have 3 hits due to what is showing in the MUL file.
There is also the issue of the blown-off limb preventing replacement. That is separate but also should be fixed.
Ok, I have been able to track down the specific problem here. MekGyro.updateConditionFromPart was mistakenly repairing the engine before applying gyro hits. That probably goes a long way to explaining the various engine shenanigans users have noted.
However, trying to fix this brought up a bigger issue. The reason that code was there was as a clumsy way to handle the problem of assigning too many hits to a system because the existing hits are not taken into account. There is no such code like this on most parts however which is probably why engines with a few hits are accumulating more hits with each successive save/load, ala Bug [#854]. So, I am going to try to fix this problem before closing this bug. It should be as simple as collecting the number of existing hits to the system and then only adding more if that number is short of the required amount, however my first attempt at this on MekGyro was not successful. Investigating further.
Ok, this has now been fixed for the next release. I ended up changing the Unit.damageSystem to keep track of existing hits before applying new ones. The changes to the code were pretty significant so we may want to keep an eye on this to make sure I didn't create more issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Savegame
Wrong log from original, correct one attached.
Also, it lists a DHS for salvage, but it has no listed location.
There is a bug since 312 which behaves like this...
If the fight and resolution happens during the same MHQ session (almost always)
If the unit is a BattleMech
If any location needs to be replaced and even though all viewable items are salvaged.
You will need to save and reload in order to replace the destroyed location.
It counts for Hip/Shoulder as well as just plain destroyed.
An Engine will appear in the location but doesn't need to be salvaged. You just need to reload.
Last edit: scjazz 2015-05-04
Could this possibly be related to the bug involving extra engine hits showing up?
I updated all three programs with the latest dev releases last weekend and now I have this bug as well. I think my mekhq was version 3.6 which worked fine and automatically listed parts to salvage before replacing a location while the mech was still listed as "repair" status. Now 3.13 you have to save and reload.
OK, I have been able to load the file and see the problem. I believe this is the same underlying problem as bug [#875] and may be related to bug [#854]. The engine is not showing up as destroyed but in the actual file that unit has a MissingEnginePart associated with it. The engine should be destroyed on loading due to the MissingEnginePart but instead or at least it should have 3 hits due to what is showing in the MUL file.
There is also the issue of the blown-off limb preventing replacement. That is separate but also should be fixed.
Related
Bugs:
#854Bugs:
#875Last edit: Taharqa 2015-08-01
Ok, I have been able to track down the specific problem here. MekGyro.updateConditionFromPart was mistakenly repairing the engine before applying gyro hits. That probably goes a long way to explaining the various engine shenanigans users have noted.
However, trying to fix this brought up a bigger issue. The reason that code was there was as a clumsy way to handle the problem of assigning too many hits to a system because the existing hits are not taken into account. There is no such code like this on most parts however which is probably why engines with a few hits are accumulating more hits with each successive save/load, ala Bug [#854]. So, I am going to try to fix this problem before closing this bug. It should be as simple as collecting the number of existing hits to the system and then only adding more if that number is short of the required amount, however my first attempt at this on MekGyro was not successful. Investigating further.
Related
Bugs:
#854Last edit: Taharqa 2015-08-01
Ok, this has now been fixed for the next release. I ended up changing the Unit.damageSystem to keep track of existing hits before applying new ones. The changes to the code were pretty significant so we may want to keep an eye on this to make sure I didn't create more issues.