Notes on Thing Properties


Most of the verbs in this section modify the template settings of a thing. This template setting is listed beside the verb.

User Data

All things have a user data assigned to them. By default it is 0. The user data was created so that the "user" could store values with a thing. It can be very useful for attaching values to players. Since the user data is often used by patches, the author recommends that level authors abstain from using the user data of common things like the player.

Class & Capture Cogs

A thing has a class cog and a capture cog. Both of the thing's cogs receive its messages. A thing's class cog is meant to control the effects associated with all things of that template. And so it is defined in the template so that all things of the same "class" have the same class cog.

A capture cog is meant to "capture" a specific thing once it has been created and receive its messages. And because the capture cog captures individual things, it is usually used to handle specific things that have a special role in the game. But of course, a capture cog can capture as many things as needed.

Template Timers

Called "life left" in cog, template timers control how long the thing should stay in the game before it's removed. Ever notice how stormtroopers' bodies don't disappear while you're looking at them? When the body's timer expires, JK checks to see if you're close to the body and if you can see it. Based on that, the exe either removes the thing, or gives it a new lease on life of 3 seconds. When the 3 seconds are over, JK checks again.

Thing Parents

Here's an analogy to explain parents: Adam was the first human. To Seth, his son, Adam was the parent. To Seth's children, Adam was still the parent. But if Seth died and Adam still lived, then the grandchildren will lose their link to Adam and not find their parent. When these children (or any thing) cannot find their parent, they substitute themselves instead. But if Adam had died and Seth still lived, Seth would then be the parent of his children. This is how thing parents work in JK.

Not all verbs will link the things they create to a parent. Only FireProjectile() is known to. The template settings, creatething, fleshhit, and explode will link the things they create to the parent associated with the projectile that created them.

A Thing's Sector

JK bases a lot of operations on things' sectors. SetThingPos() would be a good verb to use if it updated the thing's sector. But since it doesn't, alternatives will have to be used. If you know the sector where the thing should go, use CreateThingAtPos(). If this is MotS, you can use SetThingSector() or SetThingPosEx(). Or if there's a thing already there, use TeleportThing().

If you need to use CreateThingAtPos() but do not know the sector, use the Position's Sector code from the Tutorial Section's Solution category. This will give you the sector of the position that the thing needs to be created at.

A Thing's Signature

A thing's signature is a unique number assigned to each thing in the level. Thing signatures start at one greater that the number of the last thing created. But unlike thing numbers, they are not reused. Signatures are mainly used as a safeguard so the wrong thing is not used by mistake. Look at this example:
#------------------------
created:
   SetTimerEx(5, 0, GetSenderRef(), GetThingSignature(GetSenderRef()));

Return;
#------------------------
timer:
   if(GetThingSignature(GetParam(0)) == GetParam(1)) DestroyThing(GetParam(0));

Return;
#------------------------
Because thing numbers are reused, the wrong thing may be used by mistake. In the above example, the signature is stored by the created message, and then in the timer, it is compared to the signature that the thing is supposed to have. If the signatures are not equal, the sender of the created message had been destroyed. If they match, we know the thing still exists, and it is safe to destroy.