Is dated 25/11/1996.

But I am assuming that if I run FQ directly from the .exe file, it will link to the ID1 folder and will not somehow use another -game setting? 

I moved everything out of the Quake folder and just left the ID1 folder in there.

Anything in the config file that might affect things?

No, hang on; I have a map using my progs.dat that does not display the problem. FMB_BDG has a teleporter to get you to a secret area and there are no issues at all. The map that displays the error is the next map in this series. 

I only have FQ and have never used anything else. I will down load something else and try it - any suggestions? 

My point is, even if Fitzquake displays the warning, it doesn't prove there's a serious issue. It may just as well work fine in other engines. I also get the sv_touchlinks (engine) warning in some of my maps, and they still work flawlessly. 

It's true that the map does not crash (because FQ mugtraps the error) and the teleporter works. So it can be released like that. I just don't like the message popping up on screen: it's wrong.

I also find it annoying that sometimes it errors and some times it does not.

Now here's a funny thing. In one instance, a teleporter is actually being used as a short-cut. If you use it (by finding a secret) you teleport to immediately behind a monster (shhh, he does not know you're coming), and you get the error message. However, if you kill that monster first (he is nothing to do with the secret, and he is not targeted, he's just an ogre plain and simple) and then go and do the secret teleport, there is no error.

I know my maps are not exactly state of the art, but I do try to get them looking good and playing good. I guess this is compromise time, but as it is my last map, I would have preferred if it did not stutter over such a thing. 

I think I can eliminate the message! If you avoid spawning the tdeath trigger during the teleport touch function, instead just spawning a helper entity with a think function that will spawn the tdeath as soon as possible. The think I wrote was:

void() spawn_tdeath_wrapper =
{
spawn_tdeath(self.origin, self.enemy);
remove(self);
};

and the replacement for the spawn_tdeath call in teleport_touch goes like

tdeath = spawn();
tdeath.origin = t.origin;
tdeath.enemy = other;
tdeath.nextthink = time;
tdeath.think = spawn_tdeath_wrapper;

Trying your test map in glquake doesn't cause a crash though, even before the fix. I think I can see why the error message occurs intermittently and is essentially benign. When a touch even is fired, the engine is in the middle of an internal physics function which holds some state information about the world. That state is an except of a linked list holding the physical entities in the world.

When the tdeath gets added, this is a physical entity which need to be included on the list. If we are very unfortunate then the little bit of the list that the function already has is now out of date. In less careful engines the function does not even notice that it's bit of information is out of date. Does this matter?

Well, that depends. If you care that the function might be skipping our new entity then there is a bug, but we've already acknowledged that we don't expect reliable collisions this frame (that's why force_retouch is set to 2).

I think there's also a more dangerous problem which can arise in this code if the mismatch is because the QC removed an entity, because then the engine is using out of date information to access a dead entity. Dead entities get their physical properties removed so expectations might get violated.

Since we're adding not removing, that class of error can't happen, so I'd expect we are safe. If the error message is irritating the QC workaround above exists, although it might add an extra frame worth of delay to telefrags so it's not entirely without tradeoff. 

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.