Yeah, that's the interesting bit. Like I said, it compiles just fine without the keys and key values for a custom entity, even if the custom entity is there. I even tried adding the custom entity as a pointclass in the FGD after trying all other things, and it still doesnt work.

Maybe it's something stupidly simple I'm overlooking. 

You'll get bored with the problem, go have a drink, come back to the PC and the solution will be staring you in the face. Sod's law. 

Lol, yeah. I'm boring you guys with these little agreviating problems :P. Porblably gonna go and play some game soon, or watch some dvd or something. 

but even there I get an error (along the lines of "data missing in entity bracket")

can you maybe do the export to .map thing and then open the .map file and CnP the bit with the custom entity here? it sounds like WC isn't writing the entity correctly. i wouldn't be able to solve the problem if that was the case, but at least you'd know what was causing it. :S

maybe find the relevant bit in the vmf (or is it rmf? not sure) file as well for a CnP here too. 

Bits from the .map file:

{
"classname" "ambient_sound"
"volume" "1"
"speed" "1"
"soundfile" ""ambience/suck1.wav""
"origin" "192 -128 -64"
}


bits from the .rmf file:

CMapEntity
[some bits of file that cant be copied]
ambient_sound[some bits of file that cant be copied]
volume[some bits of file that cant be copied]
speed[some bits of file that cant be copied]
soundfile[some bits of file that cant be copied]
"ambience/suck1.wav"[some bits of file that cant be copied]

I hope that gives you a better overview of the problem. 

"soundfile" ""ambience/suck1.wav&quo...

apart from the end of that line that got garbled, notice there's a double " at the start of the key's value.

that would definitely mess things up but i think in this case, it's the .map exporter messing up because i don't see the "" in the rmf clipping.

so... i guess that didn't help at all, sozz :S 

I have a small issue (I'm using Quoth BTW): I'd like a GK door to start closed, then to open with the gold key, but later I'd like to close it in order to force the player to use another way to the exit. I tried using the toggle field, but unfortunately it does not work... any idea ? 

A hacky way might be to have a copy of the door in the same location that starts open. Then trigger it closed when you need it. If the doors are textured the same it shouldn't result in any noticeable z-fighting or anything. 

instead of a copy of the door, you could just do like bars or something (or a different door in roughly the same spot) to make it look less cheesy. 

"(or a different door in roughly the same spot)"

Right, that's basically what I was saying. A second door that closes but looks like it was the original door. 

OK, I understand the idea: thanks for the tip ;) 

I'm searching for a way to use the thunderbold flash for some kind of event, but I can only come up with the chtong hack, ie using it in a map with no doors. 

also is there a way of putting a clip brush that only effect monsters? Where did I hear mon_clip or monclip? 

There is no monster-only clipping in Quake1. I think that came in during Quake2. There are 2 clipping hulls in Quake maps and everything uses them equally. 

oh well. thanks anyway! 

If you set the angles key directly it should work, give it
pitch yaw roll

Also, isn't there a hacky way to emulate monsterclip using clip brushes as part of a func_wall? You need a regular brush tied to the same entity to make it valid, which you hide inside level geometry. Then the clip parts don't impede player movement/physics objects, but some glitch makes them count for monster navigation. Anyone remember what I'm talking about here? 

i think clip brushes in func_s do stop player movement. i'm pretty sure i tried that once, but it was a long time ago 

one trick is to put holes or gaps in the floor, which are too small for the player to fall through. The monsters use hull0 for navigation, so they will think they can't cross those gaps. 

The monsterclip by func_wall I posted above does work, but since it's a hack there are some big pitfalls. So far I've found:

* Physical movement by a monster is not blocked. Examples of this include fiends(etc...) leaping, and monsters dropping from mid-air onto the monsterclip.

* If a monster is stepping (that is to say changing height because the ground in front is slightly higher or lower) at the same point which it hits the monsterclip, it will penetrate it.

Although in some of these cases it sounds reasonable for the monster to enter the clipping brush, once one gets in, they are stuck as if they were spawned inside a wall. The fiend can escape by jumping again, but is still glitchy otherwise. So unless you use it sparingly, only in situations where these things can't occur, it's probably wise to avoid it.

Perhaps a good solution would be made QC-side. I've got an inkling of how it could be done in a clean manner, but I'd need to mess around a bit with it. 

i could have swore i had built an old school ladder that moved out of a func_door. 

fire brigade! 

Possibly not the best plan if your house is actually burning down. Phone would probably be quicker... 

phone was the course... 

With a trigger next to it that killtargets it when touched by player - who'll never even know it was there.

That's assuming you don't need the thing to permanently block monster movement.

In Quoth it'd be a togglewall, or you could use a skipped func_wall, or else a clip brushed func_wall which has visible brushes on the extents. I mean visible as in not clip texture, embedded in geometry, with the functional centre being clip. 

Isn't that going to block lots of other important things though, like projectiles, and light of sight checks made by monsters?