I know RMQ engine supports masked textures (to make fences and such), but which other engines support it? 

DirectQ. 

And FTE, I just checked. 

I had a look anyway after I posted. It seems this is a standard feature of RMQ and anything that forked from fitz after a certain point. 

Yeah, using sunext and skylight now with all the bells and whistles :) 

While waiting on the Quoth update. I'm thinking of doing a DM map. I want bot support because I don't DM. What would be the best bot to use? I want to use waypoints. 

Has a nice waypoint system.

You build it in-game by placing points then dump it to an external .way file that you bundle with the level. 

Sounds good. I think I played with that on a few years ago. 

Hi iam just wondering if there is anyone can tell me on how to make an elevator lift that i make? I know it is a noobish question but you can contact me on x-fire blueultima thank you for anyone able to get back to me. 

Build the elevator in its extended position (up) and make it a func_plat. If it has a cylinder to the bottom, you're set. If it's a floating elevator, set its height key to determine the moving distance to the ground.
With the plat_low_trigger spawnflag, it can be made to only start moving when stepping onto it from below, otherwise it will also start moving if you jump down the shaft. 

http://felikkz7.free.fr/tuto_pipes.html

This is really interesting 

Any tutorial that starts with 'set the grid to 1 unit' should be cause for alarm. Nothing about those pipes are done correctly. 

awesome scamps...

I have to say I really should get some pipe prefabs made up (especially if I do any more base maps). It'd be nice to have a 2d brush shaper/rotator tool like in UED. 

I didn't see anything wrong with the tutorial's end result though. Quark users should check out:

http://quakeone.com/forums/quake-talk/other-games/5783-hexen-ii-community-work-discussion-90.html#post127434

follow the links, could be useful. Grid at 1 unit shouldn't be a problem. I'm making brushes at 0.2 units max thickness, all on grid for .bsp models. 

i didn't know arghrad had phone shading:
Arghrad's Phong shading feature allows smoothing on rounded shapes. Two conditions are required to obtain this effect:
- each face must have a light value >0
- the texture must be wrapped without break

I think better criteria would be to have some critical angle on which phone shading would be applied (let's say 45 degrees). I wonder if that could be added to other light utilities? 

that's how q3 light tools do it.

Arghrad works but is very manual, you can effectively make any edge "soft" or "hard" by carefully setting adjacent faces to have the same or different light values. 

Apparently Quark doesn't fuck up on rounding float-point like most other editors do.


Necros: Q1rad does that (essentially a HL light compiler made to work with Q1 BSPs) 

yeah that�s neat! 

i was hoping to get that functionality in a modern light util though... i'd really like to keep all of aguirre's enhancements as I couldn't do lighting without them. 

Quark has the same problems with floating point coordinates as other editors, unless it knows magic ;-). What does Quark do better than other editors? 

Quark doesn't mess up brushes on non-90� rotation. As that tutorial in particular shows it works fine, but wouldn't work in any editor I know - Radiant, WC or BSP - the rotated brushes would be slightly distorted and unaligned. Apparently Quark has better precision.
Also Quark has 3-point float texture coordinates keeping the textures aligned even with rotation.
I'm not a quark guy, don't know what else it does better. 

is also very well implemented. 

You're talking about two different things. I'm not sure about BSP, but neither WC nor Radiant support floating point coordinates at all. That's why brushes get distorted when you rotate them.

Quark allows floats for the plane points that define a plane, but that comes with its own set of problems. It can cause microleaks. It's not a problem for pipes, but as soon as you have brushes with floating point coordinates which are supposed to seal the map, you can run into all sorts of problems. But maybe Quark fixes these problems somehow?

The texture alignment thing is actually because Quark implements the Valve 220 map format, which later versions of WC also support. 

and that's all I'm going to say about that.

When I started this map I made a promise to myself that I wouldn't exceed any of the normal Quake engine limits. I figured if I had no limits, I'd probably never finish the map (been working on it since 2007, so maybe that logic was flawed).

I've been re-texturing the map and in the process I made a few (very few) changes to the brush work. I'm absolutely certain that the changes reduced the number of actual brushes and visible faces, but the marksurfaces increased from 31763 to 31892. That's over 100! I only changed like 6 brushes. Very annoying.

Some adjustments to the geometry are unavoidable in order to work with the new textures, and I'm probably less than halfway done at this point. I sure hope I don't hit the limit before I finish the re-texturing. 

I think the issue is that the number of marksurfaces can be affected by the order in which brushes are compiled into the map. It's an unstable algorithm. Deleting a brush might move another one higher up the compile limit, where it doesn't fit as efficiently.

Has anyone ever tried permuting the order of the brushes in the compiler, either according to some design (like sorting on the x axis or largest to smallest volume) or even randomly? Given how much faster bsp is than vis, I'm sure that running the former a few dozen times with different orderings would not be a big burden. If you have a target like marksurfaces in mind, you can then take the ordering which maximises it.

I suppose what with the map format being basically text, you could even do it with some kind of script. Generate a bunch of permuted map files, compile them all in turn, and keep the one with the best output...