Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revostae bug reports #103

Open
IceRaptor opened this issue Jun 8, 2021 · 10 comments
Open

Revostae bug reports #103

IceRaptor opened this issue Jun 8, 2021 · 10 comments

Comments

@IceRaptor
Copy link
Collaborator

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
Copy link
Collaborator Author

@IceRaptor
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@IceRaptor
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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 😄
FrostRaptor — 05/17/2021
Actually, I'm confused

@IceRaptor
Copy link
Collaborator Author

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 😄 MeleeDebuggingMission1BTALogs-20210516_232552.zip
FrostRaptor — 05/17/2021
No worries, just couldn't understand why things weren't matching

@IceRaptor
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@IceRaptor
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant