Last unit ignored

[kernhe]

Environment

Version: 0.49.6-SNAPSHOT OS: Linux 64 (ubuntu 18.04) Java: openjdk version "11.0.11" 2021-04-20

Description

I came upon an issue that is happening from while to while, I cannot replicate it, but it happens at least once in every battle: when clicking "Done" the last unit (mech, VOTL, ...) in the battle (e.g. the fourth mech in a lance if only 4 mechs are on my side, the 12th when I have a company,...) is ignored in the movement and than later in the firing phase.

I can select the last unit manually, but if I use the "Done" button in movement phase, after the 3rd click on done, the firing phase is starting. The bot moves all units.

[Krrast]

I've run across this problem my last couple drops with Nightly MekHQ #618 version of MM. Can provide log if it helps, didnt want to double the submission.

[HammerGS]

Logs and a save would be a huge help.

[Windchild292]

To clarify, a before save

[Krrast]

Black Hand30760929.cpnx.gz megamek.log i dont have a save of the drop, but the drop that is pending is the second one i've had the issue with, the previous drop was last contract. Player name is Black Hand. It didnt skip any of my movements that I can recall, but about 1/2 the time the BattleAxe's turn came during firing phase it skipped it.

[Windchild292]

I just ran through two games of 25 phases on the above campaign, trying to recreate. I could not do so from the provided information... but do know one way this can occur. If you rapidly hit done with the doing nothing nag disabled, it will complete the turn for both units and seem to not provide a turn for the unit.

I'll need a MegaMek save from the phase this issue occurs, and preferably with one from the phase before it occur to trace anything down.

[sshagent]

I'll see about getting some saves for this, our group get this most games.

The interesting bit is that it still shows the units name 'lit up' to show that its not done its firing phase yet. Even once you've 'done' all your firing.

We do play with simultaneous firing phase, so thought it might be something to do with that.

[sshagent]

mmlogs.zip

As per conversation on discord in #nightlies-discussion I've included logs from server and client. I've put some notes in a text file to try and explain what we've seen.
After the game was reloaded back in, every opportunity it was spamming in chat that the bots (or everyone) had disconnected that wasn't the case. it kept saying it, so if you see that...we weren't doing that.

[PhoenixHeart512]

I run into this issue at least once every mission. I will try to get a save and data. At first I thought my mouse was just double clicking the "done" button, but I have since confirmed that is not the case. In very rare instances I've had it skip the last two mechs, not just the last one.

It's serious enough that I've started choosing which mechs to fire first based on "if one of you doesn't get to fire, it's going to be this mech so I'll designate their targets last". Thankfully, the ally-provided units are usually worthless enough to fulfill this important role.

I use "simultaneous firing phase" in the initiative rules, but I turned that off and am about to replay a mission to see if that helps.

So far I've only ever had this happen in MegaMek games that were launched by MekHQ scenarios, I have yet to see it happen in regular MegaMek games that are not related to MekHQ.

I've also ONLY ever had it skip the firing phase, never movement, physical or offboard phases. It has skipped both mechs and vehicles before, so it does not seem to be specific to a unit type.

I will go ahead and upload the MekHQ save I have here (I am about to replay the May 28th 3069 mission because of this bug), maybe by launching the scenario through MekHQ it will repro for you, Wind mekhq bug report files.zip .

EDIT Forgot to mention, I am on 0.49.7, and this has only started occurring after upgrading from 0.48, so this is a relatively new bug for me. Win10 21h1/OpenJDK 11 (from megamek FAQ link).

All necessary files are in that zip (custom mechs, options, and a save file from MekHQ)

[PhoenixHeart512]

After playing a round with "simultaneous firing phase" turned OFF, I did not see any turn skipping for the first time in weeks. I will play a few more battles with it off, then turn it back on to see if the issue returns.

[HammerGS]

Princess doesn’t support any of the Sim unofficial options.

[PhoenixHeart512]

Before you dismiss it for that reason alone, keep in mind that this bug has only popped up in the new 0.49.7 build, I ran the same options on 0.48 and never once encountered it.

Plus, I'm not sure that the fact that it's a princess bot has anything to do with it, since the Princess bot is not the one in charge of deciding when all of my units have completed their turn (as far as I'm aware)

[sshagent]

Oh for sure, and its not princess thats skipping her turn. Its our last unit. This bug has been about for a couple of the 0.49.x versions.
I didn't get feedback on whether my saves and logs were useful above. My group players a few times a week, so happy to run any debug versions thats needed if someone wants.
@PhoenixHeart512 my group have taken to including a tiny BV vehicle as our last unit which has been a nice work around

[PhoenixHeart512]

So I've run about 5 missions in a row now with the "simultaneous firing phase" option disabled, and I have not seen the issue occur a single time. Considering I was seeing it multiple times every mission before, I suspect that option has something to do with it. Gonna turn it back on and see if I can get a save file and record a video of the issue occurring.

I hope not though. This option is crazy helpful when playing with friends, it speeds up the game considerably, and the order that shots are assigned makes zero gameplay or tactical difference. Plus, the bot is so fast at assigning targets that it also groups all player shots in the same section of the log, lol.

[sshagent]

Agreed. We play 1 lance per player, and fight against more than in hostiles. Without simultaneous firing its not going to happen at all.
The weird bit, is when someone has this problem...you can still see that unit with its name label in bright text to show its not done its turn. Yet from the owners perspective, that unit doesn't exist for that firing phase.

[HammerGS]

I'll let @Windchild292 comment on the status of this.

[PhoenixHeart512]

Successfully replicated with a video and a save made moments before it occurred. I loaded the save and repeated the process 3 times and got the exact same behavior all 3 times. Two attempts were made with the FIrestarter as the second to last unit (with warhammer being skipped) and the 3rd attempt was with the warhammer as the second to last unit (with the Firestarter being skipped).

Attaching the normal log files here, saves, custommechs, including the mekHQ save in case it's relevant. I am going to attach a second zip file separately with the video showing the process and exact behavior since it's much larger mekhq bug report files.zip .

[PhoenixHeart512]

Ah, I guess there's a file size limit. Youtube link to unlisted video: https://youtu.be/C8BHpHz8xRg

Hope this helps!

[Windchild292]

Status Update: 1) This issue is caused by the Simultaneous Firing Phase unofficial option (I thought I had noted it here, apologies that I did not) 2) I'm working on #3450, which will modernize the connection code and handle a few bugs. This includes some fixes for issues from @sshagent's logs. I had hoped to have this done by this weekend, but it's going to take a few more weeks to do for personal reasons (ill). 3) Once #3450 is merged I'll create a very specific setup for debugging this specific issue, one that's extremely over the top when it comes to logging and thus provide all the data necessary to figure out the state. I'll need some help once that's ready, and it'll need to be everyone using the specific build on a server running it too to capture the info.

Also @PhoenixHeart512... what happened with your second set of logs? Did you delete them while MegaMek was loaded? It's largely nulls and not actually a log.

[sshagent]

This sounds promising. Best of luck with the personal issues, i hope it's not too rough.

As always thanks for your time on this.

[sshagent]

I didn't comment on your point 3,i host our server... And control when our group switches to new builds. So we'll do that for sure.

[PhoenixHeart512]

Hm, I collected the second set of logs after closing MegaMek and MekHQ, which (in my experience) allows them to be written to the file, and does not clear until the program is launched next.

Glad to hear though, and I hope you get to feeling better! That's never fun.

I also host my own server so I have complete control of builds, I'd be happy to help with testing once the debug client is ready.

In the meantime, let me know if you still need logs, I'm not sure if you meant for me to re-upload them, or were just commenting on them being empty.

[PhoenixHeart512]

@Windchild292 Any word on the logging-overkill build for us to test this with? I am more than happy to sacrifice a few firing phases worth of mechs to help get this identified and resolved, haha

[Windchild292]

I'm going to be spending most of my time this weekend working on and hopefully finishing #3450. It requires a lot of consideration and energy to do, which is why I've not worked on it while handling a huge code rework at work.

[PhoenixHeart512]

Any updates on this? If you would prefer to not be reminded no worries, or if there's a different format I should reach out to you on that's fine too. This is as much a reminder for me to keep an eye out as it is asking for an actual update, I assume you're busy with other things too and/or IRL. It' s a fine line to walk between helpful reminders and annoyance, sorry if I stray.

[Windchild292]

Update: I'm splitting out the internal reworks to make this easier to work on, which I'll need to handle this internally. #3593 has been merged, while #3596 has been opened for the first phase of cleanups.

[sshagent]

Thanks for the update and work, it's much appreciated. If you need anything testing, more than happy to do this.

We've had this bug happen with just 1 unit deployments recently. Normally we've each got a few units... And it's the last one who might lose a firing phase. But we've had a few 1 v 1s and it's occured to.

[gsparks3]

Adding another save+logs in case it helps, although if you don't need more, feel free to let me know.

Player "Soup" encountered this issue during one of our multiplayer games. Named savegame and logs were taken immediately after the bug occurred; autosave is from the beginning of the firing phase (and we managed to reproduce the behavior at least once starting from said autosave, with a different one of his units the second time - thankfully a much less relevant unit than the Nightstar that got skipped the first time.

lastunitstuck.zip

[HammerGS]

Confirmation that this is still happening in 49.10