as in not distorted to an extent that is noticeable in game, and the brushes are not divided to the extent that they are overly simplified.

I have converted all of the original Q3 Arena maps using bspc and then converted over to Q1 maps for testing purposes, and it works fine without a hic-up. 

moving ones, like the expanding intestine like things in Q3DM4 do not translate well. 

I contacted the guy who wrote the md2, md3 and Q3 bsp converters for Blender several months ago (http://scourage.servebeer.com/programming/blender/index.html) to throw some ideas around and this idea is something we discussed.

Mesh to brush conversion has been a holygrail of mine for a long time now, since that article advanced brushes appeared on Rust that makes it sound like the easiest thing in the world to accomplish.

Any inaccuracies of the fallowing are my fault and not his.

The formula would perhaps go something like this -- deviding the surface into trigs you determine the width and legnth of the mesh from the visibility set of the adjacent normals, with the normal direction being the eventual thickness.

Brushes are volumetric, so you will have to determine a volume of at least 1.0 when calculating the thickness (width * height(thickness) = 1.0) So, a trig side of .25 will need a height of .40 to be an actual brush.

After this, determine within the group of touching trigs which of them is the thickest (and therefore the smallest brush) and adjust the height for the other brushes of the set to this size for a more coherent brush model unit. 

Good to see you got it going. And like everyone has said, you can't use Curves/patches with Quake, well without using engines that allow it. Also somethng that I forgot about (Blame DooM3}, is that aguirRe's tools will do the Q3/Q map format converting for you (with the use of the switch), doing away with the need for a seperate prog to do that step. 

Is it my imagination, or do I recall someone once wrote a cool interface for QuakeC editing. Googling doesn't yield much. Any thoughts? 

somehow, i doubt it would be any good. i am pesimistic hero. 

I have a gangway over some slime made of bars.
Monsters (knights, ogres) can't walk over this bars. Is there any way to enable this?
Check the picture:
http://republika.pl/quake_1/way1.jpg 

If you mean that monsters fall between the bars, just uses clip brush in order to plug the holes... I can't see another way to do that... 

I want monsters to walk over the bars. The distance between bars isn't big. The player can walk over easily. I have tried to use clip brush to cover the whole thing but it didn't help 

over the bars and see if it works then or not. 

That's due to a bug in the monster AI... You can attempt to place a clip over those bars, may even that may not work... I know last time someone had this issue, the best solution was to place monster jumps at either end that just so slightly hopped them onto them. Still not a perfect solution, but may work with some experimentation.

Otherwise, you may have to bite the bullet and remove the bars, making a flat bridge for them to walk over. 

...and used a single clip brush that was one unit taller than the offending brushes. The clip brush is invisible to the player and the one unit difference is not noticable as a 'step' during play. The monsters happily walked on the clip brush.

That may help in this case. 

Line traces used in the walkmonster movement code are done in hull0, rather than the correct hull for the monster's bbox. Therefore, a monster attempting to navigate "broken ground" thinks he's a point object and therefore won't attempt to pass over small gaps in the geometry, that would otherwise be filled in the larger hulls. Placing clip brushes will have no effect sadly.

You could place an invisible, but solid bmodel in the gaps, and monsters will "see" it as solid, but it will block everything, including gibs and missiles, so that may not be the ideal solution. 

oh if that's the case, I stand corrected ^_^ 

Another suggestion would be to alter the design from bars to a grill, like the one in dm1 near the YA alcove. The monsters will still wander slightly erratically but they should be able to navigate down the length of the longitudinal brushes. 

No, you're right. A clip-brush does not solve this particular problem. I am confusing things with my use of a one unit clearance in another problem. It should be mirror, signal, manouvre; not manouvre, signal, mirror :-)

Sorry Ankh. 

Here's my problem:

- In my map is a section with three doors. Each door has 4 pieces - like a plus sign and each of the 4 pieces moves away from the center when triggered. The first door works fine and is triggered by a trigger_multiple. The second and third doors work fine if they only consist of 2 pieces. I button triggered them for testing as I first suspected the trigger_multiples used before. When I make the other doors 4 pieces, Quake (FitzQuake) fails to load the map and displays info and declares a program error. Here are the main comments:

Program Error (map doesn't load)
Object error in Linkdoors
Cross Connected Doors

What really confuses me is that the second and third doors are duplicates of the first door with thier names changed. They work with two but not 4 bars. The first door works fine with 4 bars.

Any clues?

I can provide a small map file upon request. 

cross-connected doors means you have the doors triggering each other as well as being triggerd by another entity.
Enable the 'Do Not Link' spawnflag. 

That was a fast reply and accurate.

Problem fixed - thanks. 

Is it possible to determine coordinates of the place where you are while playing a Q1 map? 

Try typing edict # on the console, and replace the # with a number. It will print out info about that specific edict (entity) in the map.
Edict 0 should be the world, edict 1 should be the first link in the bodyqueue, and so on, so if you continue increasing the number you should eventually stumble across the player edict/entity (it should be around 8 or 9 or so iirc).
In the printout from the player entity, there should be a line "origin" that contains, (duh,) the origin of the player at that time.
There's also a field "angles" (I think) where you can read the view angles of the player, in case you need that for setting up an info_intermission or something.

(Of course, the most practical solution would be to make a tiny adjustment to the qc, so you could make, say, impulse 167 print out the origin of the player to console.) 

(Of course, the most practical solution would be to make a tiny adjustment to the qc, so you could make, say, impulse 167 print out the origin of the player to console.)
Excepts it's impulse 99, I think. 

The Hipnotic progs.dat has an impulse command that dumps the player coordinates to the console. I can't check what it is though, as I'm at work atm. 

use fitzquake
type 'viewepos' at the console
and you'll get your current coordinates

also, you can get coordinates of the point you look at, type 'tracepos' 

I will check the qdqstats solution first.

Also I have used Kells suggestion to change the design from bars to grill to enable monster walk over it. Looks a bit strange how monsters search for the way on the grill, but at least they get thru (it takes some time however).