VanishedOne

What entity type are you talking about? func_securitycamera should be skinnable like any other entity with a static model, allowing the use of nodraw or nodrawsolid materials in the skin def; if that doesn't work it's presumably a bug. [Edit: I see it defaults to security_camera_on, so maybe the entity type is set up to change its own skins with state, and that's interfering somewhere? *checks code* I see some hardcoded stuff: try overriding the security_camera_on and security_camera_on_spotlight_off skins.] func_beam accepts a "skin" spawnarg that actually needs the name of a material, not the name of a skin. [Edit: did you by any chance try with a material affected by light? I'm not sure whether I ever tried, but I wouldn't bet on beam models accepting light interactions.] See whether this prefab works:

It's telling you the entity def is set up to use some scripting that's missing. I don't know why TDM has the entity def without the script, but you could try copying the script files from A New Job and see whether that fixes things.

What are you actually putting as the "skin" spawnarg? Despite being called "skin" it actually wants a material name, not a skin name.

For that you probably want a blendlight rather than an actual foglight (if you examine TDM's built-in fogs, several are actually blendlights). Textures for foglights are... an ongoing mystery to me, quite honestly: see my notes at http://wiki.thedarkmod.com/index.php?title=User:VanishedOne#Lights

It's hard to tell from the video, but the leak seen when you tried to testmap version 17 might have appeared at some point while you were making version 16. testmap <map> is basically dmap <map> + map <map>, and if the dmap stage fails it'll still continue to the map loading stage, which won't fail if the files from an earlier successful dmap are still there. This can lead to errors arising from the use of obsolete files. Try using dmap instead of testmap and see whether there's a leak report.

It's the BITMAP field: http://wiki.thedarkmod.com/index.php?title=ASE_to_TDM N.B. It's possible for DR to be misleading about ASE material names, so if things still don't work, investigate with a text editor: http://bugs.thedarkmod.com/view.php?id=4644

As I read this, if it runs in the first 5 seconds after map load it does nothing; if it runs later, it spawns a zombie, immediately checks whether it has health, and does nothing unless the zombie has spawned with no health. Is that what you wanted, or are you trying to check for when the zombie has been killed?

It sounds as though you'll need to make a customised version of the flame particles. If you don't want to affect every instance in the FM, you can copy the existing flame particle set-up in DR's particle editor, save the custom one under a new name, and then I think it's the model spawnarg you'd set on the flame to use the custom particles. Edit: model_lit, joebarnin is right. If you're lucky, just changing the particles' RGB in the particle editor will be enough (see the tdm_fire_torch_* family for examples) and you won't need custom textures. Or you could check Use Entity Colour, which I think should let _color work on the particles.

It looks as though you have a TGA file inside the dds/ hierarchy; if it doesn't work try diffusemap textures/darkmod/stone/sculpted/cube_marble_d.tga (assuming the file is in the matching location). I thought we had a working material def. for the main statue, and it was only the base that was missing one. Here's the tracker entry: http://bugs.thedarkmod.com/view.php?id=4429

Climbable banners have only appeared in Judith's Builder Compound asset pack as far as I know. I haven't noticed those in a released mission yet.

How about chain?

If you aren't just using a blue-tinted ambient light for it, I'm guessing a parallel light is what you're after. (Or maybe multiple ones in practice, since they're reputed to have trouble with light volumes' covering multiple visleafs (visleaves?). An ambient cubic light might also suit moonlight but I don't know whether anyone's tried...) This may be of interest, though: http://forums.thedarkmod.com/topic/16046-dynamic-moonlight/

You can use the saveRagdolls command to save a pose but it poses the entire ragdoll. It might be worth experimenting with selectively deleting the spawnargs it creates in the map file... Posed ragdolls still drop when exposed to physics, though. Edit: someone here mentions trying to use bindRagdolls per joint and apparently running into difficulties... And apparently Ishtvan had experimental code related to binding two parts of the same ragdoll together (and maybe altering a rope's AF is worth investigating...?). Apparently HL2 rope sections are rendered similarly to id Tech 4 beams, but after a subdivision process based on splines. In theory you could already set up a load of _BEAMs and even manipulate them dynamically via a script, but I'm not sure the result would look plausible. (I'm not even sure offhand whether beam models can receive light.) It appears id looked into dynamically generating a chain-type entity at some point: /*************************************************** chain ***************************************************/ entityDef env_chain { "editor_color" "1 .5 .3" "editor_mins" "?" "editor_maxs" "?" "editor_usage1" "A chain hanging down from the ceiling." "editor_usage2" "Do not use in game. For testing only." "editor_var links" "Number of links in the chain." "editor_var length" "Length of the chain. (default: number of links times 32)." "editor_var width" "Width of a link." "editor_var drop" "Set to 1 to not bind to world." "editor_var density" "Density of each link in the chain." "spawnclass" "idChain" "links" "3" "width" "8" "density" "0.2" "drop" "0" }

Yes, I was about to note the same thing: I have some static metal cables in my w.i.p. that are either cylinders or reskinned rope models, but as far as I know our ragdoll system doesn't give mappers a way of binding both ends of an MD5 rope to the world while letting the remaining joints move with physics impulses: as someone once pointed out in relation to hanging ragdolls by the neck, we have bindToJoint but not bindFromJoint. (I'm guessing from the grabber's ability to move individual limbs that there's some kind of internal support for manipulating joints independently, but I don't know whether it's accessible to scripting...)

Some (remarkably long-enduring) black market history:

That might be a leak problem: does File -> Pointfile in DR yield anything?

dmap is a command in TDM's own console, not DR's (there used to be a semi-implemented dmap in DR but it was removed some time ago). Prefabs are collections of brushes, patches and/or entities, so you can resize the brushes and patches, and use the scaling tool on the entities with models (after ungrouping if the prefab's been imported as a group). If this is a lamp with an LWO or ASE model, you can use the scaling tool (one of the buttons on the left of the main window, with the tooltip Model Scaler). Someone else will have to help with the crash problem; in the past greebo has fixed crashes when I sent him crash dumps, but according to http://forums.thedarkmod.com/topic/19955-darkradiant/?do=findComment&comment=436732 he might be unavailable, in which case probably OrbWeaver is your best hope.

SSAO is in the 2.08 roadmap, actually: http://bugs.thedarkmod.com/view.php?id=4972 I've no idea whether STiFU has started work on it, though.

Alternatively, ask the Inventors' Guild about an artificial leech: http://www.medicineatmichigan.org/history/2016/spring/artificial-leech

I wasn't. And yes, crash on quickload button, crash from the menu, even a crash on trying to start the mission again after that.

I hit the same problem: original release, 64-bit TDM, Win8.1. After it started crashing on load, I tried starting the mission anew and it still crashed. I switched to 32-bit and was able to restart the mission, but I can't say for sure that's what fixed it.

While it might be interesting for a mapper to override the location ambient if any AI in the location are searching, as a general system I think non-bark audio cues would run into problems: e.g. if an AI finding a body on the other side of the map triggers feedback that's just going to confuse the player.

From a quick check in DR, it looks as though spiders (and probably AI in general) don't actually have a response to STIM_KILL by default. Try giving it one.

There's a longstanding tracker entry for material maps to let one material support multiple surface types - Q4 and ET:QW implemented that in their versions of the engine - but there doesn't seem to be any current prospect of getting it working.

Depending on what you were doing, you might be able to restore the old behaviour by making a differently named copy of the portalsky material: http://bugs.thedarkmod.com/view.php?id=4635