Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision | ||
en:toolworks:docs:apparatus:deferred [2022/05/29 14:46] – vladius | en:toolworks:docs:apparatus:deferred [2022/06/05 21:40] – vladius | ||
---|---|---|---|
Line 3: | Line 3: | ||
It's no secret and if fact by design, that you can't execute methods that change a Subject' | It's no secret and if fact by design, that you can't execute methods that change a Subject' | ||
- | So there come handy the deferred operations (or // | + | So there come handy the deferred operations (or // |
- | Say, we are implementing a real-time strategy game. A user can select multiple units and assign them orders (tasks). Send them marching to a destination point, for example. We could defer the Trait setting operation while Operating concurrently on the selected units. Check out this exemplary snippet:< | + | ====== Setting Traits ====== |
+ | |||
+ | Say, we are implementing a real-time strategy game. A user can select multiple units and assign them orders (tasks). Send them marching to a destination point, for example. We could defer the Trait setting operation while Operating concurrently on the selected units, using the corresponding [[appi> | ||
FVector Destination = GetUserClickedPoint(); | FVector Destination = GetUserClickedPoint(); | ||
auto SolidChain = Mechanism-> | auto SolidChain = Mechanism-> | ||
SolidChain-> | SolidChain-> | ||
{ | { | ||
- | Unit.SetTraitDeferred(FMoveToPointOrder{Destination}); | + | Unit.SetTraitDeferred(FMoveToPointOrder{Destination}); |
}); | }); | ||
</ | </ | ||
+ | |||
+ | ====== Removing Traits ====== | ||
+ | |||
+ | Removing Traits can also be deferred in a quite similar fashion. Here's an [[appi> | ||
+ | SolidChain-> | ||
+ | { | ||
+ | Buffed.Timeout -= DeltaSeconds; | ||
+ | if (Buffed.Timeout <= 0.0f) | ||
+ | { | ||
+ | Unit.RemoveTraitDeferred< | ||
+ | } | ||
+ | }); | ||
+ | </ | ||
+ | |||
+ | 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> | ||
+ | Unit.RemoveAllTraitsDeferred(); | ||
+ | </ | ||
+ | |||
+ | ====== 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' | ||
+ | SolidChain-> | ||
+ | { | ||
+ | Charging.Timeout -= DeltaSeconds; | ||
+ | if (Charging.Timeout <= 0.0f) | ||
+ | { | ||
+ | Mechanism-> | ||
+ | } | ||
+ | }); | ||
+ | </ | ||
+ | |||
+ | ====== 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:< | ||
+ | SolidChain-> | ||
+ | { | ||
+ | if (Health.Level <= 0.0f) | ||
+ | { | ||
+ | Unit.DespawnDeferred(); | ||
+ | } | ||
+ | }); | ||
+ | </ | ||
+ | |||
+ | ====== 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" | ||
+ | |||
+ | The default automatic behavior minimizes the effort and guarantees that the Deferreds get applied accordingly, | ||
+ | |||
+ | Deferreds Applicators are created explicitly, by calling the [[appi> | ||
+ | { // Start of the explicit scope. | ||
+ | auto Applicator = Mechanism-> | ||
+ | Mechanism-> | ||
+ | // Your first mechanic producing deferred operations. | ||
+ | }); | ||
+ | // The Deferreds won't be applied at this point. | ||
+ | Mechanism-> | ||
+ | // Your second mechanic producing deferred operations. | ||
+ | }); | ||
+ | // Now the Deferreds get actually applied. | ||
+ | } // End of the explicit scope. | ||
+ | </ | ||
+ | |||
+ | Note that the Applicator is actually introduced within its own explicit scope (the curly brace' |