VanishedOne

As far as I know everything in that article requires the custom script.

Tangentially related to the MD3 animated water: did anyone see this? When I tried it, after changing "inherit" to "spawnclass" I got splashes but no visual model (I tried both material and texture paths in the 'shader' line), so maybe fhdoom did something to enable it.

You can get Obsttorte's script via http://wiki.thedarkmod.com/index.php?title=AI_behaviour_depending_on_players_actions_(new_version)

You do: idThread has getcvar() and setcvar() script events.

Do those electric lights have idStaticEntity spawnclasses or idLight spawnclasses? atdm:wall_sphere_lit for example is an idLight entity. Whereas atdm:lamp_wall_gasflame03_lit is an idStaticEntity which spawns an idLight attachment.

Maybe the problem is that it's the atdm:lamp_wall_gasflame03_lit entity (which is an idStaticEntity) that has an s_shader set, not the light_gasflame attachment (which is the actual light entity)?

Apparently at least one person is still posting on their forum. With a proposal to change engines.

There are probably a few different ways to implement a basic pressure plate that triggers when the player stands on it; it's fancier implementations that run into trouble with e.g. the diagrams in http://forums.thedarkmod.com/topic/14017-making-traps/page-2?do=findComment&comment=294561

There's a shadowcaulk material that does cast shadows. I ended up replacing a lot of regular caulk with it recently to fix some problems with light bleed.

The comments about incongruous styles in mass-collaborations reminded me of http://thiefmissions.com/readmes/ChainProject.txt

I think this may be related to the shifted origin you mentioned. If I set g_showCollisionModels 1 in the console, when I walk into the visible model I see a red box nearby, and when I walk to where that appeared I push the model. I think it's centred on the ASE's origin, which from what I see in DR is quite a way outside the ASE model. After a quick test, I think the ASE export script may be using the map's origin, rather than the func_static entity's, unless the 'Center objects at 0,0,0 origin' option is in use. If you turn that on, hopefully you'll get an exported ASE with a more useful origin position, and then you can re-export a CM corresponding to that. If that still fails, I'd try making the models' origin the same as the map's origin (0,0,0) prior to exporting.

Any chance you could upload the testmap + ASE and CM somewhere? (If they're small enough you could give them a fake .txt extension so the forum software will accept them as attachments.) Edit: before that, one other thing I thought of: there are sometimes odd problems when dmap doesn't fully regenerate the files it makes, so it might be worth deleting the <your map>.proc and <your map>.cm from dmapping (that's the map's .cm, not the model's) and running dmap again.

I think the game infers from the .skin extension that it's a skin if the keyword is absent. In Doom3+RoE you can find e.g. entityDefs and skins for the X-ray machine zombies placed together in monster_zombie_xrays.def, but TDM organisation favours putting all skins in skins/*.skin.

I just noticed that in the posts above you gave the classname as "atdm: moveable_base", and it should be "atdm:moveable_base" without any spaces. Failing that, are you seeing any potentially relevant console errors/warnings? Edit: also, if you literally gave it the path to the folder rather than the file, that would go wrong.

I'm not certain of the details of how the ASE exporter handles origins, but I see it has a 'Center objects at 0,0,0 origin' option. As for the other thing, I was remembering buggy behaviour someone experienced after replacing brushwork with a model from the asset folders by editing the entity's spawnargs. I just tested though and DR removed the brushes entirely, so maybe it's been fixed since then.

Have you changed the "model" spawnarg to point to your ASE? (Or better yet created a replacement entity using it, since I'm not sure what happens to an entity's brushwork when replaced by a model, and I vaguely recall someone having trouble with an entity that still had unused brushes.)

I don't have a mission folder set either, and I'm not seeing those errors.

func_spyhole? https://en.wiktionary.org/wiki/spyhole

If you're talking about what I think you are, there's a wiki entry at http://wiki.thedarkmod.com/index.php?title=Grass_Edges

http://wiki.thedarkmod.com/index.php?title=File:Farrell.jpg has most of that, just no city.

Is there anything relevant in this (from the olden days of 2004) or is that a different topic? https://www.gamasutra.com/view/feature/2107/realtime_glow.php

Yes, I was about to post about deform flare too. The main limitation with that is that only rectangular surfaces can be transformed into flares. Edit: _quadratic gives a nice effect, but it isn't an absolute requirement. I used a couple of flare materials in In The Black, and one uses textures/darkmod/sfx/candleglow.tga instead.

Although it needn't look that bad either: see http://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page-245?do=findComment&comment=375979 for a basic example (easy to set up with func_beam entities). It won't react to the player's view angle or the visibility of the 'light source', though, which I think is the kind of thing Epifire was asking about in http://forums.thedarkmod.com/topic/17301-directional-based-visibility/ -- so it could certainly be improved upon, and I'll be interested in the volumetric lighting thread.

That was just in relation to someone's wanting a GUI display of stats mid-mission, not for persistent storage of anything even on the local machine.

I remember wondering about Thief-style damageable doors from the player's side. My interest in bashing things was also piqued by the discovery there's an unused player arm view model wielding a club instead of the sword. I had some ideas about how damageable doors might be jury-rigged, but one problem - not specific to doors; attempting e.g. a Thief-style slashable banner would run into it too - was that outside the S/R system, there was no apparent way to check the source of damage (via script). You don't have Thief's slash, bash and poke stims. In the context of damageable doors, that would imply you could 'break the lock' by firing broadheads at the door, since broadheads deal damage. Damage defs have some interesting features - kick, knockback, push - which might be more appropriate here than generic 'damage' to the door's 'health': e.g. atdm:damage_rock does "push" "6" but atdm: damage_firearrowdirect does "push" "425", so if you want, say, a door that can be blasted open explosively but is immune to having rocks hurled at it, that might be useful. (But I don't know of any way to use it as things currently stand.)