New custom builds of MegaMek, MegaMekLab, and MekHQ - 2014/07/21

[ralgith]

Log files are pretty much useless in this instance. I need a MM save, MHQ campaign, and any related customs that are all pre-set to this issue.

[mchapman1970]

Log files are pretty much useless in this instance. I need a MM save, MHQ campaign, and any related customs that are all pre-set to this issue.

that file is to big to put on here even zipped

[pheonixstorm]

So mine didn't help at all? Bummer... I am going to try and reproduce with a fresh campaign to give you something with minimal crap to have to deal with. Hope you can figure it out before the next release.

And while I am thinking about bugs.. any progress on the SPA bug?

[ralgith]

So mine didn't help at all? Bummer... I am going to try and reproduce with a fresh campaign to give you something with minimal crap to have to deal with. Hope you can figure it out before the next release.

And while I am thinking about bugs.. any progress on the SPA bug?

Did I miss a set of files from you that uploaded somewhere to reproduce this?

[pheonixstorm]

I managed one log with a few errors that were server/hq related. The ONLY time I saw them out of 2 attempts to auto resolve (selecting no to battlefield control). I had hoped they were related but since you stated the logs were useless, kinda dashed my hopes that it was related :(

[saginatio]

It appears to me to be the same issue that was brought up in the last thread and it seems to be a result of MHQ losing its connection with MM before MHQ can process the results of the battle. It happens with or without AtB and it happens in Linux as well as Windows.

I've tracked this bug to mekhq.campaign.ResolveScenarioTracker.processGame(). Invocation of client.getGame().getEntities() and client.getGame().getRetreatedEntities() methods returns an empty list in both cases. It looks like those lists were cleaned in MM prior to gamePhaseChange(...) listener invocation.

I've stumbled into this bug before atb patch and only with 37._exp and 39. versions of MM.

[Random]

It appears to me to be the same issue that was brought up in the last thread and it seems to be a result of MHQ losing its connection with MM before MHQ can process the results of the battle. It happens with or without AtB and it happens in Linux as well as Windows.

Yep.  I had this last night.  (Windows & no AtB)

[pheonixstorm]

I think I found a minor bug. Started doing a lot of armor repairs from my last scenario and noticed (as I ran out) that armor for scheduled jobs are not being reserved from the warehouse.

I first noticed when one of my machines had two armor replacements scheduled that showed they were scheduled but I had 0 armor to use for the repair. After, I stripped down another newly captured mech for its armor and finished my repairs leaving me with 26pts on hand and 1k on order. My scheduled repairs though total over 40 points and all look to want to try and complete the next day. I have a hand actuator reserved for repair and an srm 4 reserved for a refit but nothing else.

[TS_Hawk]

What about Cross campaigns say I have such and such stuff and I heard that say either epic or phoenix had something in their campaign that I might want but haven't been able to get could it be possible to trade for that with them as long as if we are in the same era?

[saginatio]

[...] Had to restart a couple of times due to client died  and then all mechs was shown as total loss, when that was not the case and also the kills was not assigned that is not a big deal was able to use the drop down menu to fix that.  [...]

I've managed to fix this, I'll send the patch to ralgith so he can test and apply it.

[scJazz]

I've managed to fix this, I'll send the patch to ralgith so he can test and apply it.

Saginatio,

Just in case it is not the same bug I am posting this log.

Game opened and played from MekHQ fine (no AtB). In the end the Auto-Resolve marked my headshot killed Griffin as survived, my other 3 mechs... total loss. I had to manually resolve.

If this isn't the same bug then I need to post a bug report.

[saginatio]

Saginatio,

Just in case it is not the same bug I am posting this log.

Game opened and played from MekHQ fine (no AtB). In the end the Auto-Resolve marked my headshot killed Griffin as survived, my other 3 mechs... total loss. I had to manually resolve.

If this isn't the same bug then I need to post a bug report.

It is hard to say based only on the log. It is probably the same bug, but might be another:) You can fill ticket in SF since there is none yet concerning auto-resolve. Or I can send you my patched custom build of MHQ.jar.

[scJazz]

Posted Bug Report...
https://sourceforge.net/p/mekhq/bugs/541/

you can send the patch I might play another game today and use it...

[pheonixstorm]

I can test as well so attach the patch and I can add it to my test build.

[saginatio]

you can send the patch I might play another game today and use it...

Patch is really short so I just paste it here. It changest auto-resolve behavior a bit (it appears one-click-on-'Done' earlier). I'll send a compiled version with patches to base attack scenarios, camo and wartime contracts later.

Code: [Select]

Index: src/mekhq/MekHQ.java
===================================================================
--- src/mekhq/MekHQ.java (revision 1925)
+++ src/mekhq/MekHQ.java (working copy)
@@ -372,7 +372,7 @@
  try {
  //FIXME: I would prefer to check on the old victory phase but for some reason
  //it wont progress to that stage with the test bot
-            if (e.getOldPhase() == IGame.Phase.PHASE_VICTORY) {
+            if (e.getNewPhase() == IGame.Phase.PHASE_VICTORY) {
         
              boolean control = JOptionPane.showConfirmDialog(campaigngui.getFrame(),
                         "Did your side control the battlefield at the end of the scenario?",
[\code]

[scJazz]

Patch is really short so I just paste it here. It changest auto-resolve behavior a bit (it appears one-click-on-'Done' earlier). I'll send a compiled version with patches to base attack scenarios, camo and wartime contracts later.

Code: [Select]

Index: src/mekhq/MekHQ.java
===================================================================
--- src/mekhq/MekHQ.java (revision 1925)
+++ src/mekhq/MekHQ.java (working copy)
@@ -372,7 +372,7 @@
  try {
  //FIXME: I would prefer to check on the old victory phase but for some reason
  //it wont progress to that stage with the test bot
-            if (e.getOldPhase() == IGame.Phase.PHASE_VICTORY) {
+            if (e.getNewPhase() == IGame.Phase.PHASE_VICTORY) {
         
              boolean control = JOptionPane.showConfirmDialog(campaigngui.getFrame(),
                         "Did your side control the battlefield at the end of the scenario?",
[\code]

You know if this were Visual Basic that code would be easily usable by me. But... I don't know Java yet (on the todo list) pasting the code here is totally useless to me :)

[pheonixstorm]

Its pretty simple. When in eclipse open MekHQ.java. Find line 372 and replace if (e.getOldPhase() == IGame.Phase.PHASE_VICTORY) { with if (e.getNewPhase() == IGame.Phase.PHASE_VICTORY) {

I am about to add it and compile a new build to see if it fixes the issue. If it does ralgith can get it in the next release unless he feels its a critical issue that requires a new release asap.

[neoancient]

This is the same thing I came up with, but while it allows MHQ to process the resolution, it still can't close the MM window and still generates a NPE when it tries to shut down the server. MHQ doesn't refresh, so there is no post-battle report. I didn't check whether the results of the battle are applied.

[saginatio]

This is the same thing I came up with, but while it allows MHQ to process the resolution, it still can't close the MM window and still generates a NPE when it tries to shut down the server. MHQ doesn't refresh, so there is no post-battle report. I didn't check whether the results of the battle are applied.

With my patch I'm getting a deadlock when i press 'cancel' in autoresolve dialog. I've not experienced NPE in other situations, but definitely this needs more work.

[neoancient]

I haven't dug through enough of the MM code, but what appears to be happening is that the server is resetting the game (which clears all the entities) when it enters the victory phase, while it used to do it after the victory phase ended. Since MHQ processes the scenario when it receives a game change event that indicates the game changed from the victory phase to another one, it can't find any entities and marks them all as a total loss. The exception is an entity without a pilot, which is marked as crippled but I haven't looked into how MHQ gets the info that the pilot is missing.

[scJazz]

well that explains what happened to me since one of my mechs was headshot... pilot dead.

[ralgith]

The problem with this solution is that the victory screen in MM isn't displayed before you resolve in MHQ. I don't consider that ideal. I need to...

1. Find out why that change was made in MM
2. If there wasn't a good reason for the change, revert it. Stop.
3. If there was, look into an alternate solution to the problem. Stop.

[Jayof9s]

The problem with this solution is that the victory screen in MM isn't displayed before you resolve in MHQ. I don't consider that ideal. I need to...

1. Find out why that change was made in MM
2. If there wasn't a good reason for the change, revert it. Stop.
3. If there was, look into an alternate solution to the problem. Implement alternate solution. Stop.

Fixed that for you.  :D

[scJazz]

The problem with this solution is that the victory screen in MM isn't displayed before you resolve in MHQ. I don't consider that ideal. I need to...

1. Find out why that change was made in MM
2. If there wasn't a good reason for the change, revert it. And head smack the Dev responsible Stop.
3. If there was, look into an alternate solution to the problem.  Implement alternate solution. Stop.

Fixed that for you.  :D

u screwed up...
ftfy O0

[saginatio]

The problem with this solution is that the victory screen in MM isn't displayed before you resolve in MHQ. I don't consider that ideal. I need to...

1. Find out why that change was made in MM
2. If there wasn't a good reason for the change, revert it. Stop.
3. If there was, look into an alternate solution to the problem. Stop.

phase_lounge comes after phase_victory - it is natural to clean every entry when you enter into phae_lounge so MM behaves naturally now imho and I would not change it.
What you want to do, if you want to preserve current MHQ behavior,  is to  A) 1)read the state of the entities when in phase_victory, 2)save it internally in MH, 3) when in phase_lounge fire auto-resolve dialog, using the saved state.
OR B) make additional listener phaseAboutToChange(...) :/


For those who cannot wait for the next release I've attached my custom build of MHQ.jar together with changelog. DO NOT post or mention encountered bugs when using this custom version. (You can PM me with those). You need to replace the original in mekhq-0.3.6-dev-r1925-dylan-with-dev-and-data.tar.gz package.

https://dl.dropboxusercontent.com/u/368014/MekHQ.jar
https://dl.dropboxusercontent.com/u/368014/saginatio_autoResolve_baseAttack_camo.patch

[scJazz]

DO NOT post or mention encountered bugs when using this custom version. (You can PM me with those). You need to replace the original in mekhq-0.3.6-dev-r1925-dylan-with-dev-and-data.tar.gz package.

Would it be alright to post seemingly totally unrelated bugs in the Tracker? I mean even though I don't know Java... I do understand programming in general so...

yes/no

I'd like to use a more usable version. For no other reason than to break it repeatedly in more interesting ways  >:D

[pheonixstorm]

So somebody might have screwed up. We all know it happens, just take this line as proof even a large dev company doesn't like screwups.

// Jeremy ... the usual leg breaking rule aplies if you remove this again

[scJazz]

So somebody might have screwed up. We all know it happens, just take this line as proof even a large dev company doesn't like screwups.

My earlier comment was tongue in cheek.

You however just won the internet for the day  ;D

[Davout73]

Most of the parts still have a TN of "Impossible."  Other than that I havent run into anything reproduce-able.

Dav

[pheonixstorm]

For those who cannot wait for the next release I've attached my custom build of MHQ.jar together with changelog. DO NOT post or mention encountered bugs when using this custom version. (You can PM me with those). You need to replace the original in mekhq-0.3.6-dev-r1925-dylan-with-dev-and-data.tar.gz package.

Patch works, now just need to fix the issue of MM/HQ crashing after clicking finish.  So, we can now get the correct data from MM but it still locks up when clicking finish to shut down MM. I got an odd socket error in the log, maybe it will help. Also got a strange NPE that I have no clue what happened to cause it.

This this may be a cause?

Code: [Select]

java.net.SocketException: Software caused connection abort: socket write error
Is it AtB related or just another change in MM that casue another issue.