<h1>OnDemandHandler<aclass="headerlink"href="#ondemandhandler"title="Permalink to this headline">¶</a></h1>
<p>This handler offers help for implementing on-demand state changes. On-demand means that the state won’t be computed until the player <em>actually looks for it</em>. Until they do, nothing happens. This is the most compute-efficient way to handle your systems and you should consider using this style of system whenever you can.</p>
<p>Take for example a gardening system. A player goes to a room and plants a seed. After a certain time, that plant will then move through a set of stages; it will move from “seedling” to ‘sprout’ to ‘flowering’ and then on to ‘wilting’ and eventually ‘dead’.</p>
<p>Now, you <em>could</em> use <codeclass="docutils literal notranslate"><spanclass="pre">utils.delay</span></code> to track each phase, or use the <aclass="reference internal"href="TickerHandler.html"><spanclass="doc std std-doc">TickerHandler</span></a> to tick the flower. You could even use a <aclass="reference internal"href="Scripts.html"><spanclass="doc std std-doc">Script</span></a> on the flower. This would work like this:</p>
<li><p>The ticker/task/Script would automatically fire at regular intervals to update the plant through its stages.</p></li>
<li><p>Whenever a player comes to the room, the state is already updated on the flower, so they just read the state.</p></li>
</ol>
<p>This will work fine, but if no one comes back to that room, that’s a lot of updating that no one will see. While maybe not a big deal for a single player, what if you have flowers in thousands of rooms, all growing indepedently? Or some even more complex system requiring calculation on every state change. You should avoid spending computing on things that bring nothing extra to your player base.</p>
<li><p>When the player plants the seed, we register <em>the current timestamp</em> - the time the plant starts to grow. We store this with the <codeclass="docutils literal notranslate"><spanclass="pre">OnDemandHandler</span></code> (below).</p></li>
<li><p>When a player enters the room and/or looks at the plant (or a code system needs to know the plant’s state), <em>then</em> (and only then) we check <em>the current time</em> to figure out the state the flower must now be in (the <codeclass="docutils literal notranslate"><spanclass="pre">OnDemandHandler</span></code> does the book-keeping for us). The key is that <em>until we check</em>, the flower object is completely inactive and uses no computing resources.</p></li>
<h2>A blooming flower using the OnDemandHandler<aclass="headerlink"href="#a-blooming-flower-using-the-ondemandhandler"title="Permalink to this headline">¶</a></h2>
<p>This handler is found as <codeclass="docutils literal notranslate"><spanclass="pre">evennia.ON_DEMAND_HANDLER</span></code>. It is meant to be integrated into your other code. Here’s an example of a flower that goes through its stages of life in 12 hours.</p>
<spanclass="k">return</span><spanclass="sa">f</span><spanclass="s2">"This </span><spanclass="si">{</span><spanclass="bp">self</span><spanclass="o">.</span><spanclass="n">name</span><spanclass="si">}</span><spanclass="s2"> has seen better days."</span>
<p>You could now create the rose and it would figure out its state only when you are actually looking at it. It will stay a seedling for 10 minutes (of in-game real time) before it sprouts. Within 12 hours it will be dead again.</p>
<p>If you had a <codeclass="docutils literal notranslate"><spanclass="pre">harvest</span></code> command in your game, you could equally have it check the stage of bloom and give you different results depending on if you pick the rose at the right time or not.</p>
<p>The on-demand handler’s tasks survive a reload and will properly account for downtime.</p>
</section>
<sectionid="more-usage-examples">
<h2>More usage examples<aclass="headerlink"href="#more-usage-examples"title="Permalink to this headline">¶</a></h2>
<p>The <aclass="reference internal"href="../api/evennia.scripts.ondemandhandler.html#evennia.scripts.ondemandhandler.OnDemandHandler"title="evennia.scripts.ondemandhandler.OnDemandHandler"><spanclass="xref myst py py-class">OnDemandHandler API</span></a> describes how to use the handler in detail. While it’s available as <codeclass="docutils literal notranslate"><spanclass="pre">evennia.ON_DEMAND_HANDLER</span></code>, its code is located in <codeclass="docutils literal notranslate"><spanclass="pre">evennia.scripts.ondemandhandler.py</span></code>.</p>
<spanclass="n">ON_DEMAND_HANDLER</span><spanclass="o">.</span><spanclass="n">clear</span><spanclass="p">(</span><spanclass="n">cateogory</span><spanclass="o">=</span><spanclass="s2">"category"</span><spanclass="p">)</span><spanclass="c1">#clear all with category</span>
<pclass="sidebar-title">Not all stages may fire! </p>
<p>This is important. If no-one checks in on the flower until a time when it’s already wilting, it will simply <em>skip</em> all its previous stages, directly to the ‘wilting’ stage. So don’t write code for a stage that assumes previous stages to have made particular changes to the object - those changes may not have happened because those stages could have been skipped entirely!</p>
<li><p>The <codeclass="docutils literal notranslate"><spanclass="pre">key</span></code> can be a string, but also a typeclassed object (its string representation will be used, which normally includes its <codeclass="docutils literal notranslate"><spanclass="pre">#dbref</span></code>). You can also pass a <codeclass="docutils literal notranslate"><spanclass="pre">callable</span></code> - this will be called without arguments and is expected to return a string to use for the <codeclass="docutils literal notranslate"><spanclass="pre">key</span></code>. Finally, you can also pass <aclass="reference internal"href="../api/evennia.scripts.ondemandhandler.html#evennia.scripts.ondemandhandler.OnDemandTask"title="evennia.scripts.ondemandhandler.OnDemandTask"><spanclass="xref myst py py-class">OnDemandTask</span></a> entities - these are the objects the handler uses under the hood to represent each task.</p></li>
<li><p>The <codeclass="docutils literal notranslate"><spanclass="pre">category</span></code> allows you to further categorize your demandhandler tasks to make sure they are unique. Since the handler is global, you need to make sure <codeclass="docutils literal notranslate"><spanclass="pre">key</span></code> + <codeclass="docutils literal notranslate"><spanclass="pre">category</span></code> is unique. While <codeclass="docutils literal notranslate"><spanclass="pre">category</span></code> is optional, if you use it you must also use it to retrieve your state later.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">stages</span></code> is a <codeclass="docutils literal notranslate"><spanclass="pre">dict</span></code><codeclass="docutils literal notranslate"><spanclass="pre">{dt:</span><spanclass="pre">statename}</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">{dt:</span><spanclass="pre">(statename,</span><spanclass="pre">callable)}</span></code> that represents how much time (in seconds) from <em>the start of the task</em> it takes for that stage to begin. In the flower example above, it was 10 hours until the <codeclass="docutils literal notranslate"><spanclass="pre">wilting</span></code> state began. If a <codeclass="docutils literal notranslate"><spanclass="pre">callable</span></code> is also included, this will be called <em>the first time</em> that state is checked for (only!). The callable takes a <codeclass="docutils literal notranslate"><spanclass="pre">evennia.OnDemandTask</span></code> as an argument and allows for tweaking the task on the fly. The <codeclass="docutils literal notranslate"><spanclass="pre">dt</span></code> can also be a <codeclass="docutils literal notranslate"><spanclass="pre">float</span></code> if you desire higher than per-second precision. Having <codeclass="docutils literal notranslate"><spanclass="pre">stages</span></code> is optional - sometimes you only want to know how much time has passed.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">.get_dt()</span></code> - get the current time (in seconds) since the task started. This is a <codeclass="docutils literal notranslate"><spanclass="pre">float</span></code>.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">.get_stage()</span></code> - get the current state name, such as “flowering” or “seedling”. If you didn’t specify any <codeclass="docutils literal notranslate"><spanclass="pre">stages</span></code>, this will return <codeclass="docutils literal notranslate"><spanclass="pre">None</span></code>, and you need to interpret the <codeclass="docutils literal notranslate"><spanclass="pre">dt</span></code> yourself to determine which state you are in.</p></li>
</ul>
<p>Under the hood, the handler uses <aclass="reference internal"href="../api/evennia.scripts.ondemandhandler.html#evennia.scripts.ondemandhandler.OnDemandTask"title="evennia.scripts.ondemandhandler.OnDemandTask"><spanclass="xref myst py py-class">OnDemandTask</span></a> objects. It can sometimes be practical to create tasks directly with these, and pass them to the handler in bulk:</p>
<p>Normally, when a sequence of <codeclass="docutils literal notranslate"><spanclass="pre">stages</span></code> have been cycled through, the task will just stop at the last stage indefinitely.</p>
<p><codeclass="docutils literal notranslate"><spanclass="pre">evennia.OnDemandTask.stagefunc_loop</span></code> is an included static-method callable you can use to make the task loop. Here’s an example of how to use it:</p>
<p>This is a trap state that loops through its states depending on timing. Note that the looping helper callable will <em>immediately</em> reset the cycle back to the first stage, so the last stage will never be visible to the player/game system. So it’s a good (if optional) idea to name it with <codeclass="docutils literal notranslate"><spanclass="pre">_*</span></code> to remember this is a ‘virtual’ stage. In the example above, the “deadly” state will cycle directly to “harmless”.</p>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">OnDemandTask</span></code> task instance has a <codeclass="docutils literal notranslate"><spanclass="pre">.iterations</span></code> variable that will go up by one for every loop.</p>
<p>If the state is not checked for a long time, the looping function will correctly update the <codeclass="docutils literal notranslate"><spanclass="pre">.iterations</span></code> property on the task it would have used so far and figure out where in the cycle it is right now.</p>
<p><codeclass="docutils literal notranslate"><spanclass="pre">evennia.OnDemandTask.stagefunc_bounce</span></code> is an included static-method callable you can use to ‘bounce’ the sequence of stages. That is, it will cycle to the end of the cycle and then reverse direction and cycle through the sequence in reverse, keeping the same time intervals between each stage.</p>
<p>Unlike the <codeclass="docutils literal notranslate"><spanclass="pre">stagefunc_loop</span></code> callable, the bouncing one <em>will</em> visibly stay at the first and last stage until it changes to the next one in the sequence. The <codeclass="docutils literal notranslate"><spanclass="pre">OnDemandTask</span></code> instance has an <codeclass="docutils literal notranslate"><spanclass="pre">.iterations</span></code> property that will step up by one every time the sequence reverses.</p>
<p>If the state is not checked for a long time, the bounce function will correctly update the <codeclass="docutils literal notranslate"><spanclass="pre">.iterations</span></code> property to the amount of iterations it would have done in that time, and figure out where in the cycle it is right now.</p>
<h2>When is it not suitable to do things on-demand?<aclass="headerlink"href="#when-is-it-not-suitable-to-do-things-on-demand"title="Permalink to this headline">¶</a></h2>
<p>If you put your mind to it, you can probably make of your game on-demand. The player will not be the wiser.</p>
<p>There is only really one case where on-demand doesn’t work, and that is if the player should be informed of something <em>without first providing any input</em>.</p>
<p>If a player has to run <codeclass="docutils literal notranslate"><spanclass="pre">check</span><spanclass="pre">health</span></code> command to see how much health they have, that could happen on demand. Similarly, a prompt could be set to update every time you move. But if you would an idling player to get a message popping up out of nowhere saying “You are feeling hungry” or to have some HP meter visually increasing also when standing still, then some sort of timer/ticker would be necessary to crank the wheels.</p>
<p>Remember however, that in a text-medium (especially with traditional line-by-line MUD clients), there is only so much spam you can push on the player before they get overwhelmed.</p>
