diff --git a/DarkEdif/Inc/Shared/Edif.hpp b/DarkEdif/Inc/Shared/Edif.hpp
index ec6ccfb9..8dcaa784 100644
--- a/DarkEdif/Inc/Shared/Edif.hpp
+++ b/DarkEdif/Inc/Shared/Edif.hpp
@@ -234,6 +234,24 @@ namespace Edif
 
 		void Rehandle();
 
+		// Used to allow the rough selection restore to work when multiple events are triggered.
+		// @remarks The following explanation is dubious. I can't reproduce the bug scenario anymore.
+		// My original scenario it occurred in was in DarkScript, which generates events from expressions,
+		// and restores object selection across its generated events. Most objects don't do that.
+		// Until I've isolated ActionCount's change scenarios, I'm keeping this in SDK.
+		//
+		// Dubious explanation:
+		// oilActionCount must differ to rhActionCount for a new event to properly loop
+		// object instances during actions. rhActionCount is normally incremented by runtime when a new generated
+		// event is run to cause that difference.
+		// However, that difference invalidates selection in the event that started the generated one,
+		// like running a fastloop will.
+		// To keep caller event selection, DarkEdif rolls back all selection variables to their original
+		// after the generated event. But that same original being incremented means the runtime rhActionCount
+		// is re-incremented to the same value on both first and second generated event.
+		// That breaks the 2nd+ generated event's selection, so instead we increase rhActionCount by 1, 2, etc.
+		static int actionLoopIncrement;
+
 		// Immediately creates an event, calling that condition ID in this object, and invalidating object selection.
 		void GenerateEvent(int EventID);
 		// Queues an event to run at the end of the actions, which will ccall this condition ID.
diff --git a/DarkEdif/Lib/Shared/Edif.Runtime.cpp b/DarkEdif/Lib/Shared/Edif.Runtime.cpp
index 332ef1ae..638b5447 100644
--- a/DarkEdif/Lib/Shared/Edif.Runtime.cpp
+++ b/DarkEdif/Lib/Shared/Edif.Runtime.cpp
@@ -153,6 +153,9 @@ std::size_t CRunAppMultiPlat::GetNumFusionFrames() {
 #endif
 }
 
+// Static definition
+int Edif::Runtime::actionLoopIncrement = 0;
+
 #if TEXT_OEFLAG_EXTENSION
 std::uint32_t Edif::Runtime::GetRunObjectTextColor() const
 {
@@ -212,7 +215,6 @@ void Edif::Runtime::Rehandle()
 	CallRunTimeFunction2(hoPtr, RFUNCTION::REHANDLE, 0, 0);
 }
 
-//static int steadilyIncreasing = 0;
 void Edif::Runtime::GenerateEvent(int EventID)
 {
 	auto rhPtr = hoPtr->hoAdRunHeader;
@@ -225,8 +227,8 @@ void Edif::Runtime::GenerateEvent(int EventID)
 
 	// This action count won't be reset, so to allow multiple of the same event with different object selection,
 	// we change the count every time, and in an increasing manner.
-	//rhPtr->SetRH2ActionCount(oldActionCount + (++steadilyIncreasing));
-	//rhPtr->SetRH2ActionLoopCount(0);
+	rhPtr->SetRH2ActionCount(oldActionCount + (++actionLoopIncrement));
+	rhPtr->SetRH2ActionLoopCount(0);
 
 	// Saving tokens allows events to be run from inside expressions
 	// https://community.clickteam.com/forum/thread/108993-application-crashed-in-some-cases-when-calling-an-event-via-expression/?postID=769763#post769763
@@ -1328,7 +1330,6 @@ void Edif::Runtime::Rehandle()
 	// GenEdifFunction reHandle
 }
 
-static int steadilyIncreasing = 0;
 void Edif::Runtime::GenerateEvent(int EventID)
 {
 	const auto& rhPtr = this->ObjectSelection.pExtension->rhPtr;
@@ -1342,7 +1343,7 @@ void Edif::Runtime::GenerateEvent(int EventID)
 
 	// This action count won't be reset, so to allow multiple of the same event with different object selection,
 	// we change the count every time, and in an increasing manner.
-	rhPtr->SetRH2ActionCount(oldActionCount + (++steadilyIncreasing));
+	rhPtr->SetRH2ActionCount(oldActionCount + (++actionLoopIncrement));
 	rhPtr->SetRH2ActionLoopCount(0);
 
 	// In older Fusion builds, the expression token became invalidated and that was the only problem.