You make the terrain out of wedges, then lower and raise verts to get what you need. Wedges are more difficult to break by vertex manipulation than rectangles.

Garden gnomes you can export from a 3d package - Qme can get you there with enough patience. Other features like a gazebo, rockery or magic waterfall + rainbow are a bit more complicated.

Oh yeah, and fish will most likely get stuck on the sloping edges of the pond. 

fdsafdsafdsa 

tetrahedrons are impossible to break. 

Thats for sure. More difficult to use though.

I tried developing a decent rock strategy for them but things got a bit too organic - everything ended up becoming a slope. and adding to it just decreased the inclination.

clockworkdroog:

http://www.katsbits.com/htm/tutorials/trisouping.htm

Apparently the method is called trisoup - which sounds stupid, but there you go. 

Thanks for the help. 

"trisoup" usually implies an aribtrary pile of triangles with no regular connectivity. At the very least when you make terrain out of triangles, you're probably at least making one continous sheet. And usually people arrange the triangles into a grid, so you end up with a pretty well-ordered array of triangles, basically a heightmap. 

A trisoup would have them intersecting, I assumed. Technically would work just as well if you stuck to a decent sized grid, but would be a mess to work with. 

agh, how many times will i be deceived by the stupid 'pitch roll yaw' explanation in the quakec comments and quake.def file. It's pitch yaw roll, damnit. 

Rollin' 

I've installed WC 1.6 to keep things old school.
Something blocking the oldschoolness of my map making is the fact that my copy of quake now resides in my steamapps folder. Perhaps this is why I get this message when I try to compile my map?

nput file: C:\Program.map
Output file: Files\Steam\steamapps\common\quake\id1\maps\square01.bsp
---- LoadMapFile ----
*** ERROR 34: Failed to open C:\Program.map: No such file or directory

Elapsed time : 0:00

Peak memory used : 0.0 MB

** Executing...
** Command: Change Directory
** Parameters: C:\Program Files\Steam\steamapps\common\quake


** Executing...
** Command: C:\Program Files\Steam\steamapps\common\quake\quake.exe
** Parameters: -window +map square01

Hope I'm not retardedly missing something obvious.
Thanks! 

I'm guessing it's upset about spaces in path names so that "C:\program files\..." gets truncated to "c:\program". Try installing into a path without any spaces in the name.

Or, if possible, try to surround your paths with quotation marks but that's probably not going to work in this context. 

just keep everything inside c:\quake\id1\maps and nothing can go wrong. tools, source, everything. 

What you have to do is make the path name absolute - with a " at the start and end, that way it forces the spaces to be visible to shitty windows.

So

C:\Program Files\Steam\steamapps\common\quake

Becomes:

"C:\Program Files\Steam\steamapps\common\quake" 

You're suggesting I add quotes on either end of the directory in the 'game' tab, correct? this isn't working.
I didn't have these problems with the steam version of half life, but I was the newer version of hammer, not worldcraft. Maybe I'll try wc 3.3... 

Worked for me . . . 

Now its working, though worldcraft is telling me that my map wasn't built.

Whatever. I can play my maps now, thanks guys! 

Is there any engine whose software renderer works in WinXP? 

aguirre's winquake should work in winxp 

winquake.exe 

has a software engine. You get two executables in the file. A GL engine and a software one. It works pretty good IIRC. 

Hmmm, must be something with my setup. Every engine crashes right after creating the window, with some variation on the "illegal memory write" error.

I wonder if the assembly code doesn't quite work on AMD? 

JoeQuake and stuff should work no problem, perhaps you should update your graphics card drivers? Or DirectX.

I'm quite sure your AMD CPU is 100% compatible with the assembly code in SW Quake. 

Had to turn off Data Execution Protection - apparently the sw renderer uses self-modifying code. I remember now I had to do the same thing to get Unreal to run. 

Shouldn't it be possible to manually define the volume of a point (notnull?) trigger with absmin/absmax/size ? 

Thinking of that for triggers without models.