Toggleable music

[echoreece]

I'm making a map with a switch designed to change the entire theme and atmosphere, by activating some doors, func_walls, and such. I have two valid song files for each of these switch states, but I can't seem to find a way to apply both of them effectively. I'm afraid this is impossible, but I'd like to consult here before giving up or devising an incredibly ineffective method. Is it possible to create a toggle-able (looping included) global sound file? If so, how?

[mrwonko]

Does target_play_music work in mp? Might want to give that a try.

[MUG]

Does target_play_music work in mp? Might want to give that a try.

It does indeed. It's what I used for S&D

[echoreece]

Whoa, I completely missed that. Is there a way to invert the input so one can start off, and one trigger switches between them? It switches automatically if the worldspawn music is set as one, but it won't switch back.

[MUG]

Whoa, I completely missed that. Is there a way to invert the input so one can start off, and one trigger switches between them? It switches automatically if the worldspawn music is set as one, but it won't switch back.

Whenever you target one, the current music stops and the new one starts looping.

[echoreece]

That doesn't work if I only have one trigger for on/off. It has to target one, both, or none, not one at a time. The only way to branch off into separate alternating inputs I can find is target_randoms or target_relays with the random key (By the descriptions they work the same way). However that's random, and so I gather it won't reliably alternate.

 

Then again I could be missing something obvious again.

[mrwonko]

You'd simply need a somewhat more elaborate setup of target_activates and target_deactivates - or a script, which has the benefit of keeping the entity count down.

[MUG]

You'd simply need a somewhat more elaborate setup of target_activates and target_deactivates - or a script, which has the benefit of keeping the entity count down.

Here's the entity solution:

you just target the bottom relays to switch music. The entity tower will then trigger one of the groups of entities and then deactivate one relay, and activate another, to make it trigger the other group of entities next time you target the system.

[echoreece]

Thanks for the help, that picture really seemed like it would work. Really. I can't see any flaws in it. It's really clear and easy to see how it works.

 

The trigger toggles the bottom two, m0 (cropped out of the 2d view, sorry)

which goes to the second two, m1 and m2. m1 has the 'inactive' box checked.

Both sides have an activator, targeting the other side's relay, a deactivator targeting its own relay, and a music file.

Two possibilities attempted:

 

1. m1 targets the three entities titled music1. m2 targets the three entities named music2.

Result: Each time I press the button, music2's file restarts.

 

2. m1 targets music1, and applies target2 and target3 to m1a and m1d. m2 has the same, but with music2, m2a, and m2d.

Result: First press activates music2's music, every subsequent press does nothing.

 

In the latter I switched the order of target2 and target3, thinking it was important whether it hit the deactivator or activator first, but there was no change. I've checked, re-checked, and re-re-checked all the targets and targetnames and entity types to make sure everything is in order.

[MUG]

@@Naythan hmm yeah, it isn't working for me now that I tested it...very mysterious...I'll give it more poking.

[MUG]

@@Naythan okay, cracked it. This is slightly crazy. Basically, what was happening, was whenever you pressed the button, it would send a "pulse" up both the relay lines. As we go up the first line, we play the music and also activate the other relay. Our "pulse" would still be live on the other relay line when it was activated, so it would actually set off the first music, and instantly unlock, and set off the second music.

 

My fix for this was to add a target_delay before each of the target_activates. Ensuring that our "pulse" had finished before the second relay was activated. Only downside is if you try to toggle the music again before the target_delay is over, it wont do anything. Wont break it though.

[echoreece]

Sweet, it works! Thank you so much

[MUG]

Why you people wouldn't just make a script, ill never know.

Scripts are for pussies =P Insane towers of entities all the way.

[Szico VII]

I think the easiest way is 2 triggers pointing to separate music changers and then have the activates and deactivates alternate the active trigger each time it is used.

[MUG]

I think the easiest way is 2 triggers pointing to separate music changers and then have the activates and deactivates alternate the active trigger each time it is used.

That's kinda exactly what we have already done at length =P

[echoreece]

Why you people wouldnt just make a script, ill never know.

 

Pff, like I know how to script. This method is way more interesting and fun.

[mrwonko]

Scripts are for pussies =P Insane towers of entities all the way.

Because it's not like there's an entity limit or anything. Oh, wait...

[MUG]

icarus is really easy. Drag and drop.

The problem is knowing what to drag to where. I find it all about as compruendable as..... my spelling of "compruendable".

[echoreece]

Theres a lot you cant do without icarus. Overcoming limitations and doing things that people tell you "will never work" is my idea of fun and interesting.

 

So basically what you're saying is, if you don't use scripting, some things "will never work".

[echoreece]

Yeah..... the things you can't do with entities. Which was the point I was making. Derp.

 

And the point I was making is it's fun and interesting to prove you wrong in that statement.

[echoreece]

You've proven me wrong by doing what exactly? I never said what you are doing cant be done strictly with entities. I was saying a script would have been much simpler, and used less entities.

 

I'm not saying I've proven you wrong. I was bringing to light your obvious contradiction in this post. You said that some things won't work without icarus. Right after that, you said it's fun to prove people wrong who say something won't work. So you inadvertently said it's fun to prove yourself wrong. Is that clear now?

[echoreece]

You know, it's really hard to hold a cohesive argument when we're arguing about two completely different things. I'm out of this discussion.

[Szico VII]

Scripts never make a map less breakable. I find entity layouts MUCH more reliable. (Although they are limited, which is when I would use scriptin')

[Szico VII]

I cant help but think if they were more reliable everything would have been scripted. However from many coder posts here it does appear Raven are somewhat lax in their work ethic

 

Ive never had any problems with entity setups but scripts (performing the same actions) occasionally throw up silly problems for no good reason. Just my two cents.

[Seto]

Somehow this off-topic argument brought me out of lurk mode o.o...

 

1. Simplest way to make a toggle using entities (or otherwise) is to use a proxy func_door

2. Entity limit isn't an issue unless you know you're going to approach it... if you know your map will never use enough ents to get there, then there is some wisdom to NOT using scripts because it will introduce unnecessary modularizations (people with engineering degrees are allowed to make up words!) to your map content, which increases the risk of incompatibility or other issues and also makes development versioning a tad trickier to keep track of.

3. Effective scripting DOES make things easier, especially for large event sequences, and having mental access to the logical basis of scripting lets you think more efficiently and may increase development productivity... if you are intending to utilize such complexities to begin with.

 

In other words, personal preference .

 

inb4lock