Ok so I pretty much have the same question I had last time... but this time with doors. Can I make it so that touching a func_door kills the player? 

You can use a thin trigger_hurt brush assigned with enough damage to kill the player, placed right in front of the door.

Then if you had a button(or another entity/trigger/action)to open the door you would also add a "killtarget" targeting the trigger_hurt brush.

Here's the setup...

door:
targetname = dr1
spawnflag set to "toggle"

trigger_hurt:
targetname = kill_payer_now
Damage(dmg) = 1000

button:
target = dr1
killtarget = kill_player_now

In JACK adding a killtarget to a button is done using "smart edit" and adding a new key/value pair. I don't know about TB and other editors.

You of course can adjust this to suit your needs.

hth's,
- damage_ 

You mean, a door that crushes the player while closing? It's the property "dmg". Give it a high value like 1000. 

I should have clarified. In my original post about the func_train issue, I wanted the player to be killed by merely touching the train, not the force of the train pushing you into the wall. This was made possibly by using "touch" "train_blocked" as a keyvalue.

I'm trying to replicate that effect but this time with a door. Essentially, I want to create a large spike ( using a func_door ) that acts as a trap that kills the player as if by impalement, instead of being " crushed " aka pushed into a wall by the spike. So the problem is that, even though I'm giving it a high damage value, it isn't doing anything to the player without having another surface nearby to press them into.

If that isn't possible, I could try to redesign the whole thing by using a func_train instead of a func_door I suppose. 

I'm not sure if func_door overwrites the touch function in its setup. I know it does if you give it a message, but it might not if you leave it blank? If it does, you should be able to use the same trick as for the train. 

From https://quakewiki.org/wiki/doors.qc
self.touch = door_touch;
It always overrides the touch function, so you can't use that trick.

I guess you could maybe do the whole thing as an info_notnull and add all the door functionality manually? It's not doing anything crazy on setup, you just have to explicitly set its movement and give it sounds and stuff.

Posting on mobile so I can't verify anything... 

Or simply a clip brush above the spike? 

Then just make your spike inside a trigger_hurt. 

Hacks on doors tend to be very hard to pull off. Some of the reasons:

� The door spawn function overrides almost all of the functions that you can use for hacks. Not just touch, but also use, think, blocked and th_die

� Every class of SOLID_BSP type has a use function specified in its spawn function, putting up barriers to the idea of creating a SOLID_BSP info_notnull which can be activated like a door

� The function LinkDoors requires all of your doors to have the same classname, so a door made from a hacked func_wall cannot link to regular doors.

� Entities which go through the func_door spawn function get their classname changed to "door", which prevents masquerading of classnames

Nevertheless, I think I still have some tricks up my sleeve, so I'll persist. If I come up with something it'll be posted in the Teaching Old Progs New Tricks thread, but I'll try to post the bad news here if it fails. 

Here's how to do it:

https://tomeofpreach.wordpress.com/2017/03/05/masquerading-as-a-door/

Here's a test map that demonstrates it:

http://www.quaketastic.com/files/single_player/maps/mask.zip

Obviously this is a bit more complicated than just adding one key to an entity, but I can't see a simpler way. Let me know if it misbehaves. 

Obviously way over the top for something as simple as a spike trap, but I'm curious as to which other application this may have. 

@Preach Thanks for the help - unfortunately this solution looks a bit over my head, and I'm not sure how I would go about applying it to the way I have my trap set up. I've never messed with these types of entities before. As far as my problem goes, I might just look into other ways to set up the trap itself, as in the positioning of it, not the entity functions. I appreciate you going out of your way to help though! 

Hey, if someone knows more about quake textures, I have question for you.

Is there similar textures like wizard wood, something that would go to trees and roots? 

Is there a pre-made texture wad featuring all the textures from Quake, Rogue and Hipnotic? I had been using one called q.wad that claimed to be, but I got around to finishing Rogue and realised there were many textures there that weren't in the .wad. 

Hipnotic WAD
Rogue WAD 

I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd

Tested with J.A.C.K steam release 

Too many vertices (65579 > 65535). Recompile with the "-bsp2" flag to lift this restriction.

is this bad? is compiling in bsp2 a bad thing? 

Is your map sealed? If not, then seal your map and the problem will go away.

If your map is sealed, then it usually means your map is bum-splashingly large. This is not generally a problem now, and bsp2 is not bad, but it means people can only play it in bsp2-supporting engines. Is that an issue today? I doubt it. If something thinks it is, I'd like to hear reasons. 

If something thinks it is

If *someone* thinks it is 

Thanks for clearing that for me! 

Are there any basic map scripting guides? I'm wanting to make a brush (or rather a group of brushes) move 64 units while rotating so that it appears to be rolling out of the way. Attempting to search for this turns up a lot of unrelated results, or stuff to do with HUD scripting for Quakeworld. 

Rotating brushes are not a feature of vanilla Quake. You'd need to use the mission pack Scourge of Armagon or another mod that has the same feature.

Hipnotic quake-c (original release 3.12.97) - with compiler warnings fixed. A great mod code base if you want: rotating brushes / doors, water swell, rubble, clocks, earthquakes, etc. Featured in "Scourge of Armagon" - Mission Pack 1. NOTE: any code that requires models / sounds must be modified or you must acquire the mission pack.

http://www.moddb.com/groups/qc/downloads/hipnotic-quake-c-release 

Ah, in that case I might just move the brush rather than delving into this for my first map, it's only for a secret, so digging into this to add a little bit of detail rather than focusing on the map itself is missing the forest for the trees. Although I'll certainly have a look once I become more adept at making maps.

If I shift into stuff more pertinent to actual design, the best kind of secret seems to be one where the player notices a potential rocket/nade/slope jump, tries it and is rewarded both for being observant and having the ability to make the jump. But when that isn't on the table, is it best to make the reward for finding a secret visible to make them start hunting for it? Originally I had the key hidden behind an octagonal panel, and the key could be seen around the edges, but I'm unsure whether it's better to directly signpost secrets like this or just to create interesting areas in the map that prompt investigation, that then leads to finding a secret. It probably doesn't matter as much for little ammo caches and the like, but for something like a key that will unlock a sizeable secret or the only LG/RL available in the map I'm not too sure which approach is best. 

1. I once had documentation on the amount of map unit the player can traverse per second, when he jumps, how he climbs stairs, anybody still has it?

2. Can sky brushes be turned into func_doors, especially func_door_secret?