hearers(), as defined by the reference:
This is just like viewers(), but it is a list of mobs that can hear the center object. Currently, this is computed on the assumption that opaque objects block sound, just like they block light.
viewers(), as defined by the reference:
This is just like view(), but it is a list of mobs that can see the center object, rather than a list of objects visible to the center object.
So, quite obviously, viewers=hearers. I'm guessing that the BYOND staff did have something in mind to do later so that hearers didn't viewers, but here's my thoughts.
Currently, from my bedroom, I can hear my mum on the phone and my brother shouting "WHAT?!" from the lounge room. So, maybe like luminosity, opacity should have levels. If the value is true, it blocks light and viewers is treated the same. However, if opacity is true and equal to 2, hearers = viewers + 2 squares beyond the wall in range(2,usr). While I'm sure this could be possible to achieve through a few procs, it would most likely be easier and would use less CPU if opacity was changed or a new var added to atom's.
While to many people this has no use, it would be spectacular for RP games like Death Note Online, or some other RP War Game.
Another idea is to give a hearing var, similar to sight, to make it so people can go death (such as canhear).
ID:260737
 Jun 20 2009, 2:14 am (Edited on Jun 20 2009, 2:35 am)
|
|
I'd simply like sound (as in the result from hearers() - this wouldn't effect the sound() proc) to be blocked either by dense objects or by a new var instead of opaque atoms. It doesn't seem like opacity should change how well sound will travel through an object.
| |
Demon_F0rce wrote:
So, quite obviously, viewers=hearers. On first glance, maybe, but upon a proper look, quite obviously, no. This proc either wouldn't have existed if it had an exact equivalent, or it would've been explicitly stated that it's identical to viewers(), instead it states a difference: viewers() returns who can see the center object, and hearers() returns who can hear it (which is only based on opacity of objects). This means hearers() will still include an object even if the player can't see it, as long as it's in range and not blocked by opaque objects. There could be multiple reasons for an object to be in range but unseen (other than opacity) ,such as that object being invisible or the 'potential see-er' being BLIND. In such cases, under the appropriate conditions, viewers() will not return the object, as it can't be seen, but hearers() will. So, no, the hearers() proc is not as useless as you think, and it IS a good idea to use it for sound announcing/hearing (though not necessarily always). Of course, most people often use viewers() for sound hearing as well (sometimes inappropriately) but then again a lot of people also use view() wrongly very often, such as for range-based ('area effect') effects that shouldn't be based on visibility, and for things that call for hearers()/viewers() instead such as announcing that someone is doing an action. So when using such procs, try and use what's most appropriate rather than what's "the norm". | |
The opacity variable would have to be adjusted, but not too much: a value of 1 would block light, a value of 2 blocks sound and a value of 3 blocks both light and sound.
Games compiled in an older version would just rely on opacity being 1 or 0, with 1 being silently translated to 3.
I don't know how much it'd take, but Lummox JR certainly knows more about this 3D sound business than any of us -- I'm pretty sure it would be trivial since he already knows the calculations that are needed for basic 3D sound.
Thing is, the sound() proc would also have to be changed to allow for a source object to be specified. In the end, it might just be better to check post post [link] and create your own system.