Developer mode just shows you additional error messages / warnings, if any. 

That answers most of my questions for now. 

After mapping in Radiant1.5 I get the error meassage when attempting to compile.
It's a bit confusing because now I have to reload the map in quark to compile.

http://members.home.nl/gimli/radia.jpg

What statement do I miss to let the compiler find the map? 

You have to edit this file: C:\Program Files (x86)\GtkRadiant 1.5.0\q1.game\default_build_menu.xml
You must fill in the correct path to q1 and the compilers.
I made it like this:
______________________
<?xml version="1.0"?>
<!--
build commands
[RadiantPath]: path to Radiant .. C:\Program Files\Gtkradiant
[EnginePath]: path to the engine .. C:\Games\Quake
-->
<project version="2.0">
<var name="bsp">"[RadiantPath]yourbsp"</var>
<var name="vis">"[RadiantPath]yourvis"</var>
<var name="light">"[RadiantPath]yourlight"</var>
______________________ 

I changed the first lines as noted,
so I did but the error still occurs. 

The last part of my post was cut down, sry.

You also have to change the name of your bsp, vis and light in

<var name="bsp">
"[RadiantPath]yourbsp"
</var>

<var name="vis">
"[RadiantPath]yourvis"
</var>

<var name="light">
"[RadiantPath]yourlight"
</var>

for example yourbsp to txqbsp, and so on. 

I changed the paths,
but for some reason the program wants to execute
[bsp]"[MapFile]".

This gives me the two para's that wont compare.
c:\Progra~1\GtkRadiant1.5\hqbp
C:\Quake\ID1\maps\test.map

I'm doing something wrong but just to noob to see.
I think I compile them just aside Radiant.
Thxks anyway. 

who knows if i'm right.
Just had similar problems at the beginning, it just did'nt want to compile.
Btw, i also had to copy the bsp, vis and light .exe's in the radiant folder before it worked...

btw, is it also true that q1 has no detail brushes, just solids, for vis? 

Q1 has a balancing act. You can use FUNC_WALL entities for detail but each one you create eats into your entity count ... and they won't cast shadows. 

Also note that func_wall'ing stuff like you would do with detail brushes is not always beneficial to performance. Sometimes quite the contrary. It does speed up vis time, though.

As for the build scripts, if nothing else helps, just open a command prompt and compile from there. The default entries in GtkR1.5 aren't that useful for Q1 anyway. You'd have to remove a whole lot of them and rewrite the rest to match the syntax of the Q1 tools, and depending on you intend to use them/test the map. 

How do you all do it? What are your thoughts when creating a sp map?
Especialy on layout/routes, puzzles, that kind of stuff.
I often see intertwined paths in quake maps, want something like this too, but lack inspiration... 

I like to start with the floor plan of an area, which you can interlock.

You can try to make a hub area, with a bunch of exits, then link them with other areas.

Blocking out is making a sort of simple version of the map, figuring out distances and scale. Make your layout first, then add detail afterwards. 

I usually do both layout and detail at the same time (per room or area) as they influence each other. Not always the best method. Blocking out the entire layout first works for some people, but can also be somewhat restrictive.

I guess in modern games, and probably for dm levels, it's pretty much mandatory to get layout and gameplay/flow right beforehand. Quake's monsters, however, are so versatile (or simple) that you usually don't need much pre-structuring to make them work.

It's good to have some ideas before starting the map, how rooms are supposed to look and connect to others, what puzzles and gameplay situations might be interesting in them, and so on, but quite often the map just evolves dynamically depending on what's already there, so to speak. After a while, one gets a feeling for it.

Perhaps try drawing some layout ideas on a grid paper and see how you can expand them. Keeping the principles of deathmatch levels in mind while coming up with a layout can help. Floors at multiple height levels that interconnect or meet in open areas/atriums maybe. Of course you could also create a room and just add a bridge somewhere above, or two doorways - something that forces you to connect other areas to, and eventually it may come together as a proper layout.

If you lack general inspiration, just play a few custom levels and examine how it's done there (noclip around on and look from the outside). Or check the inspiration&reference thread. 

There is a thread about the design process, might be helpful to you, though it's more about overall methodology than specific gameplay design.

http://www.celephais.net/board/view_thread.php?id=60554 

Blocking out the whole layout before detailing can be boring, but tends to make the creation of the map happen much faster, since you waste less time detailing areas you later redesign or throw away. Coming up with a theme idea before that is a good idea though, since the setting might well influence the design and architecture quite a lot - even at the rough stage.

I think adding a few monsters during the block out phase, even if it's not final gameplay, is very important, since you need to test how they handle the geometry and for ogres in particular, how effective they are. Ogres can be UTTERLY ineffective if placed too high or low, and whilst their presence alone and rain of grenades might make the player twitchy, if they realise all the grenades are missing the combat loses its urgency. Basically, if you build some ledge somewhere with the intent to populate it later and have monsters attack the player from it, just test a couple of different monsters to make sure it works. You can always adjust later, but it's easier to try and get right first time.

Layouts where the route goes through an area multiple times from different angles is something I love about Quake maps. It's not neccessary to do this, but it's fun to revisit areas sometimes. CZG tends to do this really well in his maps, so have a look at them (esp. honey!).

One thing I'm not sure I gave much though to before recently is the way you introduce the player to keys and key doors. Generally you want to block the player's path with a locked door, then send them on a trip to get the key, which may be located tantalisingly near to the door and in plain sight but unreachable. Don't give them the key before they get to the door (this could happen in a very non-linear map by accident I guess) because there is no point otherwise. Sorry if this point is crazy obvious :) 

Good Tips, already helped!

The CZG (especialy honey) maps where btw the reason i wanted to make a q1 map, their just gorgeous and interesting to play.
But realy realy hard to imagine how to build something like this, at least for me ^^ 

Than - good points.
I agree with Sock that I'd love to see more mappers doing blogs detailing work in progress, mapping styles, etcetera etcetera.
I'd love to see a video of Negke, among others, making a speedmap, for example. 

Is there any reason why Imps do not follow path_corners apart from the fact that they are little imps? 

Drew:
so people really want blogging on that stuff? i started with some doom mapping but figured no one really cared as it ended up not really being all that interesting to read. "i put in a room today... also, i textured stuff" etc...

Mike:
imps?
i'm going to guess you are talking about the flying imps from Hx2 that kinn ported over?
if so, then your question is actually related to flying monsters not following paths.

essentially, a monster won't move up or down unless it has the target as an enemy.
there's some code stuff but essentially, you can haxor it in yourself by doing this: http://celephais.net/board/view_thread.php?id=60097&start=601&end=601

ALSO what's not mentioned in that post is that the path_corners must have a movetype other than MOVETYPE_NONE (which is 0, so any entity that DOESN'T set a movetype has MOVETYPE_NONE).

so in your path_corner spawn functions, add in a self.movetype = MOVETYPE_NOCLIP;. 

A bug in Qouth code where the monster will not use the path if positioned directly above the path_corner. Apprently this bug was inherited from elsewhere.

Could well be fixed in latest version, or just not be the problem - but worth bearing in mind. 

As I remember it was if the monster shared its starting position with its first path_corner.

As Necros mentions vertical position is irrelevant for Quake Ai, apart from fliers and swimmers wanting to stay above their chosen enemy. 

the bug to which you are referring to was introduced by me.

it was so 'wait' keys on path_corners would allow monsters to stand around for a few seconds before moving on, and the way i checked if the monster had 'arrived' was by measuring the flattened distance to the corner to see if it was less than 4 units.
unfortunately, as you pointed out, it has the side effect of making monsters not register anything if they start on the corner. :( 

I typically like it.

haven't looked at this in depth but it might be cool, for example: http://www.rockpapershotgun.com/tag/level-with-me/ 

i guess.
whatever. 

Learn something new every day. Think I saw this in Quoth2 content.