...is some of the numbers at the end, which represent brush flags, surface flags, light values, etc. And I think HL has a different texture alignment format. But the brush geometry itself is the same across all of them, I think. 

is some of the numbers at the end, which represent brush flags, surface flags, light values, etc.

Yeah, that's certainly the difference between Q1 and Q2/3 .map format. That's as explained in the older mapconv tool readme.
I'm not sure what the particular flags/info in the HL format .map are, but ages ago I successfully opened some Q1 .maps in WorldCraft 2/3 without any conversion. The texture info was indeed lost, but the brush info required no translating. 

cheers for the replies - here's some info which might be useful. I tested in gtk, creating a "map" consisting of one 128x128 brush centered on the origin. This is the Q1 .map

// entity 0
{
"classname" "worldspawn"
// brush 0
{
( 64 64 64 ) ( 64 -64 64 ) ( -64 64 64 ) NULL 0 0 0 1 1
( 64 64 64 ) ( -64 64 64 ) ( 64 64 -64 ) NULL 0 0 0 1 1
( 64 64 64 ) ( 64 64 -64 ) ( 64 -64 64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( 64 -64 -64 ) ( -64 64 -64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( -64 -64 64 ) ( 64 -64 -64 ) NULL 0 0 0 1 1
( -64 -64 -64 ) ( -64 64 -64 ) ( -64 -64 64 ) NULL 0 0 0 1 1
}
}

Note that the half-life version would be very similar to the Q1 version, but GTK wasn't playing nice with me in HL mode for some reason, so I couldn't test. The only difference between HL and Q1 afaik are some extra texture alignment properties. The way it stores brush geometry is the same. The HL .map format is detailed here:

http://collective.valve-erc.com/index.php?go=map_format

and this is the same "map" again, remade in D3 mode:

Version 2
// entity 0
{
"classname" "worldspawn"
// brush 0
{
brushDef3
{
( 0 0 1 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 1 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 1 0 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 0 -1 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( 0 -1 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
( -1 0 0 -64 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "_emptyname" 0 0 0
}
}
}

As you can see, even the syntax for the brush coordinates are stored differently. Here's as much as I could find regarding the D3 map format (I didn't look very hard, mind):

http://www.modwiki.net/wiki/MAP_%28file_format%29

Getting from HL -> Q1 is something i've done before. SPoG once made a quick build of GTK for me that opened a HL .map and saved a Q1 .map. I've lost this unique build ever since I had to reformat my laptop; SPoG, I don't suppose there's a chance you've still got it saved somewhere?

Daz: I thought mapconv.exe only worked for swapping between Q1 and Q2/3, or is there another version around?

I hear that getting from Q3->D3 is possible too, something about DOOMEdit will import a Q3 map that's been saved in "brush primitives mode". If true, then HL -> Q1 -> Q3 -> D3 might be achievable with existing tools, but I'm currently still stuck on the first stage... 

can do several (if not all) of those formats natively and usually you can also choose between several output formats for a specific game. I can e.g. get it to output a Valve 220 (Hammer) format map from a Q1 source directly.

I've also used it for converting from Hammer format maps to BSP editor format. The only obvious problem then is the lost extra tex info. There might of course be accuracy losses as well if it's a big and complex map. 

I have a gold key that targets other events e.g. spawn a monster. I collect the gold key and sure enough, the monster spawns in.

In another map, I have exactly the same set-up but the monster doesn't spawn in. In the editor I can see that the key is linked to the monster, and target and targetnames are correct.

Why would it work in one map and not in the other? 

Wait, so the key is targetting the monster itself? Does that mean you're using a modified progs like spawn64, where you set a flag on a monster to spawn it? It's possible that custom code would behave oddly. Otherwise I can't see any reason why a key would fail to target something if you replace it with, say, a button with the same target. 

... more haste, less speed.

I hadn't vis'd the map. The monster was there, I just couldn't see it. Ho hum! 

Wasn't ignoring you, our messages overlapped.

And yes, I'm using your 'style 1' idea and it all works just fine. It's just that Qbsp takes 3.5 minutes and Vis takes another 3, so I don't use it (or Light) when I'm only doing quick checks.

As I say, everything is all right. I might even post some screenies sometime. 

You might want to check out the tutorial I posted on inside3d a few months back.

http://www.inside3d.com/showtutorial.php?id=171

It's a kinda updated version, makes it so it uses spawnflags(which does make more sense really) and cuts down on the amount of code you need to change to integrate it(you no longer need to modify each monster to teleport it). Practically though it doesn't add anything the old code didn't do, so there's no "need" to migrate the map if it works as it is. It is a much nicer base to work from if you need custom monsters though, so I thought I'd advertise it here for people to use in future. 

i like your method a lot more preach. much cleaner. 

necros if u have msn add me trinquinha@gmail.com

i need last .mdls :) 

Yes, I agree with necros; a much neater solution.

However, I had already changed all the monsters to the 'style' method sometime ago and as everything is working OK, I'll stick with it now. 

cheers for the quark info, although i may have a solution in the pipeline anyway now 

Just a silly thing really: I'm using your engine to test my map as Fitz balks with the SZ_GetSpace error (I know what I have to do), and I notice that if a monster's bounding box overlaps an edge (perhaps he's standing on a crate) your 1.31 engine gives a 'walkmonster stuck in wall' type warning. He's still available for slaughter in-game so it is no problem but I don't see this kind of warning in FQ.

It only seems to happen in Fitz if the monster is actually inside or partly inside a brush.

Umm, just an observation. 

OK, I'll throw it open - can anyone help with my query in post #5452 above? 

STEP 1. Make a brush or group of brushes to rotate.

STEP 2. Place an info_rotate entity at the centre of rotation. Give it a targetname

STEP 3. Convert the brush(es) from step#1 into a rotate_object, give it a targetname, and set it's target to the info_rotate from step#2

STEP 4. Create a func_rotate_entity - placement doesn't matter, but it's a good idea to put it near the object it's related to (directly above the info_rotate seems like the best spot). Set it's target to the rotate_object from step #3 and fill in the rest of the data. NOTE: the 'rotate rate' must be in this format '0 0 0' each number controls the rate of rotaion in each axis (x y z) - the higher the number, the faster the rotation. Positive numbers are clockwise and negative numbers are counter-clockwise. You can also target this entity from a button to start/stop the rotaion, but you'll also have to set it's 'TOGGLE' (and possibly 'START_ON') spawnflag(s).

STEP 5. Build!

You should now have a continuous rotating object, doors are similar to set up. Rotating platforms are similar but need path_rotate entities to follow They are a pain to setup and are not covered here.

I found it in the extras_r4 I'm working with.
http://members.home.nl/gimli/rotate.html 

It is for the Paroxysm Mod, so I don't know if it is the same for the hipnotics.qc 

it's the same. Hiprot.qc is in the compile list for Paroxysm's Extras.

This brings up an idea Kell and I tossed around once. Anyone have ideas on making the rotation code easier to use? I suggested that because the Half-Life rotation code is easier to use for a mapper there has to be a better way to do it, and Kell reminded me that the hull structure is different in Half-Life and that could possibly account for the difference.

It is one of those things I'll need to get around to at some point in time for my own modding needs, but I would be interested if someone like, for instance QuakeCSuperFly Preach, has already done so or given some thought to it. 

half-life rotation and quake2 rotation are easier becuase they support "origin" brushes, which define the rotation point. Without that, we need the "info_rotate" entity.

however, I have a theory that it would be possible to have origin brushes supported in quake simply by adding support to qbsp.

And then you could write your quakec rotation code to take that qbsp change into account (should be much easier -- rotating brushes in quake are totally hacked and becuase all bmodels have their true origin at the center of the world.) 

Preach, i just used your monster spawning code from i3d. Very straightforward. Thanks!

http://www.inside3d.com/showtutorial.php?id=171 

http://members.home.nl/gimli/doors.7z

can't time them to shut, though they turn at the same time. 

This is a video of the problem I have:-

http://www.mysharefile.com/v/2534536/rotate_judder_v2.avi.html

(It's 6meg so if you are on dial-up it's probably not worth it, and my apologies for the 12 secs delay before you can download)

In-game the judder is much worse, at least twice as bad - the video capture program affects the fps so this extract may not come across as anything to worry about.

Both doors are set up the same with the exception of the direction parameters. 

You have your rotation bits slightly mixed up.

I think this is what you want: from the player's point of view whan you walk on the button the two doors open inwards and stop until the second button is walked on (actually, either button toggles the doors).

{
"classname" "rotate_object"
"target" "t10"
"targetname" "right_door"
{
//"0000" "0"
( 16 0 -272 ) ( 16 88 -272 ) ( 16 88 -400 ) DR05_2 384 -128 0 0.25 0.25
( 0 0 -400 ) ( 0 88 -400 ) ( 0 88 -272 ) DR05_2 0 -128 0 1.0 1.0
( 0 88 -400 ) ( 16 88 -400 ) ( 16 88 -272 ) DR05_2 -64 -128 0 1.0 1.0
( 0 0 -272 ) ( 16 0 -272 ) ( 16 0 -400 ) DR05_2 -64 -128 0 1.0 1.0
( 0 0 -400 ) ( 16 0 -400 ) ( 16 88 -400 ) DR05_2 -64 0 0 1.0 1.0
( 0 88 -272 ) ( 16 88 -272 ) ( 16 0 -272 ) DR05_2 -64 0 0 1.0 1.0
}
}
{
//"0000"
"classname" "info_rotate"
"targetname" "t10"
"origin" "0 88 -272"
}
{
//"0000"
"classname" "func_rotate_door"
"target" "right_door"
"rotate" "0 1 0"
"targetname" "door_mover"
"origin" "0 88 -272"
"angles" "0 -90 0"
}
{
"wait" "2"
"classname" "func_button"
"target" "door_mover"
"angle" "-2"
{
//"0000" "0"
( -120 72 -396 ) ( -120 -72 -396 ) ( -120 -72 -400 ) FLOOR01_5 0 -456 0 1.0 1.0
( -64 72 -400 ) ( -64 -72 -400 ) ( -64 -72 -396 ) FLOOR01_5 0 -456 0 1.0 1.0
( -64 -72 -400 ) ( -120 -72 -400 ) ( -120 -72 -396 ) FLOOR01_5 -8 -456 0 1.0 1.0
( -64 72 -396 ) ( -120 72 -396 ) ( -120 72 -400 ) FLOOR01_5 -8 -456 0 1.0 1.0
( -64 72 -400 ) ( -120 72 -400 ) ( -120 -72 -400 ) FLOOR01_5 -8 0 0 1.0 1.0
( -64 -72 -396 ) ( -120 -72 -396 ) ( -120 72 -396 ) FLOOR01_5 -8 0 0 1.0 1.0
}
}
{
"wait" "2"
"angle" "-2"
"target" "door_mover"
"classname" "func_button"
{
//"0000" "0"
( 112 -72 -396 ) ( 56 -72 -396 ) ( 56 72 -396 ) FLOOR01_5 -8 0 0 1.0 1.0
( 112 72 -400 ) ( 56 72 -400 ) ( 56 -72 -400 ) FLOOR01_5 -8 0 0 1.0 1.0
( 112 72 -396 ) ( 56 72 -396 ) ( 56 72 -400 ) FLOOR01_5 -8 -456 0 1.0 1.0
( 112 -72 -400 ) ( 56 -72 -400 ) ( 56 -72 -396 ) FLOOR01_5 -8 -456 0 1.0 1.0
( 112 72 -400 ) ( 112 -72 -400 ) ( 112 -72 -396 ) FLOOR01_5 0 -456 0 1.0 1.0
( 56 72 -396 ) ( 56 -72 -396 ) ( 56 -72 -400 ) FLOOR01_5 0 -456 0 1.0 1.0
}
}
{
//"0000"
"angles" "0 90 0"
"origin" "0 -88 -272"
"targetname" "door_mover"
"rotate" "0 1 0"
"target" "left_door"
"classname" "func_rotate_door"
}
{
//"0000"
"origin" "0 -88 -272"
"targetname" "t10"
"classname" "info_rotate"
}
{
"targetname" "left_door"
"target" "t10"
"classname" "rotate_object"
{
//"0000" "0"
( 16 -88 -272 ) ( 0 -88 -272 ) ( 0 0 -272 ) DR05_2 -64 0 0 1.0 1.0
( 16 0 -400 ) ( 0 0 -400 ) ( 0 -88 -400 ) DR05_2 -64 0 0 1.0 1.0
( 16 0 -272 ) ( 0 0 -272 ) ( 0 0 -400 ) DR05_2 -64 -128 0 1.0 1.0
( 16 -88 -400 ) ( 0 -88 -400 ) ( 0 -88 -272 ) DR05_2 -64 -128 0 1.0 1.0
( 16 0 -400 ) ( 16 -88 -400 ) ( 16 -88 -272 ) DR05_2 0 -128 0 1.0 1.0
( 0 0 -272 ) ( 0 -88 -272 ) ( 0 -88 -400 ) DR05_2 384 -128 0 0.25 0.25
}
}

If you move your existing doors, buttons and entities out of the way and then save the map, you can then copy and paste the above straight into your map file, it should work.

The func_rotate_door is not the door but the entity that causes the door to move. The door itself, the bit that you see move in the game, is called rotate_object.

I've copied this from the map file I just created based on your sample, so it is not in any sort of order but once you see it in the editor it will probably make sense.

Let me know if this is OK but if not, I can always e-mail the map to you. 

By 'inwards' I mean that the doors open away from the player. 

half-life rotation and quake2 rotation are easier becuase they support "origin" brushes, which define the rotation point. Without that, we need the "info_rotate" entity.

however, I have a theory that it would be possible to have origin brushes supported in quake simply by adding support to qbsp.

And then you could write your quakec rotation code to take that qbsp change into account (should be much easier -- rotating brushes in quake are totally hacked and becuase all bmodels have their true origin at the center of the world.)

What?! that'd be... well, awesome. i would absolutely love to know how this is done. :o