I think there’s something fundamental about parts that I haven’t grasped. Try this little playable demo.
(I’m using Dialog Interactive Debugger (dgdebug) version 0j/02. Library version 0.36)
(current player #player)
(#player is #in #nursery)
#nursery
(room *)
(name *) nursery
(look *) Improbably cheerful animals peek at you from every wall.
(from * go #north to #hall)
#firetruck
(item *)
(descr *) A bright red fire truck with six wobbly wheels.
(dict *) lorry
(name *) fire truck
(* is #in #nursery)
(appearance *) A red fire truck lies discarded on the floor.
(* attracts #truckwheels) %% doesn't work
#truckwheels
(item *) %% ? Surely a part should only be an item if its parent is an item. Doesn't fix the problem, anyway.
(name *) wheels
(plural *)
(dict *) wobbly
(descr *) They're very wobbly.
(* #partof #firetruck)
(* is #in #nursery) %% but surely the location of a part should be the location of its parent? I don't know how to code that. Besides, since this is true of all parts, surely the library should do it for me?
(#firetruck attracts *) %% doesn't work either.
#hall %% If you take the truck and go north, the wheels don't follow the truck. What's the point of making them part of it?
(room *)
(name *) hall
(look *) Rather dingy. The nursery door stands open to the south.
(from * go #south to #nursery)
While you’re in the nursery you can examine the truck, and its wheels. But if you take the truck and go north into the hall, the wheels are no longer in scope. As you can see, I’ve tried making the wheels floating items using the “attracts” system, but it didn’t work. I could manually add the wheels to scope if the truck is in scope, but that’s what I thought the purpose of making the wheels #partof the truck did. I initially didn’t set the location of the wheels at all, with the result that they were nowhere. As far as I can tell, this relation does nothing out-of-the-box.
#partof is a relation, just like #in or #heldby. This should be sufficient:
(#truckwheels is #partof #firetruck)
Note the “is”, which is missing from the #partof line in your example code.
As a general rule, parts of an item should not be declared as items themselves, because the player cannot take just the part.
Floating objects, as in ($ attracts $), is an unrelated feature. That’s for objects that seem to exist in multiple rooms, like a floor or the moon.
Here’s the complete code:
(current player #player)
(#player is #in #nursery)
#nursery
(room *)
(name *) nursery
(look *) Improbably cheerful animals peek at you from every wall.
(from * go #north to #hall)
#firetruck
(item *)
(descr *) A bright red fire truck with six wobbly wheels.
(dict *) lorry
(name *) fire truck
(* is #in #nursery)
(appearance *) A red fire truck lies discarded on the floor.
#truckwheels
(name *) wheels
(plural *)
(dict *) wobbly
(descr *) They're very wobbly.
(* is #partof #firetruck) %% Note "is".
#hall
(room *)
(name *) hall
(look *) Rather dingy. The nursery door stands open to the south.
(from * go #south to #nursery)
Ah, thank you!" It was driving me around the bend!
But you say that parts shouldn’t be used in this way? I don’t understand. The classic example of a part in the DM4 is of a briefcase with a handle - wherever the handle went, the briefcase did too. I thought the idea of constructing a game-world “object” out of parts was so that we could give the player the illusion of greater depth to the world – like a wall painting with a clue in it, say, where the player must “examine the Chancellor’s face” to see that the perspective’s subtly wrong and he’s looking at a secret cupboard or something.
Anyway, thanks for answering so fast, it was really bothering me that something could be this broken and nobody had noticed. What a relief!
Oh, this is a matter of terminology. Parts are great, they add depth to the implementation; they should be objects. But they shouldn’t be items, which (in Dialog) means something that the player can pick up.
