Shaders not included ;)

Playing thru Fallout: New Vegas I really liked the subtle use of surface materials. Normals, gloss, reflections etc. I basically know what Darkplaces expects for replacement textures(files/names) but cannot find the information for FTE.

Or is it the same?

I know they share some commonality of certain features but I also know FTE has it's own extensions/capabilities as well.

If anyone has a link or can post the information I would appreciate it.

As far as lighting, to use surface materials, what in the menu's are the bare minimum I need to enable? Lighting Mode: Realtime and Offset Mapping? Or does Dynamic Lighting have to be used also?

My purpose here is to use the bare minimum solely for texture effects. Not complete RT rendered and shadowed Quake.

That's a start ;) 

Yay! It would be nice if FTE were discussed more.

1) Single player modern maps. Runs them all.
2) Co-operative play is an option because it has Spike's superior form of the Quakeworld protocol ...
3) -- which is backwards compatible, so it can online deathmatch also.
4) Conservative in appearance by default.
5) Compatibility and expected behavior. (Sorry, DarkPlaces).
6) Extended capabilities available -- support for more model formats, Q3 maps, is the source of the effects available in Quakespasm Spiked, QuakeC extensions.

Weakness: No Mac build, although there are only 15 Mac users in all of Quake. It is understandable since it almost requires a Mac to compile for a Mac.

Minor gripe ... the useful "apropos" should be renamed "find" modelling after the (successful and user-friendly) Half-Life 2 engine (Source) -- instead of mirroring the goofy name for a (unsuccessful with average people and not user-friendly) Linux operating system command that DarkPlaces chose (lemmings, cliff, and all that). Why not mimick winners instead of user unfriendliness?

If there were one engine that can do the most things that Quake/Quakeworld can do and do it right, it is FTE.

FTE has a wiki with documentaton:

http://fte.triptohell.info/wiki/index.php/Main_Page

(Link to wiki on FTE page is broken? Or is there a new wiki?) 

dynamic light aspect is interesting, i was thinking about making a map with the level of destructibility of hexen 2 but have concerns with how with how pre-baked is going to play with things like that.

Also if i made a map exclusivly using dynamic lights i think you may actually have to take geometry complexity and map size into consideration.

maybe... it runs pretty well for all the graphic addons usually ports like this have all kinds of input problems and just dont feel like the original. 

that was my post, weird forum 

...this week on my new/old map. I found an issue last night but I will be damned if I can recall what it was... it was at the end of the night and not a crash. I will go back later tonight and see if I can jog my memory.

maybe physics? I dunno. I was swapping between engines last night.

I do know I would love FTE to have FF and REW of demos. 

@damage_inc
gl_load24bit 1 // otherwise you get no high-res textures.
gl_specular 1 // enables specular (aka: gloss)
r_glsl_offsetmapping 1 // uses the height values in the alpha channel of the normalmap
r_deluxemapping 1 // combines the normalmap with pre-baked lighting directions (light your map with -lux). No RT lights needed.

r_shadow_realtime_dlight controls whether to attach rtlights to stuff like rockets and explosions. should not normally be used at the same time as r_dynamic (ie: lightmap-based dynamic lights, doesn't affect lightstyle animations).
r_shadow_realtime_world controls whether most static rtlights should be used. note that each static rtlight has a 'mode' field that allows it to be enabled by either rtdlight OR rtworld (or if either is enabled).
r_shadow_realtime_world_lightmaps controls the strength of the lightmaps when rtworld is on.

texture naming is basically the same as DP, except more permissive for fuhquake/ezquake compat reasons.
q3-shader is compatible with q3 instead of dp, if you want to use shaders made for DP then you can try r_programmify 2, but its a global setting. That said shaders that don't specify any glsl probably shouldn't be used anyway.
Here's an example shader that explicitly names all the textures to use:
foo
{
program defaultwall //the glsl to use to draw this surface. use defaultskin for mdls/iqms.
diffusemap foo
normalmap foo_norm //alpha should be height values for offsetmapping
specularmap foo_gloss //alpha is an exponent multiplier
fullbrightmap foo_luma
//uppermap foo_upper //not normally needed for walls
//lowermap foo_lower //not normally needed for walls
reflectmask foo_mask //mask for cubemap reflections
reflectcube somecubemap //better to set VF_ENVMAP in csqc than use this
width 64 //explicit sizes avoids weirdness with .maps (which lack the size info from embedded mips)
height 64
}
You may wish to throw in an explicit pass if you want the shader to work properly in DP or without glsl, or if you want to specify a blend mode.
The program term can be used to load custom glsl code for your surface (eg altwater that samples from reflection/refraction fbos for 'pretty water' type stuff). You can pass args by appending #foo=bar onto the program's name (or adding #foo onto the texture name in the map, if you can avoid q1bsp's 16 char limit).
Custom glsl can do lots of stuff, but is more likely to break (eg: with the d3d renderers).

@sgtstabs
r_shadow_realtime_dlight can enable static dlights without affecting static lighting. When combined with a few spotlights, the result should be much more efficient than trying to light the entire map with omnilights.
Or stick to fence textures for your destructables, and flag them as not casting shadows.
The real issue with rtlights is that mappers have no idea which setting the user is actually using, which means either lots of work, or users complaining that its bugged or whatever.
sidenote: if you want authentic hexen2, then remember that hexen2 has a habit of just forcing absolute light levels, ignoring the prebaked lighting entirely on various bmodels. 

demo rewind is _far_ from trivial once you have proper delta compression and sporadic stuff like player updates (or worse...). While it would theoretically be possible to create a 'reverse' copy of the demo, that sort of thing would be a _lot_ of work, and probably be buggy more often than not.
That said, demo_jump -10 will jump 10-secs backwards by restarting the demo(when jumping backwards) and instantly replaying it up to that target point, or you can give timestamps.
cl_demospeed can be used to provide fastforward or slow motion stuff. You just can't set it to a negative value.

regarding physics, fte defaults to qw physics for prediction to work. set sv_nqplayerphysics to 1 if you want nq physics instead, but its probably best avoided in multiplayer. note that one or two of the presets also set this.