From The DarkMod Wiki
Jump to navigationJump to search

VanishedOne's notes and queries. idDevNet link: [1]


Type Comment in tdm_stim_response.script My notes
STIM_FROB Frobbed The Response to apply STIM_FROB won't work everywhere the dedicated frob Response will (only the latter collects loot).
STIM_DAMAGE damages target AI and the player have a STIM_DAMAGE Response to make this the case. It's not a response to ordinary damage (though a script object could listen for SIG_DAMAGE).
STIM_SHIELD protects against arrows or physical blows Used? Usable?
STIM_HEALING heals target The player has a Response to this; AI, by default, don't.
STIM_HOLY holy is applied Undead use a special script to get the damage def. from the source (usually a holy water arrow result); without one, there's no effect.
STIM_MAGIC Magic is being used Used anywhere? What's the purpose of this one? (From Thief's MagicZapStim?)
STIM_TOUCH triggered if touched Couldn't get a Response to fire on ordinary collisions, or on entering brush triggers. Maybe it's meant to be used as a collision stim.
STIM_KNOCKOUT target is knocked out AI/heads (including the player head) inherit a Response to this as standard to enable it to knock AI out, but the blackjack presumably uses a non-S/R mechanism for hit-cone-dependent knockouts.
STIM_KILL target is killed AI don't have a Response to this as standard. No luck activating Responses through death by normal means.
STIM_RESTORE target is restored What does this mean, if not the same as STIM_HEALING?
STIM_LIGHT triggered by light [2] Testing revealed no special handling (and 'use bounds' doesn't work with light volumes; presumably if a light has a model it'll use that).
STIM_SOUND triggered by sound Testing with a speaker revealed no special handling. (What about AI-audible soundprop?)
STIM_VISUAL visual contact Handled in code
STIM_INVITE can be used to trigger special behaviour (like a stool can invite an AI to sit down) Probably related to this idea from 2005: [3]
STIM_READ Can be read Used?
STIM_RANDOM Random response is selected (does this make sense?) Whether it was meant to fire any of the entity's Responses by random selection, or one of its Responses to this stim, I'm not sure this works (but the latter case can be taken care of by enabling 'Random Effects' on any Response).
STIM_TIMER Timer has been triggered. Used?
STIM_COMMUNICATION Communication vocalization Handled in code
STIM_GAS Gas arrows / mines
STIM_TRIGGER Entity "activation" stim
STIM_TARGET_REACHED Can be emitted if the endposition (e.g. by using an effect_moveToPosition) is reached Sent to AI when they've been directed by the Response effect Move To Position or Move To Random Position.
STIM_PLAYER The "player" stim Radial stim on the player
STIM_FLASH The flashbomb stim
STIM_BLIND A "blind" stim that blinds the actor (this is stronger than a FLASH stim, no visibility is needed)
STIM_MOSS stim from moss arrows (e.g., for dampening window shattering) func_fractures come with a Response that calls breakable_glass::on_moss_stim (in tdm_breakable_glass.script)

Nonsolid response entities, like the candle flames, may need to have "clipmodel_contents" "131072" set. (Do they also need explicit "mins"/"maxs"?)

Is the magnitude of collision stims affected by velocity/force of collision, as reportedly in the Dark Engine?

Are these (in Response.h) used?

* How much damage must be applied for this response?
float				m_MinDamage;
* No more than this.
float				m_MaxDamage;


'looks like Doom3 can load FLT models, which seem to be quite terrain specific. Might be something to look into if anyone has copious free time.' [4]

A couple of D3BFG FX decls refer to .ips models (itemspawn.fx - model "itemrespawn.ips"; berserkspawn.fx - model "berserkrespawn.ips"). Maybe another development relic like the .particle extension?

Custom vertex normals usable in ASE but not LWO? [5][6]


Keywords not in [7]:

in settings:
model (same as mesh?)
contents (solid, body, corpse, playerclip, monsterclip) (clipping for moveables applied automatically?)

in body sections:
contents (solid, body, corpse, playerclip, monsterclip) (clipping for moveables applied automatically?)
mod (orientation, position, both) -- 'joint mod'
('custom' model type for bodies isn't actually implemented.)

fixed - constraint type, includes:

slider - constraint type, includes:


"enable_death_anim" spawnarg to use an anim called 'death' before going into ragdoll: [8]


Behaviour noted in [9] is not standard for an id Tech 4 game. Typically you don't see AFs when using g_showCollisionModels, and AI without AFs (e.g. the fish in Arx: EoS) don't cause a crash when approached. The difference is perhaps linked to the fact that TDM's melee system seems to use AFs for collision checks: if af_push_moveables is disabled the AI is immune to melee attacks (at least from the player; I haven't checked other AI's), which is why you can't melee a rat.


Comment in Misc.cpp: 'idAnimateds are the only class allowed to simply still their md5mesh as a LOD optimization, which they do by setting "model_lod_N" to the special value "be_still". They can also swap in another animated model, or a static FS model.'


'D3's folder depth limitation for DDS files. You cannot have DDS files more than 5 folders deep... - D3 just doesn't want that, only the id people know why this unfortunate limit is there in the first place.' [10] (Does this limit remain?)

Material shaders

Stuff not in [11] (including TDM's additions):

xrayRenderMap -- ported as of TDM 2.08. Previous comment was: some code support from RoE may be missing (cf. Entity.cpp, BrittleFracture.cpp...). Perhaps TDM was built on /neo/game instead of /neo/d3xp. What's left can create a subview that skips some surfaces, e.g. there's an AI it can make bald, but the rules are unclear (some bodies just turn invisible, some don't) and I think "skin_xray" and "skin_head_xray" spawnargs may be broken. (Also D3BFG has a base/_common/generated/images/textures/sfx/xrayblend#__0200.bimage for which there's no apparent equivalent.)

A token called 'inclusive' seems to have been added to TDM's xrayRenderMap:

 ts->dynamic = DI_XRAY_RENDER;
 			//ts->width = src.ParseInt();
 			//ts->height = src.ParseInt();
 			ts->width = 0;
 if ( src.ReadTokenOnLine( &token ) ) {
 				if ( !token.Icmp( "inclusive" ) ) {
 					ts->width = 1;

portalRenderMap -- disabled at tr_subview.cpp line 790. Still appears in textures/smf/portal_sky

vertexParm2, stereoeye left/right -- not in TDM. Seems to be something id added to D3 BFG. [12]

shadowDraw -- appears in D3's shaderdemos/shadowDrawLight in, but presumably leftover from an earlier stage of development. Would have been used in a stage of a light material to make that stage 'drawn on the shadows'. (It's listed in [13] for Prey but I didn't find the string when checking the Prey .exe in a text editor. A variant of shaderdemos/shadowDrawLight is in the leaked D3 alpha build, but while that build accepts the keyword, a shadowDraw light didn't look noticeably different from a regular light when spawned.)

glasswarp -- removed. [14][15] Heathaze program stages are used instead.

texgen normal -- disabled. (Apparently id's code had it generating a warning, similar to the unused glasswarp implementation. [16])

suppressInSubview -- global; appears occasionally in D3/RoE materials. Probably does what it says and hides surfaces in remote/mirror views, but I haven't tested.

screen -- stage keyword; appears in D3/RoE's textures/smf/window_scratch, and in TDM's portal_sky. Projects to screen instead of surface co-ordinates?

screen2 -- same as screen? Code comment: 'duzenko: treated by renderer same as TG_SCREEN, simplified'

name -- stage keyword. Code comment: 'BSM Nerve: Added for stage naming in the material editor'

portalSky -- as distinct from sort portalSky. Unused? draw_common.cpp:

 if ( shader->IsPortalSky() ) { // NB TDM portal sky does not use this flag or whatever mechanism
 		return;    // it used to support. Our portalSky is drawn in this procedure using
 	// the skybox image captured in _currentRender. -- SteveL working on #4182

'New _currentDepth global image accessible by any shader. Unlike _currentRender, using this keyword in a material file does not delay the shader being drawn. New ignoreDepth material file keyword. Prevents the shader being clipped by solid geometry.' -- [17]

'Added new material flag: sort afterfog Applied it to material textures/particles/dustcloud and that seems to fix the fog overdraw. This only works well for ambient-only materials, that weren't fogged before, like the waterfall in the test map.' -- [18]

islightgemsurf [19]

withAudio -- parameter added to videoMap [20] [21]

cubicLight, ambientCubicLight -- [22] lightFalloffCubeMap, makeIrradiance() -- [23]

shadowmapOffset -- global keyword. Obviously a shadowmap tweak, but seems to be undocumented so far.

ambientRimColor -- [24] Presently global; unclear whether we'll get it as a stage keyword, and whether the global version will remain if we do.

fogAlpha, sort last -- [25]

I'm coming to doubt that masks work in light-interactive stages. (Unsure about maskDepth.)

Do we have `sort underwater`? Seen here but not in idDevNet docs. (Maybe a mix-up with Quake 3 or ET:QW?)

noFog used to do nothing except during dmap with lightCarve -- [26] -- but now see [27],[28]

Is this how the hardwood surface type differs from regular wood? -- No: [29][30]

'rgb parameters work on cubemap stages ONLY when there are no diffuse/bumpmap/specular map blending stages set on the material' [31]

Under these conditions, vertexColor has an effect but inverseVertexColor seems to have the exact same effect.

ignoreAlphaTest appears not to work on light-reactive stages.

In my experience the following can't be used with light interactions:

  • Surfaces altered by deforms. Bump/specular seems to be possible with turbulent but in the wrong, i.e. unchanged, places. (Carmack: '...internally there are a number of things I consider flaws with the Doom engine, for instance, surface deforms, where you have something that's an auto-sprite or uses some other deform, that happens in the wrong place in the pipeline to get lit.' [32])
  • Particles spawned from surfaces (except that the simple ambient can add colour to them).
  • 'Smoke' particles.

Do vertex colours work with deforms? [33]

deform eyeball -- [34]

clamp keywords: if materials look fine in DR but warped or invisible in TDM (e.g. for hinge decals), move the control points in the Texture Tool so the top-left is at 0,0. This seems reliable on patches. On brushes, I'm not sure clamp/zeroclamp/alphazeroclamp is reliable at all.

'The "add" image program only works with uncompressed textures.' [35] I think this may be true of other image program functions too.

It seems "soundmap" gives bars for any string token except "wavelength". "soundmap" alone is an error.

What's the nodrop surface parameter for (in textures/common/nodrop)? Same as [36]? Yes, apparently -- comment from D3 assets: 'nodrop is a volume modifier that is tested before dropping items, used to keep items from cluttering up death pits'

id's cushion material is 'solid to movement', TDM's is set nonsolid.

Do blood decals still use this hack? [37]

'The "enhanced" interaction shader derives the glossiness part from the color-values of the specularmap, which were normally just driving the specular strength as you mentioned. The non "enhanced" shader does not do this and uses a preset gloss value instead.' [38] (Do the GLSL shaders replicate this?)

'...using 3D textures. I found code in TDM's source to support loading such images but no corresponding material keyword to invoke it.' [39]

TDM macros: [40]






 polygonOffset 1
 sort decal

(Why translucent?)


Number Alias (RenderWorld.h) Alias in tdm_defs.script My notes


Contra List_of_shaderParm_variables, may be set > 1 by LOD fading.

Read by lights on spawn.

4 SHADERPARM_TIMEOFFSET Set on func_static activation [41]. Lights set this to -MS2SEC(gameLocal.time) on turning on, when they break, and on spawn if shaderParm4 isn't set in spawnargs.
5 SHADERPARM_DIVERSITY Programmer comment: 'random between 0.0 and 1.0 for some effects (muzzle flashes, etc)'

Used for particle randomisation ([42] [43]; see also [44])
Toggled on func_static activation [45].



Programmer comment: 'for selecting which shader passes to enable'

Security camera: q.v.
Programmer comment: 'for the monster skin-burn-away effect enable and time offset'
Toggled on func_static activation [46]. Set to 1 when a light breaks.



Programmer comment: 'for scaling vertex offsets on md5 models (jack skellington effect)'

Programmer comment: 'for _beam models'
No effect on deform sprite patch; maybe its model isn't _SPRITE?
Programmer comment: 'don't spawn any more particles after this time'
AI script event shrivel(time): 'Modifies shaderparm 8 from 1.0 to 0.5 over time (will return after multiple frames). Not used in Doom 3.' [48] Is this what SHADERPARM_MD5_SKINSCALE is about? Setting parm8 to nonzero on an AI caused wild glitching in the vertex positions when I tried to look at it: is this just broken or do the materials need something special? See [49], [50].





11 SHADERPARM_BEAM_WIDTH Luckily it's unlikely someone would want a frobable func_beam

_SPRITE should behave like deform sprite according to code comments ('A simple sprite model that always faces the view axis.' -- Model_sprite.cpp), but in my tests, on an idStaticEntity it faced the reverse of the entity's direction, even with no "angle" spawnarg. (Whereas _BEAM worked as expected.) Using a deform sprite material (setting materials via a wildcard skin) overrides this but stops the aspect ratio changing: you can use the parms for scaling but the sprite can't change shape any more.

id's comment on the decalFade table:

 // this will be full intensity for 90% of the time, then fade to 0
 // parm3 is set to the time the mark is spawned
 // parm4 is set to the time the mark will be removed

id's comments on damage overlays (I'm unsure how much of this is active in TDM, given that D3's doublevision is disabled):

 // player damage tunnel vision effect
 // parm3 will range from 0.0 to 1.0 based on health, 1.0 is full health
 // parm0 will be the time that damage was last taken, allowing an
 // accentuation and fade out
 // screen damage blobs
 // the alpha paramater (parm3) will decrease from 1.0 to 0.0 over the length of
 // time on screen


Used the old ARB backend. megaTexture material token is commented out in current Material.cpp.

The idea of megatexture channels as used in ETQW seems to be just appearing in the available code: Megatexture.h has

 static const int MAX_MEGA_CHANNELS = 3; // normal, diffuse, specular

but this variable doesn't actually seem to be used. D3's shaderDemos/megaTexture applies the megatexture as blend gl_one, gl_zero. Version 2 of the D3 megatexture mod instead applies it as blend filter (with a regular texture as a diffusemap).


Do the image maps in foglight stages actually do anything (besides keeping the parser happy)? tdm_fogs/cloud_fog uses lights/spot01 instead of _fog, but nothing I've tried seems to make any visual difference.

Ditto for falloff images in foglights, as in fogs/pitFog_to_black.

This (from D3BFG's is how it's supposed to work:

 // If you replace the default internal fog projection image with your own
 // texture, make sure that the alpha starts at 0 in the center, reaches
 // 255 at the borders, and is generally radially symetrical.
 // The color channel can be left solid white, or it can have additional
 // color changes with position.

Using images with alpha channels doesn't seem to make any difference, though.

Foglight alpha values from 0 to 1 have fixed behaviour distinct from the way foglights behave with alpha > 1. D3's says the default is applied if alpha 'equals the default 1.0', but that's not the actual test. renderer/draw_common.cpp:

 // if they left the default value on, set a fog distance of 500
 	if ( backEnd.lightColor[3] <= 1.0 ) {
 		a = -0.5f / DEFAULT_FOG_DISTANCE;

Foglights can only have one stage:

 // assume fog shaders have only a single stage
 stage = lightShader->GetStage( 0 );


 // A portal will be considered closed if it is past the
 // fog-out point in a fog volume.  We only support a single
 // fog volume over each portal.

Does forceShadows in foglight and blendlight materials work, as id's docs claim? My test suggested not.

Falloff images don't have to be monochrome.


I don't think particle decls accept .mtr-style expressions like [53] suggests, but the parser does check for table names. You pass the table name (without []) as the parameter for speed, rotation, size or aspect, and what I think happens is that the table is used to change the particle over its lifespan in place of the usual 'from' and 'to' numbers, allowing more complex transitions. I'm not sure whether it's possible to use more than one table per decl, since I ran into 'can't integrate tables' errors (there's some evidence in the Prey SDK that HH fixed this for their engine version).

TDM additions:

WorldAxis -- [54]

DiversityPeriod -- [55]

softeningRadius -- [56]

cutoffTimeMap, mapLayout, collisionStatic, collisionStaticWorldOnly -- Particle_collisions_and_cutoff

Custom paths:

 const ParticleParmDesc ParticleCustomDesc[] = {
 	{ "standard", 0, "Standard" },
 	{ "helix", 5, "sizeX Y Z radialSpeed axialSpeed" },
 	{ "flies", 3, "radialSpeed axialSpeed size" },
 	{ "orbit", 2, "radius speed"},
 	{ "drip", 2, "something something" }

From framework/DeclParticle.cpp

orbit presumably should correspond to Spherical in editParticles, but that's broken; type "orbit" in manually instead. drip does work in the editParticles menu. Neither is available for selection in DR, and it can't read them.

 if ( !token.Icmp( "customPath" ) ) {
 			src.ReadToken( &token );
 			if ( !token.Icmp( "standard" ) ) {
 				stage->customPathType = PPATH_STANDARD;
 			} else if ( !token.Icmp( "helix" ) ) {
 				stage->customPathType = PPATH_HELIX;
 			} else if ( !token.Icmp( "flies" ) ) {
 				stage->customPathType = PPATH_FLIES;
 			} else if ( !token.Icmp( "spherical" ) ) {
 				stage->customPathType = PPATH_ORBIT;
 			} else {
 				src.Error( "bad path type: %s\n", token.c_str() );

This, however, checks for a "spherical" (not "orbit") keyword, but has no "drip". PPATH_DRIP is defined in the header file and tested elsewhere, though.


Frob highlight: 'The frob.vfp program is not active. This has been part of Rebb's frobhighlighting improvement project, but in the end we ran into an issue with TGA files (they ended up with a heavy green tint in-game, which (we think) is due to some sort of limitation in the closed source parts - can't remember exactly).' [57] See [58] This is due to be made redundant by GLSL newFrob anyway.


'In the vanilla code "trackorigin" will not work unless "fadeIn" or "fadeOut" is set too.' [59] Bug remains in TDM: [60]

Decal splatting has a short vertical range. For FX called in frame commands, use bindto "origin". For func_fx, its origin should be < 8 units above the ground. Decals are randomly rotated and there seems to be no way to override that.

Does ignoreMaster work in singleplayer? (The fall of my AI test partner's ragdoll from the sky suggests not.)

 idEntity *ignore_ent = NULL;
 if ( gameLocal.isMultiplayer ) {
 	ignore_ent = this;
 	if ( fxaction.shakeIgnoreMaster ) {
 		ignore_ent = GetBindMaster();


Focus doesn't work in TDM: [61]

It looks as though GUIs can use tables, etc. like materials, as seen in D3's malfunction.gui:

 windowDef Static {
 	//static overlay
 		rect	0 ,0 ,640 ,480 
 		visible	1
 		background "gui/static"
 		matcolor	1, 1, 1, pdhalffade[ time * 0.001 ]

And test user variables in conditions (as in D3's sttp.gui and indeed TDM's Loading_Screen_Text).


Stuff not in [62] (including TDM additions; passing over reverb, ordered, plain and onDemand, all marked no longer supported):

antiPrivate -- opposite of private, presumably


fromVideo -- [63] [64]

no_efx -- [65]


Patches can be used for triggers and 'there could be separate triggers to be walked into depending on which direction you are walking'. [66]

'This is a trigger_relay with set of targets (items) which will be gived to the player when map will be loaded. All targets will be activated by Code. This trigger must have a "devmap" name.' 'trigger playtesting item gives, if we didn't get here from a previous level' 'the devmap key will be set on the first devmap, but cleared on any level transitions' [67]


target_setinfluence removed? (Maybe considered redundant with S/R or too D3/'demonic'-specific? Comparing [68] to the TDM entity list suggests a purge of even some quite generic entities may have occurred.) idTarget_SetInfluence still exists so it can be recreated, but may be bugged in TDM [69]. Can crash TDM on map load if e.g. targetted by worldspawn. D3 usage: [70]; D3 def here: [71]


Game_local.h --

 enum {
 	PORTALSKY_STANDARD = 0,			// classic portalsky
 	PORTALSKY_GLOBAL = 1,			// always following portal sky
 	PORTALSKY_LOCAL = 2,			// following portal sky from a spot

Misc.cpp --

 if ( spawnArgs.GetInt( "type" ) == PORTALSKY_GLOBAL )
 gameLocal.portalSkyScale = spawnArgs.GetInt( "scale", "16" );	

[72], [73]


Apparently AAS can include 'swim reachabilities', but I'm not sure what (if anything) can be done with them. Arx: EoS fish seem to use AAS with both swim and fly reachabilities turned on, use MOVETYPE_FLY (there being no MOVETYPE_SWIM) and have added code to limit their maximum 'flying' height.

Security camera

idSecurityCamera::Pain() refers to an "fx_damage" spawnarg not documented in the entityDef. Similarly, idSecurityCamera::Killed() refers to an "fx_destroyed" spawnarg.

idSecurityCamera::SetAlertMode() looks to have code to update SHADERPARM_MODE (parm7), where


suggesting it's possible to have something like the T2 Watchers' colour-changing lights.


There seems to be a TDM-specific decl class called tdm_matinfo, intended to appear within .mtr files. 'A TDM-specific material information declaration class. Currently, the only info it contains is surfacetype.' Unused?

What is/was trigger_air? (textures/common/trigair) There's no such entity def., even among the commented-out ones in triggers.def. Maybe related to the commented-out info_vacuum in d3_junk.def? A target_air/idTarget_Air turned up in Q4's defs.

`knockout` spawnarg on atdm:weapon_base ('If set to true, a hit with that weapon knocks the AI out') -- working/used? The blackjack instead uses a `knockout` arg in its melee def. (melee_blackjack_ovr): compare atdm:damage_moveable, which also has a `knockout_power` spawnarg ('powered-up knockout, not used' according to a def file comment).

There's a "kill_all" spawnarg for letting moveables kill AI.[74]

`inv_item_count` defined on atdm:playertool: used for anything? (Compare `inv_count`.)

$player1.replaceInvItem($some_inv_item, $null_entity) -- if $some_inv_item was simply placed in the world, the inventory icon will disappear if it was on the screen; if it entered the inventory via the shop, the icon will remain until cycled away from.

func_splat -- undocumented in the entityDef, "splatAngle" spawnarg can specify rotation. (I'm not sure the fade respects decalInfo. Decals seem to disappear after a fixed time even if there is no decalInfo.)

It should be possible to set the player's entity class by setting player_classname on worldspawn.[75]


 "classname" "func_static"
 "sr_class_1" "S"
 "sr_radius_1" "0"
 "sr_state_1" "1"
 "sr_time_interval_1" "200"
 "sr_type_1" "2"
 "sr_use_bounds_1" "1"
 "solid" "0"

Texture brushes of this entity with textures/common/collision and put them under your rain/snow patches so you can no longer carry a lit candle through a downpour.