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. 

Glad to have the option for the physics and that was what I was trying to remember after all! I recall trying to make some very specific jumps to a very narrow ledge and slipping off a bit. I am so used to NQ with QS that it's extremely noticeable. I have quite a few jumping puzzles in the map I am testing.

thx 

mmmm thats bad how the lighting setting would need tweaking to look right in the first place for users .

I did some experiments with breakable furniture, i guess it dosnt look to bad when its not casting a shadow, the AO these new compilers have kinda helps it not look to shitty.

Its always fun to play with new toys tho, especially all the render option this one has, is there an FGD file for the entitys i wouldnt mind playing around with it. 

I'm not concerned with DP, just wanted to know what translated that I already knew. This would simply be for FTE only mapping. 

.fdg files are a human-friendly and easily editable. It's very to edit a .fgd file to add what you want.

Beginner level mapping stuff, really. Open one and look. 

Just wanted to say that r_softwarebanding is a seriously awesome feature, very similar to gl_tonemap=5 in GZDoom (https://forum.drdteam.org/viewtopic.php?t=7097).

Just wish it would be ported to Quakespasm (maybe the "Spiked" fork?) someday. It's the only "feature" that's still missing from DOS/WinQuake.

On another note, how did you fix the texture seams when upscaling the HUD in Hexen 2? It's still broken in Hammer of Thyrion after all these years. Did you change GL_CLAMP to GL_CLAMP_TO_EDGE or what was it? 

I've heard positive things about FTE, so i decided to put it to the test. Not only did it load both really large maps shib3 and shib5, it performed really well, marginally better than Quakespasm. Of course FTE does have it's minor problems.

Many distant scenery had details missing, and there were odd holes in the cliff side wall. In addition, at some point transparent textures and static entities disappear. Could this be hitting an efrags limit?

Shib 5 had less visual issues, but more prominent ones. The mountains in the background disappear completely until you get fairly close to them, which you typically cannot do, so the scenery looks really bland.

Despite these visual defects, the maps themselves run fine with no gameplay issues

The other odd issue that can be game breaking is every so often, the player will just spontaneously warp to a completely different spot in the map, either inside or outside. It just happens randomly without rhyme or reason.

But despite these small setbacks, it appears to be a terrific engine with lots of customizable options to suit the needs of any players. 

Shib requires gl_farclip 256000, which FTE doesn't seem to support. 

all that jazz and no VR support?

these older games play really well in VR for some reason if VR is modded in correctly the new quakespasm sdl2 works great.

hacky injected forced VR however is poison 

Spike once said FTE has recursive mirrors. (99% on this).

FTE also has true rotation available and ericw-tools map compiling tools true rotation as an option. (To get the most out of true rotation -- like doors and drawbridges and such -- requires QuakeC, the Remake Quake game code QuakeC has that available http://svn.icculus.org/remakequake/src/ ). 

Am I reading that right?

Just need to add RMQ's rotation QC code to a progs compile and all the pieces(ericw tools + progs + FTE) are in place for true rotation? 

I already tested this so, it worked. No need for a reply.

Such an easy setup. Only downside left is the "choppiness" of the rotation. But every Quake rotation has this as well. 

That is correct. Should work in DarkPlaces as well. DarkPlaces also supports true rotation.

Rotation particularly is required for, say, func_door. You have to modify the door code.

As I understand it, it's probably a notch or 2 above novice level -- so if you are completely QuakeC clueless/coding adverse you'll either need to commit to doing a QuakeC tutorial or 2 to move yourself above novice --- or find a QuakeC literate friend and either bribe him/twist his arm to doing the task or helping you along the way.)

If you use something like WinMerge (a user-friendly file app to compare files or whole folders) to compare versus vanilla progs 1.06 source code to the below, you may find this useful as a start ...

http://forums.insideqc.com/viewtopic.php?f=12&t=2376 (ignore all the engine code on that page like world.c, sv_phys.c -- that ain't QuakeC).

Nothing about it is "hard". But will require a medium commitment to detail.

I, in fact, was quite newbie writing that tutorial and used WinMerge to extract the door rotation QuakeC from Avirox's source code. I doubt I understood much about the actual QuakeC -- but I didn't need to. Then I made a test map with Rubicon wad setting angle and such.

The QuakeC source is included with the sample map. 

Choppiness of the rotation should be able to be fixed. It needs higher precision angles.

I would expect that in DarkPlaces it may be smooth as silk because I believe DarkPlaces protocol 7 uses precise angles by default.

FTE may need some kind of "hint" to cause smooth angles.

I don't know how to do that.

Hopefully Spike notices your angle precision needs. FTE has protocol extensions (etc.), but I am not versed on those. 

You might be able to do "sv_protocol 999" in FTE. It may immediately resolve it if it is available, although if 999 is available in FTE, I'm not sure that FTE doesn't have something better available that would be a better choice in the long run. 

Spike can confirm, but I think it's "sv_bigcoords 1" 

I had vsync enabled(hate screen tearing), it is smooth as silk now.

Thanks Eric, Baker, Spike and the RMQ peeps. 

@KenChennar
gl_maxdist 0 will give you an infinite projection matrix, at the cost of depth precision.

@damage_inc / Baker
sv_bigcoords 1 is equivalent to sv_protocol 999, but also applies to fte's qw protocol too (and is required for the server to use dpp7, also).
this setting provides both 32bit coords and 16bit angles.
enabling vsync or setting cl_netfps lower, or making the thing rotate faster can avoid two sequential snapshots with the same angle (ie: the rotation periodically stops), giving better use of the precision that's already there. 

I'm not sure what that command has to do with what I described, considering its always on 0 by default.