Thank you

After that, probably the best way to loop the crusher sound would be to have the sound play when triggered by a logic_timer's OnTimer output. So if you wanted the crushers to crush every 10 seconds, you could have the player trigger play the sound and enable the timer. The timer would then fire its OnTimer output to the ambient_generic every 10 seconds to play the sound.

They way I have it set up is:

OnTimer: "CrusherSound": PlaySound: OnlyOnce(No)

OnTimer: "Crusher": SetAnimation: smash_fast: OnlyOnce(Yes) "But the crusher keeps going, for some reason, which I am not complaining about"

I am guessing I need to set a delay for the crusher? But I do not know. Please help.
BTW: I have it so that when a player passes through trigger, it activates the logic_timer and so those "OnTimers" is from the logic_timer.

OnTrigger: "Crusher": SetAnimation: smash_fast: OnlyOnce(Yes)

Time the delay between the crusher impact and the sound using a stopwatch. If the crusher impacts the surface before the sound plays, you need to set the delay in the trigger output to the crusher to what you timed that difference to be. If the crusher impacts the surface after the sound plays, you should set the appropriate delay in the trigger output that starts the sound timer.

Edit: I checked my old map and this is what I did. For the crusher I made these adjustments:
I used smash_fast as the crush animation.
For output I used "OnAnimationDone" the set the "crusher" to have "SetAnimation" for to "smash_fast."
I also made another "OnAnimationDone" then set the "crusher_sound" to "PlaySound"
I also used a trigger to begin the smash_fast animation for the first time, but you can probably use a Logic_auto to take care of that.
Oh, and make sure the "crusher sound" has a SourceEntityName named after your crusher's name.
After your done making the necessary adjustments, test it out to see if it's good.

MasterLagger wrote:
After your done making the necessary adjustments, test it out to see if it's good.

It works perfectly MasterLagger. I knew that there had to be an eaiser way then actaully timing it, I didn't think Valve sat behind a stopwatch wating for the perfect second to add into the delay bar. Thank you very much though for offering the idea BOB74j, I really appreciate that you answered to my post in the time that you did.

Now that I see that having 3 crushers going at the same time doesn't look so good, kind of makes me think that I should probably add a delay to the two of them so they don't all go at the same time. I think this should work and if not, you will probably see me (be totally lazy again) and ask for help

Thanks again.

EDIT: Alright, I tried adding a delay and of course that was to simple to work, and I tried to do the logic_timer thing again, but I don't know how that would be set up to begin with. Any ideas.. (Once again I am trying to do a OnMapSpawn where three crushers would go off at seperate times but in a pattern)

Crusher Instances (many custom options)
It's configured to be prepared for every situation.
If this isn't what you are looking for, you could take a look in it and maybe find something you maybe missed.

&

MasterLagger wrote:

Edit: I checked my old map and this is what I did. For the crusher I made these adjustments:
I used smash_fast as the crush animation.
For output I used "OnAnimationDone" the set the "crusher" to have "SetAnimation" for to "smash_fast."
I also made another "OnAnimationDone" then set the "crusher_sound" to "PlaySound"
I also used a trigger to begin the smash_fast animation for the first time, but you can probably use a Logic_auto to take care of that.
Oh, and make sure the "crusher sound" has a SourceEntityName named after your crusher's name.
After your done making the necessary adjustments, test it out to see if it's good.

Ok so it has been a long time since I have been on on the forums, but I am nearing the Chapter(s), there has just been to much stuff to do in the summer here. But I've ran in to a problem with the three crushers I have. I was forced to change the crusher from crush_fast to crush_big because the crusher would just go off to fast... I know I am missing something here, but even though I have the "OnAnimationDone" on, the "crusher_sound" is now delayed because of this crusher impact change. Honestly, I am getting tired of trying to make little changes that don't work to help improve this "fault of mine" because compiling the map is taking just too long.

Unless there is a way, and I'm sure there is, to make the smash_fast go slower, I'm out of ideas.

BlackBird Studios wrote:
ONMAPSPAWN: Crusher: SetPlayBackRate: Parameter 1

To make them slower, you need to use smaller values than 1, for example 0.6.

Skotty wrote:
BlackBird Studios wrote:

ONMAPSPAWN: Crusher: SetPlayBackRate: Parameter 1

To make them slower, you need to use smaller values than 1, for example 0.6.

To make things more specific, like Brainstone said, setting the "SetPlayBackRate" to 0 puts the animation speed at 0%, while setting the "SetPlayBackRate" to 1 puts the animation speed at 100% (the original animation speed). So putting the "SetPlayBackRate" to 0.5, for example, would reduce the animation speed by half (50%).

(A little help if anyone wouldn't mind, is there a way to find the spot in your map in which it is leaking, it is causing my map to not load in Chapter 2. Idk why, but it has to be just the smallest crack imaginable... Nothing to obvious. If not, I guess I will just have to fly around until I literally find it... (and now I am getting an error message from something else now... which closes portal down before I can even start it up) I am getting confused by the second, if a trigger leaks does that cause an error at all? Even if it is from the smallest smallest crack?

EDIT: Alright so I found what is wrong with my map and why it wont compile, I deleted the last edit so it didn't look so big here on the forums, but it is my arm panels. When I deleted them the map spawned fine, put them back up, Portal 2 would get to 2 blue circles on the loading screen and then it would crash. I can't find the problem with these arms though. I've used the before perfeclty fine but now idk. If anybody can help me with this second problem also that would be great.

And to answer your question MasterLagger, no they are the arm54x64_interior.mdl, the ones that look black and have 2 verticle lines coming down in the middle and the whole thing is connected to an arm.

In response to you BEARD!, I did what you said, but still no dice. I checked the map and there are no fun_detail that are left open. Anything that I thought would cause a problem like that, I just covered it ontop with a wall. I really can't find out what's going on. It has to be somthing in the map because I created a bigger box around my map to see if that would get rid of the problem, but soon when I expand the map, I don't want that box there so I would like to try to find the problem.

If anybody has anymore ideas on what to do that would be greatly appreciated.

BlackBird Studios wrote:
[...] the red line is the weirdest line I've ever seen. It comes out of a wall that (I know definitly has no holes in it and the line extends outwards from the box and then shoots up at an angle and comes back down...

If you are sure that this wall is not a func_detail or something like that, then it could be that the brush is just invalid. This has happened to me a few times as well. Just delete and recreate the wall and try again.