Geas Home | Play the Game

2.3.2.5 Destroying objects

Sooner or later you will want to get rid of an object. The efun you use is destruct(). However, the gamedriver only allows the object that issued the destruct() efun to actually be removed. This means that every object need to have a function that you can call from another object in order to be able to destroy it from without. If the object doesn't contain the destruct() efun, it will remain for the duration of the game.

Well, actually there exists a backdoor that allows you to destroy any object, but it's a command you have to issue manually. You can't use it in a program.

However, the standard object base - which is being discussed in more detail later - does define a function called remove_object() that you can call to destroy the object. Since all objects actually in the game MUST inherit the standard object you can rely on having that function there. It's possible to mask it, thereby blocking that function. However, masking remove_object() is tantamount to sabotage so please don't even think about it. The reason the function is maskable is so that you should be able to add last-second cleanup code, not so that you should be able to render the object indestructible.

void remove_object() e.g. void remove_balrog(string bal_name) { object bal; bal = find_living(bal_name); if (objectp(bal)) bal->remove_object(); }

If you use the destruct() efun directly or call remove_object() in the object itself, make DOUBLE sure that no code is being executed afterwards. You see, execution isn't aborted on completion of the destruction, the object is just ear-marked as destructed, actual removal is done when execution of it is finished. This means that function calls or commands issued after destruction might give rise to runtime errors in other objects.

void destruct() e.g. void destruct_me() { write("Goodbye, cruel world!\n"); destruct(); }

When an object is destructed, ALL object pointers (not string references) in the game pointing at the destructed object are set to 0. Due to this fact it's usually sensible to make sure that an old object reference still is valid before doing anything with it. You never know, it just might have been removed since you obtained it.

if an object contains other objects in its inventory when it is destructed, those objects will be destructed with it. The exception is interactive objects, players. If you update a room you are effectively destructing it, if it has players in it they will be moved to their respective starting locations. If the room is the start location or if there is a problem with moving them (buggy start location or impossible to move them) those players will be destructed as well. In any circumstances you should always be able to rely on an object being destructed when ordered to.

The one time there's problems with this is when the function remove_object() has been overridden and has a bug in it. That might just abort the process and cause problems.