VanishedOne

If it did originate with EoS then it looks as though TDM has permission to use it: http://forums.thedarkmod.com/topic/11604-arx-end-of-sun/?do=findComment&comment=227921 DCE's readme has a list of sources but (understandably) no detail about who made which models.

That looks familiar: is it by any chance this one that appeared in Arx: End of Sun?

Your problem reminds me of http://idtechforums.fuzzylogicinc.com/index.php?topic=395.0 -- which doesn't give an answer, unfortunately. It doesn't actually seem even as neat as that: there are loads of clearly TDM materials, like tdm_collision_*, outside the textures/ hierarchy, and even within textures/ you have e.g. textures/readables/newspaper_bridgeport_review01

That material will work, but there are also collision materials for specific surface types (they affect impact sounds): type tdm_collision_ while DR's media tab has focus. (I don't know why they aren't in textures/common/ like tdm_nodrawsolid_*.) The last thread I linked seems to indicate that they don't strictly need to be always convex but people have had mixed results getting concave ones to work. http://forums.thedarkmod.com/topic/7015-collision-model-issues/page-4?do=findComment&comment=137162 indicates that id's word on the matter is that convex hulls are 'usually preferred'. The limits on the numbers of verts/edges/polygons do seem to be strict, though.

Also clipmodels for moveables need to be convex and very simple, I believe; http://wiki.thedarkmod.com/index.php?title=Moveables#Create_a_Collision_Model_.28CM.29 isn't entirely clear on that point: Edit: Followed by some discussion of chair clipmodels: I just checked models/darkmod/misc/clipmodels/armchair1_cm.lwo and it seems to be made of two convex hulls. But then models/darkmod/misc/clipmodels/chair_simple01_cm.lwo just seems not to be convex. http://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page-80?do=findComment&comment=256019 refers to another concave collision mesh that works, as a 'fluke'. There seems to be conflicting information here. http://forums.thedarkmod.com/topic/7015-collision-model-issues/ seems to get into multiple definitions of 'convex'.

http://wiki.thedarkmod.com/index.php?title=Clip_Model

There must be a bit more to the implementation since they scale between minimum and maximum sizes. Or at any rate Unreal's do: the page I linked refers to MinCoronaSize and MaxaCoronaSize values. What I demo'd above does use a func_static patch with a deform sprite material: the size of the patch defines the maximum size (in the world, not screen space), and the rest involves passing shaderParms to the material. However, it's supposed to be possible to use shaderParms in particle defs, which will be a more flexible method if it works.

For the version above, since it piggy-backs on LOD, that'll depend on the entity's 'think' rate set by dist_check_period. A hypothetical script-controlled version would presumably be slower, and I'm not sure how best to optimise it (waitForRender?).

While I'm posting stuff that works when the stars are suitably aligned, here's my new experiment: Basically, a while back I was playing Unreal and Red Faction, and noticed that they had light corona effects that scaled between minimum and maximum sizes with player proximity to the light. So I tried hijacking the LOD fading mechanism to emulate the effect. (Another reason I'm interested in distance-dependent manipulation of glow effects is the possibility of light-at-the-end-of-a-tunnel flares.) I got it basically working: well enough to add to the mansion courtyard in ITB (which is about to return to beta testing). However, since LOD wasn't designed to be co-opted for this, there seems to be no way to disable scaling by Object Detail option for values above Normal, so the higher the value you have in your settings, the further you have to be to see the full size. Also, the sprite can clip through geometry; ignoreDepth can fix that, but then it draws over everything and only visportals can cull it. (A full corona replica would fade out when its origin was occluded.) So I have some thoughts about the possibility of an improved version using script control.

This is more a 'what are you surprised to discover?' Some caveats: You can have a bumpmap, but can't e.g. scroll it. A HeatHaze stage before the texgen one will work though, so locally fake-reflective water may be possible.Postprocess sorting only, otherwise contact with light glitches the colours. Hence no light interactions; for those you'd still need to make dedicated, per-skybox materials in the usual way, or deploy nbohr1more's ambient cubic lights. Possible use cases are basically glass, water, and highly reflective metals placed where the sky is the only possible light source (a blend filter stage can tone down the reflection a bit).I've only tested in small, isolated, cubic rooms so far; I don't know how complex geometry, visportals, or proximity to other cubemap-using materials will affect this. Even in those simple rooms, if there isn't a cubemapped skybox in the area, or if there is but it's just one wall, glitches result. (It's possible to put the cubemapped skybox in a portalSky area, though.)Edit: further testing shows the presence of other cubemapped materials does mess this up, so I'm afraid it's just a curio after all. Too easily broken for general use. If you want to try it, have a stage with texgen reflect, but don't declare a cubemap; instead use 'map _black', or 'map _currentRender' and a blend mode if you want transparency.

Seconded; SteveL once had to PM me some bugfixed scripts after I pointed out there was no public access to them.

I just looked at a D3 map, and instead of player_spawnclass its worldspawn has "def_player" "d3xp_player_doommarine". (I haven't tried it out.) See also http://www.moddb.com/mods/opencoop/tutorials/7-roe-maps-and-custom-playerdefs Edit: hmmm..... https://gitlab.pluribusgames.com/games/RBDOOM-3-BFG/blob/a315630d7dbbc8fce7a29a46ced2de3dff1a880a/neo/d3xp/Game_local.cpp { // precache the player args.Set( "classname", gameLocal.world->spawnArgs.GetString( "def_player", "player_doommarine" ) ); } But from TDM's Game_local.cpp: // greebo: Allow worldspawn to specify a different player classname if (!isMultiplayer && world != NULL && world->spawnArgs.FindKey("player_classname") != NULL) { playerClass = world->spawnArgs.GetString("player_classname", cv_player_spawnclass.GetString()); } So maybe player_classname is the correct spawnarg.

I'm not entirely sure what you have in mind, but have you looked at the shadow blendlights under Other Materials/lights/shadows?

If a mission produced with this monetary patronage features changes in the player's class, will people who responded here get a small share?

Are you using a script or an atdm:gui_message entity? I'm just looking at the script listing for createOverlay(): it's under the idEntity spawnclass but there's a note that says 'must be used on the player'. So I'm wondering whether the GUI is being created for the player entity and the view from the camera entity doesn't receive it.

A quick test suggests full screen mode is okay with f.lux running and TDM on its exclusion list, but windowed mode isn't.

For some reason it inherits "hide" "1"; change that to "0" and the model should spawn. Though my best guess about the delay is that your area/density is sufficient to give your hardware trouble. (I ended up switching from SEED combining to inlining in one case for that reason: I decided a bloated .proc file would be preferable to long loading times.)

Slightly tweaked frobs per material aren't unknown: tdm_pagan_orb_glow adds some white twice, which gives the orb a bluish frob glow. I remember finding the frob highlight of textures/darkmod/wood/panels/beam_brown_old too dark to see easily; had I needed to keep that entity frobable I'd probably have tweaked the material def. (I wondered whether it was a deliberate choice not to give bc_doublebass_* materials frob highlights: a frobable double bass will have only the strings highlighted. Whether that's helpful visual language probably depends on whether one intends to have the frob play a sound or pick up the entity.) So there's something to be said for being able to control the frob highlight on a per-material basis. Edit: quoting this here before I forget it's there:

I wonder whether there's a way of scripting around this. http://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page-243?do=findComment&comment=374726 gives a way of accessing the player's breath level in a script via the GUI system. Maybe a script could use setGuiInt() to decrement the visible breath level, and start applying damage_noair once it's reached zero. Edit: it could run into trouble if e.g. breath potions are available, since you'd be manipulating the GUI rather than the 'real' breath level. But if there's no better way it might be worth a try.

As for the froblock, I imagine you could bind it to a func_rotating.

I think that works with brush-and-patches too; I'm pretty sure I've made a rotating ceiling fan with patchwork.

It's pretty efficient according to this. However, I don't think it'll be flexible enough for many use cases: presumably the player lantern won't illuminate surfaces with a mismatched spectrum, for example. http://forums.thedarkmod.com/topic/17593-decal-request-white-dirtslime/ (That's odd: my image attachment in that thread has gone missing. Yours too by the look of it.) The question in that discussion was whether we could find a blend mode that did the job without blend add's glow-in-the-dark tendencies. For moonlight, additive blending might be just fine (and we already have moonlit window materials). I imagine blendlights (like your shadow light suggestion, but brightening) might be the simplest way.

It's the projectile entity that has the "has_result" and "def_result" spawnargs, not the damage defs. The standard set-up for projectiles seems to be that they 'detonate' on impact, removing the projectile entity and spawning any specified result entity (and projectile and result can each have a def_damage, e.g. atdm:result_projectile_rock inherits from atdm:moveable_rock_small so it has atdm:damage_moveable). For melee, I think what happens is that the "melee" frame command is used with the damage def. anim melee_attack models/md5/chars/undead/zombie/zombie_attack_lefthand.md5anim { frame 12 sound snd_swing frame 15 melee melee_zombie_Left } Which is basically where we ended up before. It's possible to spawn entities via frame commands, and to call script functions: SteveL made a script to apply a stim specifically to the target of an attack. So it's possible, with some customisation of the anim defs. I queried Obsttorte's comment about just specifying a stim in a damage def because that would be so much simpler and more convenient.

frob.vfp was designed to give a fresnel-like frob highlight, but it's unused because of a bug with TGA textures. http://forums.thedarkmod.com/topic/8747-tweaks-to-frob-highlight/?do=findComment&comment=174954 http://forums.thedarkmod.com/topic/10129-tdm-commands-and-variables/?do=findComment&comment=199639

Necromancy seems fitting enough for this thread... Is it actually possible to apply a stim via a damage def? If memory serves, what projectiles do on impact is spawn a result entity, which can carry stims just like any other entity that has a location in the world. But zombies do melee damage. When I've previously asked about applying stims via melee attacks, nobody had a simple way to do it. (This would also apply to a question I had about identifying which weapon the player was doing damage with.)