User:VanishedOne
VanishedOne's notes and queries.
Archive.org idDevNet link: [1]
Stim/Response
| 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_FIRE | Fire | |
| STIM_WATER | Water | |
| 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;
Models
'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]
AFs
Keywords not in [7]:
in settings:
model (same as mesh?)
noMoveTime
noMoveTranslation
noMoveRotation
minMoveTime
maxMoveTime
contents (solid, body, corpse, playerclip, monsterclip) (clipping for moveables applied automatically?)
clipMask
in body sections:
contents (solid, body, corpse, playerclip, monsterclip) (clipping for moveables applied automatically?)
clipMask
mod (orientation, position, both) -- 'joint mod'
inertiaScale
frictionDirection
contactMotorDirection
('custom' model type for bodies isn't actually implemented.)
fixed - constraint type, includes:
body1
body2
slider - constraint type, includes:
body1
body2
friction
axis
Animations
"enable_death_anim" spawnarg to use an anim called 'death' before going into ragdoll: [8]
AI
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.
LOD
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.'
Textures
'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 -- see Xrays. (No mention of RoE's "skin_head_xray" spawnarg; use skin_xray on the head entity instead.)
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 shaderDemo.mtr, 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 -- see Xrays.
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]
PARTICLE_MACRO:
noselfShadow noShadows translucent discrete nonsolid noimpact
GLASS_MACRO:
noselfShadow noShadows translucent twosided
TWOSIDED_DECAL_MACRO:
discrete nonsolid noimpact polygonOffset 1 noShadows sort decal noselfShadow noShadows translucent twosided
(Why translucent?)
ShaderParms
| Number | Alias (RenderWorld.h) | Alias in tdm_defs.script | My notes |
|---|---|---|---|
| 0 | SHADERPARM_RED | ✓ | |
| 1 | SHADERPARM_GREEN | ✓ | |
| 2 | SHADERPARM_BLUE | ✓ | |
| 3 | SHADERPARM_ALPHA
SHADERPARM_TIMESCALE |
✓
✓ |
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]) |
| 6 | |||
| 7 | SHADERPARM_MODE SHADERPARM_TIME_OF_DEATH |
✓ ✓ |
Programmer comment: 'for selecting which shader passes to enable' Security camera: q.v. |
| 8 | SHADERPARM_MD5_SKINSCALE
SHADERPARM_MD3_FRAME SHADERPARM_BEAM_END_X SHADERPARM_SPRITE_WIDTH SHADERPARM_PARTICLE_STOPTIME |
|
Programmer comment: 'for scaling vertex offsets on md5 models (jack skellington effect)'
[47] |
| 9 | SHADERPARM_MD3_LASTFRAME
SHADERPARM_BEAM_END_Y SHADERPARM_SPRITE_HEIGHT |
[51] | |
| 10 | SHADERPARM_MD3_BACKLERP
SHADERPARM_BEAM_END_Z |
[52] | |
| 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
Megatextures
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).
Lights
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 fogs.mtr) 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 fogs.mtr 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 );
renderer/RenderWorld_local.h:
// 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.
Particles
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.
GLprogs
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.
FX
'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. (Footprints in Written In Stone use sys.projectDecal() instead.)
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();
}
}
GUIs
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).
Sound
Stuff not in [62] (including TDM additions; passing over reverb, ordered, plain and onDemand, all marked no longer supported):
antiPrivate -- opposite of private, presumably
playonce
no_efx -- [65]
Triggers
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]
Targets
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]
PortalSky
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" );
AAS
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.
Misc.
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]
Weather
"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.
