User:VanishedOne: Difference between revisions

Revision as of 17:02, 10 September 2019

VanishedOne's notes and queries.

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	[1] 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: [2]
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	Emitted to what?
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)

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.' [3]

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? [4][5]

AFs

Keywords not in [6]:

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: [7]

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.' [8] (Does this limit remain?)

Material shaders

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

xrayRenderMap -- 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.)

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. [10]

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 [11] so maybe it survived in Prey?)

glasswarp -- removed. [12][13] Heathaze program stages are used instead.

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

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.' -- [15]

'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.' -- [16]

islightgemsurf [17]

withAudio -- parameter added to videoMap [18] [19]

cubicLight, ambientCubicLight -- [20] lightFalloffCubeMap, makeIrradiance() -- [21]

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

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

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 -- [23] -- but now see [24],[25]

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

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

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. (All non-particle deforms? Does TDM even use 'deform eyeball'?) But turbulent is at least partly compatible with light-interactive bump/specular. Others...?
Particles spawned from surfaces (except that the simple ambient can add colour to them).

deform eyeball -- [29]

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.' [30] 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 [31]? 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? [32]

'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.' [33] (Do the GLSL shaders replicate this?)

TDM macros: [34]

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 [35]. 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 ([36] [37]; see also [38]) Toggled on func_static activation [39].
6
7	SHADERPARM_MODE SHADERPARM_TIME_OF_DEATH	✓ ✓	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 [40]. Set to 1 when a light breaks.
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)' [41] 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.' [42] 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 [43], [44].
9	SHADERPARM_MD3_LASTFRAME SHADERPARM_BEAM_END_Y SHADERPARM_SPRITE_HEIGHT		[45]
10	SHADERPARM_MD3_BACKLERP SHADERPARM_BEAM_END_Z		[46]
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

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 [47] 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.

TDM additions:

WorldAxis -- [48]

softeningRadius -- Presumably to tweak soft particles. Defaults to -2.0f, meaning 'auto' according to code comments.

 /* Soft particles -- SteveL #3878
 	-2.0 is the value at initialization, meaning no user specification: "auto".
 	-1.0 means no change to old system: suppress soft particles, but allow modelDepthhack if specified.
 	 0   means disable all softening for this stage, including modelDepthHack.
 	 +ve value means apply soft particle effect, allowing overdraw up to the specified depth. 
 	This is more flexible even when not using soft particles, as modelDepthHack 
 	can be turned off for specific stages to stop them poking through walls.
 	*/

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).' [49] See [50]

FX

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

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();
 	}
 }

GUIs

Focus doesn't work in TDM: [53]

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 [54] (including TDM additions; passing over reverb, ordered, plain and onDemand, all marked no longer supported):

antiPrivate -- opposite of private, presumably

playonce

fromVideo -- [55] [56]

no_efx -- [57]

Triggers

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

'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' [59]

Targets

target_setinfluence removed? (Maybe considered redundant with S/R or too D3/'demonic'-specific? Comparing [60] 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 [61]. Can crash TDM on map load if e.g. targetted by worldspawn. D3 usage: [62]; D3 def here: [63]

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" );

[64], [65]

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

 enum { SCANNING, LOSINGINTEREST, ALERT, ACTIVATED }

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

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.

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

Does clipmodel_contents still exist/work? -- Yes, as in atdm:blood_marker

$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.)

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.