Hotfix for crash issue:

When combat is broken by dialog (originating in san_enter_combat, specifically), it could trigger a start combat / end combat inifinite loop, resulting in stack overflow. Added "forceEndedCombatNow" flag to handle this

TemplePlus/combat.cpp

@@ -802,6 +802,13 @@ BOOL LegacyCombatSystem::StartCombat(objHndl combatInitiator, int setToFirstInit
 
 	if (AllPcsUnconscious())
 		return FALSE;
+
+	if (forceEndedCombatNow) { // temple+: added this vs. combat start/end loops
+		logger->debug("StartCombat: averted due to forceEndedCombatNow = true");
+		return FALSE;
+	}
+
+
 	logger->debug("StartCombat: entering combat mode; initiated by {}", combatInitiator);
 
 	*combatAddresses.combatRoundCount = 0;

TemplePlus/combat.h

@@ -61,6 +61,7 @@ struct LegacyCombatSystem : temple::AddressTable {
 
 
 	uint32_t* combatModeActive;
+	bool forceEndedCombatNow; // to prevent loops where combat is entered and exited at the same time event
 	bool isCombatActive();
 	bool IsAutoAttack();
 	bool AllCombatantsFarFromParty();

TemplePlus/gamesystems/timeevents.cpp

@@ -1067,7 +1067,7 @@ void TimeEventSystem::AdvanceTime(uint32_t newTimeMs) {
 
 		}
 	}
-
+	combatSys.forceEndedCombatNow = false; // reset this
 
 	if (!timeAdvanceBlockerCount || uiSystems->GetDlg().IsActive()) {
 

TemplePlus/python/python_object.cpp

@@ -226,9 +226,10 @@ static PyObject* PyObjHandle_BeginDialog(PyObject* obj, PyObject* args) {
 		uiPicker.CancelPicker();
 
 		// Temple+: added this, otherwise the combat continues briefly and goes on to the next combatant who can start an action
-		// the dialog event callback does this anyway, but 1ms later
+		// the dialog event callback (0x1014CED0) does this anyway, but 1ms later
 		auto leader = party.GetConsciousPartyLeader();
 		if (leader) {
+			combatSys.forceEndedCombatNow = true;
 			combatSys.CritterExitCombatMode(leader);
 		}