News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
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. 
 
That is terrible, what a stupid bug. Maybe prepending http://www.quaddicted.com would work. 
That Wiki Page Could Use A Complete Overhaul.... 
 
 
you dont say 
Spirit: 
yup, that worked. 
Quoth 
Is there a way for spawning a megahealth with info_multispawn? 
I Believe So 
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 
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. 
More Weird Questions... 
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 
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. 
Negke 
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 
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 
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 
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... 
Negke 
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? 
necros/highwind.wav
Goldwave shows a cue point on that file 
Onetruepurple 
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 
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... 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.