Finding the used supporter more efficiently?!


(Harald Schuster) #1

Hi - me again. :slight_smile:

It’s dead easy to exctract a used supporter at the “start” of a rule like

.... if the player is on a supporter (called trap)
.... is enclosed by an enterable container (called trap)

Once trapped you can set a variable like trapped or use a defintion for trapped to make use of the trapped state/variable in further actions

Instead of taking something when the player is trapped:

But … when I need to access the actual trap the player is on … I haven’t found a way to do this “easily”.

I know I can store the object once the player is trapped and refer to it via this variable

I know I can do something like

let L be the list of traps; 
repeat with trap running through L: 
   if the player is on trap ... < ---now I have  found my trap

I am merely wondering if there is a handy way that I am unaware of that would save me all that trouble.
I can get a list of items carried by the player - I do not have to cyle through every item to see if it is carried.
I can cycle through the list of worn items just as easily.
I can get the location/room the player is in without cycling through the rooms.

But I haven’t managed to come up with such a simple access to

The container the player is in
The supporter the player is on

Am I just missing something or is there really no “easy” way to get access to that information?


(Daniel Stelzer) #2

The “holder” of an object is its parent in the object tree: the person holding it, the container containing it, the supporter supporting it, or the room enclosing it. So “the holder of the player” will either be a room (if they’re not trapped) or the relevant trap.


(Harald Schuster) #3

Ah, thanks - I am sure after reading ALL the pages in the Documentation and ALL the examples I’d have found this out by myself but, alas, the Documentation is excellent in some cases and not quite so in many others.

So I am really thankful for all the great help that is provided here by this forum. That’ll save me a LOT of unneeded loops now - time to rewrite some code. :slight_smile:


(Andrew Plotkin) #4

This works inside a rule too. You can use it anywhere.


(Harald Schuster) #5

Yes, but it’s an extra if check that - as I just learned - can be avoided by using “holder”.

Call me picky but I like to keep my code as clean as possible and avoid unneccessary checks when possible. That’s why learning about “holder” made me happy. I managed to delete more than 300 lines of code by using it. :slight_smile:

Such small performance improvements may not really matter on a PC but tablets or smartphoes, especially older models, are a different thing.


(Daniel Stelzer) #6

What Zarf is saying is that these two things are fundamentally equivalent, and any differences in runtime are small enough not to matter.

if the player is in a container (called the trap): if the holder of the player is a container:

So it’s really a matter of personal style. I’ve ended up using “holder” fairly often especially when moving objects around.


(Andrew Plotkin) #7

Yeah, it’s doing an object parent test either way. The difference is meaningless even on slow machines. (Unless the test is in a tight loop being checked hundreds of times per turn.)


(Andrew Plotkin) #8

The concern with “holder” is that it doesn’t distinguish between containment, support, and being a part of something. So you could wind up accidentally breaking a relation you didn’t mean to break.


(Harald Schuster) #9

That’s a good argument …