Finding objects

[Legacy_Leurnid]

               

Failed.Bard wrote...

Leurnid wrote...

Failed.Bard wrote...

If GetObjectByTag is working for selecting them, you would just need to standardize the naming so that you can get them using a loop on that function instead.  Area tag + sound + night/day, perhaps, so you can toggle on/off certain sound placeables based on time of day as well.

Using the GetObjectByTag script snip of GoG's, you don't need area or day/night checks:  Place the sound objects, then on the advanced tab, uncheck 'active' but set the time the sound should play.  When the script runs, those sounds turn active until you use another script similar to it to deactive them, but they will only play according to the time params. So when the object with the script event is tripped, all the correctly tagged sounds will activate, but only play based on time of day. '>

  I'm just not personally a fan of global switching, since it implies being HB driven.  Area tagged day/night specific sounds can be easily turned on or off in an areas OnEnter script, and the mods HB script can toggle them twice a day in the areas currently occupied by PCs if needed.
  That way, short of putting 5000+ sounds in a given area, you're never risking a TMI error or noticeable lag to the script.

  Now, if you're planning to have some sounds that only play during a specific hour, then you'd be best with on and off time ints stored to the sound objects, but tagging them Area Tag + sound (or sound + area tag) allows for them to be toggled specifically where needed off a single compact generic script.

If you are planning to have sounds play at specific hours, just tell the
sounds to play at specific hours, no script, no HB, no fuss. Running a script to do what the engine is designed to do natively is less efficent.

If you use the sound's default time settings, you never need to use a HB Event to fire them, on the mod, on the area, on the anything.

In this case, I am talking about toggling sounds to 'active' with switches, doors, or triggers, in the on-enter, on-open, or on-use events, but again, no HB involved. I spare myself a lot of scripting headache trying to determine the time by simply toggling sound 'active', then letting the built in functionality of the sound determine when it actually makes noise. I am not trying to turn every sound object in a mod on/off, just a few local to the activating object with the script, and the time-to-play settings on the sound objects circumvent the need to run HB scripts to fire sounds at specific times.

This arrangement seems the ideal case for when you open a door, you have sound objects parked right behind it play.

For example: 
You have a door tagged 'OgreLair', and 5 'inactive' sound objects tagged 'OgreLair_sound'.
When the door opens, it cycles and activates all 5 sound with the door's tag +'_sound' using a generic script.
All 5 sounds turn on, but using the built in times on sounds, only the ones you want will play at specific times, so you hear ogre grunts, ominous evil entrance, and wailing women at night, but during the day, you hear ominous evil entrance, snoring, and wimpering women.

A no script use of the built in sound timing function, that never requires scripts, let alone HB, is blacksmith's shop... set all the sounds to daytime only, when the smithy and apprentice are supposed to be present; place sound objects for the bellows, hammering, the fire, and one or two random bump-thump-and-scrape, all set in the sound properties to only play during the day.
               
               

               

                     Modifié par Leurnid, 22 mai 2012 - 04:06 .
                     
                  

            

[Legacy_henesua]

               Another way to have dynamic sounds that respond to events is to use PlaySound in a script executed by the event.

In the case of a trigger (which can not play a sound) or when you want a sound to play at a particular location other than the object with the event, you can create an invisible object (associate this invisible object with the object executing the event, and Assign the PlaySound command to play on that invisible object.

This technique is not perfect, as sometimes the sound does not play when you first create the invisible sound object, but it usually works, and once the invisible sound object is created it is thereafter always capable of playing the sound.
               
               

               

                     Modifié par henesua, 22 mai 2012 - 04:16 .
                     
                  

            

[Legacy_Leurnid]

               

henesua wrote...

Another way to have dynamic sounds that respond to events is to use PlaySound in a script executed by the event.

In the case of a trigger (which can not play a sound) or when you want a sound to play at a particular location other than the object with the event, you can create an invisible object (associate this invisible object with the object executing the event, and Assign the PlaySound command to play on that invisible object.

This technique is not perfect, as sometimes the sound does not play when you first create the invisible sound object, but it usually works, and once the invisible sound object is created it is thereafter always capable of playing the sound.

I experimented with that, but was disappointed to find there were no range and volume control for the PlaySound action, and have been using SoundObjectPlay in most cases to circumvent those limitations.  PlaySound seems ideally suited for when you want one-off sounds centered at or near the player's location and the max volume is irrelevant or desired.

*oddly, this sound conversation started because I was looking for alternate and possibly more efficient ways of toggling lights... but curiosity lead me down the rabbit hole into the wonderland of sound.
               
               

               
            

[Legacy_henesua]

               You may not be able to adjust the radius of PlaySound but it works well. I've created triggers for undergrowth and whenever a creature blunders into a shrub one of the bush rustle sounds is set to play which makes for a dynamic set of sounds when you set a bunch of boar loose in a forest.

I agree that you need more flexibility in some instances, but in many this technique works very well, and does not require you to place sounds or objects in an area. (although, it does require you to make the triggers to define the undergrowth's extents)

Sound and lighting are important. Enjoy your trip through the wonderland, and bring back treasures for us.
               
               

               
            

[Legacy_Leurnid]

               

henesua wrote...

You may not be able to adjust the radius of PlaySound but it works well. I've created triggers for undergrowth and whenever a creature blunders into a shrub one of the bush rustle sounds is set to play which makes for a dynamic set of sounds when you set a bunch of boar loose in a forest.

I agree that you need more flexibility in some instances, but in many this technique works very well, and does not require you to place sounds or objects in an area. (although, it does require you to make the triggers to define the undergrowth's extents)

Sound and lighting are important. Enjoy your trip through the wonderland, and bring back treasures for us.

That *sounds* awesome.  I will have to experiment with that.

On a side note, if you are already painting triggers, which won't play sounds (amongst many other things, those poor triggers), you need to drop an object to anchor the sound on anyway, so why, OOC, at that point not use a sound object?
               
               

               
            

[Legacy_GhostOfGod]

               

Leurnid wrote...

henesua wrote...

You may not be able to adjust the radius of PlaySound but it works well. I've created triggers for undergrowth and whenever a creature blunders into a shrub one of the bush rustle sounds is set to play which makes for a dynamic set of sounds when you set a bunch of boar loose in a forest.

I agree that you need more flexibility in some instances, but in many this technique works very well, and does not require you to place sounds or objects in an area. (although, it does require you to make the triggers to define the undergrowth's extents)

Sound and lighting are important. Enjoy your trip through the wonderland, and bring back treasures for us.

That *sounds* awesome.  I will have to experiment with that.

On a side note, if you are already painting triggers, which won't play sounds (amongst many other things, those poor triggers), you need to drop an object to anchor the sound on anyway, so why, OOC, at that point not use a sound object?

For "PlaySound" I usually just have the Player or entering object play the sound. So no need to create any objects or anything. Doing as henesua suggests does make for a good quick way to play a sound from any location instantly and then you can just destroy the object right after the sound. So I suppose it could aslo cut down on the number of permanent objects in an area by not having to place many sound objects.
               
               

               
            

[Legacy_henesua]

               I don't have to place anything manually. Its all done by script. The script that wants to play a sound, creates the object the sound will play on and stores the association. If a trigger already has an associated object with which it uses for sounds, rather than create a new object, it plays the sound on that object. I have not yet added the functionality to destroy those objects, but I could if I needed to, since the association is stored. At present server resets handle this garbage collection and its not a big deal.

Why did I do it this way? It is simpler than the alternative which is to place countless sound objects throughout the area.

I don't want to place more objects in the area than I absolutely have to to achieve my goal. Simplicity is better in my opinion. Despite all the detail I put into my area design, I try to keep game objects to a bare minimum. Each object should serve an important function. If I don't have to place it, then I avoid doing so. Dynamically creating and destroying game objects when needed is thus appealing to me.

Furthermore, its already a TON of work to draw all of these triggers, decorate an area with placeables, and set up the non-dynamic sound objects. I'd rather not increase that workload.

Lastly I already have many sound objects in an area, adding fifty or so more would make it very difficult to keep track of the sounds that regularly play. I tend to put a lot of effort into creating day/night cycles that are expressed via a combo of various sound objects in different parts of each area. At dawn and dusk in rural areas for example insect sounds and rodent sounds play near rock walls. Wetlands have frog and toad sounds etc.... There are many of these which PCs can't really interact with. They just happen and define the character of the area. If I cluttered up an area with other sound objects that were meant to be dynamic it would be very difficult to keep track of which is which. Given that I regularly edit areas, I might accidentally delete something that I shouldn't have etc...
               
               

               
            

[Legacy_henesua]

               

GhostOfGod wrote...

For "PlaySound" I usually just have the Player or entering object play the sound. So no need to create any objects or anything. Doing as henesua suggests does make for a good quick way to play a sound from any location instantly and then you can just destroy the object right after the sound. So I suppose it could aslo cut down on the number of permanent objects in an area by not having to place many sound objects.

One reason why I developed this technique was to solve a problem I noticed. When a PCs action queue is full it can not play a sound. I had to clear all actions prior to the sound playing. So if a PC clicks on a location to walk to, and thus crosses a trigger that Assigns playsound to the PC, the sound won't play because the PCs action queue is busy.

Another reason is that triggers can't play sounds.