As if. Adding a check that I could copy and paste from the function right below wasn't work :P
No problem, I can't complain when someone saves me some work hehe.
Ticket 3744 has been modified: Change of bot unit ownership in lobby doesn't "take"
Edited By: Dylan Myers (ralgith-erian)
_resolution updated: u'none' => u'fixed'
Owner updated: u'arlith' => u'ralgith-erian'
The new "Change Owner" option in the lobby is quietly misleading when it comes to bot-controlled units. The control change seems to take place -- the display changes accordingly to indicate it --, but when the game starts the bot will still be in charge of the unit and deploy it in its own color and all anyway. (This doesn't keep it from accepting "donations" from players in turn, however.)
Either taking away the bot's toys in the lobby needs to be properly enabled or MegaMek needs to at least stop pretending it's doable. (I noticed that between players it's not actually possible to simply seize another's units either, but there at least the option is properly grayed out and unselectable in the first place when I try.) Since I've been known to assign units to the bot purely by mistake before and it would be rather convenient to have an easy way to fix that, I'd naturally favor the former approach. :)
Ticket 3744 has been modified: Change of bot unit ownership in lobby doesn't "take"
Edited By: Nicholas Walczak (arlith)
_milestone updated: u'undetermined' => u'stable 0.36'
Owner updated: None => u'arlith'
Well, now I know why the Precognition.pause() method wasn't synchronized. Fix is in r9459.
From the log:
error opening file to load board!
java.io.FileNotFoundException: data/boards/\unofficial\Jayof9s\64x65 Wilderness Escape.board (No such file or directory)
java.lang.NullPointerException
Whups!
Log from the other half of the game.
There are two issues here. The first is the same issue as reported in [#3625]. The second are the NPE errors that are occurring. These are somewhat related. It looks like, because of the transport error the MovementDisplay's ce state variable is set to null, which is the cause of the NPE's. Fixing the transport/drop issue would fix the problem, but I also added some null checks in MovementDisplay and BoardView1. This was done in [r9458]. This has fixed the NPE's regardless of the transport/drop bug. I'm going to close this ticket since the remaining issue is duplicated in the ticket I mentioned before.
It seems that there are issues cropping up when artillery is used with double blind the following was repeated a lot in the error log (the other player was able to reconnect with no issues after but they disconnected between rounds each time):
player Morges 1st Cavalry on turn: 2 Special type: ARTILLERY_INCOMING drawing: true details: Artillery Incoming. on round 2 from player Morges 1st Cavalry
player Morges 1st Cavalry on turn: -99 Special type: ARTILLERY_AUTOHIT drawing: true details: ArtyAutoHit Hex, for Morges 1st Cavalry
Error: Attempting to filter a Report object that is not public yet has no subject.
messageId: 3630
Ticket 3742 has been modified: Artillery and Double Blind Causing Disconnects
Edited By: Dylan Myers (ralgith-erian)
_milestone updated: u'undetermined' => u'stable 0.36'
Owner updated: None => u'ralgith-erian'
Rats. I'll have to have a look at it after I get home from work tonight.
I tried recreating this again in trunk and I was unsuccessful. I had three APCs on North Scar, and had 3 Ahab's with inferno's and clusters. I tried bombing one APC in the open, and two in buildings (a medium and hardened building). I couldn't reproduce the bug.
I have made some code changes to how inferno missiles deal damage to units in buildings since 35.35, but I don't know if this effects inferno bombs or not.
Can you reproduce the bug? If so, sending a log file would be helpful.