Stim/Response

From The DarkMod Wiki
Revision as of 10:43, 7 February 2006 by Sparhawk (talk | contribs)
Jump to navigationJump to search

Stim/Response system for The Dark Mod

This article describes how the stim/response system works for The Dark Mod. The name is taken from the Dromed Stim/Response system. However this does not mean that you should assume any other similarities. The system was described to me (sparhawk) and I coded it accordingly, but I have no Dromed experience, beyond some very simple maps, without any special features. I never got beyond the "Create a room and texture it" stage. :) So while this system may be similar on how it works as seen by the users, you can't assume that this is is more then a fleeting similarity as defined by it's common requirements.

How does it work?

The general concept is pretty easy to understand. The mapper populates his map with entities. Each of this entities, can be either a kind of actor (a stim) or an actee (the response). Any entity can be both at the same time, however stims don't affect the owner itself. So if the entity carries a stim and it triggers, it will not be act on himself, even if the entity has a response for that stim. Stims and responses are defined by numbers. The Dark Mod already defines some very common stims (like water) and reserves numbers for them. For a complete list you should take a look at thje darkmod_stim_response.script in the script folder. You will notice that there is one stim named USER. This stim has no special meaning. Instead it defines the lowest number that users can use for themself. So if you define new stims to be used in your maps, you should use USER+N for your individual stims. All numbers below USER are assumed to be known stims and may trigger specific actions if needed, which possibly includes specific SDK support code.

As explained above, stims and responses are identified by their id's (the numbers). Whenever a stim is active, the system evaluates all stims and checks if appropriate responses are within it's reach. A response is identified by having teh same id as the stim. When such a response is found, the response is triggered and a script action is executed for it. If the response doesn't have a scriptaction associated, nothing will happen, but this is usually a waste of CPU, unless the response is coded in C++ directly in the SDK.

Stims and responses can be enabled and disabled at runtime. This is not only a feature, it is very important for the health of the system. If stims are not destroyed after they are used up, they will take up memory and hog your machine down after time. Also accumulating stims will cause the system to respond slower after time, as more and more stims have to be tested. For example: The arrows (like the water arrow) will spawn an entity that carries the water stim, when the arrow explodes. If that stim is not destroyed, it will continue to fire. Once a water arrow is exploded it doesn't makes sense though to keep it running, so it has to be destroyed. However, there is no definite rule when a stim has to be destroyed because it depends on their actual usage. Some stims may run throughout the game and others should be destroyed after they are used up.