#12228 posted by necros on 2012/11/20 18:59:55
the link to light.exe was broken, so i tried to fix it, but it still doesn't work because the filename has uppercase chars, but the link is not being generated with uppercase even though the source page has them.
#12229 posted by Spirit on 2012/11/20 19:07:17
That is terrible, what a stupid bug. Maybe prepending http://www.quaddicted.com would work.
That Wiki Page Could Use A Complete Overhaul....
#12230 posted by negke on 2012/11/20 19:10:39
#12231 posted by Spirit on 2012/11/20 19:12:23
you dont say
Spirit:
#12232 posted by necros on 2012/11/20 19:43:43
yup, that worked.
Quoth
Is there a way for spawning a megahealth with info_multispawn?
I Believe So
#12234 posted by Preach on 2012/11/22 11:44:37
The way you're supposed to to it use the classname "info_health" everywhere you'd usually use a monster classname, but also set the second spawnflag on the info_multispawn - spawnflags on the info_multispawn get passed onto the things it spawns. Not tested this particular case though...
That Worked
Thanks.
SV_TOUCHLINKS: NEXT != L->NEXT
#12236 posted by Mike Woodham on 2012/11/24 23:26:32
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.
#12238 posted by necros on 2012/11/25 02:24:53
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.
More Weird Questions...
#12239 posted by Fern on 2012/11/25 05:22:25
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.
Radius Damage
#12240 posted by Preach on 2012/11/25 10:23:40
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.
#12241 posted by negke on 2012/11/25 10:35:00
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.
Negke
#12242 posted by Preach on 2012/11/25 12:40:18
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?
Preach Again
#12243 posted by Fern on 2012/11/25 12:49:13
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.
Preach
#12244 posted by negke on 2012/11/25 15:04:02
Yes, you're right. Radius damage still works.
Quoth Sounds
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"
}
Preach
#12246 posted by negke on 2012/11/28 20:43:04
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?
#12247 posted by necros on 2012/11/28 21:45:23
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...
Negke
#12248 posted by necros on 2012/11/28 21:48:38
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.
Looping?
#12249 posted by mechtech on 2012/11/28 21:49:36
necros/highwind.wav
Goldwave shows a cue point on that file
Onetruepurple
#12250 posted by Preach on 2012/11/28 23:07:35
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.
Killtarget Didn't Work.
n/t
Ok, Plan B
#12252 posted by Preach on 2012/11/29 00:08:37
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...
|