I am trying to insert linefeeds into the textstory messages for my AD map.

Ok so there was a post about this somewhere. I know I need to use backslash n (without space). Func won't display my backslash... I am copying the method directly from socks available .map files. I am typing text backslash n text (no spaces). But in game I get the virtual text backslash n and no line breaks. I am not typing /n by mistake.

I have only had moderate success getting backslash b to make the title bold as well, sometimes the slash is in the message sometimes not. Is my keyboard broken? Is this a Trenchbroom 2.0 bug? I can type backslash in all programs fine. Please help me. 

I assume you are checking the actual .map file as well? Are you sure it's carrying over from TB2 to the .map? 

I believe the issue lies with TB not handling backslashes properly 

I believe the issue lies with TB not handling backslashes properly

Working with vanilla Quake I've had no issues.

In Quake

In Tb2 rc4

Here's a tiny test map made this a.m. So vanilla works fine. 

Ok so I've looked at my .map in JACK, All of my backslashes have become double backslashes. Why would this be the case? It only appears as a single backslash in TB. I'm having troubles opening the .map in TB now that it has been edited in JACK (I have a backup though).

I see that dumptruck_ds is able to get linefeeds to work in TB fine. Is this some kind of keyboard settings glitch? 

Redfield, i think this is fixed in tb2 rc4, im guessing you are running a previous build 

Thank you ericw. This has cleared up everything! I should have noticed from dumptruck_ds post that I didn't even have rc4. I didn't know there was a new version. After compiling with this new version, I've also noticed that audio crackling from custom sounds has gone away. This is great! 

I've never heard of \\b - is it even a standard ("vanilla") method? Only ever used name maker scripts to get non-standard characters. 

It's non-standard, it's something I added to my tools (light.exe I think). When it sees \b it converts the following text to orange. It's written out the the .bsp in the standard way though and the \b's are stripped out, so it works in all engines. 

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.