Thanks. 

Haven't touched the map for a couple of months and today I go to have a play-test because I think it's ready for a full vis and this pops up. FitzQ carries on OK but what am I looking at here; good, bad, or forget it? 

If it doesn't crash (which it does in some cases) then), it's probably forget it but it can be fixed nonetheless, I think. 

there is something to do with entity links. that message means that fq is avoiding a crash by fixing the link.

It can be cause by setting origin of bmodel entities during a touch function. probably other things as well. 

Are func_breakable's supposed to be damaged by monsters? In my last map at least two people got an ogre to open the ROS secret and I wanted to incorporate something like that in mission 2. But right now for some reason the brushes break when the player shoots them but not when ogre grenades explode on them. 

I suspect the problem is not specific to a func_breakable, but is down to the way radius damage applies to brush entities. The grenade does damage to all brush entities whose centre-of-mass* is close enough to the grenade. If your func is large enough, grenades on the ground won't reach it. One test would be to turn it into a shootable func_button and see if that can be triggered.

A possible (untested) solution if that is the problem would be to add a set of point-sized, 1 health trigger_once entities that target the func_breakable. Spread them around enough to give you good coverage.

*Here centre-of-mass means the centre of the bounding box enclosing the brush object, not a calculation based on volume or density. 

Shootable triggers don't work as point entities unfortunately - a point can be touched, but in order to receive damage it needs to have a volume. 

I'd have thought they'd be impossible to hit with nails or shotguns but that they'd still receive radius damage, is that not the case? 

thank you. splitting the func_ brushes into several parts worked like a charm. and until your post I didn't realize func_breakables could be targeted, so that provides a workaround just in case the first plan doesn't work. 

Yes, you're right. Radius damage still works. 

Having a bit of a problem with toggling a play_sound_triggered on and off. My intention is to have the player trigger the sound on (spawnflag 1 is supposed to give that effect, right?) by picking up a weapon, and then off by killing a monster nearby. Instead, the sounds keeps playing after killing the monster.

The ents in question:

// entity 257
{
"classname" "weapon_supernailgun"
"origin" "2048 2048 64"
"target" "desertambience"
"target2" "fog_sand"
"target3" "woodsecr"
}
// entity 258
{
"classname" "monster_scourge"
"origin" "2144 2048 56"
"angle" "180"
"target" "desert_out"
"target2" "desertambience"
"target3" "fog_off"
}

(...)

// entity 261
{
"classname" "play_sound_triggered"
"origin" "2048 2048 128"
"targetname" "desertambience"
"noise" "necros/highwind.wav"
"impulse" "1"
"spawnflags" "1"
"speed" "-1"
"state" "1"
} 

A weird occurence in my map, can you explain what's going on? I use into_notnulls as dormant triggers for unlockable doors, and their touch field uses multi_trigger in order to allow monsters to open them as well. There's one of such triggers that spawns automatically on mapstart (only used to create a smaller door radius). Now, what happens is, it fires its door once right after spawning (understandable as both touch), BUT it also fires whenever the player (and I assume monsters also) teleport around the level. Wtf?!

Another question about the func_wall-as-door hack you posted once: do you think it could work as a door while at the same time still supporting the func_wall_use function so as to change the texture when triggered? 

I think there might be some quirk with the sound entity that's not letting it turn off again. I'll need to check when I get home... 

There is a force retouch in the teleport death check which I believe causes touches for all entities to be reconsidered.
When you make a hack trigger you bypass normal touch check which means ALL entities can trigger it. 

necros/highwind.wav
Goldwave shows a cue point on that file 

I think the toggling code may have never worked. When you toggle an active play_sound_triggered it silences the currently playing sound but doesn't cancel the scheduled retrigger of the sound. This is not the advertised behaviour so I will put it on the fix list for 2.2.

In the meantime, it sounds like you would get away with killtargetting the play_sound_triggered entity instead, since I guess you are alright with it switching off permanently. If the sound still persists when you killtarget, write back and I can describe a more complicated set-up to ensure it gets used and then immediately killed. 

n/t 

The slightly more complicated way that I think stands a good chance of working. We want to first target the play_sound_triggered so that the broken toggle code at least silences the currently playing sound, then immediately killtarget the entity so it can't play again.

Luckily when the code was fixed to allow entities to killtarget and target things at the same time, the order that these things happen is targets first, then killtargets. This is to allow self-destructing set-ups to work without relying on using entities which have been removed (too much), but it also helps us here. Set the scourge to both target and killtarget that play_sound_triggered. If that doesn't work you might have to hold out on the patch... 

Seems like killtarget won't remove the sound no matter what. 

If that doesn't work you might have to hold out on the patch...

Eh, I might end up scrapping this bit altogether since the execution is far removed from how I envisioned it.

Thanks anyway! 

k, I had a chance to look over my code and I remembered:

In order to do what you are doing, you need to set 'wait' to 999999. As long as the sound has it's own loop points (as that one does) it will work fine. 

At the end of scampsp1 I had tried to use Shub's death sound at the start of the end battle, and it turned out to be looping... I threw so many millions of entities at it to kill the looping behavior... but uughh *shudder*. 

sometimes it actually did turn off! 

I made it "Fort Driant" map, stopping the looping sound of the central nuclear power plant.... as far as I remeber the idea is to chain triggers that loops, and one is triggering the sound. note the sounds doesn't have to have loop marker, as it is repeated by trigger... so with a kill target, it is possible to break the chained trigger , hence breaking the loop, and then stop the sound...
dunno whether it is clear enough...
Other option is to exhumate the map code... though... 

Adding wait only made the sound not turn on on the first time it was targeted.