Hiya,
In a previous mud I worked on we had 'world wide events' for things like 'drop', 'death', etc.
and each object could 'listen' for specific event classes. I miss that, kinda, sorta. But I think it
really ate up the processing.
Anyway-
in /lib/std/room.c
Function eventHearTalk()
Here is where all talking is 'caught' that occurs in a room.
You will find that on most of them that the objects are filtered by living etc.
For your domain (area) you could create a 'class' file that inherits the
lib/std/room and all your area rooms will inherit your 'class'.
Basically 'overwrite' this function:
varargs mixed eventHearTalk(...
//call short delay to a sorting function to let the lib room do its thing first?
call_out("VoiceSorter",1, who, targ, msg);
return room::eventHearTalk(...
In your VoiceSorter function you can make whatever checks and actions you
need, including calling specific functions in objects in the local room.
Note- I have not tested this yet.
eventRecieveObject()... yup like Crat suggests. Though if you have something
going on different in each room you might put it in your 'class' file and have
it call a 'local' function in each room file outside of the eventRecieveObject()
In both these instances you will know 'who' or what, so within your sorting or local
functions you can check for player/npc, race, profession, vision, thirst level,
time of day, season, if in combat, special property, specific id, and on and on...
to decide what responce action you want to initiate.
Plus you will preserve the Lib.
But- remember there is quite a bit of interactive ability already in stock DS.
Such as 'functionals' for the setlong, setshort, and descrips of dummy items.
There are functions such as CanGet() that gives you the chance to insert checks
in the specific objects in the room. Browsing through the inherit list of
/lib/std/item.c could give some ideas on whats possible for special physical
interactions.
Memrosh