OrbWeaver

Just make it darker (more black). You may not even need a specular at all for some models. A lesser-known fact is that you can also colour the specular, so you could give it a brownish rusty sheen, for instance.

Correct. The *BITMAP line should be "//base/" followed by the material name, "waterpump" in this case. You can use backslashes or forward slashes according to preference. Multi-material single meshes do not work, multi-material multi-meshes do work. Depending on your modelling app the difference may be significant or not (in Blender it is actually easier to use the latter).

"Made up" is usually taken to mean "consciously invented". Words like "fuck" are not made up in this sense, they arise through the natural process of linguistic evolution.

I did the washbasin, not sure if it ever made it into the repository though.

{ blend add map path/to/my_illumination_map.tga }

This is now fixed in trunk, ready for next release.

The materials are prepared for fades - that's the easy bit. It's the coding to actually calculate and implement the fade that is more difficult.

Any discussion of legalising vs banning something are ultimately flawed, in that they assume that you can solve a problem by attacking its symptoms. You can pass as many laws as you like restricting guns, drugs, terrorism, glorifying terrorism, thinking about terrorism, failing to express adequate disapproval of terrorism, ad nauseam, without making an atom of difference to anything. Unless you tackle the root of the issue (poverty, perceived injustices or whatever), the problem is not going away no matter how many grandstanding politicians come up with Great New Schemes to eradicate social ills.

Yes, that's the only way renderbump parameters can be provided to Doom 3. I guess the idea is you set up the parameters for each skin, and then you can re-run them if you change the high-res model during development.

I was hoping that was the case, there is some ghastly spaghetti code in the xlink processing bit, which my EntityInspector code does not attempt to imitate. I'll get rid of the function and file altogether. I'm not sure what to do about msvcrt71.dll, we could just tell Win2k users to download it, or we could package it in the installer assuming it is legal to do so.

The global.xlink is an XML file containing what appears to be web links to GtkRadiant resources. This looks like some kind of binary incompatibility - maybe the version of libxml2.dll that I provided in the installer only works on Windows XP. I can remove the global.xlink as we are not using it, but we do need libxml2 for the entity categories.

Some known issues: * Changing a property on an entity (such as the colour of a light) does not update the "Map modified" property, so you can't save until you have changed something else (to be fixed in next point release). * Dragging static meshes does not update the position until the drag has finished. The "Translate" button on the toolbar activates the translation manipulator, which makes this a bit easier until it is properly fixed. Under investigation. * Quite a lot of models and geometry show up as "shader not found" in the preview even though they work in game. Under investigation. * There is not yet a model selector, so don't bother looking for one. You add a model by adding a func_static entity and selecting a LWO/ASE file in the filestructure. The addition of a proper model selector with preview is a priority for the 0.6 release.

Looking good so far, I'm reading that performance impact as "utterly negligible, possibly even statistically insignificant".

That is a planned feature for the much-needed model browser interface. I might integrate this into the tree view, so that a model with skins could be opened up to have alternative skins displayed as its children.

Yes, that's a GtkColorSelection. There is a need for a dedicated Property Editor to provide this interface for adjusting _color keys.

Good idea, DoomEdit does this. One thing I would like to do with light radii is provide an option to overlay the light texture onto the light radius in the 2D view, so that it would be easier to see which parts of the radius are actually lit.

Rotation does work in DarkRadiant - all objects rotate around a common centre. Presently the location of the centre is automatically calculated based on the objects' positions, but presumably it would be not too difficult to allow the user to set the centre point manually.

A foglight isn't really a light, so don't worry about the performance.

For that you might use a foglight. Particle fog is not really appropriate for underwater, but the foglight gives you a nice "growing more opaque with depth" effect.

"Not consciously remembered" is not equivalent to "pointless".

Dual core allows the processor to "do two things at once", in certain circumstances. Many applications cannot take advantage of this, since they require things to be done in a certain order and cannot easily parallelise their operation. The main advantage appears when you are running several applications simultaneously, like encoding an MP3 in the background while playing Doom.

That's a marketing myth. Dual-core does not give you twice the performance of single core.

I don't quite see how the y component can be identically 0 - surely the up vector must have all three components since it is perpendicular to the direction vector which can point anywhere? E.g. with a direction vector of [0 1 0], start tilting backwards. The up vector will start to point in the negative y direction.

Basically yes, although the up vector does not have to be perpendicular to the direction vector. In fact for most purposes you would never touch the up vector, it would always be [0 0 1], but it is necessary to change it if you want the camera to pitch past the vertical.

I understood normals to be unit-sized, which means they should not be scaled. The direction of the normals would not change whether scaled with the model or not, so the issue would be whether their size is scaled and whether the renderer has a problem with this or not.