Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:toolworks:docs:apparatus:deferred [2022/05/29 18:24] – vladius | en:toolworks:docs:apparatus:deferred [2022/06/08 22:06] (current) – Добавил ссылку на внутреннюю документацию jispar | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Deferred Operations (Deferreds) ====== | ====== Deferred Operations (Deferreds) ====== | ||
- | 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 // | ||
Line 18: | Line 18: | ||
====== Removing Traits ====== | ====== Removing Traits ====== | ||
- | Removing Traits can also be deferred in a quite similar fashion. Here's an example which removes a " | + | Removing Traits can also be deferred in a quite similar fashion. Here's an [[appi> |
- | SolidChain-> | + | SolidChain-> |
{ | { | ||
- | Buffed.Timeout -= DeltaTime; | + | Buffed.Timeout -= DeltaSeconds; // Decrease the initially allocated timeout using the current Tick's delta time period. |
if (Buffed.Timeout <= 0.0f) | if (Buffed.Timeout <= 0.0f) | ||
{ | { | ||
Line 27: | Line 27: | ||
} | } | ||
}); | }); | ||
- | </cpp> | + | </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> | ||
+ | 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' |