i think you could also do an overly large findradius then compare bbox absmin/maxs?
that would avoid using force_retouch entirely. 

The force_retouch isn't something new, it's been there always to handle a teleporting monster landing on a standing monster. If a monster doesn't move then it won't collide with the tdeath without it, and force_retouch seems designed for this situation. I mean you could reimplement the whole physics engine in QC and not bother with movetypes : - P 

Annoying messages eradicated. 

Hi Guys!
I'm new to q1 mapping, and i'm wondering if there are any good tutorials out there.
I'm familiar with q3 mapping, so i'm mostly interested in the differences.
Or if it isnt too anoying i could also ask the most necessery stuff here.
Thanks! 

there's bunch of basics there
http://www.quake-1.com/wc16a-tutorial/

though, modern mappers mostly use radiant, but the basics are basics ;) 

If you're familar with Q3 mapping, just look at a Q1 editor def file. You'll see a list of all entities with short descriptions that should give you a basic overview. Maybe open some map in the editor, from the id map sources maybe, for concrete examples.

Q1 mapping isn't too different from Q3, except it requires texture wads, there are no curves and no caulk, and a few more entity types (which are pretty self-explanatory for the most part).

Here is a set of compilers and some other tools that might come in handy at some point. A fairly large collection of texture wads can be found here. If you use Radiant, the .wad has to be in the ID1 folder, and you need to add "wad" "path\tex.wad" to worldspawn for QBSP. 

If you're into Radiant, I suggest you give Netradiant a try, see if it works for you. It's an updated version of GtkR 1.5.

Compiling a map works like with q3map2, only there are three tools instead of one: txqbsp, light, wvis.

Fitzquake or Quakespasm are good engines for testing; Darkplaces is not recommended. And be sure to enable developer mode (console) before loading the map. 

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?