OrbWeaver

The monster clip is especially important, this should be used everywhere it can. Basically anywhere a monster cannot go can be sectioned off by adding a brush textured with the appropriate clip texture to remove the geometry from the AAS. This includes, for example, putting a clip "wall" over a mesh or patch fence which the AI cannot get past.

OK, although it will need to be documented as part of the installation that either Medium quality must be set, or the respective CVARs will need to be enabled (probably image_usePrecompressedTextures, image_useCompression and image_useNormalCompression).

Does Doom 3 not load a DDS file in High or Ultra even if there is no TGA image? This could present a problem if DDS is going to be used as the primary format for textures.

I never really understood collision models, in my view you should just be able to create a model in your 3D app along with the actual mesh, and use it as the collision model - however when I made a mover I had to muck around with drawing brushes and exporting or something like that before the mover would respond properly.

It will run, but you won't be able to do anything as none of the assets will be available.

Lever locks are exceedingly difficult to pick, which is why (at least in the UK) having a 5-lever lock is a prerequisite for home insurance.

You will need to get set up with Scons (which requires Python or ActivePython on Windows) and the GCC toolchain (available as MinGW on Windows). If you are on Linux you will need to get these tools from your distro. These will allow you to build DarkRadiant. If you want to develop you will need to know C++, there is a thread in the public forum with people's suggestions for learning resources. I found http://cma.zdnet.com/book/c++/ to be quite helpful.

GTK itself is not hard although it can be quite mucky with its C API, but using it to generate a usable (rather than merely functional) GUI can be more challenging for the inexperienced. The DarkRadiant code is available under the GPL anyway, so if you are interested in helping feel free to download and look through the code. It is available by Subversion at https://svn.sourceforge.net/svnroot/darkradiant and requires GCC and Scons to build.

Hmm..that depends. Greebo - do you have any experience writing GUIs with GTK, or with OpenGL/graphics in general?

I have to agree on that count - Sparhawk's suggestion sounds more appropriate for a property which makes a link between two specific objects (such as target) but my understanding of Stim is that it is a generic broadcast/reception system that does not involve links between individual pairs of objects. This already seems to work actually, since the paths use "target" which displays a connecting arrow in the 2D view.

OK, so they are just normal properties. The mapping of enum->integer is easy, I can code up a Property Editor which allows a list of number/string mappings to be defined in the XML file and selected from a dropdown. The multiple thing is something I completely forgot about when writing the Entity Inspector, assuming that there would only be a single instance of each property so "property1", "property2" etc are not handled. I think the best way of handling this without too much recoding would be to add an extra layer of expandable tree below the properties themselves (check the DarkRadiant screenshots for what I'm referring to), so you would have: + Stim/Response | |-- + stimkey_something | |-- 1 value | |-- 2 value | |-- + stimkey_somethingelse |-- 1 value |-- 2 value There may still be a use for a separate dialog though, rather than exclusively using the Entity Inspector (even if ours is a lot better than D3Radiant's).

What are spawnArgs exactly? Are they another kind of keyval added to an entity? This sounds a little more involved than a standard Property Editor, maybe a separate GUI will be required. Would this be more or less of a priority than a proper model selector with preview, which is what I intended to start working on once the 0.5 bugs are ironed out?

That will solve the problem of it being invisible from the back, not the side. A polygon will appear invisible from the side because it is infinitely thin.

If the curved parts are an alphamap, won't parts of the model be invisible when viewed side-on?

_s has always stood for specular, there is no change proposed in this regard. I suppose for self-illumination an additive stage could be named _a

I have done, but didn't really like it because 1) I am not spectacularly good, and even with appropriate ratings tended to get my ass kicked, and 2) I much prefer the face-to-face social setting. Without the psychological cues the game loses a lot of its appeal. Fair point. I only ever play on God mode and spend most of my time looking at the models and textures to see how it was done, so it's debatable whether I actually "play" the game at all.

Are you referring to your experience with D3Radiant or GtkRadiant?

I take it you are referring to contributions by FM authors who create and distribute Dark Mod missions, not the core mod code itself? Obviously with the core code being under the GPL there can be no restriction on using it for something non-TDM-related.

Actually it makes a lot of sense - activities that are repetitive and intellectually undemanding are often used for relaxation purposes. I enjoy the mental challenge of chess, but I certainly wouldn't describe it as "relaxing".

Don't count on Doom 3 being able to handle dots in filenames, in all cases I have tried it has stripped or ignored them.

True, although it's best not put up a gallery at all until you have something substantial to show. Still, the stuff they've got is a whole lot better than the crap Unforeseen Consequences was calling "official screenshots".

I wouldn't want to see _diffuse and _specular, that is just making the names too long and harder to read. _n instead of _local sounds fine, although I don't think there's much in it either way (Doom 3 mappers will be used to _local even though its meaning is not obvious).

I take that back. The game doesn't even have to be released. Not that I have any doubt that they will go a long way with their six untextured models and basic concept art.

It is one of the laws of the universe that as soon as a new game is released, somebody has to suggest making a Thief mod for it. This has to be done based purely on the visual content of the released game, not through any technical analysis of its capabilities. It is especially important that somebody does this by "announcing" such a mod on TTLG and trying to recruit large numbers of programmers and artists to implement their amazing idea.

No it isn't