also... lights on plane with a surface won't light that surface. So you can do this:

- With a recessed light fixture, place a light in the hollow cubby but co-planar with the larger wall surface. This fills the inside of the cubby but not the surrounding wall.

- Then place a dimmer light out in front of the wall a small amount, to give some light on the wall around the cubby.

- Or, if there is a perpendicular surface, like a floor, place a light on the floor plane, so that you can simulate light bouncing back up onto the wall. It won't light the floor.

- if a spotlight is shining down onto the floor, place a dim light just above the floor to create bounce light on the surrounding walls, this also softens the circular edge of the spotlight. 

Awesome, thanks! 

https://www.quaddicted.com/reviews/e1m5quoth.html
https://imgur.com/a/AZgmFLL

Trying to take a gander underneath the hood, but I can't seem to in either Valve (first image), or Standard. Using the latest Trenchbroom. 

Select Standard mode in the drop-down and it should open. Bal convinced Sleep and ericw to change the default behavior. A decision that has caused confusion for people who want to examine older maps. 

But TB should really auto-detect the map format on load...

The map in question uses Valve 220 format by the looks of it. 

Well, there's a syntax error in the map file which prevents it from loading in TB (though not in Netradiant). Open the map in a text editor like Notepad++ and delete the opening and closing brackets on line 10271 and 10272. Then the map will load fine.

( 64 1720 -64 ) ( 48 1720 -64 ) ( 48 1592 -64 ) CITY2_7 ...
}
{ ←
} ←
{
( -832 -416 40 ) ( -832 -416 24 ) ( -320 -416 24 ) METAL5_2 ... 

Alright, thanks a bunch! Opened right up. 

Guys how do I make a force field? I cannot find anything on this. No tutorial or anything. Could you guys help me out? 

Do you want an invisible barrier?

Do you want a particle forcefield like in Scourge/Quoth?

Do you want a solid "energy" surface covering the whole door frame?

Do you want bars of "energy" in the middle of the door frame?

Do you want it to just block movement?

Should it hurt or instakill the player instead? 

I want to accomplish an invisible force field or maybe with particles. I want to point a monster to it, and once he's death, the force field should go down. 

Sometime ago I had the same idea @maxwell.

Forcefields depend on a changing screen inside a doorwall that can be turned on or off. The screen itself can be a changing animation on a transparant screen. You can use filters for it, or make use of the transparant "R_wateralpha 0.5" command for engines that use this feather.

The first forcefield I saw was in "Visions" from Wazat, who used three round bars and gave them a transparant neon light. The bars could be easily turned with a func_train.

After seeing that I liked to try another one. First I tried ti use a sprite for forcefield, but then layed it off as sprites turn with the players view.

Then I decided to use a static entity. A static entity a model, that uses an *.mdl file. With a little scripture in qc it can be turned on in game.
Being a little smarter would make it tog-able, so it can be used in game.

Here is an example of it so you can fidle it out.

forcefield.zip .

If you got any more question feel free and go ahead. 

And it works.
https://quake.blog/trenchbroom-windows-setup-tutorial.html 

Nice to have.

There's a useless Export step in the compile configuration he's showing there, but things will still work as long as you're not using the new Omit From Export feature on layers. 

Probably I should add a bit more detail...

If you're going to Export, then the exported map should be the one you compile. That example does an export but then just compiles the original map.

If your tools then force you to end up with a bsp name you don't like, e.g. "mymap-compile.bsp" rather then "mymap.bsp", you can add a final Copy Files action to copy the bsp to the name you want. 

has anyone used q3map2 for godot? I'm using:

q3map2 -convert -format obj map.bsp

but I don't get the textures or the lightmaps. 

Hi @k20abcu. I am using Godot, but I'm not using q3map2 for it. I use Trenchbroom and qodot. Link related https://github.com/Shfty/qodot-plugin

Might be worth a look for your project. I've used it a bit for some Godot prototypes and it's quite useful, and lets me place entities in Trenchbroom that will be converted accordingly over in Godot. 

Checked few maps and saw simple setup of rotate_object linked/pointing to info_rotate. Trying to reproduce, but it doesn't move.

When I run ad_test3 all rotating stuff works as expected: fans, vault door, giant hatch, valve.
Best result I got was using func_rotate_entity - it rotates in game, but ignores info_rotate and moves around world center instead.

What am I doing wrong?

https://drive.google.com/file/d/193eW0C24NiSXcwvHyrsssqnZIRpFRI3A/view?usp=sharing

gtkradiant 1.6
trenchbroom 2020.2
ericw-tools 0.18.1
quakespazm 0.93.1
arcane dimensions 1.80p1 

Rotation only happens if I link rotate_object to func_rotate_entity.
info_rotate clearly affects it, but it is not treated as pivot.

https://youtu.be/qJUzrr7eeCk 

Is it possible to have one exit for two maps and solve this via .ent?

Example:
One map (let's call it "origin") leads to another called "target1". Now there is a patch and "target1" gets renamed for some reason to "target2". However, I would like the .ent file written for "origin" to work in both cases.
Is there a way to write an .ent file for "origin" that works like "if there is a map named target1, use that one, otherwise target2"? 

I'm pretty sure that this won't be possible, but I'm trying to understand what's going on with these patches - I don't understand why you don't just rename target2 back to target1? 

I think this is the solution, if I understand your problem:

original release (pak0.pak) has 2 maps: origin.bsp, target1.bsp. And origin.bsp's changelevel entity points to target1.

then you release a patch (pak1.pak) which contains target2.bsp, and also contains origin.ent which updates the changelevel entity to point to target2.

The solution you proposed is not possible AFAIK. QuakeC could have a modified changelevel entity that takes two different mapnames, but doesn't have a way to check if they exist on disk. 

It is as I thought, then. The problem is that there are two versions of the same origin map, each leading to the same target level, but with different names.

It would have been easy if I didn't have to include a patch for the origin map as well, forcing me to decide which target level should be the "chosen one". That really leaves no option other than to include the target map itself to make sure everybody gets the same result. I had hoped I wouldn't have to include an entire map for this, but apparently it's the only way.