Differences

This shows you the differences between two versions of the page.

--- en:toolworks:docs:apparatus:deferred [2022/05/29 18:26] – [Removing Traits] vladius
+++ en:toolworks:docs:apparatus:deferred [2022/06/05 21:40] – vladius
@@ Line 18: / Line 18: @@
 ====== Removing Traits ======
-Removing Traits can also be deferred in a quite similar fashion. Here's an example which removes a "buffed" status from the units, when expiring:<code cpp>
+Removing Traits can also be deferred in a quite similar fashion. Here's an [[appi>struct_t_subject_handle.html#a56e0ae342a44051765f2a784718c188d|API]] usage example which removes a "buffed" status from the units, when it's expiring:<code cpp>
 SolidChain->OperateConcurrently([DeltaSeconds](FSolidSubjectHandle Unit, FBuffed& Buffed) // Process the selected units in a parallel fashion.
 {
@@ Line 29: / Line 29: @@
 </code>
+There is also a possibility to remove all the traits altogether. In a deferred fashion of course. This is just a matter of calling the corresponding [[appi>struct_t_subject_handle.html#a71c1b5b8374a70ed9371d102241533a2|method]] as in here:<code cpp>
+Unit.RemoveAllTraitsDeferred();
+</code>
+====== Spawning Subjects ======
+Not only traits can be added or removed in a deferred fashion but the whole Subjects can be spawned and despawned this way. So, if you have multiple units spawning a projectile when they're charged, you could do it like so:<code cpp>
+SolidChain->OperateConcurrently([Mechanism, DeltaSeconds](FSolidSubjectHandle Unit, FCharging& Charging, FDamageDealer& DamageDealer)
+{
+	Charging.Timeout -= DeltaSeconds;
+	if (Charging.Timeout <= 0.0f)
+	{
+		Mechanism->SpawnDeferred(FProjectile{DamageDealer.Power}); // Spawn a new subject with an FProjectile trait.
+	}
+});
+</code>
+====== Despawning Subjects ======
+The process of destroying a Subject is quite analogous. Kill all units once their health is zero or below. Just do something like:<code cpp>
+SolidChain->OperateConcurrently([](FSolidSubjectHandle Unit, FHealth& Health)
+{
+	if (Health.Level <= 0.0f)
+	{
+		Unit.DespawnDeferred();
+	}
+});
+</code>
+====== Applying =====
+Until when? This is quite a logical question when dealing with something that is deferred by design. And the default answer is "when the time is right". That essentially means that the behavior is automatic by default, i.e. when the corresponding Mechanism's Chain gets disposed and the current active state is non-Solid.
+The default automatic behavior minimizes the effort and guarantees that the Deferreds get applied accordingly, but maybe you would like to have more control on when and where the application is happening. This is exactly why the concept of //Deferreds Applicators// was introduced.
+Deferreds Applicators are created explicitly, by calling the [[appi>class_a_mechanism.html#ac658045eedfb7def7bd238dae45cc676|UMechanism::CreateDeferredsApplicator]] method as in:<code cpp>
+{ // Start of the explicit scope.
+	auto Applicator = Mechanism->CreateDeferredsApplicator();
+	Mechanism->EnchainSolid(...)->OperateConcurrently([](){
+		// Your first mechanic producing deferred operations.
+	});
+	// The Deferreds won't be applied at this point.
+	Mechanism->EnchainSolid(...)->OperateConcurrently([](){
+		// Your second mechanic producing deferred operations.
+	});
+	// Now the Deferreds get actually applied.
+} // End of the explicit scope.
+</code>
+Note that the Applicator is actually introduced within its own explicit scope (the curly brace'd region). That is in fact done on purpose since the Applicator will apply the pending changes right when it is destroyed, which is guaranteed by ''Applicator'' being a local (automatic) variable and the ''{}'' scope.