BattletechModders / CBTBehaviorsEnhanced

Applies Classic BattleTech behaviors to the HBS BattleTech Game
MIT License
5 stars 6 forks source link

Revostae bug reports #103

Open IceRaptor opened 3 years ago

IceRaptor commented 3 years ago

Making a new ticket to consolidate the most up-to-date info I have on the bugged melee stuff. Closed/deleted the old one because I lost some of the logs. I'll be sure to keep these this time. I also am going to include videos of the full battles where the logs are from. The descriptions have clickable links for time-stamps on the video where the "important" stuff happens as well as a brief description of what is going on at that time stamp for easier viewing. May also help navigate to the important parts in the log based on the order of events. Battle #1 Logs: https://drive.google.com/file/d/1hZ4jJe0DAwYwSAgqxD1LUNogaopLm2Df

Battle #1 Video: https://www.youtube.com/watch?v=VTTE8XmDvgI

IceRaptor commented 3 years ago

Battle #2 Logs: https://drive.google.com/file/d/1VTDM5_0IooSbyABGA6DO9o8w1fdqEC0X

Battle #2 Video: https://www.youtube.com/watch?v=_zGAOH7L6iY

IceRaptor commented 3 years ago

Auto-Select Melee Bug: I've been able to figure out more, mechanically (at least in game) how the auto-select melee thing seems to get broken and how it "fixes itself" as well as how to re-break it. It almost certainly allows clan mechs to ignore the clan negative melee quirk as I landed 16 melee attacks successfully in these two battles. This is in addition to at least another 15-20 clan mech melee attacks I have landed using this bug. It's unlikely I'm just lucky enough to land a 10% or so chance 30-40 times in a row.

Essentially it seems to be failing to properly auto-select a melee attack. If you manually select an attack it "fixes itself" even if you choose another target, change off Move to Sprint and back, or do other things. However, you can reliably break it again to not properly auto-selecting an attack if you activate any ability (even if you cancel it before using it). This includes Battlelord, Sensor Lock, Attack Ground, etc. Once you do that, it is "broken" again and you can use the auto-selected melee attack to ignore the clan negative quirk.

I could not accurately determine which melee attack it would select, it might be random if it's in range? If you're at max melee range it will always charge so it doesn't seem to completely ignore the melee rules. . Weapon Attacks After DFA Bug: This one is a bit weird and I am having trouble reliably reproducing it, it seems random. I have seen it occur with flamers and with medium pulse lasers. So it has happened to me with both support and energy weapons. The location of the weapons doesn't seem to matter either.

One constant seems to be that the DFA has to kill the enemy for the weapons to fire. Nevermind, previously I have video of weapons firing after DFA where the enemy did not die to it. However, the DFA killing the enemy does not guarantee the weapons will fire. Other DFA video and logs: https://www.youtube.com/watch?v=q5Qoe1UnJD4 https://drive.google.com/file/d/1nwjI8EupGklQ7f-lJGP2--upCimaMRlA/view?usp=sharing (Note this video and logs were using the old DLL as the first one t-bone sent in the zip was the old version by mistake)

IceRaptor commented 3 years ago

[Uploading MeleeDebuggingBTALogs-20210516_163052.zip…]()

IceRaptor commented 3 years ago

2021-05-16T16:14:04 CombatLog.MechDFASequence [LOG] DFASequence ExecuteJump 2021-05-16T16:14:04 CombatLog.ActorActivation [LOG] Actor Stormcrow (b5a4f55e-c235-4ac0-a13c-e5f067910690.0) - Activated by Team Player 1 2021-05-16T16:14:04 CombatLog.ActorActivation [LOG] Actor Stormcrow jumping 2021-05-16T16:14:08 CombatLog.MechDFASequence [LOG] OnMoveComplete. msg id: b5a4f55e-c235-4ac0-a13c-e5f067910690.0 2021-05-16T16:14:08 CombatLog.MechDFASequence [LOG] DFASequence ExecuteMelee 2021-05-16T16:14:08 CombatLog.AttackDirector [DEBUG] [OnAttackSequenceBegin] needs to face target! 2021-05-16T16:14:08 CombatLog.AttackDirector [LOG] [AttackSequenceSetupCallback] 2021-05-16T16:14:08 CombatLog.Attacking [WARNING] OnAttackSequenceImpact is dealing <= 0 damage: base dmg: 25, total: 0 2021-05-16T16:14:08 CombatLog.Attacking [WARNING] OnAttackSequenceImpact is dealing <= 0 damage: base dmg: 25, total: 0 2021-05-16T16:14:09 CombatLog.MechImpacts [LOG] All messages completed as expected! 2021-05-16T16:14:09 CombatLog.MechImpacts [LOG] All messages completed as expected! 2021-05-16T16:14:16 CombatLog.MechDFASequence [LOG] OnMeleeComplete. msg id: 2030, our id: 2024, our rootid: 2024 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 GameInfo [ERROR] Weapon Flamer has already pre fired! Has fired? False 2021-05-16T16:14:16 CombatLog.MechDFASequence [LOG] DFASequence FireWeapons

A similar section in the logs seems to occur whenever DFA + Weapons Fire occurs.

IceRaptor commented 3 years ago

i dont see the error message i added, exactly... so if the try-catch is working, its not working the way i expected. @FrostRaptor i see this in the first set of logs: 2021-05-16T23:06:58 GameInfo [ERROR] Attempted to set a melee target that we could not path to! 2021-05-16T23:06:58 MessageCenter [ERROR] CRITICAL ERROR, PLEASE REPORT: Delegate OnCombatantHovered - Standard for message type ActorHoveredMessage failed with exception Object reference not set to an instance of an object at (wrapper dynamic-method) BattleTech.Pathing.UpdateMeleePath_Patch2(object,bool) at BattleTech.Pathing.Update (UnityEngine.Vector3 mousePos, System.Boolean calledFromUI) [0x00008] in <4184af8dbeb44635831353f4d349631c>:0 at BattleTech.UI.SelectionStateMove.SetPotentialTarget (BattleTech.ICombatant target) [0x00033] in <4184af8dbeb44635831353f4d349631c>:0 at BattleTech.UI.SelectionStateMoveBase.ProcessHoveredCombatant (BattleTech.ICombatant target) [0x00043] in <4184af8dbeb44635831353f4d349631c>:0 at BattleTech.UI.CombatSelectionHandler.OnCombatantHovered (MessageCenterMessage message) [0x0002b] in <4184af8dbeb44635831353f4d349631c>:0 at MessageCenter.SendMessagesForType (MessageCenterMessageType messageType, MessageCenterMessage message) [0x00037] in <4184af8dbeb44635831353f4d349631c>:0

so we're still getting an NRE in UpdateMeleePath, but it isn't with the try-catch message I added to CU. it isn't even registering as coming from either CBTBE or CU. are we just pushing the NRE further down the stack somehow, or is this a completely separate issue?

IceRaptor commented 3 years ago

that seems a completely different one 2021-05-16T21:56:24 MessageCenter [ERROR] CRITICAL ERROR, PLEASE REPORT: Delegate AddStackSequence - Standard for message type AddSequenceToStackMessage failed with exception Object reference not set to an instance of an object at (wrapper dynamic-method) BattleTech.Pathing.UpdateMeleePath_Patch2(object,bool) at BattleTech.Pathing.Update (UnityEngine.Vector3 mousePos, System.Boolean calledFromUI) [0x00008] in <4184af8dbeb44635831353f4d349631c>:0 at BattleTech.MechMeleeSequence.GenerateMeleePath () [0x0005e] in <4184af8dbeb44635831353f4d349631c>:0 at (wrapper dynamic-method) BattleTech.MechMeleeSequence.OnAdded_Patch1(object) or not completely same method but different message Ⓕ-bone — 05/17/2021 yeah same method...which didn't get caught by the CU try-catch either. so it could be NRE-ing in the vanilla method somehow. why i was wondering if its the same root issue, just relocated where the NRE crops up Granner — 05/17/2021 This one doesn't cause lock up at least FrostRaptor — 05/17/2021 The NRE in both cases in a patch Patch2, second listed in the harmony_summary, which is probably CU? Ⓕ-bone — 05/17/2021 BattleTech.Pathing.UpdateMeleePath: Postfixes: io.mission.customunits us.frostraptor.CBTBehaviorsEnhanced nope...CBTBE wtf oh... makes sense though. CBTBE dependsOn CU, and harmony is still shitting the bed wrt priority annotations FrostRaptor — 05/17/2021 No That's an older CBTBE version, 0.8.4 not 0.8.6 I'm checking to see if that matters. No, 0.8.4 should be fine - I should be try/catching pretty much everything. Ⓕ-bone — 05/17/2021 looks like you are at leaste for UpdateMeleePath but the order is still CU -> CBTBE, so that NRE is CBTBE and the try-catch isn't...working? FrostRaptor — 05/17/2021 Or that your premise was correct, and it's vanilla that's erroring As I see this in the logs right before the end: 21:25:51.083 UpdateMeleePath diagnostics failed - CU patch may NRE shortly! 21:25:51.083 -- OwningActor != null? True owningActor: Bushwacker_Slapdash_5E2A019C 21:25:51.083 -- CurrentGrid != null? True ResultDestination != null? True 21:25:51.083 -- CurrentPath != null? False Ⓕ-bone — 05/17/2021 yeah... is the Patch2 actually supposed to be the patch number in harmony? is that normally what those Patch# mean? FrostRaptor — 05/17/2021 Yes Ⓕ-bone — 05/17/2021 huh... TIL :smile: FrostRaptor — 05/17/2021 Actually, I'm confused

IceRaptor commented 3 years ago

so even when the actual dll isnt references in the error, you should be able to see where it came f rom by checking harmony FrostRaptor — 05/17/2021 Which logs are you all looking at? the last ones? Ⓕ-bone — 05/17/2021 the first set FrostRaptor — 05/17/2021 MeleeDebuggingBTALogs-20210516_163052.zip ? Oh Granner — 05/17/2021 My snippet was from RT log Ⓕ-bone — 05/17/2021 MeleeDebuggingMission2BTALogs-20210516_232552.zip FrostRaptor — 05/17/2021 MeleeDebuggingMission1BTALogs-20210516_232552.zip then? Granner — 05/17/2021 just to get the old error to compare FrostRaptor — 05/17/2021 No wonder timestamps didn't line up Granner — 05/17/2021 sorry for the confusion I just wanted to see if there's anything different Ⓕ-bone — 05/17/2021 fuck. yes. that one :smile: MeleeDebuggingMission1BTALogs-20210516_232552.zip FrostRaptor — 05/17/2021 No worries, just couldn't understand why things weren't matching

IceRaptor commented 3 years ago

So best I can tell During that time frame a second AI controlled Raptor activated 2021-05-16T23:06:32 CombatLog.ActorActivation [LOG] Actor Raptor (d6da469a-a846-4c67-b83b-898a80dea61b.0) - ends activation 2021-05-16T23:06:32 CombatLog.RoundSequence [DEBUG] [ShouldCompleteActivationSequence] 'this is AITeam' true 2021-05-16T23:06:32 CombatLog.RoundSequence [DEBUG] [CompleteActivation] ActivationSequence.ForceComplete = true 2021-05-16T23:06:32 CombatLog.ActorActivation [DEBUG] [think] AI Team isComplete (HasActivatedThisRound) 2021-05-16T23:06:33 CombatLog.RoundSequence [LOG] [SendTurnActorActivateMessage] turnActorIndex 8 2021-05-16T23:06:33 CombatLog.RoundSequence [LOG] [_SendTurnActorActivateMessage] 2021-05-16T23:06:33 CombatLog.RoundSequence [LOG] Team TargetTeam becoming active 2021-05-16T23:06:39 CombatLog.InvocationHandler [DEBUG] [GenericInvoke] 2021-05-16T23:06:39 CombatLog.Invocations [LOG] Invoking a MOVE! So AI turn goes and completes, then Revostate activates at 06:46, then the escape key 2021-05-16T23:06:58 GameInfo [ERROR] Attempted to set a melee target that we could not path to! comes from Pathing.SetMeleeTarget, which is invoked by SelectionStateMove.SetPotentialTarget Along with MechMeleeSequence.GenerateMeleePath Only thing in the melee logs between then is: 04:06:45.627 Invalidated meleeStates for actor: Hunchback_Sentinel_548A795B 04:06:46.726 Invalidated meleeStates for actor: Raptor_Defender_D4C67737 04:07:04.516 Checking available animations for attacker: Valkyrie II_Exodus_68BECF7F from position: (-204.0, 408.1, 478.0) versus target: Wasp LAM_Gunner_9620933A at position: (-180.0, 410.8, 478.0) with distance: 24.14352 04:07:04.516 Evaluating melee attack height for Valkyrie II_Exodus_68BECF7F at position: (-204.0, 408.1, 478.0) vs. target: Wasp LAM_Gunner_9620933A The errors are all from 'OnCombatantHovered' So definitely the SelectionStateMoveBase.ProcessHOveredCombatant -> SelectionStateMove.SetPotentialTarget -> Pathing.SetMeleeTarget flow Revostae — 05/17/2021 To clarify: This particular set has the old non-try/catch CustomUnits.dll. It was mostly to give a 2nd example of a DFA + weapons fire where the target didn't die. The other sets have the try/catch updated CustomUnits.dll. Hope that isn't too confusing! FrostRaptor — 05/17/2021 Thanks for the clarification, and especially for the video with timestamps That's really helpful and was a bit of work, I would think Always have to appreciate such thorough reports Revostae — 05/17/2021 Yay! I was hoping it would be helpful haha. I was trying to think of what I would find useful (although this is of course way beyond my understanding of the inner workings of the game and mods). I was trying to come up with a way to direct link the logs to the video but my brain started to melt at that point lol I plan to do a few more test runs with the new DLL. I haven't managed to soft lock with it yet but weirdly enough I wasn't soft-locking with the old one either. I'm not sure if I'm doing something that is letting me "get away" with charging/meleeing like crazy that most players aren't doing? I'll try doing a few melee-only missions with none of the special actuators and TSMs and stuff that I put on to make it easier heh

IceRaptor commented 3 years ago

MeleeDebuggingMission2BTALogs-20210516_232552.zip

IceRaptor commented 3 years ago

[Uploading MeleeDebuggingMission1BTALogs-20210516_232552.zip…]()