I havn't tested vanilla Quake. But after getting TB rc4 \b text \b will make the text orange coloured. Seems to be good for making titles in the text books. 

Except for Darkplaces. Darkplaces doesn't honor the orange text but instead uses Quake 3 colors ^3, ^4, etc.

FYI 

My fog is showing up fine in QS but not in DP. I just downloaded the latest auto build and reset all to default. Don't they use the same fog format? Googling is not helping. Here's my worldspawn (which was basically stolen from a AD map with a few tweaks.)

"_tb_mod" "Quoth"
"_tb_def" "builtin:Quake/Quoth2.fgd"
"aflag" "13"
"worldtype" "3"
"sky" "July5"
"_sunlight_penumbra" "5"
"_sunlight2" "160"
"_sunlight_dirt" "1"
"_sunlight2_dirt" "1"
"_sun_mangle" "150 -45 0"
"_sunlight" "160"
"fog" "0.03 0.1 0.05 0.1"
"_dirt" "1"
"_dirtgain" "0.75"
"_dirtmode" "1"
"_dirtdepth" "160"
"sounds" "128" 

DP fog 

It's set in the worldspawn already and when I type FOG in the console it shows my worldspawn settings. 

(I mean not the one from 2014 that's on the main page, you'll have to dig in the /files/ page)

Autobuilds aren't exactly known for being bug-free and they might temporarily break stuff. 

tried stable and beta builds - will keep trying but luckily it's just the fog. 

the fog is a lot thinner for me in dp, you might not notice it without a long line of sight. \fog 0 should tell you if its working without recompiling with dif density. 

If you don't find a way to fix this, you could make an extra .ent file with higher fog values for DP. No need to recompile. 

So an .ent is an external file that runs along with the bsp like a .lit file?

#18670 I'll give it a shot - that could be it. Thing is I have very long line of sight in much of the map. Will keep trying. 

I don't remember the exact syntax but when you have a map loaded in DP, there's a command to save an external .ent file of said map. You can then edit it in a text editor. You can tweak, add or remove any entity this way. 

sv_saveentfile 

I am trying to get a light to look good. The problem is its a small flame on a torch holder on an angled wall (45 degrees to the grid). Normally these look fine, but the angled wall is causing the light to stop in a flat line and spread across the torch holder. Using tyrutil v0.15.9

The 2 screens in this album show the torch holders on the walls in the room, with the 2nd screen being a close up (look closely you will see the light stops on a flat line):
http://imgur.com/a/lDpUP

I have tried putting a second light entity slightly in front of the flame, and the flame itself is set with mangle 0 90 0 so it points straight up and the light doesn't hit the wall. With or without the second light entity, or changes to the torch mangle nothing gets rid of this solid line of light.

Any tips? Should I just not put torch holders on angled walls? 

Are you in Darkplaces?

Try making the wall texture face aligned instead of world aligned, that way the lightmap might not goof up inside Darkplaces.

Try also to make your light holder a func_wall. Then, inside you func_wall create a world brush that is ever so slightly NOT touching the wall and completely covered by your func_wall. This way the light shouldn't hit an edge of a polygon since you won't break up the t_junc. 

This is Arcane Dimensions so Quakespasm only. I can try that func_wall approach and see what happens. 

Didn't have much luck with putting a brush inside the func_wall. There seemed to be effects caused by the other light sources in the room, and in one case the light was cast straight down the wall behind the brush.

I might try just raising the overall light level in the room to mask it, but this isn't ideal. Geesh, what I would give for real-time, dynamic lighting. 

Try func_wall with the key "_shadow" "1" set, and no world brush inside.

Alternatively, try updating to the beta version of my tools: https://github.com/ericwa/tyrutils-ericw/releases

with either the original setup (world brush) or func_wall. 

Changing to a func_wall with shadows enabled has cleared up this mess! The light now spreads around the torch holder evenly and it is shadowed under. I guess this has something to do with splitting the geometry? It was a func_detail before.

Thanks again ericw, and I guess I can start compiling with the new tools and see what they are like. 

Geesh, what I would give for real-time, dynamic lighting.
Good to see that you've resolved the issue but when you release your map, you could provide a .rtlights file for DP users. AD can run in DP. 

In a cave, with my head in the sand, apparently. I had given up Darkplaces as completely dead years ago. No wonder I had no idea what Qmaster was talking about.

I thought Quakespasm was the only engine that could reliably run AD. Well, in this case I can look into making an .rtlights file. 

to be fair, new DP builds aren't exactly well avertised. Even the engine's homepage shows an old 2014 build as the latest. One has to go to the /files/ subsection to find the new builds - ironically enough, on the main page this subsection is presented as a repository for old versions... Go figure. It's almost like LordHavoc doesn’t want us to use his engine! 

I have dug this out of my HDD. I haven't tried it yet but it's supposedly better than DP's built-in editor. You might find it handy. No idea who the author is and not exactly sure how to install it, the archive lacks any readme. 

I didn't think implementing Rtlights would be so confusing. Seems one has to do it within the Darkplaces game engine itself? This editor here seems to be nothing more than a progs file, so some kind of mod to run while editing the map in-game?

I can't promise I will be able to make Rtlights file with my map, but I will release the .map file when I am done so someone else can do it. I love the work all these creators have put into their respective engines, but trying to make a single map work a dozen or so engines seems counter-intuitive. 

as you have to manually edit each light. Possible workaround: I might be wrong but I think EricW's tyrutils can output .rtlights files. Can someone else confirm this? 

placement of rtlights is often dependent upon performance rather than merely compile times, as such its generally best to place them inside the same program that will have the performance issues so you can easily see when you've overdone it.

tyrutils-ericw does NOT have support for .rtlights files, rather the engine tries to generate rtlights automatically from the ent lump. This is of course more limited and kinda fuzzy as its trying to support maps that were made without realtime lights in mind.
This also means it doesn't understand surface lights, etc.

the easy way to deal with rtlights is to just ask people to disable r_shadow_realtime_world and let someone else place the fancy lights if they really want them... DP users should be used to that by now, at least for the recent/complex maps.