Use this tool to convert from .bsp to .map

Drag and drop your .bsp file onto winbspc.exe

http://quaketastic.com/files/tools/WINBSPC.zip

The textures you seek can be found here:

https://www.quaddicted.com/files/wads/

download all the speedbz and speedy wads 

 

All I see are normal medkits. 

And is it possible to make monsters teleport/spawn in like in Doom 3? 

add a normal medkit, click on "spawnflags" then check "Megahealth" in the set of checkboxes that appear below. 

Spawning monsters in vanilla Quake is a bit...odd.

You have to create a room outside of your level to hold the monsters you wish to spawn. Put a trigger_teleport around the monster. Make the trigger teleport target an info_teleport_destination. Then you need to trigger the trigger_teleport with a trigger_once for example.

Evidence of this can be seen in the id1 maps.

http://quaketastic.com/files/single_player/maps/quake_map_source.zip 

And use the Search feature above, func has a lot of info you can find on this stuff. A lot of these questions are answered. And I agree with Muk. Definitely open up those original Quake levels for a lot of tricks.

I am working on video tutorials for Trenchbroom geared toward beginners but they are still many weeks away. 

Looking forward to those tutorials.

Oh, and I am super exited after discovering it's actually possible to use Trenchbroom to make unreal 4 levels with this program somebody made! 

HammUEr is a pretty cool tool. 

link for the unaware: https://nte.itch.io/hammuer 

When loading a texture wad in trenchbroom you are asked if you want the textue path to be absolute, linked to file etc. What do those things mean? So far I am just using the absolute method but what do those things mean?

I want to make it so that even if the bsp file is played on another computer by someone else the textures (including custom textures) will show up and work properly obviously. 

Once the BSP is compiled, none of that matters. So as long as it's building correctly, you picked the right option. 

To clarify, Quake stores textures inside the BSP file so the WAD path only matters during compilation. 

But I did actually google this, but found nothing :/

For some reason textures don't appear to be aligned correctly in game even when they are in the editor. For example if I change the angle of a texture in the editor it will look correctly there, but once in the game it will still be the wrong angle. Whati is causing this?

Oh, and as a gift in return for asking all these questions, here are a few screens from the level I am working on:

https://imgur.com/a/LbuLB

https://imgur.com/a/IFIzn

https://imgur.com/a/dtRof 

The options are related to where your texture .wad(s) are in relation to the map file. Relative to game directory or application file tells it to check within the folder of either Quake itself or Trenchbroom's install folder respectively- if you have your wads stored someplace else, these choices will often fail because it requires going up a level from the starting point and changing folders, which tends to get screwy. Relative to map file is the same thing but relative to where the .map file you're making is saved- this one fails often as well, and will obviously not work if you haven't saved your map yet (i.e. loading texture wads before starting actually mapping), because then you're telling it to figure out a directory path from the texture wad to nothing. Absolute is the full file path to the wad and is the most reliable.

No real reason to pick one over the other if multiple options work- the only place it shows up in-game is if someone uses the edict (or edicts) command, specifically for edict 0 (worldspawn) which will include a list of what .wads were used when compiling the map and their filepaths, like these examples- the first one is id's own E1M1 which uses only their own base.wad and had the file located within their editor's folder, the second one is an example of the full file path showing up if you use the 'absolute path' option. 

Check your tools and editor are up to date.

tyrutils (Tyrann's original, not my fork) required the "-oldaxis" option to be used for qbsp.

TrenchBroom hasn't had any issues like this in quite a while except for this one: https://github.com/kduske/TrenchBroom/issues/1821 which only comes up if you use the "rotation" tool, and even then only under specific conditions. 

 

http://ericwa.github.io/ericw-tools/

Download some more recent compiling tools and you wont have to use oldaxis 

I'm testing a map, that starts with a warning: 765 efrags exceed standard limits of 640.
The light.log shows:736 entities read, 329 are lights. FindLights: 962 total lights.
I used a lot of lightmaps on a texture in the hope to reduce the lightcount, but it seems to go much too far. I added quiet a lot of new monsters.

While playing I can't reach the end of the map, because of an overload. It looks as if I can't make a room with more than three monsters.

Should I just start removing lights to see what happens? 

Ordinary lights (non-dynamic ones, and ones with no model) don't use up any resources except light.exe compile time, so removing lights probably won't help anything. Removing walltorches will help if you're going over static ent / signon buffer limits, but those would prevent the map from loading at all.

efrags are created when entities span multiple BSP leaves. e.g. the most extreme case: if you made a trigger_once that covers your entire map, and the map has 10k leafs, it would create 10k efrags.

While playing I can't reach the end of the map, because of an overload.
What is the error message and what happens (engine crashes, dropped to console, etc?) which engine? 

I placed a range of secret doors, that were all working independed. When I couldn't make them work on one side without the backside, I placed them all on one trigger_once. So that could be reason.

I can play the whole map (116 ent), untill the last stage, where an overload starts.
The reason is a Launcher_Touch that is in use with one of the baddies. If I delete the monster, another one complains again about its Laser_Touch.

Here are a screenshot and log.
overload
log 

Thanks for posting the log madfox, it turns out that the efrags message is just a warning. The real error which ends your map is "Stack overflow". The rest of the error message shows that the stack overflow is happening inside a chain of triggers.

The simplest way this can happen is that you build a really long chain of triggers which target each other (without any delay):

trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger3
trigger3 ---targets---> trigger4
...

If you have 10 or more triggers connected in a row the game runs out of space on the stack, and you get a stack overflow error. Add a delay somewhere and it should be fixed

In practice most people don't have ten triggers in a row, it gets too complex to be useful. The other way that it can happen is you create a loop. If you have two triggers that target each other, they go into a loop

trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger1
trigger1 ---targets---> trigger2
trigger2 ---targets---> trigger1
...

This loop never ends, so you hit the limit of 10 and the error appears. Check your triggers to see if any of them are targeting themselves, or if they are creating a loop of targets. 

Anyone have any experience with this?

I've successfully created a couple that work fine in KmQuake2 but in other engines they don't render correctly.

Any useful links, tips or suggestions would be appreciated. 

The map had a teleporter with a loose target.
Still I'm a bit confused, because the WARNING: couldn't nudge light in solid at seems strange as there are no lights at that point. 

If you are using light from surfaces, the light tool generates light entities just off of the surface. Could be you have a func_ with a light texture butting against a wall.