The DarkMod Wiki - User contributions [en]

Missing assets by map

2013-06-24T08:50:59Z

Fidcal: /* Thief's Den (Fidcal) */

This page is a list of missing assets by map. My plan is to go through these map by map to find which assets need to be added.

I will not include warnings that also show up in 1.08, as these aren't standalone issues: [[list of pre 2.0 warnings]]

= READY FOR 2.0 RELEASE =
These are maps that have been tested under TDM 2.0 and deemed ready for release. Missions that have an updated .pk4 will be noted.

== Tears of St. Lucia (jdude/Springheel) ==

==Reap as you sow (Fieldmedic) ==

== Betrayal (Fieldmedic) ==

== Awaiting the Storm (HappyCheeze)- new .pk4 ==

== House of Theo (Theothesnopp) ==

== Rake Off (Jesps) - complete! ==

== A Score to Settle (Springheel) - new .pk4 ==

== The Phrase Book (Sotha) - complete! ==

== WS1: In the North (grayman) - complete! ==

== Lockdown Part 1 (GameDevGoro Bikerdude Fidcal) ==

==Dark Mod Training Mission, The ==

== A Night to Remember (Fieldmedic) ==

== Beleagured Fence (Sotha) - complete! ==

== Builder Roads (Obsttorte) - complete! ==

== The Transaction (Sotha) - complete! ==

== Patently Dangerous (demagogue) - new .pk4 ==

== Trapped! (RailGun) - complete! ==

== Swing (Komag ) ==

==Illusionist's Tower (stumpy) ==

== Sons of Baltona Part 1 (Carnage) - complete! ==

== Rightful Property (jysk) - complete! ==

== Living Expenses (Sonosuke) - complete! ==

== Builder's Influence (Railgun, Springheel) - complete! ==

== A Special Delivery (Silencium18) ==

== Mad's Mountain (Jesps) ==

== Parcel, The (Xonze)- complete! ==

==Chalice of Kings (Fidcal) - complete! ==

== Somewhere Above the City (grayman) - new .pk4 ==

''on FTP site''

==Crown of Penitence, The (Jesps) - complete! ==

== Return to the City (Melan/Bikderdude) - new .pk4 ==
''on FTP site''

== Knighton's Manor (Sotha) - complete! ==
== Sneak and Destroy (SeriousToni) - complete! ==
== Fiasco at Fauchard Street (Melan) - complete! ==
== The Thieves (Silencium, RailGun, Fidcal) - complete! ==
== Pandora's Box (Jesps, Fidcal) ==
== The Outpost (angua/greebo) - complete! ==
== Too Late (Nielsen74) - complete! ==
== Let Sleeping Thieves Lie (Sir Taffsalot, Bikerdude)- complete! ==
== Vengeance for a Thief Part I (Sir Taffsalot) - new .pk4 ==

''on ftp''

= READY FOR MAPPER FIXES =

These are maps that require fixes by a mapper, or are waiting to be beta-tested to make everything works properly. Once they are corrected or confirmed working, they will be removed from this category. Updated .pk4s should be given to the development team for release after 2.0.

== Glenham Tower (Sotha) ==

''New .pk4 just needs to be beta-tested. I'll test it.''

WARNING:Couldn't load image: models/mapobjects/hell/site3/archviletemple/candle
_a

== Old Habits (1) (Obsttorte) ==

recyc_pipedrip10 ''<-- still listed as missing, but the particle ISN'T missing. It's in tdm_water.prt. Huh?''

WARNING:Couldn't load image: lights/blamplighttile ''<--mapper fix''

WARNING:Couldn't load image: lights/floorvent01x ''<--mapper fix''

''Obsttorte will be making any necessary updates to this map''

==Alchemist, The (Sotha, Fidcal) ==

WARNING:Couldn't load sound 'stone_sliding.wav' using default ''<-- mapper fix; cannot find any such file''

WARNING:Couldn't load image: lights/tdm_sky_skyfadebiground1 ''<-- mapper fix''

WARNING:Couldn't load image: models/misc/rope_dark_noshadows ''<-- mapper fix''

WARNING:Couldn't load image: textures//priestbottom_black_d ''<-- mapper fix''

WARNING:Couldn't load image: textures/darkmod/nature/skybox/starry1_moon ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/bacteria_4 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/metal1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/wood1 <-- mapper fix; replace with "textures/darkmod/wood/boards/old_worn_black"

''I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal''

==Dragon's Claw (Bikerdude, Flanders) ==

WARNING:Couldn't load image: lights/squarelight2 ''<-- mapper fix; cannot find such a light in D3''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! Make sure you triplet it down ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

''Biker will make any necessary changes to this map''

== House in Blackbog Hollow (Stumpy) ==

"blooddrippy" particle apparently used, but the "textures/particlesbloodstream4" in the particle does not seem to exist anywhere ''<-- mapper fix;''

''stumpy will make necessary fixes to this map''

== St. Alban's Cathedral (Bikerdude) ==

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock1.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock5.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock6.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves1_7.ASE' (nor the fa
llback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves2_5c.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== In Remembrance of Him (RPGista) ==

''conversations broken in 1.08...might be a good time to fix them''

==Deceptive Shadows (ShadowHide) ==

NO MISSING ASSETS

==The Caduceus of St. Alban (Bikderdude)==

WARNING:Couldn't load image: textures/decals/stainwallfadered ''<-- mapper fix; typo?''

WARNING:Couldn't load image: textures/hell/rock1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/items/shells_ammo/shells_large.lwo' (nor t
he fallback to ASE) ''<-- mapper fix'

''Biker will make any necessary changes to this map''

==Crystal Grave (ERH+ Bikerdude) ==

NO MISSING ASSETS

== Business as Usual (Bikerdude) ==

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Rift (Baddcog) - complete!==

Has been beta-tested: http://forums.thedarkmod.com/topic/14768-the-rift-baddcog/page__pid__311580#entry311580

''Will need a new pk4.''

== Alberic's Curse (Bikerdude) ==

*D 200: aboutpostiilightdustbig ''<-- mapper fix; cannot find any particle with this name''

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== Winter Harvest (Shadowhide) ==

WARNING:Couldn't load image: models/mapobjects/hell/site3/archviletemple/candle
_a ''<-- mapper fix''

'''Will need new .pk4'''

== Thief's Den (Fidcal) ==

Beta-tested: http://forums.thedarkmod.com/topic/14731-thiefs-den-fidcal/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix. Used on lift''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with darkmod/furniture/beds/mattress.lwo
''

I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

==Closemouthed Shadows (LordSavage, Bikerdude) ==

Beta-tested: http://forums.thedarkmod.com/topic/14742-closemouthed-shadows-lordsavage-bikerdude/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix; could easily be replaced with rope texture''

== Seige Shop (PranQster) ==

''Contains its own outdated version of tdm_ai_commoners.mtr and tdm_heads_dev.mtr, so is trying to load all kinds of files that no longer exist, and may not even be used in map.''

WARNING:Couldn't load image: models/characters/scientist/head02/hair ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgerbottom_shad
ows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgertop_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black_s ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/npcs/beard_black_local ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: new_average_jack_texture ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head06 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head08 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: shoulder_cowl ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_light_tan_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged_shadows ''<-- mapper fix; outdated file''

= REPLACEMENT ASSETS NEEDED =

These are maps that still need to have assets replaced by the development team. They are not ready for mapper fixes or beta-testing yet.

== The Creeps (Mortem Desino) ==

*D 206: kpillar_celingdust1

*D 207: recyc_hexdrip3

*D 208: recyc_hexdrip1

*D 209: recyc_hexdrip2

*D 210: recyc_hexdrip4

*D 211: mcu_minifalldust

WARNING:Couldn't load image: textures/Leaf_1_s ''<-- not in either set of material files''

WARNING:Couldn't load image: textures/Leaf_5_s '''''Note from MD:''' These three "leaf" specularmaps are not crucial (i.e. they probably should just be 100% black images, anyways).''

WARNING:Couldn't load image: textures/Leaf_6_s

'''''MD:''' I think most of these light textures could be replaced with another TDM-2.0-ready light texture in DR. ''

WARNING:Couldn't load image: lights/hellgate1 '''''MD:''' The one bound to revenant_spirit_chase; Could be replaced in DR by any red-colored light.''

WARNING:Couldn't load image: lights/hellgate1_colorme '''''MD:''' Present in a lot of ambient lights. I think if there were a suitable replacement for squareishlight, that could double as a suitable replacement for hellgate1_colorme.''

WARNING:Couldn't load image: lights/redcircuit '''''MD:''' AKA: redlight01, the light bound to revenant_spirit_shadow; could be replaced in DR by any red-colored light''

WARNING:Couldn't load image: lights/squareishlight '''''MD:''' See note on hellgate1_colorme.''

WARNING:Couldn't load image: lights/vivlight '''''MD:''' Present, I think, only on light_25 in the catacombs. Replace in DR with any turquoise-ish square light?''

WARNING:Couldn't load image: models/items/flashlight/dust

WARNING:Couldn't load image: models/items/lantern/lanternflare

Additionally, I've made up a quick drag-n-drop [https://dl.dropboxusercontent.com/u/12230253/tdm/thecreeps_oggrepl.zip replacement for one SFX], so the mission plays nice with iD copyright.

''Mortem would like a volunteer to update .pk4''

= NOT CURRENTLY WORKING =
These are missions that won't load under 2.0 for whatever reason. Could be related to missing assets, or could be something about my local copy. Either way I'll be leaving these for last.

== Samhain Night on Bone Hill (PranQster) ==
'''runs, but needs fully working werebeast to be playable'''

*D 168: tels_firearrow_explosion ''<-- Mapper fix''

*D 169: tels_waterarrow_trail ''<-- Mapper fix''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

WARNING:Couldn't load sound 'monster_zombie_maint_footstep.wav' using default

WARNING:Couldn't load sound 'sound/ambient/environmental/steelswing_01.wav' usi
ng default

==Mandrasola (Sotha) ==

Will probably run, but will not be playable without working animations for missing character (you know who you are)

== Flakebridge Monastery (Jesps) ==

'''Crashes with error:'''

ERROR:Joint 'Rhand' not found for bind on 'func_static_212'

'''This is due to the new zombie having different joint names. It will require fixing the .pk4.'''

WARNING:Couldn't load sound 'stone_impact.wav' using default

WARNING:Couldn't load sound 'paper_impact.wav' using default

WARNING:Couldn't load sound 'book_impact.wav' using default

==Heart of Lone Salvation, The (Fidcal)==

'''Crashes with error:
ERROR:idMoveable 'sheet_paper6': cannot load collision model models/mapobjects/
filler/paperwad1.lwo'''

WARNING:Couldn't load model: 'models/mapobjects/filler/paperwad1.lwo' (nor the
fallback to ASE)

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; use models/darkmod/furniture/beds/mattress.lwo''

''Obstortte has volunteered to fix this.''

= NOT TESTED =

== Old Habits II (Obsttorte) ==

== The Lich Queen's Demise (Sotha) ==

==Lord Dufford's (stumpy)==

''stumpy will make necessary fixes to this map''

==Q4 Conversion: Yan's Test (Bikerdude) ==
== No Honour Among Theives: episode 1 (goldchocobo) ==

This was crashing at map start, but should be retested with at least SVN revision 13442.

That revision fixes the crash, which was unrelated to the presence or absence of D3 assets.

'' Since an update to this is due to be released shortly, I will wait before testing the NHAT maps.''

==No Honor Among Thieves Part 2 (goldchocobo) ==
==No Honor Among Thieves Part 3 (goldchocobo)==

Missing assets by map

2013-06-06T09:59:39Z

Fidcal: /* Heart of Lone Salvation, The (Fidcal) */

This page is a list of missing assets by map. My plan is to go through these map by map to find which assets need to be added.

I will not include warnings that also show up in 1.08, as these aren't standalone issues: [[list of pre 2.0 warnings]]

= READY FOR 2.0 RELEASE =
These are maps that have been tested under TDM 2.0 and deemed ready for release. Missions that have an updated .pk4 will be noted.

== Lockdown Part 1 (GameDevGoro Bikerdude Fidcal) ==

==Dark Mod Training Mission, The ==

== A Night to Remember (Fieldmedic) ==

== Beleagured Fence (Sotha) - complete! ==

== Builder Roads (Obsttorte) - complete! ==

== The Transaction (Sotha) - complete! ==

== Patently Dangerous (demagogue) - new .pk4 ==

== Trapped! (RailGun) - complete! ==

== Swing (Komag ) ==

==Illusionist's Tower (stumpy) ==

== Sons of Baltona Part 1 (Carnage) - complete! ==

== Rightful Property (jysk) - complete! ==

== Living Expenses (Sonosuke) - complete! ==

== Builder's Influence (Railgun, Springheel) - complete! ==

== A Special Delivery (Silencium18) ==

== Mad's Mountain (Jesps) ==

== Parcel, The (Xonze)- complete! ==

==Chalice of Kings (Fidcal) - complete! ==

== Somewhere Above the City (grayman) - new .pk4 ==

''on FTP site''

==Crown of Penitence, The (Jesps) - complete! ==

== Return to the City (Melan/Bikderdude) - new .pk4 ==
''on FTP site''

== Knighton's Manor (Sotha) - complete! ==
== Sneak and Destroy (SeriousToni) - complete! ==
== Fiasco at Fauchard Street (Melan) - complete! ==
== The Thieves (Silencium, RailGun, Fidcal) - complete! ==
== Pandora's Box (Jesps, Fidcal) ==
== The Outpost (angua/greebo) - complete! ==
== Too Late (Nielsen74) - complete! ==
== Let Sleeping Thieves Lie (Sir Taffsalot, Bikerdude)- complete! ==
== Vengeance for a Thief Part I (Sir Taffsalot) - new .pk4 ==

''on ftp''

= READY FOR MAPPER FIXES =

These are maps that require fixes by a mapper, or are waiting to be beta-tested to make everything works properly. Once they are corrected or confirmed working, they will be removed from this category. Updated .pk4s should be given to the development team for release after 2.0.

== Old Habits (1) (Obsttorte) ==

recyc_pipedrip10 ''<-- still listed as missing, but the particle ISN'T missing. It's in tdm_water.prt. Huh?''

WARNING:Couldn't load image: lights/blamplighttile ''<--mapper fix''

WARNING:Couldn't load image: lights/floorvent01x ''<--mapper fix''

''Obsttorte will be making any necessary updates to this map''

==Alchemist, The (Sotha, Fidcal) ==

WARNING:Couldn't load sound 'stone_sliding.wav' using default ''<-- mapper fix; cannot find any such file''

WARNING:Couldn't load image: lights/tdm_sky_skyfadebiground1 ''<-- mapper fix''

WARNING:Couldn't load image: models/misc/rope_dark_noshadows ''<-- mapper fix''

WARNING:Couldn't load image: textures//priestbottom_black_d ''<-- mapper fix''

WARNING:Couldn't load image: textures/darkmod/nature/skybox/starry1_moon ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/bacteria_4 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/metal1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/wood1 <-- mapper fix; replace with "textures/darkmod/wood/boards/old_worn_black"

I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

==Dragon's Claw (Bikerdude, Flanders) ==

WARNING:Couldn't load image: lights/squarelight2 ''<-- mapper fix; cannot find such a light in D3''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! Make sure you triplet it down ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

''Biker will make any necessary changes to this map''

== House in Blackbog Hollow (Stumpy) ==

"blooddrippy" particle apparently used, but the "textures/particlesbloodstream4" in the particle does not seem to exist anywhere ''<-- mapper fix;''

''stumpy will make necessary fixes to this map''

== St. Alban's Cathedral (Bikerdude) ==

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock1.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock5.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock6.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves1_7.ASE' (nor the fa
llback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves2_5c.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== In Remembrance of Him (RPGista) ==

''conversations broken in 1.08...might be a good time to fix them''

== Betrayal (Fieldmedic) ==

WARNING:Couldn't load image: textures/decals/floor_drain ''<-- mapper fix''

WARNING:sound shader 'beam_fall_1' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_1.wav' ''<-- mapper fix; sound not found''

WARNING:sound shader 'beam_fall_2' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_2.wav' ''<-- mapper fix; sound not found''

==Deceptive Shadows (ShadowHide) ==

NO MISSING ASSETS

== Awaiting the Storm (HappyCheeze) ==

WARNING:Couldn't load image: textures/hell/wood1 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/darkmod/architecture/buildings/wooden_shed
.lwo' (nor the fallback to ASE) ''<-- mapper fix; no such model''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with models/furniture/bed/mattress.lwo''

''unable to contact HappyCheeze about modifying this map''

==The Caduceus of St. Alban (Bikderdude)==

WARNING:Couldn't load image: textures/decals/stainwallfadered ''<-- mapper fix; typo?''

WARNING:Couldn't load image: textures/hell/rock1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/items/shells_ammo/shells_large.lwo' (nor t
he fallback to ASE) ''<-- mapper fix'

''Biker will make any necessary changes to this map''

==Crystal Grave (ERH+ Bikerdude) ==

NO MISSING ASSETS

== Tears of St. Lucia (jdude/Springheel) ==

WARNING:Couldn't load sound 'sound/xian/roomtones2/dangerlow_01.wav' using defa
ult ''<-- mapper fix''

WARNING:Couldn't load sound 'sound/xian/suspense/loop_suspense_07.wav' using de
fault ''<-- mapper fix''

''Springheel has signed up for any updates needed to this map.''

==Reap as you sow (Fieldmedic) ==

WARNING:Couldn't load sound 'tdm_impact_small_soft_object.wav' using default ''<-- mapper fix; no such sounds exists''

== Rake Off (Jesps) - complete! ==

Beta-tested: http://forums.thedarkmod.com/topic/14757-rake-off-jesps/

''easter egg objective fires after 9 instead of 10?''

NO MISSING ASSETS

== Business as Usual (Bikerdude) ==

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Rift (Baddcog) - complete!==

Has been beta-tested: http://forums.thedarkmod.com/topic/14768-the-rift-baddcog/page__pid__311580#entry311580

''Will need a new pk4.''

== A Score to Settle (Springheel) ==

In DR, following textures not being found:
sqsky

''Springheel has signed up for any updates needed to this map.''

== Alberic's Curse (Bikerdude) ==

*D 200: aboutpostiilightdustbig ''<-- mapper fix; cannot find any particle with this name''

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Phrase Book (Sotha) - complete! ==

NO MISSING ASSETS!

== WS1: In the North (grayman) - complete! ==

NO MISSING ASSETS!

''grayman will be making any necessary updates to this map''

== Winter Harvest (Shadowhide) ==

WARNING:Couldn't load image: models/mapobjects/hell/site3/archviletemple/candle
_a ''<-- mapper fix''

'''Will need new .pk4'''

== Thief's Den (Fidcal) ==

Beta-tested: http://forums.thedarkmod.com/topic/14731-thiefs-den-fidcal/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix. Used on lift''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with darkmod/furniture/beds/mattress.lwo
''
I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

== House of Theo (Theothesnopp) ==

WARNING:Could not find anim idle_sit_2 on entity atdm_ai_townsfolk_commoner_3 ''<-- mapper fix; should be idle_sit2 (not 2.0 related)''

==Closemouthed Shadows (LordSavage, Bikerdude) ==

Beta-tested: http://forums.thedarkmod.com/topic/14742-closemouthed-shadows-lordsavage-bikerdude/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix''

== Seige Shop (PranQster) ==

''Contains its own outdated version of tdm_ai_commoners.mtr and tdm_heads_dev.mtr, so is trying to load all kinds of files that no longer exist, and may not even be used in map.''

WARNING:Couldn't load image: models/characters/scientist/head02/hair ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgerbottom_shad
ows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgertop_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black_s ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/npcs/beard_black_local ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: new_average_jack_texture ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head06 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head08 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: shoulder_cowl ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_light_tan_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged_shadows ''<-- mapper fix; outdated file''

= REPLACEMENT ASSETS NEEDED =

These are maps that still need to have assets replaced by the development team. They are not ready for mapper fixes or beta-testing yet.

= NOT CURRENTLY WORKING =
These are missions that won't load under 2.0 for whatever reason. Could be related to missing assets, or could be something about my local copy. Either way I'll be leaving these for last.

== Samhain Night on Bone Hill (PranQster) ==
'''runs, but needs fully working werebeast to be playable'''

*D 168: tels_firearrow_explosion ''<-- Mapper fix''

*D 169: tels_waterarrow_trail ''<-- Mapper fix''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

WARNING:Couldn't load sound 'monster_zombie_maint_footstep.wav' using default

WARNING:Couldn't load sound 'sound/ambient/environmental/steelswing_01.wav' usi
ng default

== Glenham Tower (Sotha) ==

Haven't tried to load it, but I know it will crash with an error about zombie joints. Will need mapper fix to replace old joints with joints that exist on new skeleton.

''Sotha is looking for volunteers to fix this map.''

==Mandrasola (Sotha) ==

Will probably run, but will not be playable without working animations for missing character (you know who you are)

== The Creeps (Mortem Desino) ==

'''Fails to load with error:'''

ERROR:Joint 'Head' not found for attachment position 'velvetcap_1' on entity 'i
dAFAttachment_atdm:ai_headbox_zombie_646'

WARNING:Couldn't load anim: 'models/md5/characters/npcs/zheads/z1idle.md5anim'

WARNING:file def/tdm_ai_heads.def, line 274: Couldn't load anim 'models/md5/cha
racters/npcs/zheads/z1idle.md5anim'

'''NOTE FROM MD:''' I anticipated this problem. The solution for this is already in the FM package:
on entity revenant_spirit_shadow set "def_head" "atdm:ai_head_rev_spirit"
on entity revenant_spirit_chase set "def_head" "atdm:ai_head_rev_spirit"

Now, I think all that is left are a bunch of missing particle assets (mostly water drips and dust falling from ceiling) as well as light textures (you'll notice that many of the FM's saturated colored ambient lights are missing, leaving you with only the very dim ambient_world)

''Mortem would like a volunteer to update .pk4''

== Flakebridge Monastery (Jesps) ==

'''Crashes with error:'''

ERROR:Joint 'Rhand' not found for bind on 'func_static_212'

'''This is due to the new zombie having different joint names. It will require fixing the .pk4.'''

WARNING:Couldn't load sound 'stone_impact.wav' using default

WARNING:Couldn't load sound 'paper_impact.wav' using default

WARNING:Couldn't load sound 'book_impact.wav' using default

==Heart of Lone Salvation, The (Fidcal)==

'''Crashes with error:
ERROR:idMoveable 'sheet_paper6': cannot load collision model models/mapobjects/
filler/paperwad1.lwo'''

WARNING:Couldn't load model: 'models/mapobjects/filler/paperwad1.lwo' (nor the
fallback to ASE)

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; use models/darkmod/furniture/beds/mattress.lwo''

Obstortte has volunteered to fix this.

= NOT TESTED =

== Old Habits II (Obsttorte) ==

== The Lich Queen's Demise (Sotha) ==

==Lord Dufford's (stumpy)==

''stumpy will make necessary fixes to this map''

==Q4 Conversion: Yan's Test (Bikerdude) ==
== No Honour Among Theives: episode 1 (goldchocobo) ==

This was crashing at map start, but should be retested with at least SVN revision 13442.

That revision fixes the crash, which was unrelated to the presence or absence of D3 assets.

'' Since an update to this is due to be released shortly, I will wait before testing the NHAT maps.''

==No Honor Among Thieves Part 2 (goldchocobo) ==
==No Honor Among Thieves Part 3 (goldchocobo)==

Missing assets by map

2013-06-06T09:58:46Z

Fidcal: /* Thief's Den (Fidcal) */

This page is a list of missing assets by map. My plan is to go through these map by map to find which assets need to be added.

I will not include warnings that also show up in 1.08, as these aren't standalone issues: [[list of pre 2.0 warnings]]

= READY FOR 2.0 RELEASE =
These are maps that have been tested under TDM 2.0 and deemed ready for release. Missions that have an updated .pk4 will be noted.

== Lockdown Part 1 (GameDevGoro Bikerdude Fidcal) ==

==Dark Mod Training Mission, The ==

== A Night to Remember (Fieldmedic) ==

== Beleagured Fence (Sotha) - complete! ==

== Builder Roads (Obsttorte) - complete! ==

== The Transaction (Sotha) - complete! ==

== Patently Dangerous (demagogue) - new .pk4 ==

== Trapped! (RailGun) - complete! ==

== Swing (Komag ) ==

==Illusionist's Tower (stumpy) ==

== Sons of Baltona Part 1 (Carnage) - complete! ==

== Rightful Property (jysk) - complete! ==

== Living Expenses (Sonosuke) - complete! ==

== Builder's Influence (Railgun, Springheel) - complete! ==

== A Special Delivery (Silencium18) ==

== Mad's Mountain (Jesps) ==

== Parcel, The (Xonze)- complete! ==

==Chalice of Kings (Fidcal) - complete! ==

== Somewhere Above the City (grayman) - new .pk4 ==

''on FTP site''

==Crown of Penitence, The (Jesps) - complete! ==

== Return to the City (Melan/Bikderdude) - new .pk4 ==
''on FTP site''

== Knighton's Manor (Sotha) - complete! ==
== Sneak and Destroy (SeriousToni) - complete! ==
== Fiasco at Fauchard Street (Melan) - complete! ==
== The Thieves (Silencium, RailGun, Fidcal) - complete! ==
== Pandora's Box (Jesps, Fidcal) ==
== The Outpost (angua/greebo) - complete! ==
== Too Late (Nielsen74) - complete! ==
== Let Sleeping Thieves Lie (Sir Taffsalot, Bikerdude)- complete! ==
== Vengeance for a Thief Part I (Sir Taffsalot) - new .pk4 ==

''on ftp''

= READY FOR MAPPER FIXES =

These are maps that require fixes by a mapper, or are waiting to be beta-tested to make everything works properly. Once they are corrected or confirmed working, they will be removed from this category. Updated .pk4s should be given to the development team for release after 2.0.

== Old Habits (1) (Obsttorte) ==

recyc_pipedrip10 ''<-- still listed as missing, but the particle ISN'T missing. It's in tdm_water.prt. Huh?''

WARNING:Couldn't load image: lights/blamplighttile ''<--mapper fix''

WARNING:Couldn't load image: lights/floorvent01x ''<--mapper fix''

''Obsttorte will be making any necessary updates to this map''

==Alchemist, The (Sotha, Fidcal) ==

WARNING:Couldn't load sound 'stone_sliding.wav' using default ''<-- mapper fix; cannot find any such file''

WARNING:Couldn't load image: lights/tdm_sky_skyfadebiground1 ''<-- mapper fix''

WARNING:Couldn't load image: models/misc/rope_dark_noshadows ''<-- mapper fix''

WARNING:Couldn't load image: textures//priestbottom_black_d ''<-- mapper fix''

WARNING:Couldn't load image: textures/darkmod/nature/skybox/starry1_moon ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/bacteria_4 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/metal1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/wood1 <-- mapper fix; replace with "textures/darkmod/wood/boards/old_worn_black"

I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

==Dragon's Claw (Bikerdude, Flanders) ==

WARNING:Couldn't load image: lights/squarelight2 ''<-- mapper fix; cannot find such a light in D3''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! Make sure you triplet it down ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

''Biker will make any necessary changes to this map''

== House in Blackbog Hollow (Stumpy) ==

"blooddrippy" particle apparently used, but the "textures/particlesbloodstream4" in the particle does not seem to exist anywhere ''<-- mapper fix;''

''stumpy will make necessary fixes to this map''

== St. Alban's Cathedral (Bikerdude) ==

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock1.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock5.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock6.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves1_7.ASE' (nor the fa
llback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves2_5c.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== In Remembrance of Him (RPGista) ==

''conversations broken in 1.08...might be a good time to fix them''

== Betrayal (Fieldmedic) ==

WARNING:Couldn't load image: textures/decals/floor_drain ''<-- mapper fix''

WARNING:sound shader 'beam_fall_1' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_1.wav' ''<-- mapper fix; sound not found''

WARNING:sound shader 'beam_fall_2' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_2.wav' ''<-- mapper fix; sound not found''

==Deceptive Shadows (ShadowHide) ==

NO MISSING ASSETS

== Awaiting the Storm (HappyCheeze) ==

WARNING:Couldn't load image: textures/hell/wood1 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/darkmod/architecture/buildings/wooden_shed
.lwo' (nor the fallback to ASE) ''<-- mapper fix; no such model''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with models/furniture/bed/mattress.lwo''

''unable to contact HappyCheeze about modifying this map''

==The Caduceus of St. Alban (Bikderdude)==

WARNING:Couldn't load image: textures/decals/stainwallfadered ''<-- mapper fix; typo?''

WARNING:Couldn't load image: textures/hell/rock1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/items/shells_ammo/shells_large.lwo' (nor t
he fallback to ASE) ''<-- mapper fix'

''Biker will make any necessary changes to this map''

==Crystal Grave (ERH+ Bikerdude) ==

NO MISSING ASSETS

== Tears of St. Lucia (jdude/Springheel) ==

WARNING:Couldn't load sound 'sound/xian/roomtones2/dangerlow_01.wav' using defa
ult ''<-- mapper fix''

WARNING:Couldn't load sound 'sound/xian/suspense/loop_suspense_07.wav' using de
fault ''<-- mapper fix''

''Springheel has signed up for any updates needed to this map.''

==Reap as you sow (Fieldmedic) ==

WARNING:Couldn't load sound 'tdm_impact_small_soft_object.wav' using default ''<-- mapper fix; no such sounds exists''

== Rake Off (Jesps) - complete! ==

Beta-tested: http://forums.thedarkmod.com/topic/14757-rake-off-jesps/

''easter egg objective fires after 9 instead of 10?''

NO MISSING ASSETS

== Business as Usual (Bikerdude) ==

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Rift (Baddcog) - complete!==

Has been beta-tested: http://forums.thedarkmod.com/topic/14768-the-rift-baddcog/page__pid__311580#entry311580

''Will need a new pk4.''

== A Score to Settle (Springheel) ==

In DR, following textures not being found:
sqsky

''Springheel has signed up for any updates needed to this map.''

== Alberic's Curse (Bikerdude) ==

*D 200: aboutpostiilightdustbig ''<-- mapper fix; cannot find any particle with this name''

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Phrase Book (Sotha) - complete! ==

NO MISSING ASSETS!

== WS1: In the North (grayman) - complete! ==

NO MISSING ASSETS!

''grayman will be making any necessary updates to this map''

== Winter Harvest (Shadowhide) ==

WARNING:Couldn't load image: models/mapobjects/hell/site3/archviletemple/candle
_a ''<-- mapper fix''

'''Will need new .pk4'''

== Thief's Den (Fidcal) ==

Beta-tested: http://forums.thedarkmod.com/topic/14731-thiefs-den-fidcal/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix. Used on lift''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with darkmod/furniture/beds/mattress.lwo
''
I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

== House of Theo (Theothesnopp) ==

WARNING:Could not find anim idle_sit_2 on entity atdm_ai_townsfolk_commoner_3 ''<-- mapper fix; should be idle_sit2 (not 2.0 related)''

==Closemouthed Shadows (LordSavage, Bikerdude) ==

Beta-tested: http://forums.thedarkmod.com/topic/14742-closemouthed-shadows-lordsavage-bikerdude/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix''

== Seige Shop (PranQster) ==

''Contains its own outdated version of tdm_ai_commoners.mtr and tdm_heads_dev.mtr, so is trying to load all kinds of files that no longer exist, and may not even be used in map.''

WARNING:Couldn't load image: models/characters/scientist/head02/hair ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgerbottom_shad
ows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgertop_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black_s ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/npcs/beard_black_local ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: new_average_jack_texture ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head06 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head08 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: shoulder_cowl ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_light_tan_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged_shadows ''<-- mapper fix; outdated file''

= REPLACEMENT ASSETS NEEDED =

These are maps that still need to have assets replaced by the development team. They are not ready for mapper fixes or beta-testing yet.

= NOT CURRENTLY WORKING =
These are missions that won't load under 2.0 for whatever reason. Could be related to missing assets, or could be something about my local copy. Either way I'll be leaving these for last.

== Samhain Night on Bone Hill (PranQster) ==
'''runs, but needs fully working werebeast to be playable'''

*D 168: tels_firearrow_explosion ''<-- Mapper fix''

*D 169: tels_waterarrow_trail ''<-- Mapper fix''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

WARNING:Couldn't load sound 'monster_zombie_maint_footstep.wav' using default

WARNING:Couldn't load sound 'sound/ambient/environmental/steelswing_01.wav' usi
ng default

== Glenham Tower (Sotha) ==

Haven't tried to load it, but I know it will crash with an error about zombie joints. Will need mapper fix to replace old joints with joints that exist on new skeleton.

''Sotha is looking for volunteers to fix this map.''

==Mandrasola (Sotha) ==

Will probably run, but will not be playable without working animations for missing character (you know who you are)

== The Creeps (Mortem Desino) ==

'''Fails to load with error:'''

ERROR:Joint 'Head' not found for attachment position 'velvetcap_1' on entity 'i
dAFAttachment_atdm:ai_headbox_zombie_646'

WARNING:Couldn't load anim: 'models/md5/characters/npcs/zheads/z1idle.md5anim'

WARNING:file def/tdm_ai_heads.def, line 274: Couldn't load anim 'models/md5/cha
racters/npcs/zheads/z1idle.md5anim'

'''NOTE FROM MD:''' I anticipated this problem. The solution for this is already in the FM package:
on entity revenant_spirit_shadow set "def_head" "atdm:ai_head_rev_spirit"
on entity revenant_spirit_chase set "def_head" "atdm:ai_head_rev_spirit"

Now, I think all that is left are a bunch of missing particle assets (mostly water drips and dust falling from ceiling) as well as light textures (you'll notice that many of the FM's saturated colored ambient lights are missing, leaving you with only the very dim ambient_world)

''Mortem would like a volunteer to update .pk4''

== Flakebridge Monastery (Jesps) ==

'''Crashes with error:'''

ERROR:Joint 'Rhand' not found for bind on 'func_static_212'

'''This is due to the new zombie having different joint names. It will require fixing the .pk4.'''

WARNING:Couldn't load sound 'stone_impact.wav' using default

WARNING:Couldn't load sound 'paper_impact.wav' using default

WARNING:Couldn't load sound 'book_impact.wav' using default

==Heart of Lone Salvation, The (Fidcal)==

'''Crashes with error:
ERROR:idMoveable 'sheet_paper6': cannot load collision model models/mapobjects/
filler/paperwad1.lwo'''

WARNING:Couldn't load model: 'models/mapobjects/filler/paperwad1.lwo' (nor the
fallback to ASE)

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; use models/darkmod/furniture/beds/mattress.lwo''

= NOT TESTED =

== Old Habits II (Obsttorte) ==

== The Lich Queen's Demise (Sotha) ==

==Lord Dufford's (stumpy)==

''stumpy will make necessary fixes to this map''

==Q4 Conversion: Yan's Test (Bikerdude) ==
== No Honour Among Theives: episode 1 (goldchocobo) ==

This was crashing at map start, but should be retested with at least SVN revision 13442.

That revision fixes the crash, which was unrelated to the presence or absence of D3 assets.

'' Since an update to this is due to be released shortly, I will wait before testing the NHAT maps.''

==No Honor Among Thieves Part 2 (goldchocobo) ==
==No Honor Among Thieves Part 3 (goldchocobo)==

Missing assets by map

2013-06-06T09:57:50Z

Fidcal: /* Alchemist, The (Sotha, Fidcal) */

This page is a list of missing assets by map. My plan is to go through these map by map to find which assets need to be added.

I will not include warnings that also show up in 1.08, as these aren't standalone issues: [[list of pre 2.0 warnings]]

= READY FOR 2.0 RELEASE =
These are maps that have been tested under TDM 2.0 and deemed ready for release. Missions that have an updated .pk4 will be noted.

== Lockdown Part 1 (GameDevGoro Bikerdude Fidcal) ==

==Dark Mod Training Mission, The ==

== A Night to Remember (Fieldmedic) ==

== Beleagured Fence (Sotha) - complete! ==

== Builder Roads (Obsttorte) - complete! ==

== The Transaction (Sotha) - complete! ==

== Patently Dangerous (demagogue) - new .pk4 ==

== Trapped! (RailGun) - complete! ==

== Swing (Komag ) ==

==Illusionist's Tower (stumpy) ==

== Sons of Baltona Part 1 (Carnage) - complete! ==

== Rightful Property (jysk) - complete! ==

== Living Expenses (Sonosuke) - complete! ==

== Builder's Influence (Railgun, Springheel) - complete! ==

== A Special Delivery (Silencium18) ==

== Mad's Mountain (Jesps) ==

== Parcel, The (Xonze)- complete! ==

==Chalice of Kings (Fidcal) - complete! ==

== Somewhere Above the City (grayman) - new .pk4 ==

''on FTP site''

==Crown of Penitence, The (Jesps) - complete! ==

== Return to the City (Melan/Bikderdude) - new .pk4 ==
''on FTP site''

== Knighton's Manor (Sotha) - complete! ==
== Sneak and Destroy (SeriousToni) - complete! ==
== Fiasco at Fauchard Street (Melan) - complete! ==
== The Thieves (Silencium, RailGun, Fidcal) - complete! ==
== Pandora's Box (Jesps, Fidcal) ==
== The Outpost (angua/greebo) - complete! ==
== Too Late (Nielsen74) - complete! ==
== Let Sleeping Thieves Lie (Sir Taffsalot, Bikerdude)- complete! ==
== Vengeance for a Thief Part I (Sir Taffsalot) - new .pk4 ==

''on ftp''

= READY FOR MAPPER FIXES =

These are maps that require fixes by a mapper, or are waiting to be beta-tested to make everything works properly. Once they are corrected or confirmed working, they will be removed from this category. Updated .pk4s should be given to the development team for release after 2.0.

== Old Habits (1) (Obsttorte) ==

recyc_pipedrip10 ''<-- still listed as missing, but the particle ISN'T missing. It's in tdm_water.prt. Huh?''

WARNING:Couldn't load image: lights/blamplighttile ''<--mapper fix''

WARNING:Couldn't load image: lights/floorvent01x ''<--mapper fix''

''Obsttorte will be making any necessary updates to this map''

==Alchemist, The (Sotha, Fidcal) ==

WARNING:Couldn't load sound 'stone_sliding.wav' using default ''<-- mapper fix; cannot find any such file''

WARNING:Couldn't load image: lights/tdm_sky_skyfadebiground1 ''<-- mapper fix''

WARNING:Couldn't load image: models/misc/rope_dark_noshadows ''<-- mapper fix''

WARNING:Couldn't load image: textures//priestbottom_black_d ''<-- mapper fix''

WARNING:Couldn't load image: textures/darkmod/nature/skybox/starry1_moon ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/bacteria_4 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/metal1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/hell/wood1 <-- mapper fix; replace with "textures/darkmod/wood/boards/old_worn_black"

I will look at this map when I can (but if anyone wants to volunteer then great - but check with me first in case I've started!) - Fidcal

==Dragon's Claw (Bikerdude, Flanders) ==

WARNING:Couldn't load image: lights/squarelight2 ''<-- mapper fix; cannot find such a light in D3''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! Make sure you triplet it down ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

''Biker will make any necessary changes to this map''

== House in Blackbog Hollow (Stumpy) ==

"blooddrippy" particle apparently used, but the "textures/particlesbloodstream4" in the particle does not seem to exist anywhere ''<-- mapper fix;''

''stumpy will make necessary fixes to this map''

== St. Alban's Cathedral (Bikerdude) ==

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- these are looking for joints that no longer exist; is there a def file in the .pk4 with old character definitions?''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock1.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock5.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caverock6.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves1_7.ASE' (nor the fa
llback to LWO) ''<-- mapper fix''

WARNING:Couldn't load model: 'models/mapobjects/caves/caves2_5c.ASE' (nor the f
allback to LWO) ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== In Remembrance of Him (RPGista) ==

''conversations broken in 1.08...might be a good time to fix them''

== Betrayal (Fieldmedic) ==

WARNING:Couldn't load image: textures/decals/floor_drain ''<-- mapper fix''

WARNING:sound shader 'beam_fall_1' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_1.wav' ''<-- mapper fix; sound not found''

WARNING:sound shader 'beam_fall_2' has shakes and uses OGG file 'sound/ambient/
ambience/beam_impact_2.wav' ''<-- mapper fix; sound not found''

==Deceptive Shadows (ShadowHide) ==

NO MISSING ASSETS

== Awaiting the Storm (HappyCheeze) ==

WARNING:Couldn't load image: textures/hell/wood1 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/darkmod/architecture/buildings/wooden_shed
.lwo' (nor the fallback to ASE) ''<-- mapper fix; no such model''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with models/furniture/bed/mattress.lwo''

''unable to contact HappyCheeze about modifying this map''

==The Caduceus of St. Alban (Bikderdude)==

WARNING:Couldn't load image: textures/decals/stainwallfadered ''<-- mapper fix; typo?''

WARNING:Couldn't load image: textures/hell/rock1 ''<-- mapper fix''

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

WARNING:Couldn't load model: 'models/items/shells_ammo/shells_large.lwo' (nor t
he fallback to ASE) ''<-- mapper fix'

''Biker will make any necessary changes to this map''

==Crystal Grave (ERH+ Bikerdude) ==

NO MISSING ASSETS

== Tears of St. Lucia (jdude/Springheel) ==

WARNING:Couldn't load sound 'sound/xian/roomtones2/dangerlow_01.wav' using defa
ult ''<-- mapper fix''

WARNING:Couldn't load sound 'sound/xian/suspense/loop_suspense_07.wav' using de
fault ''<-- mapper fix''

''Springheel has signed up for any updates needed to this map.''

==Reap as you sow (Fieldmedic) ==

WARNING:Couldn't load sound 'tdm_impact_small_soft_object.wav' using default ''<-- mapper fix; no such sounds exists''

== Rake Off (Jesps) - complete! ==

Beta-tested: http://forums.thedarkmod.com/topic/14757-rake-off-jesps/

''easter egg objective fires after 9 instead of 10?''

NO MISSING ASSETS

== Business as Usual (Bikerdude) ==

WARNING:Couldn't load image: textures/mcity/mcityplain6 ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Rift (Baddcog) - complete!==

Has been beta-tested: http://forums.thedarkmod.com/topic/14768-the-rift-baddcog/page__pid__311580#entry311580

''Will need a new pk4.''

== A Score to Settle (Springheel) ==

In DR, following textures not being found:
sqsky

''Springheel has signed up for any updates needed to this map.''

== Alberic's Curse (Bikerdude) ==

*D 200: aboutpostiilightdustbig ''<-- mapper fix; cannot find any particle with this name''

WARNING:Unknown body part lloarm in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part lloleg in articulated figure guard_base_newskel ''<-- mapper fix''

WARNING:Unknown body part rloarm in articulated figure guard_base_newskel ''<-- mapper fix''

''Biker will make any necessary changes to this map''

== The Phrase Book (Sotha) - complete! ==

NO MISSING ASSETS!

== WS1: In the North (grayman) - complete! ==

NO MISSING ASSETS!

''grayman will be making any necessary updates to this map''

== Winter Harvest (Shadowhide) ==

WARNING:Couldn't load image: models/mapobjects/hell/site3/archviletemple/candle
_a ''<-- mapper fix''

'''Will need new .pk4'''

== Thief's Den (Fidcal) ==

Beta-tested: http://forums.thedarkmod.com/topic/14731-thiefs-den-fidcal/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix. Used on lift''

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; replace with darkmod/furniture/beds/mattress.lwo
''

== House of Theo (Theothesnopp) ==

WARNING:Could not find anim idle_sit_2 on entity atdm_ai_townsfolk_commoner_3 ''<-- mapper fix; should be idle_sit2 (not 2.0 related)''

==Closemouthed Shadows (LordSavage, Bikerdude) ==

Beta-tested: http://forums.thedarkmod.com/topic/14742-closemouthed-shadows-lordsavage-bikerdude/

WARNING:Couldn't load image: textures/base_trim/dangertrim01 ''<-- mapper fix''

== Seige Shop (PranQster) ==

''Contains its own outdated version of tdm_ai_commoners.mtr and tdm_heads_dev.mtr, so is trying to load all kinds of files that no longer exist, and may not even be used in map.''

WARNING:Couldn't load image: models/characters/scientist/head02/hair ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgerbottom_shad
ows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/builders/forger/forgertop_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/beard_black_s ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: models/md5/chars/heads/npcs/beard_black_local ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: new_average_jack_texture ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head06 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: replacement_head08 ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: shoulder_cowl ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_brown_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_light_tan_shadows ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged ''<-- mapper fix; outdated file''

WARNING:Couldn't load image: tdm_commoner_tunic_ragged_shadows ''<-- mapper fix; outdated file''

= REPLACEMENT ASSETS NEEDED =

These are maps that still need to have assets replaced by the development team. They are not ready for mapper fixes or beta-testing yet.

= NOT CURRENTLY WORKING =
These are missions that won't load under 2.0 for whatever reason. Could be related to missing assets, or could be something about my local copy. Either way I'll be leaving these for last.

== Samhain Night on Bone Hill (PranQster) ==
'''runs, but needs fully working werebeast to be playable'''

*D 168: tels_firearrow_explosion ''<-- Mapper fix''

*D 169: tels_waterarrow_trail ''<-- Mapper fix''

WARNING:ConvertLWOToModelSurfaces: model 'models/darkmod/decorative/jack-o-lant
ern.lwo' has too many verts for a poly! ''<-- mapper fix; use models/darkmod/lights/non-extinguishable/jack-o-lantern.lwo''

WARNING:Couldn't load sound 'monster_zombie_maint_footstep.wav' using default

WARNING:Couldn't load sound 'sound/ambient/environmental/steelswing_01.wav' usi
ng default

== Glenham Tower (Sotha) ==

Haven't tried to load it, but I know it will crash with an error about zombie joints. Will need mapper fix to replace old joints with joints that exist on new skeleton.

''Sotha is looking for volunteers to fix this map.''

==Mandrasola (Sotha) ==

Will probably run, but will not be playable without working animations for missing character (you know who you are)

== The Creeps (Mortem Desino) ==

'''Fails to load with error:'''

ERROR:Joint 'Head' not found for attachment position 'velvetcap_1' on entity 'i
dAFAttachment_atdm:ai_headbox_zombie_646'

WARNING:Couldn't load anim: 'models/md5/characters/npcs/zheads/z1idle.md5anim'

WARNING:file def/tdm_ai_heads.def, line 274: Couldn't load anim 'models/md5/cha
racters/npcs/zheads/z1idle.md5anim'

'''NOTE FROM MD:''' I anticipated this problem. The solution for this is already in the FM package:
on entity revenant_spirit_shadow set "def_head" "atdm:ai_head_rev_spirit"
on entity revenant_spirit_chase set "def_head" "atdm:ai_head_rev_spirit"

Now, I think all that is left are a bunch of missing particle assets (mostly water drips and dust falling from ceiling) as well as light textures (you'll notice that many of the FM's saturated colored ambient lights are missing, leaving you with only the very dim ambient_world)

''Mortem would like a volunteer to update .pk4''

== Flakebridge Monastery (Jesps) ==

'''Crashes with error:'''

ERROR:Joint 'Rhand' not found for bind on 'func_static_212'

'''This is due to the new zombie having different joint names. It will require fixing the .pk4.'''

WARNING:Couldn't load sound 'stone_impact.wav' using default

WARNING:Couldn't load sound 'paper_impact.wav' using default

WARNING:Couldn't load sound 'book_impact.wav' using default

==Heart of Lone Salvation, The (Fidcal)==

'''Crashes with error:
ERROR:idMoveable 'sheet_paper6': cannot load collision model models/mapobjects/
filler/paperwad1.lwo'''

WARNING:Couldn't load model: 'models/mapobjects/filler/paperwad1.lwo' (nor the
fallback to ASE)

WARNING:Couldn't load model: 'models/mapobjects/tables/bunkbed/mattress.lwo' (n
or the fallback to ASE) ''<-- mapper fix; use models/darkmod/furniture/beds/mattress.lwo''

= NOT TESTED =

== Old Habits II (Obsttorte) ==

== The Lich Queen's Demise (Sotha) ==

==Lord Dufford's (stumpy)==

''stumpy will make necessary fixes to this map''

==Q4 Conversion: Yan's Test (Bikerdude) ==
== No Honour Among Theives: episode 1 (goldchocobo) ==

This was crashing at map start, but should be retested with at least SVN revision 13442.

That revision fixes the crash, which was unrelated to the presence or absence of D3 assets.

'' Since an update to this is due to be released shortly, I will wait before testing the NHAT maps.''

==No Honor Among Thieves Part 2 (goldchocobo) ==
==No Honor Among Thieves Part 3 (goldchocobo)==

Rescaling, Resizing, Models in Dark Radiant

2013-02-23T23:18:38Z

Fidcal: /* Shadow Problems */

''written by Fidcal''

== Introduction ==

Size matters! With some restrictions, most models (not AI) can be rescaled in three directions independantly in Dark Radiant. This provides for a large amount of extra variety and realism without needing extra models of different dimensions. Bowls, Plates, books, pictures, and plants do not exist in a limited size in the real world so why not vary them? How tall is a candle is like asking how long is a piece of string. Some furniture such as shelf units and tables can be stretched in one or all directions (watch that texture though), and an almost endless list of other objects can add interest to your game. A statue can be a statuette and vice versa. A building can become a doll's house; in fact most objects can be reduced to playthings for a nursery. The only limit is your imagination - so enlarge it!

== Method of Rescaling Models ==
How is it done? There is a rescaling value included in the rotation property (not to be confused with the ''rotate'' or ''angle'' properties.) There is a problem if rotation itself is needed as well as rescaling so study the [[#Rotating Rescaled Models]] section before proceeding with it.

Put simply, the rotation property default values are 1 0 0 0 1 0 0 0 1 where the first, fifth, and ninth (the '1's in the default values) are the XYZ rescale values. As you can see in the default they are all a scale of 1. It is not simple once rotated so generally only rescale the unrotated model then rotate after if needed (see [[#Rotating Rescaled Models]] section.)

The XYZ are absolute map directions so changing Y for example will affect the North/South length (top and bottom of the grid in Dark Radiant) no matter which way the object is conceptually facing. Just change the value of the 1 to that needed where 2 is double the length and .5 is half. Examples:

1 0 0 0 1 0 0 0 2 = the object is double the height. Nothing else is changed.

2 0 0 0 2 0 0 0 2 = the object is double the size in all directions.

.2 0 0 0 .2 0 0 0 .2 = the object is only one fifth scale in all planes.

== Rotating Rescaled Models ==

I don't pretend to understand the rotation values I only report some observations:

* Rescaling ALL lengths equally then rotating should be problem-free.
* Rotating 180 degrees should be problem-free no matter what lengths are rescaled or how.
* Rescaling a length not in the plane of rotation should be problem-free, so a table of lowered height that is turned sideways against another wall should be fine. Tip it over though and there is likely to be distortion of the shape.
* Rescaling and rotating (other than 180 degrees) in the same plane is likely to produce shape distortion. It might be slight if the rotation and/or the rescaling are small but it will be there.
* It should be possible to calculate ''any'' scale with any rotation but it is just not obvious so anyone who can provide a means then please post it here!

== Collision Model ==

The collision model is not created for the rescaled model so this method is not suitable for moveable items. In addition, objects, AI, and the player would pass right through a static rescaled model. Not only is this (usually) unrealistic but it can sometimes be fatal to the player character. If you really need some kind of phantom object then also add the property noclipmodel 1 and this seems to cure the sudden death problem.

But in most cases where you ''do'' need solidity, put your own unrendered brush(es) inside the model's volume using the texture : common > nodrawsolid to make the model seem solid. Consider not bothering for some items such as inaccessible objects out of reach of all activity.

Do not be too easily tempted to think that small items like a book on a table do not need any 'solidity'. True, if the player climbs on the table then the book's lack of solidity might not be noticed but try placing another object such as a candlestick holder on top of the book and it will sink through it to the table top.

== Problems ==

=== Texture Problems ===

When a model is rescaled then its texture is rescaled with it so take care to examine the texture is not ridiculously stretched. An outline of a large, inacessible, gargoyle, hidden in shadows, is not so critical as a table of three times its normal length! Probably reducing the size of models is generally 'safer' but be aware in all rescaling of the problem and examine the results!

=== Shadow Problems ===

You may get a problem with a wrong shadow - more likely if the model is reduced. In particular test moving around near the rescaled model using the player light. I saw rectangles of shadow surrounding objects with the player light even when the room light shadow looked reasonable.

If there is a problem then add the property noshadows to the object with a value of 1 and then you will get no shadow at all. If that looks odd consider a concealed brush behind the object to cast a shadow.

=== Possible Fix ===

RPGista proposed the following: you can give a model the "inline" "1" spawnarg and recompile the map, it will appearently turn a model into world brush triangles. It can have certain side effects (changing the smoothing groups, for example), but might be worth a shot.

{{darkradiant}}

Moveables

2012-12-12T09:33:48Z

Fidcal: /* Create a Collision Model (CM) */

{{Original_Reference|SneaksieDave & Ishtvan|3968}}

Physics fans rejoice! If you want an object (whether a model or multi-brush/patch) to be moveable (pick up and carry, push, float, shoot, etc.), even though it wasn't designed to be used that way, there is a way to do it anyway, and all within the editor.

==Models==

You should read the article about [[Models]] first to get some understanding of the topic.

In summary you need to create the model, make it moveable, and make sure a collision model exists for it.

=== Create a Moveable ===

# Create a brush, convert it to a moveable_base entity, and assign it the model you want to use.
# You only need one collision model file no matter how many instances of this moveable you make in your map so check if it has already been created (a .cm file of the same name as the model and in the same folder.) If not:

=== Create a [[Collision Models|Collision Model]] (CM) ===

In DarkRadiant:
# '''Important''': Make sure the model is not rotated in any way.
# Drag a new temporary brush over the model, roughly covering it.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Any texture will do on any surface.
# Convert to func_static (any entity will do)
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game. If they do not coincide then either move the brush so it coincides and resize the brush or key V and drag the origin into position.
# Use the {{menu|File|Save selection as collision model}} menu entry:
# The model selector dialog appears, Select the correct model. Click {{ok}}.
# A .cm should have now been saved in the same folder as the model and with the same name as the model. (I've done these before but recently in 1.08 it failed so I used the script menu to export as .ase and that worked! Note - in this case you must give it the common - collision texture.)
# You can now delete the temporary collision model brush entity.

Important: The shape must be very simple, not having more than say 16 faces! (I now think this is a max of 12. - Fidcal)

In DoomEd:

# Drag a new temporary brush over the model, roughly covering it. This will be the collision hull, so get it as close as you can.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Convert that brush to '''func_clipmodel'''.
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game.
# Texture it with '''common/collision'''.
# With that brush still selected, do '''Selected->Export->To CM'''. Locate the model for which it will stand as a clipmodel, and save with the same name. The path and name are vital. Don't worry, DoomEd will automatically name it .cm instead by of your model's extension, so it shouldn't overwrite anything.
# You can now delete the temporary collision model brush entity.

==Brush/Patch Moveables==

You can make virtually any brush/patch construction into a moveable. At its core must be a simple brush to form the collision shape. I've had a brush with 12 surfaces as a moveable OK. I don't know if there is a limit but it's my belief that it won't work if too complicated a shape. However, we can get round that and produce very complex moveables such as a stepladder with multiple steps and ladder surface. We do that by binding the construction to a single central collision shape brush which is the actual moveable entity.

===Simple brush moveables===

First let's take the simplest of brush moveables: a stone block. It is not uncommon in FMs to have a hole in a wall filled with stone blocks or rubble the player can move or push out of the way. So first make your brush stone block from the same texture as your wall so it will match perfectly (if desired.) If it is a broken block (rubble) then you can cut pieces off the basic rectangular block but I would get it all working first and save it then gradually cut piecess off and save the early versions. You might find if you have too many surfaces it might not work. (I am still unsure about this.) I have not tried with patches but it should work. In any event you can certainly bind a patch to an unrendered block to get what you want.

* Make the brush an atdm:moveable_base entity. Later a proper entity inheriting from atdm:moveable_base might be made up with the following spawnargs to save time. (I couldn't get this to work with the custom entities which have to use a model.)
* Give it mass (in kilos)
* No need to give it density as this is now calculated from its volume and mass.
* Give it friction (0 to 1) I usually aim low about 0.1 else it can be 'sticky'
* Give it snd_bounce as the sound it will make on impact. Example: med_metal_impact. I suggest you look at what some already existing moveable of a similar size and material is using.
* Give it an alert size and hardness. This determines how AI will react to its sound. If you don't then it will default to medium size and hard so if your object is about that then you need do nothing. Otherwise, give it these two spawnargs/values. These are the possibles:
** spr_object_hardness - can be soft, medium, or hard
** spr_object_size - can be small, medium, or large

By default, the above will highlight and can be pushed about, frobbed and picked up, carried, and manipulated by the player.

If you want it only to be pushed but not picked up then give it frobable 0.

If you want it to go in the inventory:
* Give it inv_category. This can be eg, Special, Tools, Keys. (look at currentsimilar objects)
* Give it inv_name with the value of whatever name you want it show in the inventory.
* Give it inv_icon with the value guis/assets/hud/inventory_icons/default which will show blank (otherwise you get a black square.) If you can create your own icon then even better.
* Give it snd_acquire with the value tool_pickup is a good default (the sound it makes when the player gets it.)

===Remake the map cm file if console error===

'''IMPORTANT!''' This caused me a lot of headaches over a couple of years until I realized so memorize this even if you forget everything else. When you first make a brush moveable it might work fine but later you get a console error: 'cannot load collision model'. You might get this if you rename the entity or import it as a prefab into another map. What you must do is DELETE the map cm file (in maps folder mymap.cm) then DMAP again. Dmap doesn't know if you changed anything so you need to force it to recreate the map collision file.

===More complex brush and patch moveables===

To make complex brush moveables like a stepladder you first create a simple brush moveable as described above and texture it with textures/common/collision. Size and shape this brush to approximate the basic size and shape of the object you are making. Try to avoid over-complexity of this shape; it only needs to determine collisions. For example, for the stepladder I made an upright right-angled triangle shape. This is the core of the stepladder; the actual moveable entity as described in the above section. You then make your more complex shape(s) into func_static(s) and bind to the collision shape to get the best fit. The collision shape is what the player picks up but it is not visible of course.

==== Making frobable ====

The above is OK for pushing around but if you want to be able to pick up the object it needs to be frobable. At this point only the invisible collision moveable is frobable but its highlight is invisible! To make the visible object frobable do the following:

To the invisible moveable add the property/value:

''frob_peer'' <name of visible object>.

To the visible object add the properties/vaues:

''frobable'' 1

''frob_distance'' 1 (do NOT use 0 or it defaults to the normal distance.)

What the above does is allow the visible object to highlight but not directly frobable. Instead when it highlights it means you are focused on the invisible moveable which is what you want - and it highlights the visible object through the frob_peer.

===Model/Brush hybrid===

In the earlier sections on making a moveable model is described how to make an external model cm file. In some situations you might instead bind a static model to a brush moveable as described above. In some cases you might make the brush moveable visible or some surfaces visible. An example makes it easier to understand: I took a model chest body. Made a rectangular brush moveable to completely fill it. I textured it with textures/common/collision but the top surface I gave it the texture that the chest used. When aligned carefully it complete sealed the top so it looks like a new luggable crate. Then bind the chest model to the brush moveable. To make it frobable see above [[#Making frobable]]

== Complete List of Default Key/Values for Moveable entities==
"Moveable object. Will drop to the floor and rest until activated."
"The visual model set with the 'model' key can also be used for"
"collision detection. However the model may not be too complex."
"max vertices = 32"
"max edges = 32"
"max polygons = 16"
""max edges per polygon = 16"
"The collision model must be an enclosed hull. Dangling polygons or"
"edges are not allowed. If the visual model is too complex or does"
"not meet these requirements it can be contained in a less complex"
"model for collision detection. Such a collision model is specified with the"
"'clipmodel' key."

"editor_var density" "Volume of the object times the density is the mass."
"editor_var friction" "Friction with contacting surfaces in the range [0-1] where 0 is no friction."
"editor_var bouncyness" "How much the object bounces in the range [0-1] where 0 is no bounce."

"editor_var mass" "Mass of the object (overrides density)."

"editor_model clipmodel" "Model to be used for collision detection."
"editor_var clipshrink" "Shrink the visual model with an epsilon and use it as a clip model."
"editor_var allowStep" "Set to 0 to prevent monsters from ever walking over this object."
"editor_var nonsolid" "Make the object non-solid."

"editor_bool nodrop" "Do not drop to the floor."
"editor_bool noimpact" "Do not activate by the impact of other objects."
"editor_bool notpushable" "Do not allow to be pushed."

"editor_bool unbindondeath" "Unbind entity when health drops down to or below zero."

"editor_var health" "If set the visual model changes to 'broken' when the health drops down to or below zero."

"editor_model broken" "Visual model to be used when the health drops down to or below zero."
"editor_bool explode" "If set to 1 the moveable explodes and is removed when the health drops down to or below zero."

"editor_var init_velocity" "Initial linear velocity set when activated."
"editor_var init_avelocity" "Initial angular velocity set when activated."

"editor_var init_velocityDelay" "Delay in seconds before the initial linear velocity is set after being activated."
"editor_var init_avelocityDelay" "Delay in seconds before the initial angular velocity is set after being activated."

"editor_var initialSplineTime" "Number of milliseconds the moveable should follow the initial spline path."

"editor_var damage" "Damage definition if it damages things it collides with"
"editor_var damageWhenActive" "Only damage when active ( currently for the vagary and influence stuff )"

"editor_var fx_collide" "FX system to start at impact position when object collides."

== Default Settings ==
"density" "0.5"
"friction" "0.05"
"bouncyness" "0.6"
"explode" "0"
"unbindondeath" "0"
"health" "0"
"nodrop" "0"
"noimpact" "0"
"notPushable" "0"
"clipshrink" "0"
"allowStep" "1"
"snd_bounce" "smallpanel_impact "

== See also ==
* [[Pushing]] of moveables.

[[Category:Editing]]

Moveables

2012-12-12T09:26:46Z

Fidcal: /* Create a Collision Model (CM) */

{{Original_Reference|SneaksieDave & Ishtvan|3968}}

Physics fans rejoice! If you want an object (whether a model or multi-brush/patch) to be moveable (pick up and carry, push, float, shoot, etc.), even though it wasn't designed to be used that way, there is a way to do it anyway, and all within the editor.

==Models==

You should read the article about [[Models]] first to get some understanding of the topic.

In summary you need to create the model, make it moveable, and make sure a collision model exists for it.

=== Create a Moveable ===

# Create a brush, convert it to a moveable_base entity, and assign it the model you want to use.
# You only need one collision model file no matter how many instances of this moveable you make in your map so check if it has already been created (a .cm file of the same name as the model and in the same folder.) If not:

=== Create a [[Collision Models|Collision Model]] (CM) ===

In DarkRadiant:
# '''Important''': Make sure the model is not rotated in any way.
# Drag a new temporary brush over the model, roughly covering it.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Any texture will do on any surface.
# Convert to func_static (any entity will do)
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game. If they do not coincide then either move the brush so it coincides and resize the brush or key V and drag the origin into position.
# Use the {{menu|File|Save selection as collision model}} menu entry:
# The model selector dialog appears, Select the correct model. Click {{ok}}.
# A .cm should have now been saved in the same folder as the model and with the same name as the model. (I've done these before but recently in 1.08 it failed so I used the script menu to export as .ase and that worked!)
# You can now delete the temporary collision model brush entity.

Important: The shape must be very simple, not having more than say 16 faces! (I now think this is a max of 12. - Fidcal)

In DoomEd:

# Drag a new temporary brush over the model, roughly covering it. This will be the collision hull, so get it as close as you can.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Convert that brush to '''func_clipmodel'''.
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game.
# Texture it with '''common/collision'''.
# With that brush still selected, do '''Selected->Export->To CM'''. Locate the model for which it will stand as a clipmodel, and save with the same name. The path and name are vital. Don't worry, DoomEd will automatically name it .cm instead by of your model's extension, so it shouldn't overwrite anything.
# You can now delete the temporary collision model brush entity.

==Brush/Patch Moveables==

You can make virtually any brush/patch construction into a moveable. At its core must be a simple brush to form the collision shape. I've had a brush with 12 surfaces as a moveable OK. I don't know if there is a limit but it's my belief that it won't work if too complicated a shape. However, we can get round that and produce very complex moveables such as a stepladder with multiple steps and ladder surface. We do that by binding the construction to a single central collision shape brush which is the actual moveable entity.

===Simple brush moveables===

First let's take the simplest of brush moveables: a stone block. It is not uncommon in FMs to have a hole in a wall filled with stone blocks or rubble the player can move or push out of the way. So first make your brush stone block from the same texture as your wall so it will match perfectly (if desired.) If it is a broken block (rubble) then you can cut pieces off the basic rectangular block but I would get it all working first and save it then gradually cut piecess off and save the early versions. You might find if you have too many surfaces it might not work. (I am still unsure about this.) I have not tried with patches but it should work. In any event you can certainly bind a patch to an unrendered block to get what you want.

* Make the brush an atdm:moveable_base entity. Later a proper entity inheriting from atdm:moveable_base might be made up with the following spawnargs to save time. (I couldn't get this to work with the custom entities which have to use a model.)
* Give it mass (in kilos)
* No need to give it density as this is now calculated from its volume and mass.
* Give it friction (0 to 1) I usually aim low about 0.1 else it can be 'sticky'
* Give it snd_bounce as the sound it will make on impact. Example: med_metal_impact. I suggest you look at what some already existing moveable of a similar size and material is using.
* Give it an alert size and hardness. This determines how AI will react to its sound. If you don't then it will default to medium size and hard so if your object is about that then you need do nothing. Otherwise, give it these two spawnargs/values. These are the possibles:
** spr_object_hardness - can be soft, medium, or hard
** spr_object_size - can be small, medium, or large

By default, the above will highlight and can be pushed about, frobbed and picked up, carried, and manipulated by the player.

If you want it only to be pushed but not picked up then give it frobable 0.

If you want it to go in the inventory:
* Give it inv_category. This can be eg, Special, Tools, Keys. (look at currentsimilar objects)
* Give it inv_name with the value of whatever name you want it show in the inventory.
* Give it inv_icon with the value guis/assets/hud/inventory_icons/default which will show blank (otherwise you get a black square.) If you can create your own icon then even better.
* Give it snd_acquire with the value tool_pickup is a good default (the sound it makes when the player gets it.)

===Remake the map cm file if console error===

'''IMPORTANT!''' This caused me a lot of headaches over a couple of years until I realized so memorize this even if you forget everything else. When you first make a brush moveable it might work fine but later you get a console error: 'cannot load collision model'. You might get this if you rename the entity or import it as a prefab into another map. What you must do is DELETE the map cm file (in maps folder mymap.cm) then DMAP again. Dmap doesn't know if you changed anything so you need to force it to recreate the map collision file.

===More complex brush and patch moveables===

To make complex brush moveables like a stepladder you first create a simple brush moveable as described above and texture it with textures/common/collision. Size and shape this brush to approximate the basic size and shape of the object you are making. Try to avoid over-complexity of this shape; it only needs to determine collisions. For example, for the stepladder I made an upright right-angled triangle shape. This is the core of the stepladder; the actual moveable entity as described in the above section. You then make your more complex shape(s) into func_static(s) and bind to the collision shape to get the best fit. The collision shape is what the player picks up but it is not visible of course.

==== Making frobable ====

The above is OK for pushing around but if you want to be able to pick up the object it needs to be frobable. At this point only the invisible collision moveable is frobable but its highlight is invisible! To make the visible object frobable do the following:

To the invisible moveable add the property/value:

''frob_peer'' <name of visible object>.

To the visible object add the properties/vaues:

''frobable'' 1

''frob_distance'' 1 (do NOT use 0 or it defaults to the normal distance.)

What the above does is allow the visible object to highlight but not directly frobable. Instead when it highlights it means you are focused on the invisible moveable which is what you want - and it highlights the visible object through the frob_peer.

===Model/Brush hybrid===

In the earlier sections on making a moveable model is described how to make an external model cm file. In some situations you might instead bind a static model to a brush moveable as described above. In some cases you might make the brush moveable visible or some surfaces visible. An example makes it easier to understand: I took a model chest body. Made a rectangular brush moveable to completely fill it. I textured it with textures/common/collision but the top surface I gave it the texture that the chest used. When aligned carefully it complete sealed the top so it looks like a new luggable crate. Then bind the chest model to the brush moveable. To make it frobable see above [[#Making frobable]]

== Complete List of Default Key/Values for Moveable entities==
"Moveable object. Will drop to the floor and rest until activated."
"The visual model set with the 'model' key can also be used for"
"collision detection. However the model may not be too complex."
"max vertices = 32"
"max edges = 32"
"max polygons = 16"
""max edges per polygon = 16"
"The collision model must be an enclosed hull. Dangling polygons or"
"edges are not allowed. If the visual model is too complex or does"
"not meet these requirements it can be contained in a less complex"
"model for collision detection. Such a collision model is specified with the"
"'clipmodel' key."

"editor_var density" "Volume of the object times the density is the mass."
"editor_var friction" "Friction with contacting surfaces in the range [0-1] where 0 is no friction."
"editor_var bouncyness" "How much the object bounces in the range [0-1] where 0 is no bounce."

"editor_var mass" "Mass of the object (overrides density)."

"editor_model clipmodel" "Model to be used for collision detection."
"editor_var clipshrink" "Shrink the visual model with an epsilon and use it as a clip model."
"editor_var allowStep" "Set to 0 to prevent monsters from ever walking over this object."
"editor_var nonsolid" "Make the object non-solid."

"editor_bool nodrop" "Do not drop to the floor."
"editor_bool noimpact" "Do not activate by the impact of other objects."
"editor_bool notpushable" "Do not allow to be pushed."

"editor_bool unbindondeath" "Unbind entity when health drops down to or below zero."

"editor_var health" "If set the visual model changes to 'broken' when the health drops down to or below zero."

"editor_model broken" "Visual model to be used when the health drops down to or below zero."
"editor_bool explode" "If set to 1 the moveable explodes and is removed when the health drops down to or below zero."

"editor_var init_velocity" "Initial linear velocity set when activated."
"editor_var init_avelocity" "Initial angular velocity set when activated."

"editor_var init_velocityDelay" "Delay in seconds before the initial linear velocity is set after being activated."
"editor_var init_avelocityDelay" "Delay in seconds before the initial angular velocity is set after being activated."

"editor_var initialSplineTime" "Number of milliseconds the moveable should follow the initial spline path."

"editor_var damage" "Damage definition if it damages things it collides with"
"editor_var damageWhenActive" "Only damage when active ( currently for the vagary and influence stuff )"

"editor_var fx_collide" "FX system to start at impact position when object collides."

== Default Settings ==
"density" "0.5"
"friction" "0.05"
"bouncyness" "0.6"
"explode" "0"
"unbindondeath" "0"
"health" "0"
"nodrop" "0"
"noimpact" "0"
"notPushable" "0"
"clipshrink" "0"
"allowStep" "1"
"snd_bounce" "smallpanel_impact "

== See also ==
* [[Pushing]] of moveables.

[[Category:Editing]]

Moveables

2012-12-12T09:25:15Z

Fidcal: /* Create a Collision Model (CM) */

{{Original_Reference|SneaksieDave & Ishtvan|3968}}

Physics fans rejoice! If you want an object (whether a model or multi-brush/patch) to be moveable (pick up and carry, push, float, shoot, etc.), even though it wasn't designed to be used that way, there is a way to do it anyway, and all within the editor.

==Models==

You should read the article about [[Models]] first to get some understanding of the topic.

In summary you need to create the model, make it moveable, and make sure a collision model exists for it.

=== Create a Moveable ===

# Create a brush, convert it to a moveable_base entity, and assign it the model you want to use.
# You only need one collision model file no matter how many instances of this moveable you make in your map so check if it has already been created (a .cm file of the same name as the model and in the same folder.) If not:

=== Create a [[Collision Models|Collision Model]] (CM) ===

In DarkRadiant:
# '''Important''': Make sure the model is not rotated in any way.
# Drag a new temporary brush over the model, roughly covering it.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Any texture will do on any surface.
# Convert to func_static (any entity will do)
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game. If they do not coincide then either move the brush so it coincides and resize the brush or key V and drag the origin into position.
# Use the {{menu|File|Save selection as collision model}} menu entry:
# The model selector dialog appears, Select the correct model. Click {{ok}}.
# A .cm should have now been saved in the same folder as the model and with the same name as the model.
# You can now delete the temporary collision model brush entity.

Important: The shape must be very simple, not having more than say 16 faces! (I now think this is a max of 12. - Fidcal)

In DoomEd:

# Drag a new temporary brush over the model, roughly covering it. This will be the collision hull, so get it as close as you can.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Convert that brush to '''func_clipmodel'''.
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game.
# Texture it with '''common/collision'''.
# With that brush still selected, do '''Selected->Export->To CM'''. Locate the model for which it will stand as a clipmodel, and save with the same name. The path and name are vital. Don't worry, DoomEd will automatically name it .cm instead by of your model's extension, so it shouldn't overwrite anything.
# You can now delete the temporary collision model brush entity.

==Brush/Patch Moveables==

You can make virtually any brush/patch construction into a moveable. At its core must be a simple brush to form the collision shape. I've had a brush with 12 surfaces as a moveable OK. I don't know if there is a limit but it's my belief that it won't work if too complicated a shape. However, we can get round that and produce very complex moveables such as a stepladder with multiple steps and ladder surface. We do that by binding the construction to a single central collision shape brush which is the actual moveable entity.

===Simple brush moveables===

First let's take the simplest of brush moveables: a stone block. It is not uncommon in FMs to have a hole in a wall filled with stone blocks or rubble the player can move or push out of the way. So first make your brush stone block from the same texture as your wall so it will match perfectly (if desired.) If it is a broken block (rubble) then you can cut pieces off the basic rectangular block but I would get it all working first and save it then gradually cut piecess off and save the early versions. You might find if you have too many surfaces it might not work. (I am still unsure about this.) I have not tried with patches but it should work. In any event you can certainly bind a patch to an unrendered block to get what you want.

* Make the brush an atdm:moveable_base entity. Later a proper entity inheriting from atdm:moveable_base might be made up with the following spawnargs to save time. (I couldn't get this to work with the custom entities which have to use a model.)
* Give it mass (in kilos)
* No need to give it density as this is now calculated from its volume and mass.
* Give it friction (0 to 1) I usually aim low about 0.1 else it can be 'sticky'
* Give it snd_bounce as the sound it will make on impact. Example: med_metal_impact. I suggest you look at what some already existing moveable of a similar size and material is using.
* Give it an alert size and hardness. This determines how AI will react to its sound. If you don't then it will default to medium size and hard so if your object is about that then you need do nothing. Otherwise, give it these two spawnargs/values. These are the possibles:
** spr_object_hardness - can be soft, medium, or hard
** spr_object_size - can be small, medium, or large

By default, the above will highlight and can be pushed about, frobbed and picked up, carried, and manipulated by the player.

If you want it only to be pushed but not picked up then give it frobable 0.

If you want it to go in the inventory:
* Give it inv_category. This can be eg, Special, Tools, Keys. (look at currentsimilar objects)
* Give it inv_name with the value of whatever name you want it show in the inventory.
* Give it inv_icon with the value guis/assets/hud/inventory_icons/default which will show blank (otherwise you get a black square.) If you can create your own icon then even better.
* Give it snd_acquire with the value tool_pickup is a good default (the sound it makes when the player gets it.)

===Remake the map cm file if console error===

'''IMPORTANT!''' This caused me a lot of headaches over a couple of years until I realized so memorize this even if you forget everything else. When you first make a brush moveable it might work fine but later you get a console error: 'cannot load collision model'. You might get this if you rename the entity or import it as a prefab into another map. What you must do is DELETE the map cm file (in maps folder mymap.cm) then DMAP again. Dmap doesn't know if you changed anything so you need to force it to recreate the map collision file.

===More complex brush and patch moveables===

To make complex brush moveables like a stepladder you first create a simple brush moveable as described above and texture it with textures/common/collision. Size and shape this brush to approximate the basic size and shape of the object you are making. Try to avoid over-complexity of this shape; it only needs to determine collisions. For example, for the stepladder I made an upright right-angled triangle shape. This is the core of the stepladder; the actual moveable entity as described in the above section. You then make your more complex shape(s) into func_static(s) and bind to the collision shape to get the best fit. The collision shape is what the player picks up but it is not visible of course.

==== Making frobable ====

The above is OK for pushing around but if you want to be able to pick up the object it needs to be frobable. At this point only the invisible collision moveable is frobable but its highlight is invisible! To make the visible object frobable do the following:

To the invisible moveable add the property/value:

''frob_peer'' <name of visible object>.

To the visible object add the properties/vaues:

''frobable'' 1

''frob_distance'' 1 (do NOT use 0 or it defaults to the normal distance.)

What the above does is allow the visible object to highlight but not directly frobable. Instead when it highlights it means you are focused on the invisible moveable which is what you want - and it highlights the visible object through the frob_peer.

===Model/Brush hybrid===

In the earlier sections on making a moveable model is described how to make an external model cm file. In some situations you might instead bind a static model to a brush moveable as described above. In some cases you might make the brush moveable visible or some surfaces visible. An example makes it easier to understand: I took a model chest body. Made a rectangular brush moveable to completely fill it. I textured it with textures/common/collision but the top surface I gave it the texture that the chest used. When aligned carefully it complete sealed the top so it looks like a new luggable crate. Then bind the chest model to the brush moveable. To make it frobable see above [[#Making frobable]]

== Complete List of Default Key/Values for Moveable entities==
"Moveable object. Will drop to the floor and rest until activated."
"The visual model set with the 'model' key can also be used for"
"collision detection. However the model may not be too complex."
"max vertices = 32"
"max edges = 32"
"max polygons = 16"
""max edges per polygon = 16"
"The collision model must be an enclosed hull. Dangling polygons or"
"edges are not allowed. If the visual model is too complex or does"
"not meet these requirements it can be contained in a less complex"
"model for collision detection. Such a collision model is specified with the"
"'clipmodel' key."

"editor_var density" "Volume of the object times the density is the mass."
"editor_var friction" "Friction with contacting surfaces in the range [0-1] where 0 is no friction."
"editor_var bouncyness" "How much the object bounces in the range [0-1] where 0 is no bounce."

"editor_var mass" "Mass of the object (overrides density)."

"editor_model clipmodel" "Model to be used for collision detection."
"editor_var clipshrink" "Shrink the visual model with an epsilon and use it as a clip model."
"editor_var allowStep" "Set to 0 to prevent monsters from ever walking over this object."
"editor_var nonsolid" "Make the object non-solid."

"editor_bool nodrop" "Do not drop to the floor."
"editor_bool noimpact" "Do not activate by the impact of other objects."
"editor_bool notpushable" "Do not allow to be pushed."

"editor_bool unbindondeath" "Unbind entity when health drops down to or below zero."

"editor_var health" "If set the visual model changes to 'broken' when the health drops down to or below zero."

"editor_model broken" "Visual model to be used when the health drops down to or below zero."
"editor_bool explode" "If set to 1 the moveable explodes and is removed when the health drops down to or below zero."

"editor_var init_velocity" "Initial linear velocity set when activated."
"editor_var init_avelocity" "Initial angular velocity set when activated."

"editor_var init_velocityDelay" "Delay in seconds before the initial linear velocity is set after being activated."
"editor_var init_avelocityDelay" "Delay in seconds before the initial angular velocity is set after being activated."

"editor_var initialSplineTime" "Number of milliseconds the moveable should follow the initial spline path."

"editor_var damage" "Damage definition if it damages things it collides with"
"editor_var damageWhenActive" "Only damage when active ( currently for the vagary and influence stuff )"

"editor_var fx_collide" "FX system to start at impact position when object collides."

== Default Settings ==
"density" "0.5"
"friction" "0.05"
"bouncyness" "0.6"
"explode" "0"
"unbindondeath" "0"
"health" "0"
"nodrop" "0"
"noimpact" "0"
"notPushable" "0"
"clipshrink" "0"
"allowStep" "1"
"snd_bounce" "smallpanel_impact "

== See also ==
* [[Pushing]] of moveables.

[[Category:Editing]]

Swimmable Water

2011-10-08T21:07:36Z

Fidcal: /* Troubleshooting Problems */

''written by angua''

== Create some walls ==

[[Image:Watertutorial1.jpg]]

In this example, I made this little rectangular pool, but you can also use differently shaped structures.

== Fill in your water ==

Draw a brush that is going to be your water volume and texture it with common/nodraw

[[Image:Watertutorial2.jpg]]

== Create the entity ==

In [[DarkRadiant]]: Select your brush, {{RMB}} -> Create Entity -> '''atdm:liquid_water'''

[[Image:Watertutorial5.jpg]]

In the Entity Inspector you can see that the classname is now '''atdm:liquid_water''', and the name '''atdm:liquid_water_1''' (or similiar). It should also have a blue outline in the orthographic view (The XZ Front in this case).

Note: If you use "func_liquid" instead of "atdm:liquid_water", your water will not function correctly. It will f.i. not extinguish flames.

== Texture the surface ==

Select the face that is going to be the surface ({{key|CTRL}} + {{key|SHIFT}} + {{LMB}}) and texture it with a nice water texture, for example '''water_source/water_clear'''.

[[Image:Watertutorial6.jpg]]

Do not assign the water texture to the whole brush, or you will see this: (You can also get rid of that z-fighting by dragging the brush into the wall so that it insersects with it.)

[[Image:Watertutorial4.jpg]]

However, if you don't want clear water then you need to choose another surface, say water_green or water_colored, include an extra overlay plus an underwater overlay. For this, see the next section.

==Coloured and Murky Water==

This is a method for providing water that is coloured or murky underwater and a surface that matches.

You can use this with different water surfaces but I recommend you first try:

''textures/water_source/water_colored.'' (this can be coloured but by default it is not so won't confuse the issue - the colour will be added by the overlay below.)

To your water entity give the property:

'''''underwater_gui'''''

Now give the property the name of one of the overlay guis. The names are fairly descriptive so you can choose which type you want suitable for a river, a cave pool, or a sewer, etc.:

underwater_green_midmurk.gui
underwater_green_thickmurk.gui
underwater_green_thinmurk.gui

underwater_blue_midmurk.gui
underwater_blue_thickmurk.gui
underwater_blue_thinmurk.gui

underwater_bluegrey_midmurk.gui
underwater_bluegrey_thickmurk.gui
underwater_bluegrey_thinmurk.gui

underwater_greengrey_midmurk.gui
underwater_greengrey_thickmurk.gui
underwater_greengrey_thinmurk.gui

Now with the water entity still selected:

* Choose Top view in Dark Radiant's orthoview
* Create a simple patch from the patch menu.
* Move this up flush with the surface of the water.
* Give it the texture that matches the gui you chose above. For example, if you chose '' underwater_bluegrey_thinmurk.gui'' from the above then give the overlay the texture: ''textures/water_source/bluegrey_plain_flat_thinmurk''

Using the above method you should find the surface opacity and colour matches how it looks when the players goes underwater.

== Underwater fog ==

Your water looks much more believable if it has an underwater fog. Create a light, select as texture "fog/basicfog", give it a very dark color and resize the light so it covers the entire underwater area. This will make your water darker the deeper it is, just like in real-life!

== Test your water ==

[[Image:Watertutorial3.jpg]]

And there it is!

==Current Flow==

There is at least one flowing stream surface texture at the time of writing. If you want to create your own variations then just examine that material shader, copy and modify it. Probably it can be used with other existing surface texture images or you can create new ones.

==Flow Force==

A force field can be placed in water to apply a tangible flow, eg, to push the player and/or other objects along.

See [[Func Forcefields]]

==Wave Frequency and Direction==

You can set the frequency of the surface waves from tiny undulations to large slow ones just by changing the surface texture scale in Surface Inspector. Flowing surfaces such as stream textures can of course be rotated to get the direction you want.

A better way to influence the wave speed and wave hight is via [[List_of_shaderParm_variables|shaderParms]]. Set the following spawnargs on your water entity:

<pre>
shaderParm5 0.05
shaderParm6 0.75
</pre>

parm5 controls the wave speed, parm6 the wave height. The defaults are 0.1 and 1.5, respectively. Experiment a bit, values lower than the defaults look more believable for still waterbodies, higher values for when you have a lot of wind.

==Sound==

If the water level is less than 1, you get normal footsteps.

Between 1 and 34, you get splash sounds.

Between 34 and 77, you get wading sounds.

If 77 or more, you get swimming sounds.

==Troubleshooting Problems==

===Visible Joints Between Water Brushes===

If you place brushes of water against one another, eg, along a channel, round corners, to form a canal, etc. and you can 'see the joins' then the most likely cause of the problem is that the surface textures do not align. We are used to aligning static textures but it is not so obvious with the dynamic translucent surface of water that we might not think of it. Just copy and paste shader one of the surface textures to all the others to get the same scroll and scale alignment and it should be OK.

NOTE: If you want to use the NoDraw Solid texture, be sure NOT to use it between water entities, otherwise you won't be able to swim between them.

{{tutorial-water}}

Doors

2011-09-22T16:51:42Z

Fidcal: /* AI Door management */

{{todo}}
''Written by Fidcal'' ''edit Baddcog''

==Quick Summary==

Quick way to get an unlocked door in your map:

* Insert one of the prefab doors complete with handles and select its skin property and click the button to change its skin appearance to whatever you want. Set any other properties you need.

Alternatively,

* Create a door from the entity list
* Use the "skin" spawnarg on the door to change its appearance.
* Create a handle from the entity list
* Add the ''door_handle'' property to the door and give it the name of the handle
* To the door handle add the value frob_peer and use the name of the door.
* To open clockwise, change the ''rotate'' property from <code>0 90 0</code> to <code>0 -90 0</code>

==Introduction==

This tutorial explains how to put doors into your map using Dark Radiant, as well as adjust them and their properties.

The rest of this tutorial assumes that you have a basic understanding of using DarkRadiant. If you haven't done so, please go read the [[Dark Radiant Must Know Basic Intro]] article first.

Additionally:

* Up, down, left, and right in Dark Radiant's ''top'' orthoview are regarded here as the standard map directions of North, South, East, and West where useful for clarity.
* Where the term ''brush'' is used with a door it mostly also applies to a door made up of a group of brushes and/or patches.
* Where the term ''door'' is used it often will also apply to any object you wish to rotate when frobbed, for instance an openable window, box lid, or even more exotic objects that the imaginative mapper might conceive like a signal, engine part, toy, or whatever. So long as it needs to turn or slide just a fixed amount when frobbed then return when frobbed again then the following applies.

==Door types==

All tangible objects in Dark Mod are ''entities'', having either a pre-made model shape or else brush/patch(es). So there are two ways to create a door in Dark Radiant: as a model door or a textured brush door (or a hybrid of the two).

Models are ready made door objects but cannot within Dark Radiant (at the time of writing) be resized, rescaled, cropped or clipped whereas brushes are very flexible in that respect and can be worked into custom shapes for your map, including secret doors that blend into walls and other surfaces.

Most of the current door models are found in two places along with the door handles.
*Model Viewer: doors created from here will be static in the world and have no props other than material type.
You can add any props to them to make them working doors. If nothing else it is a good place to view the different size and skin options for the doors.
*Entity List: most of the door models can be found here. These doors have properties already assigned so they are ready to be used. Only one base door of each type is listed, create the size/hinge count door you want (2 hinge doors have a 'no hinge' skin). You can choose a skin for the door once it has been created in the editor with the "skin" spawnarg (use the model name of the door you want, taken from the model list, as its value). This is the easiest way to create a door. The same goes for door handles.

Remember also that door functions may be applied to objects other than doors for instance to openable windows, drawbridges, gates, in fact anything that needs a partial rotation or slide when frobbed then return when frobbed again such as a signal device. Lockboxes and chests use similar properties.

Door/handle prefabs seem to crash Doom3 when trying to reload a map so far now just create and link each door/handle. You can create one set and copy/paste them, but you need to take great care that all the name props are changed to match each clone. Otherwise you get handles that fly off with a distant door and handles that don't move.

==Creating a Door==

Put simply, to make a door you will be creating an 'entity with model' or 'entity with brush' or some variation thereof.

===Creating a Model Door===

There are several approaches to making a model door; the simplest is to create a door from the entity list; or create a door from the model viewer (good for static unusable prop doors).

'''Entity List''':

*Deselect everything in editor by hitting the Esc button
*Right-click an ortho view and select Create Entity
*Navigate to darkmod/movers/''atdm:door_...'', choose the door you want
*Click Add
*To change its appearance, add a "skin" spawnarg to the door, with the value being the model name of the door you want.

You now have a workable door in your level.

'''Model Viewer''':

* Right click in the orthoview, select ''Create Model'' then <code>darkmod</code> and select a door.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* Click [[Image:Button ok.png]] and you have a static door.
* If you want to make it work (openable, frobbable) then:
** Select the entity inspector,
** Select the top classname line so it highlights
** Select the func_static line in the input box ''below'' the properties window.
** Edit <code>func_static</code> to <code>atdm:mover_door</code>
** Click {{check}} or press {{key-enter}}

Alternatively you can do it the old way:

* Create any temporary brush
* Right click in orthoview and select <code>Create Entity</code> then <code>atdm:mover_door</code>.
* Left lick the model name line in the entity inspector.
* Below it on the ''Entity Inspector'' panel you should now see a button 'Choose Model'
* Left click it, select a door model from the darkmod group.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* The temporary brush was deleted.

In all three instances, you now have a working door with default properties.

Name your door by adding the prop (or modifing it) to name ''My_Door_1''. You can use any name that you feel is appropriate but all doors with handles attached ''must'' have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below).

To add a handle and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

===Creating a Textured Brush Door===

'''Tip:''' If unsure of size then you might insert a temporary human AI first to get a sense of height.

==== The simplest brush door: ====

* Drag out a new brush to the size required, eg, a seven foot high door is 84" x 1.1 = about 90 units in Dark Radiant.
* Give it a door texture from the texture browser (or wall texture for a secret door)
* Right click in orthoview and select ''Create Entity'' then <code>atdm:mover_door</code>
* You now have a default door that rotates around its center.

To move the rotation point to the door edge and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

==== Multi-brush doors: ====

More complex multi-brush doors can be created using the [[Clipper]] tool, CSG, etc. - this is not covered in this tutorial. Then assign <code>atdm:mover_door</code> for that whole brush structure. Also you can collect various brushes positioned together in relation to one another as needed, select them all, then assign <code>atdm:mover_door</code> for the group. All the brushes will be children of the <code>atdm:mover_door</code> entity and will rotate and be frobbable, etc. as one unit, as one door. To add further brushes or even model shapes later see the section on [[#Adding handles and other items to doors]].

Name your door by adding the prop (or modifing it) to name My_Door_1. You can use any name that you feel is appropriate but all doors with handles attached must have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below). (repeated from above in case you didn't choose to create a model door)

=== Double Doors ===
Double doors are automatically recognised by the code when the doors are spawned. The prerequisite is that both doors are sharing/touching the same visportal. The spawnarg ''auto_setup_double_door'' (which defaults to "1") will take care of setting up the open/lock peer relationship between the two doors. The doors will open/close and lock/unlock along with each other as a result.

What happens behind the scenes: the doors are adding each other to their internal open_peer and lock_peer list, which causes the double doors to perform the same action when frobbed or used.

Note that ''auto_setup_double_door'' will not set the frob_peer relationship, i.e. each door will frob-highlight on its own without highlighting the other door. You'll need to add that spawnarg manually if you want to highlight the entire double door as one.

==Customising and Adjusting Door Properties==

Handles, lockplates, etc. can be added to doors and door properties can be adjusted for rotation, sliding, locking, and more.

Some of the door models have hinge plates and lockboxes that are reskinnable with a good variety of skins.

===Door handles and other door attachments===

Summary: just add the property ''bind'' with the door's name to the attachment and position it where you want it on the door. If it's a ''atdm:mover_door_handle'' then it automatically will work as a handle but you can bind virtually anything.
You can add handles and other items to doors such that they move correctly with the door whether rotating, sliding, or both and even if the door is not vertical such as a skylight or trapdoor.
Handle models come in two types, ''single handles'' and ''double handles''. A single handle is one sided, this means the handle will be inside the door or outside the door, but not both. A double handle has a lever on the inside of the door and a handle on the outside of the door. Each has benefits.

*'''''Single door handles''''':
Single door handles can be used on a static door, a door that's just for show that no AI's or the player can use. In this case you should just create a door handle from the model viewer, it will be static and have no properties such as scripts. It is for looks only.

Single handles can also be used inside AND outside of the same door to save on rendering. Unlike the double handles the handle on the inside of a portal won't render. The curved handle is only about 130 polys per side, but if you have a large area and 10 handles you can save 1,000 polys from being rendered. Everything counts when it comes to performance.
I will call this ''multiple handles'', see more below.

These can also be useful on brush doors created in the editor that may be very thin or very wide.

*'''''Double door handles''''':
These are models have have a handle inside and outside. The bonus is that they only use one entity. Maps are limited to about 4,000 entities but when you count lights, AI, sound speakers, ect... you can run out of entities quickly on a large map. If you plan on building a large map this is the way to go, even in a small map they have benefits, namely that you only have to attach one handle per door.

Whether you decide to use a single handle or a double handle you must first follow the instructions below and attach one handle first. If you choose a double handle, follow the instructions below and you are done. If you choose a single handle type follow the instructions then also follow the ''multiple handle'' instructions for the second handle.

Both single and double handle types can be found in two places. The model viewer which will create a static model good for show, you can manually add props to make them work OR you can look in the entity browser.
Using a handle from the entity browser saves you a little bit of time as some props are already added, you just need to add the frob_peer names for the doors/handles and the door_handle name to the door.

=== Adding a working model door handle===

Quick summary:
* Create a model or brush handle and make it an ''atdm:mover_door_handle'' entity.
* Position it on your door. Use the opposite side from the door's multicolor X-Y-Z indicator (highlight the door to see it) if it's not obvious which side it goes on.
* '''Bind''' the handle to the door (bind <doorname>)
* It should now be a working handle though may need adjustments of rotation etc. see later.

Important: read preceding section on door handle types and performance issues first.

This works with both a model door and a brush door:

'''Rotation''':
* By default the door handle entity rotates ''anti-clockwise'' (looked at from the front) then springs back. A ''double handle'' model is OK but two singles (see ''Multiple door handles'' below) need more care as only one is the functioning entity and the other is just attached to it. So anti-clockwise is fine for a door with its hinge on the left and the handle on the right - the handle will rotate down then spring back. If you put the functioning door handle on the other side you will have to change the default ''rotate'' property from -45 0 0 to 45 0 0. '''''Therefore it is easier to generally put this handle on the side of the door where the hinge is on the left and the non-functioning attachment handle on the other side.'''''
*If your door only needs one handle, eg, a cupboard door, and from outside its hinge is on the right then you will need to change the ''rotate'' property of the handle as described above.

'''''The functioning handle entity:'''''
* Create an entity door handle (movers folder) or create a brush or model handle and assign it the entity ''atdm:mover_door_handle''.
* Position it where you wish on your door.
* '''Bind''' the handle to the door, by adding the "bind" spawnarg to the handle.

You now have a working door handle with default properties.

*'''Multiple door handles''':
Now that you've got a handle attached to one side of the door it is time to add one to the other side (unless you used a double handle).
* Create the new handle. The single handles come in left and right persuasions. A door needs a left facing handle on one side and a right facing handle on the other, so if you have already added the left handle create a right handle and line it up on the other side of the door.
* Name this handle. I prefer to keep a naming convention for each door and it's respective handles, it makes things alot easier. The door is named '''My_Door_1''', the first handle is named '''My_Handle_1''' so name the second handle '''My_Handle_1_1'''. This will make it stay with the first handle in the entity list. This is important to keep organized. If you name it My_Handle_2 then when you get to another door named My_Door_2 you'll be confused.
* Place and '''bind''' that handle to your door.

You now have two single door handles on either side of the door that rotate together as if they were physically attached.

'''To add a brush to a brush door''':
* Select the new brush ''and'' the brush door all together; ''the entity '''must''' be selected '''last'''.''
* Use {{menu|Edit|Reparent primitives}}. This ensures the parent entity adopts the new item(s).
* If you have trouble selecting them in the orthoview because other brushes, etc. get selected then try in the camera view or as a last resort move them temporarily to an open area (but keep them in the same positions relative to each other.) Use {{key-shift}}+{{LMB}} on new item(s) then {{key-shift}}+{{LMB}} on main entity. Once they are all selected, use the {{menu|Edit|Reparent primitives}}.

'''To add ''model'' static items''': knockers, hinges, static handles etc. to a ''Model Door'':
* Select item
* Right click in orthoview and select ''Create Entity'' then <code>entity func_static</code>
* Position it where you wish on your door.
* To synchronize this with your particular door you need to add the property ''bind'' and the individual door name to the brush entity. To do this...
** Select the model door.
** In the entity inspector, select the ''name'' line
** Select the bottom line in the input box ''below'' the properties window.
** Copy the name
** Deselect the door with {{key-esc}}
** Select the brush entity
** Add a property "bind" to it.
** Change the value of the property by pasting in the door name
** Click {{check}} or press {{key-enter}}

'''To add ''brush'' static items''': knockers, hinges, static handles to a Model Door:
* This method is not ideal but it seems to work OK.
* Select the brush.
* Right click in orthoview and select Create Entity then ''atdm:mover_door_handle''
* Position it where you wish on your door.

To synchronize this with your particular door you need to add the property ''door_handle'' on the door, and give as the value the name of the brush you just created.

This brush turns like a handle. To stop it:

* Adding ''rotate 0 0 0'' or disabling the handle script won't help.
* Add a real working handle (as in the section above ''To add a working model door handle...'' and it must be added LAST.)

If you don't want too see a real working handle added maybe try another tiny brush with the handle function and hide it inside the door?

===Locking Doors===

To lock a door check the ''show inherited properties'' in the entity inspector for a ''atdm:mover_door'' entity and you should see the ''locked'' property. Select it and in the input box below the properties you can change its value:

* 0 = unlocked (default)
* 1 = locked

If locked it will require an entity that is associated with it to be able to act as a key to unlock it.

Currently door handles on locked doors will rotate when frobbed, they will bounce back though and the door will stay locked until unlocked.

===Keys===

Assigning specific keys to specific doors is simple.

* It is recommended that you create an existing key entity. These keys have all required props, they just need to be named.

Alternatively you can create a key from the Model Viewer and want it to be useable
* Make sure it has the properties:
useable 1 [so it can be used by the door]
frobable 1
inv_name <unique name>
inv_category Keys
inv_target player1
inv_icon guis/assets/hud/inventory_icons/<icon name>
inv_stackable 0 or 1 where 1 can be used on all copies of the same key so they show as one entry in the inventory with a total.

Add to the door the property <code>used_by</code> with the name of the key as the value. Multiple keys can open the same door by using several <tt>used_by</tt> spawnargs:

"used_by" "doorkey_1"
"used_by1" "doorkey_2

==== Keys carried by AI ====

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see [[Attaching Props to AI]].

*"def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
*"pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
*"name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
*"set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
*"set name on door_key" "door_key" //here it gets a name to be used in the map in general.

updated by bikerdude.

====Master Key for Testing====

By default, ALL locks can be opened by any key named ''key_master''. Just create a key in your map, name it ''key_master'' and it becomes a master key for use while testing. Add inv_map_start 1 to it so it is in the player inventory at game start. Remember to delete it when your mission is finished.

===Lockpicks===
''by Baddcog''

There are two lock pick types.
*'''s'''=snake
*'''t'''=triangular

A lock can be set with many pins. Each pin has a click sequence and each needs a designated lockpick type (see above). Keep in mind that the lockpicking in The Darkmod is much more involved than in T2 or T3. The player has to listen to sounds or watch a handle or lockbar to know when a lock is pin is picked.

This means that authors can be very evil and really frustrate the player, in which case their missions will probably not be played. So be nice to the player and don't waste your time. Use simple locks for the most part and save complicated locks for important sections and to build tension. Don't make the player have 20 pins to pick all with different lockpicks. In most cases 1 or 2 pins will suffice and it isn't necessary to use both lockpicks on every lock.
Also try to include a lock lever on lockboxes or chests, door handles will rotate as the pins are being picked. This gives the player visual clues to help with the picking (and essential in noisy environments where you can't hear the clicks.)
IMO this system is a huge leap foward for lockpicking but also has the ability to completely frustrate the player as stated above. Keep this in mind when designing your lockpick systems.

These props go on the door itself, or the lid of a chest, eg,
*'''lock_pins''' 1327
*'''lock_picktype''' stts

The lock_pins property specifies how many pins each lockpicktype has.
The lockpick_type property specifies how many times the player has to switch picks and which pick they have to use. You can see there must always be an equal number of lock_pins and lock_picktypes specified

So looking at the example above we have lockpick_type s(snake), t(triangular), t(triangular), and s(snake). The player will have to use these lockpicks in this order. Once the snake lockpick's pins are open the player can advance to the triangular pick and so forth.
5 is added to every click sequence so 5 is the minimum click pattern even if you set it to 0.
In the example above the lockpins specify in order which pick types have how many pins, so the s pick has 1 + 5 = 6 clicks, the t pick has 8 and so on.
The above is a difficult lock and to avoid annoying the player it is best only used rarely on a special lock like an important big vault door. Ordinary footlockers and common doors can be just 1 or 2 click sequences, eg, lock_pins 2 and lock_picktype t means the player uses one pick and listens for the end of one sequence of 7 clicks.

lockpick_rotate - is placed on the door. It is the amount the visible rotating handle or pin rotates while picking. For a rotating handle or lockbar normally ignore this and leave the default. During lockpicking it oscillates and progresses to the normal full turn of the handle. Example 0 45 0.

lockpick_translate - is placed on the door. It is the amount the visible handle or pin moves in a straight line while picking. Use this if you have eg, a lockbar that you want to move in a straight line and not rotate, eg sliding catch. Example 0 -5 0

By default, doors are pickable. If you don't set up the above lockpick spawnargs then it can't be picked. So there is normally no need to enable lockpicking - just set up the above spawnargs. There is a ''pickable'' spawnarg set to 1 by default. If set to 0 then the door becomes unpickable. But hard to think of an application except in testing or perhaps a special custom situation where it is switched by script perhaps.

===Open, Partially Open, or Closed Door at Game Start===

By default, doors are closed at game start. If you want a door to be already open or partially open then do the following.

'''Note well: Create all doors in their ''closed'' position. Adjust as follows and they will automatically be at the open position when game starts.'''

Already Open Rotating Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and tick the check button
* The door will now be fully open at game start.

* If you want it only partly open:
* Make sure its ''open'' property is set to 1 as above.
* Right click the entity inspector and select ''add property''
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* scroll down, select ''start_rotate'' then click {{ok}}
* This adds it to the property list.
* Now select ''start_rotate'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the angle you want in the same form as described in the ''Rotate Direction and Open Angle'' section. So for example, to have a door that has a fully open default ''rotate'' value of 0 90 0 to start only half open you would give it a ''start_rotate'' value of 0 45 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

Already Open Sliding Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and click {{check}} or press {{key-enter}}
* The door will now be fully open at game start.

* If you want it only partly open:
* Right click the entity inspector and select ''add property''
* Make sure its ''open'' property is set to 1
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder.
* scroll down, select ''start_position'' then click OK. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* This adds it to the property list.
* Now select ''start_position'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the position you want in the same form as described in the ''Sliding (Translation) Amount and Direction'' section. So for example, to have a door that has a fully open default ''translate'' value of 0 50 0 to start only half open you would give it a ''start_position'' value of 0 25 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

===Rotation Centre, Pivot, Hinge point===

The centre of rotation of a door is at the origin point of its entity and the door rotates with reference to the orientation of that origin point, not the world map. See ''Rotate Direction...'' for more about that. This section only deals with the ''position'' of the rotation centre in the door.

Model Door Centre of Rotation: 
The centre of rotation of a model door cannot be changed within Dark Radiant. Because a model door rotates around the centre 'spine' of its back edge this will cause clipping (penetration into solid) as in this example (where the door is set to open to 89 degrees for clarity): [[Image:modelClipping.jpg]] So care is needed with placement. You will not normally position a door right next to a wall as in the example but against a shallow frame so clipping will barely be noticeable but either way it can be fixed. You can correct it by adding a translation (see ''Sliding (Translation) Directions'') value of half the door width in the direction of the door handle. This will gently move the door out as it rotates to clear any solid on that side as in this diagram: 
[[Image:DoorClip.jpg]] 
Half a door width will typically be about 2. Any 'attachments' such as door handles will still synchronize with the door movement whether the door is rotating, sliding, or both.

Brush Door Centre of Rotation: 
The centre of rotation of a brush door ''can'' be changed. The default origin point of a brush is at its centre. Therefore a default rotating brush door will rotate around its centre when you first create it. So, mappers will commonly need to move that rotation point to a corner or even to some other offset position for example, for an openable window using the door function.

Put simply, to move the rotation point of a brush door you need to move the entity origin relative to the brush(es.)

Moving the entity origin (centre of rotation) relative to a brush door:

* Select the brush door
* Select ''Vertices mode'' (default shortcut key is {{key|name=V}} or button on top toolbar 'Select Vertices')
* Drag the door's entity origin to the point where you want the door to rotate. This should be on the corner on the leading edge side (the side to where the door is opening.) to avoid clipping as in this diagram....
[[Image:getCorner.jpg]]
* You should now find that door rotates around that point.

===Rotate Direction and Open Angle===

By default, rotating doors open anti-clockwise (viewed from above) by 90 degrees from the start orientation. If you want to change this edit the ''rotate'' property in the entity inspector. Don't confuse this ''rotate'' property with the ''rotation'' property. In the entity inspector remember that to see the inherited rotate property you must check the box 'Show inherited properties'.

The three values shown in the rotate property are degrees from the closed position around Y Z X (absolute map axes Front, Top, Side views in DR's ortho view.)

* Positive Y = Open clockwise (Dark Radiant grid front view, looking north)
* Negative Y = Open anti-clockwise (Dark Radiant grid front view, looking north)

* Positive Z = Open anti-clockwise (Dark Radiant grid top view, looking down)
* Negative Z = Open clockwise (Dark Radiant grid top view, looking down)

* Positive X = Open anti-clockwise (Dark Radiant grid side view, looking west)
* Negative X = Open clockwise (Dark Radiant grid side view, looking west)

There is a problem when you come to rotations that are not around the main Y Z X axes of the map, for instance a drawbridge that lowers down to the south east. You might think you can combine Y Z X values to get the result you want - and this can be done (for south east use 45 45 90) but it is a bit of a kludge and the drawbridge twists eccentrically as it lowers (though it arrives correctly!)

The values are in the range -179 to +180. Positive values give an anti-clockwise opening rotation (looking down from above) and negative values give a clockwise opening rotation. The value 180 is unique in that it continues in an anti-clockwise rotation when closing rather than returning clockwise so might be used if you can think of some object that might need such a motion when frobbed!

Edit the rotate value by selecting it and using the input box at the bottom and clicking the check(tick) button. That will change the angle the door will open to. Note that the line with the original default of 0 90 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Examples:
* 0 90 0 = Opens anti-clockwise round the entity's 'vertical' to 90 degrees - typical default vertical door.
* 0 0 90 = Lowers a drawbridge from the entity 'vertical' to horizontal.
* 0 0 -45 = Opens clockwise by 45 degrees viewed from the east side. This might suit a skylight in a sloping roof.

'rotate' cannot be combined with translate motions (see [[#Sliding (Translation) Amount and Direction]]) in one door; you need to bind one door to another and link they by targetting one to the other. By that means you can produce exotic and useful motions. A door opening against an upward-sloping floor can thus have a ''lifting hinge'' and raise up slightly to clear the floor; a door can rotate towards you and slide back to one side very effectively.

===Sliding (Translation) Amount and Direction===

By default a Dark Mod door will rotate open. For most sliding doors you want to stop them rotating as well as make them slide. You cannot delete (remove) the ''rotate'' property - you have to set the ''rotate'' property to 0 0 0 to stop a door rotating (see ''Rotate Direction and Open Angle''.)

Now edit the ''translate'' property value by selecting it (remember to have inherited properties box checked) and using the input box at the bottom and clicking the check(tick) button. That will change the distance the door will slide to. Note that the line with the original default of 0 0 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Typically (but not always) you will want your sliding door to slide the width of the door. The three values in the translate property by default are 0 0 0 and are X Y Z ''absolute map'' values (irrespective of door orientation) where:

* Positive X = Slide East (Right side of Dark Radiant grid in top view)
* Negative X = Slide West (Left side of Dark Radiant grid in top view)
* Positive Y = Slide North (top of Dark Radiant grid in top view)
* Negative Y = Slide South (bottom of Dark Radiant grid in top view)
* Positive Z = Slide Up (Top of Dark Radiant grid in side views)
* Negative Z = Slide Down (Bottom of Dark Radiant grid in side views)

So for a 50 unit wide door you want to slide fully to the east you would use 50 0 0 for the translate property values. A 100 unit portcullis sliding vertically up would need 0 0 100 to be fully raised.

=== Doors Collision/Push Behaviour ===
Doors are pushing all entities by default, except for the player. Doors will also stop moving when anything blocks their movement. However, this default behaviour can be changed by setting the according spawnargs:

Set '''push_player''' to '''1''' to let the player be pushed by this door:
"push_player" "1" // Push the player too (default is off)

By default '''stop_when_blocked''' is set to 1 and if a door is blocked by an entity then even if the entity is removed afterwards, the door stays still. The next frob will close the door.

Set '''stop_when_blocked''' to '''0''' to prevent the door from ending the opening sequence when anything blocks its way. It will still pause - but continue to open if the block is removed.
"stop_when_blocked" "0" // door keeps moving after being blocked (default is off)
With this setting, doors will still stop at blocking entities (the player, for instance), but will continue to move when the entity clears the way.

There is another spawnarg which stops a door pushing a moveable. Apply this to the ''moveable'' not the door...

"notPushable" "1"

===Door Sounds===

The sound of doors opening and closing is set in the snd_open and snd_close properties. You can silence them by setting the following properties as shown:

''snd_open nosound'' 
''snd_close nosound''

Don't just use a dash - as it seems to cause a sound of its own.

The above sounds are triggered as the door begins to open (eg, unlatch sound) and when it finally closed (eg, slam.) For special doors that need an on-going sound, eg, a big stone slab that moves slowly, then use:

''snd_move''

''snd_locked'' 
The sound played when a player tries to open a locked door.

''snd_unlock string'' 
The sound played when a player unlocks a door.

===Sound Propagation through Doors and Doorways===

The sound volume reduction to the player (ie, the sound the player hears) is fixed and constant in a cvar which adds a distance factor to the original sound. It is recommended that you do not change that because it will affect other FMs. Currently there is no way to change the way that sound to the player is reduced through doors and doorways.

Sound propagation to AI, eg, impact sounds or guard yells is treated separately:

Sound propagation to AI relies on visportals. For details study [[Sound Propagation: Part 1]] and [[Sound Propagation: Part 2]] as well as [[Visportals]] This tutorial will just cover the relevant sound and sound propagation ''properties'' of doors. If you set the ''show inherited properties'' box in the entity inspector you can see them as described here.

Remember, the following have no effect on what the player hears through a door or doorway.

''loss_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through an open door. (default 1dB)

''loss_closed'' 
Drop in sound volume in dB propagated to AI (not player) when going through a closed door. (default 15dB) You would want to set this very high to block all sound with a thick door but very low for a barred gate for example.

''loss_double_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through double doors when only one is open. (default 1dB)

There are also various sound properties for lockpicking: 
''snd_lockpick_pin_1 through 14'' and ''snd_lockpick_pin_success''

===Speed of Door Opening and Closing===

Rotating Door Speed: 
At the time of writing, the time a rotating door takes to open or close is set in the ''move_time'' property whatever its maximum open angle. So with rotation set at say 150 degrees the door just opens faster than at say 80 degrees. This is likely to be changed to a constant angular velocity so check to see if there a new property added if the following no longer works. The problem is that if an interruptable (see Extra Notes) door is frobbed while in motion it stops; another frob will reverse the motion - so even if the door is only open a crack it will still take the full time to close and vice versa.

To change the time a rotating door takes to open or close, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''move_time''
* Edit the second line of the input box ''below'' the properties window to the time you want.
* The time is in seconds and decimal fractions can be used.
* The default is 1 second and if set to this then the door opens and closes in one second whatever the maximum open angle, great or small.

Sliding Door Speed: 
The speed of a sliding door is set in the ''translate_speed'' property. To add this, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''translate_speed''
* Edit the second line of the input box ''below'' the properties window to the speed you want.
* The speed is in Dark Radiant grid units per second.
* The default is 0 and if set to this then the door slides open in one second whatever the distance, great or small.
* CAUTION: If you later change the door back to a rotating door then delete the ''translate_speed'' property or ensure it is set to 0 as (at the time of writing but this will be fixed) a bug makes rotating doors open and close instantly. (Note: you can still mix sliding with rotating but check - this bug might only be if ''translate'' is set to 0 0 0)

===Visportals and Doors===

A visportal face surrounded by solid at its edges and in contact with a door is closed when the door is closed and enabled when the door is open. In most cases you will place a visportal in contact with a working door unless you can see through the door (such as a true glass door or barred gate.) For full details see [[Visportals]].

==Auto-Closing/Opening Doors==
Doors that automatically close after being open for some time are easy to setup: Each frobmover entity supports these spawnargs:

;"auto_close_time":Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
;"auto_open_time":"Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

Old text:

Note that auto-closing doors and AI closing doors behind them, is very much work in progress at the time of writing, so for now, this is another method that works. Check first if true AI closing of doors is working yet before bothering with this!

I have one door that I particularly want the AI to close as there is a bit of frame lag inside if not. So I set this up and it works good as an auto-closing door - not as good as a true AI closing door as it will auto close when the player goes through as well but it does look very effective to see AI going through and closing the door behind them. Not tested exhaustively so I don't know if there could be any downside. Here's what to do....

First a quick summary to make it more clear:

'''''A trigger_relay is used both as a relay AND carries a stim. We put the trigger_relay with its stim in the path of the open door. The door has a response property. When it opens and contacts the stim its response is to send a signal back to the relay. The relay pauses then closes the door...'''''

* First, optionally give your door a suitable name like autodoor1, whatever.
* Copy that name to the clipboard.

Next we need a relay with a delay:

* Create entity > darkmod > trigger_relay

* Place it roughly at the position the door will be at when open and to be on the safe side 3/4th of the way to the far end of the door (not the hinge end) to give max distance from the close door.

* Add the property 'target' and paste in the door name you just copied.

* Give the relay itself a name, eg, autoDoor_relay_1, and copy that name to the clipboard, you'll need that too in a bit.

* Add the property delay and the value 3 - this is the delay in seconds before the door will close; 3 seems about right but 2 might be worth a try because to that 3 is added a random value between 0 to 0.5 seconds from the Time Interval we entered for the stim firings.

* Add the property 'wait' and the value 3. This is the time before it can work again in seconds. If you set it too low then in theory the door might trigger again but in this situation I don't think it's possible. Too long, eg, one minute, and it won't work if the AI goes back through the door before then. If this value is -1 then the whole thing will only work ONCE so might be used for an AI who goes through once, closes it behind him, but you don't want it to be an autodoor thereafter.

That's the relay, now we add a stim to it:

* Still with the trigger relay selected, go to {{menu|Entity|Stim/Response}}

* Custom stim tab.

* Click Add stim type, select the new custom stim type you just made at the bottom of the list and type in eg, autoDoorStim at top right in the input box.

* Click the stim tab and the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Select the new autoDoorStim in the list and on the right you need only type in the radius box 15.0 There is quite a lot of room for error. I had it working on 10 and also on 25. The value should be less than the distance to the closed door else it will trigger open! But no so small that the door might not reach it.

* Select the check box for Time Interval and enter 500 (millisecs.) This is so it doesn't keep firing more frequently than is necessary. This stim will be firing all through your mission whether the door is used or not so if you had dozens of these then maybe it would affect performance. Too big a number and there may be a long delay before the door shuts - but it will be random depending on the next time the stim happens to fire. We'll control the delay we want more precisely later.

* Click {{ok}} to confirm it.

That's the stim set up, now for the response to it which is put on the door....

* Select the doorm, then use {{menu|Entity|Stim/response}} and select the response tab.

* Click the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Right click in the big ''Response Effects'' box on the bottom right of the panel.

* Add New Effect and you should get a default 'Activate Response' response added to the list. Double click it.

* In the Effect selector at the stop select 'Trigger'

* in the Target box, paste in the name of the relay you copied or you can select it from the list at the little arrow.

* Leave the Activator box empty.

* Click {{apply}} and then {{ok}} on the main S & R panel bottom right.

It should now work. No need to wait for an AI, just frob the door and watch it close itself. If not, check the position of the stim brush is close to where the door stops when open.

==AI Door management==

See also [[#Keys_carried_by_AI]] above.

By default AI will open doors and close them behind them. Here are some spawnargs the mapper can use to modify that behaviour:

;"ai_should_not_handle" :If set to 1, AI will not attempt to handle it and add it to the forbidden areas when closed (so that it doesn't try to path through). They might still walk through the door when it is open though. Useful if you have some special use door that you don't want the AI to operate.

;"ai_should_not_close" :If set to 1, AI will not close the door behind them unless it obstructs them.

To get AI to unlock/relock specific doors there are two methods currently:

1. add the following spawnarg/value to the AI:

;"can_unlock1" ''<doorname>''

'''Do NOT use can_unlock_1.'''

For additional doors on the same AI use ''can_unlock2 doorname'' etc.

2. In the editor position an actual key that works for that door on the AI and also add to the key bind <AIname> and also bindToJoint LeftHips_Dummy (see other joints names elsewhere in wiki.) Currently, if the player pickpockets the key then the AI seeks an alternate route but otherwise does nothing (?) This may be upgraded in the future to better strategies.

3. There is the possibility in the future of an additional method which would just use special attach spawnargs to make the above easier. The key would spawn at the correct position at game start. Watch this space.

===Door handling positions===

It is also possible to set custom door handling positions for the AI. This is especially useful when the standard routine that lets the AI choose their standing positions while opening and closing the door fails, leaving them circling around in front of the door helplessly.

Place a movers > atdm:door_handling_position entity where you want the AI to stand while opening/closing the door from this side.(it can be found in the movers folder in the entity chooser)

On the door, you need to set the spawn arg "door_handle_position" "name_of_door_handling_position" You can also place a door handling position on each side of the door, the AI should automatically choose the right one. In this case, you need to set spawn args with "door_handle_position_1" etc and the corresponding names of the door handling position entities on the door.

The door handling positions can also carry spawn args that define the behaviour of the AI, which are useful for example for doors that can only be openend or locked from one side:

'''"ai_no_open"''' If set to true, the AI will not try to open the door from this side (but still walk through when the door is already open)

'''"ai_no_close"''' If set to true, the AI will not attempt to close the door from this side

'''"ai_no_unlock"''' If set true, the AI will not be able to unlock the door from this side, but still use it when it is not locked.

'''"ai_no_lock"''' If this is set true, the AI will not lock the door from this side.

===AI locking doors behind them===

If one AI is involved (no one else is in the queue), he'll lock it behind him if he had to unlock it in the first place.

If more than one AI is using the door at the same time (there's a queue), the first AI unlocks the door, and the last AI through will only lock it if it's marked "should_always_be_locked" AND they have a "can_unlock" for that door or they have a key for that door. The last AI to use the door doesn't know that the first AI found it locked, because that info is kept per AI, and not per door.

In the rare case where a door is set up to use door-handling position entities (necessary for AI to use sliding doors), either or both of those entities can have the "ai_no_lock" spawnarg, which means AI aren't allowed to lock the door from that side.

==Doors as Triggers==

''by Ishtvan & greebo''

Doors (or any binary frob mover, buttons, levers, etc) now have the option to trigger their target on closing or opening. (For definition purposes, a button is defined as "closed" in the state when it starts out and "open" in the state you press it down to. I know that's a little non-intuitive, but it came from deriving from doors).

New spawnargs on frob movers:
;"trigger_on_open" :If set to 1, this binary mover will trigger its targets when it starts out completely closed and is opened.
;"trigger_when_opened":If set to 1, this binary mover will trigger its targets when it is completely opened. Code defaults to 0.
;"trigger_on_close":If set to 1, this binary mover will trigger its targets when it completely closes after being open.

==Skins: A Wide Variety of Door Textures==

This is to remind you that as with many Dark Mod models, there is a wide range of extras skins (textures) available for door models. There are now several basic door entities of different sizes so choose your size first. Then enter the spawnarg: skin with any temporary value. Now select it and click the skin button at the bottom of Dark Radiant's Entity Inspector and you will find a large of range of skin textures from which to select to give you a choice of appearances for your door.

==Extra Notes==
The property ''interruptable'' determines whether a door can be stopped by frobbing while it is opening or closing. So by frobbing then frobbing again, the player can open a door to any position, eg, slightly ajar to peek through.

''func_darkmod_door'' is no longer used (just in case you come across it in the Dark Mod forums or wiki.) The Doom func_door is still available but for Dark Mod, but <code>atdm:mover_door</code> is the entity to use.

{{tutorial-editing}}

Error Messages

2011-07-18T07:35:27Z

Fidcal: /* Leaked */

''begun by Fidcal''
== Introduction ==

This is a list of Dark Mod (doom3) console dmap error and warning messages, what they mean and what to do about them. Please add any that you know.

== Errors and Warnings ==

=== ChopWindingWithBrush ===

''WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive [N] more than 128 windings''

The ChopWindingWithBrush error means you have too many small brushes placed against a large brush.

* Note the brush number in the message where it says primitive [N]
* In Dark Radiant, press Esc to deselect all.
* Select Find Brush in the Map menu.
* Delete the 0 in the entity input so it is blank
* Enter the value from the error message (represented above as [N])
* Click the Find button and your problem brush should be selected
* Select the clipper tool (see [[Dark Radiant Controls, Keys & Mouse|DR Controls]] for details) and cut the brush in two or more pieces making sure the cut divides up the touching brushes area. No point in just splitting it in a blank area. You obviously need to use the option to divide the brush in two not clip and discard!
* Save with a new name ideally then test dmap again and it should be OK.

=== Entity 1 has surfaces, but no name key ===

This error "Entity 1 has surfaces, but no name key" seems to occur if entity 0 is not worldspawn. Somehow the first entity 0 is some other entity and worldspawn was entity 1 so had no name key. I couldn't reproduce this but it has happened. Possibly there might be other circumstances where an entity has no name key but normally Dark Radiant would not permit that.

Solution:

* In Dark Radiant:
* Make a backup copy of your map using menu > file > save copy as.
* Deselect all with Esc.
* Menu > find brush > set brush and entity to 0
* Click OK
* Entity 0 is normally worldspawn.
* If it is some other entity not worldspawn, clone it then delete the original. This will rename the entity so you might need to check if this affects anything targetting it or bind to it, or script ref. etc.

=== Leaked ===

''Warning: ************leaked**************''

See this [[Performance: Essential Must-Knows#How to detect and fix leaks|must know]] for details of how to deal with leaks.

=== Node without a volume ===

This indicates a brush/entity/patch that is either infinite, or not properly closed. You need to delete these brushes and redo them.

To find these brushes, note the entity ID which Doom prints on the console:

############### entity '''32''' ###############
--- FaceBSP ---
0 faces
1 leafs
0.0 seconds faceBsp
----- MakeTreePortals -----
WARNING: node without a volume

In this case it is 32, so go to '''Map -> Find Brush''' in DarkRadiant, and enter this number into the '''Entity number''' box and press ''Find''. The entity in question will be highlighted in the editor.

===Too many verts for a poly===

If you notice warnings in the console like the following:

WARNING: ConvertLWOToModelSurfaces: model models/darkmod/props/decorative/statuette_priest_torso.lwo has too many verts for a poly!
Make sure you triplet it down
WARNING: ConvertLWOToModelSurfaces: model models/darkmod/props/decorative/statuette_priest_torso.lwo has too many verts for a poly!
Make sure you triplet it down
WARNING: ConvertLWOToModelSurfaces: model models/darkmod/props/decorative/statuette_priest_torso.lwo has too many verts for a poly!
Make sure you triplet it down

It means one of two things. One, you forgot to Triple your model (you cannot have 4 sided polys in D3). In Lightwave, you do this by using the "Triple" command (shift-t).

Or two, there are leftover 1 or 2 sided polys. In Lightwave, you can check this by checking the "statistics" window (w). It will list the number of 1 or 2 sided polys, and you can select them by hitting the (+) sign beside the name. If you delete them and save the model it should solve the problem.

Technically, this is just a warning, not an error, so your map will still work. But for the sake of less garbage in the console you should try and fix it.

== Useful Links ==

* [http://www.map-center.com/forums/viewtopic.php?t=331 map-center.com post] with good explanations
* [http://www.doom3world.org/phpbb2/viewtopic.php?f=1&t=7439&view=previous doom3world forum]
* [http://www.katsbits.com/htm/tutorials/common_error_messages.php quake3 errors]

{{troubleshooting}}

Combined light entities

2011-06-08T13:04:30Z

Fidcal: /* Setting spawnargs */

== Introduction ==

Many complex objects in game are build from more than one entity. Others consist of only one entity, but represent different things at the same time.

For instance, a candle consists of two entity: the candle stub, and an attached flame object.

The flame object itself consists of only one entity, but this entity both emits light, sound and particles as well as reacts to stimuli like fire and water.

This article deals with the complex entities consisting of more than one entity.

=== Two ways ===

There are two ways to attach two entities together:

* the entityDef (inside a .def file) can specify to spawn and attach a new entity when the first entity is spawned. This typical happens at map loading time, but can also happen later in game when a new base entity is spawned. This is from here one called "def_attached" due to the spawnarg being responsible: [[def_attach]].
* the mapper can manually add both entities in the map, and then arrange them in the editor so they look bound together. Additionally, one can use the "bind" or "bindToJoint" spawnargs to make f.i. a key bound to a moving AI. We refer to these ways from here on as "the manual way".

The manual way has several disadvantages but also advantages:

'''Disadvantages:'''

# manually arranging the entities is error prone, f.i. often candle flames would hover over the candle, or be slightly offset
# Moving the entities in the map must always move both in sync, or 1. happens.
# when creating a moveable entity, the mapper must also take care that the second entity moves with the first by binding them together manually
# Changing the color of all attached flames is cumbersome, as you need to modify each of them. With the def_attached method, you can simple edit the entityDef file or overwrite this entity with your own definition.

'''Advantages:'''

# Both entities are present in the editor, and can thus be seen. (For combined entities, DR will hopefully later automatically show a dashed outline for any automatically attached entities, making this point moot).
# Since the attached entity is already in the editor, its name is known, so it can be easily targeted by scripts and have spawnargs set on it. This is the main disadvantage of def_attaching entities and we see later how we can overcome it.

This article, deals primarily with the def_attach method.

== Example entities ==

=== Candle and Flame ===

Here is an example how a flame is attached to a candle:

<pre>
// attach the light, so the candle can be re-lit by fire stims
"def_attach" "light_candleflame_unlit"
"pos_attach" "flame" // At the attach point called "flame"...
"attach_pos_name_1" "flame" // ... which is defined here.
"name_attach" "flame" // Set a name to pass along spawnargs
"attach_pos_origin_1" "0 0 15" // Offset the flame X units in the Z direction
</pre>

The '''name_attach''' is the name of the attachment, which will be important for later when setting spawnargs.

=== Holder and Candle (and Flame) ===

Here is an example entity attaching a candle (which itself has an attached flame) to a candle holder:

<pre>
/* skinny tall */

entityDef atdm:moveable_candle_holder_plus_skinny_tall_candle
{
"inherit" "atdm:moveable_candle_holder_base"
"mass" "1.5"

"editor_usage" "A candle holder with an unlit tall & skinny candle."

// attach the candle
"def_attach" "atdm:moveable_candle_skinny_tall"
"pos_attach" "candle" // At the attach point called "candle"...
"attach_pos_name_1" "candle" // ... which is defined here.
"name_attach" "candle" // Set a name to pass along spawnargs
"attach_pos_origin_1" "0 0 17.5" // Offset the candle X units in the Z direction
}
</pre>

== Modifying the attached entity/entities ==

When you place a combined entity (f.i. candle+flame) in your map, you only see the base entity, in this case the candle. However, to switch the candle off or on, you would need to link some entity (like a switch or trigger) to the candle flame entity. Likewise, if you want to change the color of the flame, you would need to set the "_color" spawnarg on the flame.

But since the candle flame does not exist yet, you can't. Here is how you can overcome this:

=== Linking from the holder entity ===

If you want, for instance, a second light to go on/off, or a door to open when a candle is extinguished, simply select the candle holder, and the second entity and press {{key|CTRL}} + {{key|K}} to link them. The holder will rely on/off signals from itself to the linked entity when the flames are extinguished or relit.

=== Targeting the (invisible) entity ===

Simple target the base entity, like the holder or the candle. When triggered, these know how to extingusish or light all attached flames (even tho they don't exist at map load). The holder will then rely the signal to any targeted (either by the holder or by the flames) entities.

=== Turning lights off/on ===

Since the attached light entity is not present in your map, you do not know its name, and thus it could be difficult to do simple things like turning the lights on or off. To make this easier, three methods exist to help you:

==== Script Object ====

Each base entity has a script object attached, that features the three following methods:

# LightsOn();
# LightsOff();
# LightsToggle();

You can use them in two ways:

'''Write a script:'''

<pre>
entity my_holder = sys.getEntity("Name_of_the_light_holder");
my_holder.LightsOn();
sys.wait(500);
my_holder.LightsOff();
sys.wait(500);
</pre>

'''Use an atdm:target_callobjectfunction entity:'''

Create an '''atdm:target_callobjectfunction''' entity and give it the following spawnargs:

"call" "LightsOff"
"target0" "Name_of_the_light_holder"

Then just trigger that entity with a trigger of your choosing, or target it from a lever etc.

See the [[atdm:target_callobjectfunction|article about atdm:target_callobjectfunction]] about for more details.

==== Global functions ====

Es a last resort, there are three special global script functions that you can use to manipulate attached light entities when you only know the base entity:

<pre>
frob_light_holder_light( holder ); # turn the light on
frob_light_holder_ext( holder ); # turn the light off
frob_light_holder_toggle_light( holder ); # toggle light (if on => off, if off => on)
</pre>

'''Note:''' These functions are called without an object and take as first argument the base entity.

Example:

<pre>
void light_on( entity zone )
{
entity holder = sys.getEntity( "stone_room_light" );
if (holder)
{
// We need to tell the holder to turn off the bound light (as we do
// not know what the bound light entity is named)
frob_light_holder_light( holder );
}
// better, shorter and more clean, object-oriented way:
if (holder) { holder.LightsOff(); }
}
</pre>

'''Note:''' Don't call these functions this way:

<pre>
holder.frob_light_holder_light(); # WRONG!
</pre>

=== Setting spawnargs ===

Setting a spawnarg on the attached entity is simply done by setting the spawnarg '''set SPAWNARGNAME on ATTACHMENTNAME''' on the base entity. '''SPAWNARGNAME''' is the name of the spawnarg, while the attachment name can be looked up in the entityDef for the base entity, e.g. in DR by checking the "Show inherited" in the entity inspector.

Here is an example, changing the color of the attached flame:

<pre>
"set _color on flame" "0.2 0.2 0.9"
</pre>

In DR, enter the spawnarg name and value without the quotes. The above setting will set the spawnarg '_color' on any entity attached that has the attachement name 'flame' to "0.2 0.2 09", thus coloring the light blue.

The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.

=== noshadows_lit ===

All entities that use the "tdm_light_holder" [[script object]] can use the following combination of spawnargs:

For starting lit entities:

"noshadows_lit" "1"
"noshadows" "1"
"extinguished" "0"

and for starting as unlit entites:

"noshadows_lit" "1"
"noshadows" "0"
"extinguished" "1"

This makes the entity only cast a shadow when the light is off, the switch is done by the light holder script object. This has the effect that when the player turns on the light, or lights the torch/candle, that the model itself does not cast a shadow, preventing it from casting ugly shadows from its own light. However, if the light is off, then other light sources still cast a shadow from the candle holder. This is a compromise between having no shadows or shadows all the time and looks a lot better than just setting "noshadows" to "1" all the time.

=== Changing attached entities ===

Sometimes you want to change the actual attached entity for another variant, but the specific combination does either not exist yet, or you have made a new entity that you want to attach instead.

Now you could create the combination entity from scratch, but that can be cumbersome and error prone. Instead, just swap the attached entity.

Here is how you take a normal combined walltorch+flame and swap the flame for a green variant: Just override the spawnarg "def_attach" with your own version:

<pre>
"def_attach" "light_torchflame_green" // note: the green torch only exists from TDM 1.01 on
</pre>

All the other spawnargs have already the right value and can thus be left alone.

{{lighting}} {{editing}}

Pathfinding

2011-06-06T20:42:03Z

Fidcal: /* monster_clip : Adding AI pathfinding to Horizontal Surfaces */

''Written by Fidcal''

For information on using path entities, see [[Path Nodes]].

==Introduction==

This tutorial covers AI pathfinding. By 'AI' is meant any non-player character in the game such as a guard, spider, belcher, etc.

Plain worldspawn brush terrain (not assigned to entities) is ''collidable'' and also correctly affects pathfinding so AI 'recognize' it either as a barrier to avoid or as a surface on which they can walk. But all patches as well as brushes and models that ''are'' assigned to entities are not recognized by AI as a barrier and they will walk mindlessly forever against such obstacles unless diverted. Nor can they walk over their surface (although the player can.) This is because pathfinding does not take such surfaces into account so will not guide AI around or over them. Yet AI will ''collide'' with them so an AI may try to walk right through a model pillar but refuse to walk over a solid bridge made of static entity brush. This can be put to good use (see ''Preventing and Reducing Pathfinding in selected locations'') but first we shall look at assisting pathfinding...

==Enabling and Improving Pathfinding in Select Locations==

The mappers' most important AI pathfinding control is ''monster_clip'' - it is essential in good map building. ''monster_clip'' is an '''invisible''' material used to guide AI around obstacles and over surfaces they otherwise could not traverse. It is not applied directly to existing terrain but placed invisibly around it ''on its own brush''.

''monster_clip'' is a texture; find it in the entity inspector under:

Media > textures > common > monster_clip

* It must ONLY be applied to a worldspawn brush
* It must NOT be applied to an entity.
* It must be applied to ALL surfaces of the brush.

The ''monster_clip''-textured '''brush''' is then placed around an entity brush or model to either guide AI away from it or let them walk upon it. It can also be used on its own as an invisible collidable vertical barrier or as an invisible surface to walk upon.

Although substantial to the AI, ''monster_clip'' is completely invisible and intangible to the player so the player can pass right through it and be unsupported by it. For an invisible barrier or bridge for the player (but not to AI) use ''player_clip'' (also in textures > common.) ''player_clip'' is also useful to cover areas where the player might tend to get stuck.

==''monster_clip'' : Vertical Barriers to AI Pathfinding==

All entity-based terrain and models that lie in the path of AI should be surrounded with a brush wholly textured with ''monster_clip'' or the AI are likely to just blunder into them. They might slide off if there is an angle but they are just as likely to get stuck walking blindly against such a barrier forever. Examples are pillars, statues, railings, anything that is assigned to an entity and is not a plain worldspawn brush should be considered. This does not apply to everything wholesale; anything that will not be in the path of AI should not be surrounded by monster_clip or it will make pathfinding more complex than it needs to be (see ''Preventing and Reducing Pathfinding in Select Locations''.)

''monster_clip'' brushes around vertical barriers should fully surround them or they might not work properly. In the case of irregular shapes then extend the ''monster_clip'' brush to include the outermost protrusions. In fact in some cases you might wish to be extra generous and make the ''monster_clip'' signficantly bigger if you want the AI to steer well clear for any reason.

''monster_clip'' brushes can also be used completely on their own as invisible barriers to obstruct or divert AI for whatever reason you wish though obviously you need to keep in mind how the AI's behaviour will look to the player. Remember, the player can move freely through these invisible barriers.

==''monster_clip'' : Adding AI pathfinding to Horizontal Surfaces==

To enable AI to move over horizontal entity surfaces - whether brush or model - you need to surround the object with ''monster_clip or the AI will refuse to go there.

* The ''monster_clip'' brush should vertically surround the object ''but just below the surface and no more than roughly 16 units below (not tested, some say 48)'' else they may fail to pathfind over it. Note that if top of the monster clip is above the surface it will still work but AI footstep sounds will be stone no matter what the surface so generally keep below.
* When walking over a ''monster_clip'' brush surface, AI may stray up to around 18 units out of the 'corridor' of ''monster_clip''. It may be that the edge is calculated for the centre of the AI and not its outer width. For this reason you should reduce the horizontal width by around 18 to keep the AI pathfinding away from the edges where appropriate. For example on a bridge without side rails or walls, if an AI is to turn left or right at the end it will likely move over to one side or other of the bridge as it walks across and is likely to have one leg over the edge! By reducing the ''monster_clip'' width you will keep the AI in a corridor down the middle. If there were a side rail or wall of course then that would have its own ''monster_clip'' so that would keep them on the straight and narrow.
* AI walking over a lone ''monster_clip'' brush that has no entity core will sink into it by about 28 units. This means that if you make an invisible AI-only bridge of ''monster_clip'' then it needs to be 28 units higher than where you want the AI's feet to touch. So a channel with side walls with top surfaces at 100 will need a bridge whose top surface is at 128 in order for the AI to walk smoothly across flush with the side walls. Because 14 to 16 is the maximum step height for an AI you will need a short step of ''monster_clip'' at the entrance and exit for the AI to get on. So this step might be 14 units high but can and should be very shallow - even one unit deep is enough for the AI to pass smoothly on to the main bridge.

==Preventing and Reducing Pathfinding Complexity in Select Locations==

In areas where there are a great many entity surfaces at about the same level for the AI to walk upon then one large ''monster_clip'' brush can be exended around the lot (see all about ''monster_clip'' in the ''Enabling and Improving Pathfinding in Select Locations'' section.) This will simplify pathfinding and make it more efficient.

AI will refuse to move over models and brushes assigned to entities unless surrounded by a ''monster_clip'' brush so this is a good method of preventing and reducing pathfinding where needed. This reduces pathfinding complexity and stops AI stepping up on to places such as skirting boards (baseboards.) So...

Avoid using plain worldspawn brushwork but instead assign them to func_static or some other entity if that is appropriate on...

* Any area out of reach of AI such as rooftops, balconies, ledges, etc. and especially steep slopes as these can generate complex pathfinding.
* Areas that AI should not or will not walk on such as shallow building trim and decoration, etc.
* And do '''not''' surround them with ''monster_clip'' brushes.

==Steep Steps, Slopes, and Extreme Pathfinding!==

The maximum slope for an AI is approximately 40 degrees from the horizontal but varies upon the situation and the AI. The maximum step height for AI and player is 16 though some AI cannot step up over 14 and perhaps less. But the minimum depth from front to back of a step is only 1 and this can be used to get extreme slopes and very steep steps - even near vertical walls! So, by making a flight of steps each 16 units higher but making each alternate one only one unit deep the overall stair is very steep. The shallow step is near invisible especially if it falls on a join in the texture and anyway it can be made invisible with texture > common > nodrawsolid. Yet AI can step up both this shallow step and the normal step in one convincing motion so this is useful for getting very steep steps where needed. The player can walk up these too with ease and without mantling or jumping.

Taking the above method to great extremes, once can have the entire stair made with shallow steps no deeper than one unit and this looks like a vertical wall. If made invisible it could really be placed against a visible vertical wall if needed. Both AI and the player will shoot up these extreme steps effortlessly. This is not so natural so not easy to think of an application but mappers are very imaginative and no doubt will use it here and there! Most particularly, keep this shallow step idea in mind when you want the player to cross very rough terrain without struggling or getting stuck. The occasional hidden step here and there and the player can scamper over a boulder field or rough debris without having to keep stopping except where mantling makes better sense.

One caveat, I set up some ladder brushes as extreme steps. The AI went up and down the ladder (albeit virtually one huge jump with no animation) BUT pathfinding went strange in another part of the mission. Not conclusive but watch for that. (If you try the ladder thing, when you have made the steps, then tilt the whole lot forward so the steps still form a vertical but jagged wall.)

With all the above, complexity of pathfinding should be kept in mind but mapping is often about balancing the advantage of one thing over another and each situation must be evaluated on its own merits.

==AI Pathfinding around dynamic obstacles like dropped crates==

There is code for handling pathfinding around dynamic obstacles (such as moveables, crates, etc.) so there should be no need for the mapper to be concerned with those as AI should automatically avoid them.

==Viewing Pathfinding==

You can view where pathfinding is enabled in-game by binding _impulse27 to a key and pressing it in game. You can do this in the console as a temporary measure or bind it permanently in doomconfig.cfg, eg, to bind it to the keypad asterisk key...

bind "KP_STAR" "_impulse27"

When you press the key then the pathfinding areas are shown in wireframe. This is temporary and the display will time out after a few seconds. It also changes colour but the signifcance of the colours I do not know.

==Why ''func_static'' Brushes Anyway?==

If you need to surround static entity brushes with separate ''monster_clip'' brushes for AI pathfinding then why not just leave them as plain worldspawn brushes?

Often you do, but if you do convert a brush to func_static...

* You can add the property noshadows = 1 so that it doesn't cast shadows, improving frame rates.
* It avoids creation of millions of polys in certain situations where the engine converts a brush into loads.
* It reduces pathfinding complexity (see ''Preventing and Reducing Pathfinding Complexity in Select Locations'')

==Problems, Troubleshooting==

One mapper reported pathfinding broke down due to some monsterclip penetrating a visportal. Split in two either side cured the problem.

Others have said unsealed non-working visportals or ones crossed by func_statics also might cause pathfinding problems.

[[Category:Editing]]
[[Category:Tutorial]]

TDM Material Batch Conversion

2011-05-30T07:53:10Z

Fidcal: added new commands to handle single files and materials

=Introduction=

Some of the ambient rendering methods available in TDM require ambient stages in all the material definitions (see [[Virtual Ambient Light Textures]]). Since TDM 1.03, there are console commands that automatically converts materials to be compatible with all the ambient methods. '''tdm_batchConvertMaterials''' is used to convert batches of material files.
'''tdm_convertMaterialsFromFile''' converts all materials in one .mtr file.
'''tdm_convertMaterial''' converts one material within a file.

=Converting a single material=

To convert a single material use the command:

''tdm_convertMaterial''

Syntax:
tdm_convertMaterial <mtr-name> [forceUpdate]

Usage:
Converts specified material to support new ambient lighting.
Supports auto-complete for material name.
forceUpdate is an optional parameter, if provided, material with valid ambient blocks is forcefully updated again.

=Converting a single file=

To convert a single file use the command:

''tdm_convertMaterialsFromFile ''

Syntax:
tdm_convertMaterialsFromFile <mtr-filename> [forceUpdateAll]

Usage:
Converts all materials from a specified file to support new ambient lighting.
Supports auto-complete for filename.
forceUpdateAll is an optional parameter, if provided, materials with valid ambient blocks are forcefully updated again.

=Converting multiple files=

The command ''tdm_batchConvertMaterials'' analyses a defined number of materials and alters them according to the requirements imposed by TDM 1.03. Its console explanation reads:
<pre>
Usage: tdm_batchConvertMaterials <StartIndex> <nMaterials> [forceUpdateAll]
</pre>
''StartIndex'' is a number that defines at what material the command is supposed to start processing and ''nMaterials'' defines how many successive materials should be processed. TDM currently consists of about 9000+ materials, so one would probably go ahead and just run the command with the parameters: tdm_batchConvertMaterials 0 10000. The problem is that all materials are parsed into RAM which will eventually lead to '''malloc errors, when the RAM is full'''.

If ''forceUpdateAll'' is also set, the command will update all materials, independent of the results of the analysis.

The results of the command are stored in the folder of the currently installed FM, e.g. ''.../Doom3/thiefs_den/materials'', or in ''.../Doom3/darkmod/materials'' if no FM is installed. And in case you wonder, the materials don't need to be extracted from the pk4 archives prior to processing.

==Proper usage of the command==
In order to run the command without running into malloc errors, one has to successively execute it on different partitions of the materials. If you choose ''nMaterials=1000'' (which appears to be a good value), you'll have to start the command multiple times while increasing the ''StartIndex'' and restarting TDM after each execution (in order to free the memory again). Here is an example:

tdm_batchConvertMaterials 0 1000
*Wait for finish and restart TDM*
tdm_batchConvertMaterials 1000 1000
*Wait for finish and restart TDM*
tdm_batchConvertMaterials 2000 1000
...

Eventually the console will say "0 Materials processed and changed in total.", which means you're done.

=I followed the above instructions but still ran into malloc errors=
It may occur that you run into malloc errors, although the first executions of the command were successful. This is due to the fact that some materials are more complex than others and require more RAM for that reason. Remember the last ''StartIndex'' and re-execute the command with that index, but a decreased ''nMaterials''. Say for example, you received a malloc error after executing "tdm_batchConvertMaterials 4000 1000". You would now go ahead and do the following:
tdm_batchConvertMaterials 4000 500
*Wait for finish and restart TDM*
tdm_batchConvertMaterials 4500 500
...
After those two executions, you can actually try to raise ''nMaterials'' again to a higher value, in order to reduce the required user-input.

=Known issues=
* Can result in malloc errors. See section [[#Proper Usage of the command|Proper Usage of the command]].
* Can produce undesired results on [[DrVertexBlend (tutorial)|vertex blended materials]], e.g. one of the old ambient stages is not removed. Please double check respective materials.

{{textures}}
{{Texture Tutorials}}

Doors

2011-04-27T05:54:47Z

Fidcal: model doors now rotate relative to world axes. translate can no longer be used in combination with rotate.

{{todo}}
''Written by Fidcal'' ''edit Baddcog''

==Quick Summary==

Quick way to get an unlocked door in your map:

* Insert one of the prefab doors complete with handles and select its skin property and click the button to change its skin appearance to whatever you want. Set any other properties you need.

Alternatively,

* Create a door from the entity list
* Use the "skin" spawnarg on the door to change its appearance.
* Create a handle from the entity list
* Add the ''door_handle'' property to the door and give it the name of the handle
* To the door handle add the value frob_peer and use the name of the door.
* To open clockwise, change the ''rotate'' property from <code>0 90 0</code> to <code>0 -90 0</code>

==Introduction==

This tutorial explains how to put doors into your map using Dark Radiant, as well as adjust them and their properties.

The rest of this tutorial assumes that you have a basic understanding of using DarkRadiant. If you haven't done so, please go read the [[Dark Radiant Must Know Basic Intro]] article first.

Additionally:

* Up, down, left, and right in Dark Radiant's ''top'' orthoview are regarded here as the standard map directions of North, South, East, and West where useful for clarity.
* Where the term ''brush'' is used with a door it mostly also applies to a door made up of a group of brushes and/or patches.
* Where the term ''door'' is used it often will also apply to any object you wish to rotate when frobbed, for instance an openable window, box lid, or even more exotic objects that the imaginative mapper might conceive like a signal, engine part, toy, or whatever. So long as it needs to turn or slide just a fixed amount when frobbed then return when frobbed again then the following applies.

==Door types==

All tangible objects in Dark Mod are ''entities'', having either a pre-made model shape or else brush/patch(es). So there are two ways to create a door in Dark Radiant: as a model door or a textured brush door (or a hybrid of the two).

Models are ready made door objects but cannot within Dark Radiant (at the time of writing) be resized, rescaled, cropped or clipped whereas brushes are very flexible in that respect and can be worked into custom shapes for your map, including secret doors that blend into walls and other surfaces.

Most of the current door models are found in two places along with the door handles.
*Model Viewer: doors created from here will be static in the world and have no props other than material type.
You can add any props to them to make them working doors. If nothing else it is a good place to view the different size and skin options for the doors.
*Entity List: most of the door models can be found here. These doors have properties already assigned so they are ready to be used. Only one base door of each type is listed, create the size/hinge count door you want (2 hinge doors have a 'no hinge' skin). You can choose a skin for the door once it has been created in the editor with the "skin" spawnarg (use the model name of the door you want, taken from the model list, as its value). This is the easiest way to create a door. The same goes for door handles.

Remember also that door functions may be applied to objects other than doors for instance to openable windows, drawbridges, gates, in fact anything that needs a partial rotation or slide when frobbed then return when frobbed again such as a signal device. Lockboxes and chests use similar properties.

Door/handle prefabs seem to crash Doom3 when trying to reload a map so far now just create and link each door/handle. You can create one set and copy/paste them, but you need to take great care that all the name props are changed to match each clone. Otherwise you get handles that fly off with a distant door and handles that don't move.

==Creating a Door==

Put simply, to make a door you will be creating an 'entity with model' or 'entity with brush' or some variation thereof.

===Creating a Model Door===

There are several approaches to making a model door; the simplest is to create a door from the entity list; or create a door from the model viewer (good for static unusable prop doors).

'''Entity List''':

*Deselect everything in editor by hitting the Esc button
*Right-click an ortho view and select Create Entity
*Navigate to darkmod/movers/''atdm:door_...'', choose the door you want
*Click Add
*To change its appearance, add a "skin" spawnarg to the door, with the value being the model name of the door you want.

You now have a workable door in your level.

'''Model Viewer''':

* Right click in the orthoview, select ''Create Model'' then <code>darkmod</code> and select a door.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* Click [[Image:Button ok.png]] and you have a static door.
* If you want to make it work (openable, frobbable) then:
** Select the entity inspector,
** Select the top classname line so it highlights
** Select the func_static line in the input box ''below'' the properties window.
** Edit <code>func_static</code> to <code>atdm:mover_door</code>
** Click {{check}} or press {{key-enter}}

Alternatively you can do it the old way:

* Create any temporary brush
* Right click in orthoview and select <code>Create Entity</code> then <code>atdm:mover_door</code>.
* Left lick the model name line in the entity inspector.
* Below it on the ''Entity Inspector'' panel you should now see a button 'Choose Model'
* Left click it, select a door model from the darkmod group.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* The temporary brush was deleted.

In all three instances, you now have a working door with default properties.

Name your door by adding the prop (or modifing it) to name ''My_Door_1''. You can use any name that you feel is appropriate but all doors with handles attached ''must'' have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below).

To add a handle and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

===Creating a Textured Brush Door===

'''Tip:''' If unsure of size then you might insert a temporary human AI first to get a sense of height.

==== The simplest brush door: ====

* Drag out a new brush to the size required, eg, a seven foot high door is 84" x 1.1 = about 90 units in Dark Radiant.
* Give it a door texture from the texture browser (or wall texture for a secret door)
* Right click in orthoview and select ''Create Entity'' then <code>atdm:mover_door</code>
* You now have a default door that rotates around its center.

To move the rotation point to the door edge and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

==== Multi-brush doors: ====

More complex multi-brush doors can be created using the [[Clipper]] tool, CSG, etc. - this is not covered in this tutorial. Then assign <code>atdm:mover_door</code> for that whole brush structure. Also you can collect various brushes positioned together in relation to one another as needed, select them all, then assign <code>atdm:mover_door</code> for the group. All the brushes will be children of the <code>atdm:mover_door</code> entity and will rotate and be frobbable, etc. as one unit, as one door. To add further brushes or even model shapes later see the section on [[#Adding handles and other items to doors]].

Name your door by adding the prop (or modifing it) to name My_Door_1. You can use any name that you feel is appropriate but all doors with handles attached must have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below). (repeated from above in case you didn't choose to create a model door)

=== Double Doors ===
Double doors are automatically recognised by the code when the doors are spawned. The prerequisite is that both doors are sharing/touching the same visportal. The spawnarg ''auto_setup_double_door'' (which defaults to "1") will take care of setting up the open/lock peer relationship between the two doors. The doors will open/close and lock/unlock along with each other as a result.

What happens behind the scenes: the doors are adding each other to their internal open_peer and lock_peer list, which causes the double doors to perform the same action when frobbed or used.

Note that ''auto_setup_double_door'' will not set the frob_peer relationship, i.e. each door will frob-highlight on its own without highlighting the other door. You'll need to add that spawnarg manually if you want to highlight the entire double door as one.

==Customising and Adjusting Door Properties==

Handles, lockplates, etc. can be added to doors and door properties can be adjusted for rotation, sliding, locking, and more.

Some of the door models have hinge plates and lockboxes that are reskinnable with a good variety of skins.

===Door handles and other door attachments===

Summary: just add the property ''bind'' with the door's name to the attachment and position it where you want it on the door. If it's a ''atdm:mover_door_handle'' then it automatically will work as a handle but you can bind virtually anything.
You can add handles and other items to doors such that they move correctly with the door whether rotating, sliding, or both and even if the door is not vertical such as a skylight or trapdoor.
Handle models come in two types, ''single handles'' and ''double handles''. A single handle is one sided, this means the handle will be inside the door or outside the door, but not both. A double handle has a lever on the inside of the door and a handle on the outside of the door. Each has benefits.

*'''''Single door handles''''':
Single door handles can be used on a static door, a door that's just for show that no AI's or the player can use. In this case you should just create a door handle from the model viewer, it will be static and have no properties such as scripts. It is for looks only.

Single handles can also be used inside AND outside of the same door to save on rendering. Unlike the double handles the handle on the inside of a portal won't render. The curved handle is only about 130 polys per side, but if you have a large area and 10 handles you can save 1,000 polys from being rendered. Everything counts when it comes to performance.
I will call this ''multiple handles'', see more below.

These can also be useful on brush doors created in the editor that may be very thin or very wide.

*'''''Double door handles''''':
These are models have have a handle inside and outside. The bonus is that they only use one entity. Maps are limited to about 4,000 entities but when you count lights, AI, sound speakers, ect... you can run out of entities quickly on a large map. If you plan on building a large map this is the way to go, even in a small map they have benefits, namely that you only have to attach one handle per door.

Whether you decide to use a single handle or a double handle you must first follow the instructions below and attach one handle first. If you choose a double handle, follow the instructions below and you are done. If you choose a single handle type follow the instructions then also follow the ''multiple handle'' instructions for the second handle.

Both single and double handle types can be found in two places. The model viewer which will create a static model good for show, you can manually add props to make them work OR you can look in the entity browser.
Using a handle from the entity browser saves you a little bit of time as some props are already added, you just need to add the frob_peer names for the doors/handles and the door_handle name to the door.

=== Adding a working model door handle===

Quick summary:
* Create a model or brush handle and make it an ''atdm:mover_door_handle'' entity.
* Position it on your door. Use the opposite side from the door's multicolor X-Y-Z indicator (highlight the door to see it) if it's not obvious which side it goes on.
* '''Bind''' the handle to the door (bind <doorname>)
* It should now be a working handle though may need adjustments of rotation etc. see later.

Important: read preceding section on door handle types and performance issues first.

This works with both a model door and a brush door:

'''Rotation''':
* By default the door handle entity rotates ''anti-clockwise'' (looked at from the front) then springs back. A ''double handle'' model is OK but two singles (see ''Multiple door handles'' below) need more care as only one is the functioning entity and the other is just attached to it. So anti-clockwise is fine for a door with its hinge on the left and the handle on the right - the handle will rotate down then spring back. If you put the functioning door handle on the other side you will have to change the default ''rotate'' property from -45 0 0 to 45 0 0. '''''Therefore it is easier to generally put this handle on the side of the door where the hinge is on the left and the non-functioning attachment handle on the other side.'''''
*If your door only needs one handle, eg, a cupboard door, and from outside its hinge is on the right then you will need to change the ''rotate'' property of the handle as described above.

'''''The functioning handle entity:'''''
* Create an entity door handle (movers folder) or create a brush or model handle and assign it the entity ''atdm:mover_door_handle''.
* Position it where you wish on your door.
* '''Bind''' the handle to the door, by adding the "bind" spawnarg to the handle.

You now have a working door handle with default properties.

*'''Multiple door handles''':
Now that you've got a handle attached to one side of the door it is time to add one to the other side (unless you used a double handle).
* Create the new handle. The single handles come in left and right persuasions. A door needs a left facing handle on one side and a right facing handle on the other, so if you have already added the left handle create a right handle and line it up on the other side of the door.
* Name this handle. I prefer to keep a naming convention for each door and it's respective handles, it makes things alot easier. The door is named '''My_Door_1''', the first handle is named '''My_Handle_1''' so name the second handle '''My_Handle_1_1'''. This will make it stay with the first handle in the entity list. This is important to keep organized. If you name it My_Handle_2 then when you get to another door named My_Door_2 you'll be confused.
* Place and '''bind''' that handle to your door.

You now have two single door handles on either side of the door that rotate together as if they were physically attached.

'''To add a brush to a brush door''':
* Select the new brush ''and'' the brush door all together; ''the entity '''must''' be selected '''last'''.''
* Use {{menu|Edit|Reparent primitives}}. This ensures the parent entity adopts the new item(s).
* If you have trouble selecting them in the orthoview because other brushes, etc. get selected then try in the camera view or as a last resort move them temporarily to an open area (but keep them in the same positions relative to each other.) Use {{key-shift}}+{{LMB}} on new item(s) then {{key-shift}}+{{LMB}} on main entity. Once they are all selected, use the {{menu|Edit|Reparent primitives}}.

'''To add ''model'' static items''': knockers, hinges, static handles etc. to a ''Model Door'':
* Select item
* Right click in orthoview and select ''Create Entity'' then <code>entity func_static</code>
* Position it where you wish on your door.
* To synchronize this with your particular door you need to add the property ''bind'' and the individual door name to the brush entity. To do this...
** Select the model door.
** In the entity inspector, select the ''name'' line
** Select the bottom line in the input box ''below'' the properties window.
** Copy the name
** Deselect the door with {{key-esc}}
** Select the brush entity
** Add a property "bind" to it.
** Change the value of the property by pasting in the door name
** Click {{check}} or press {{key-enter}}

'''To add ''brush'' static items''': knockers, hinges, static handles to a Model Door:
* This method is not ideal but it seems to work OK.
* Select the brush.
* Right click in orthoview and select Create Entity then ''atdm:mover_door_handle''
* Position it where you wish on your door.

To synchronize this with your particular door you need to add the property ''door_handle'' on the door, and give as the value the name of the brush you just created.

This brush turns like a handle. To stop it:

* Adding ''rotate 0 0 0'' or disabling the handle script won't help.
* Add a real working handle (as in the section above ''To add a working model door handle...'' and it must be added LAST.)

If you don't want too see a real working handle added maybe try another tiny brush with the handle function and hide it inside the door?

===Locking Doors===

To lock a door check the ''show inherited properties'' in the entity inspector for a ''atdm:mover_door'' entity and you should see the ''locked'' property. Select it and in the input box below the properties you can change its value:

* 0 = unlocked (default)
* 1 = locked

If locked it will require an entity that is associated with it to be able to act as a key to unlock it.

Currently door handles on locked doors will rotate when frobbed, they will bounce back though and the door will stay locked until unlocked.

===Keys===

Assigning specific keys to specific doors is simple.

* It is recommended that you create an existing key entity. These keys have all required props, they just need to be named.

Alternatively you can create a key from the Model Viewer and want it to be useable
* Make sure it has the properties:
useable 1 [so it can be used by the door]
frobable 1
inv_name <unique name>
inv_category Keys
inv_target player1
inv_icon guis/assets/hud/inventory_icons/<icon name>
inv_stackable 0 or 1 where 1 can be used on all copies of the same key so they show as one entry in the inventory with a total.

Add to the door the property <code>used_by</code> with the name of the key as the value. Multiple keys can open the same door by using several <tt>used_by</tt> spawnargs:

"used_by" "doorkey_1"
"used_by1" "doorkey_2

==== Keys carried by AI ====

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see [[Attaching Props to AI]].

*"def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
*"pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
*"name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
*"set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
*"set name on door_key" "door_key" //here it gets a name to be used in the map in general.

updated by bikerdude.

====Master Key for Testing====

By default, ALL locks can be opened by any key named ''key_master''. Just create a key in your map, name it ''key_master'' and it becomes a master key for use while testing. Add inv_map_start 1 to it so it is in the player inventory at game start. Remember to delete it when your mission is finished.

===Lockpicks===
''by Baddcog''

There are two lock pick types.
*'''s'''=snake
*'''t'''=triangular

A lock can be set with many pins. Each pin has a click sequence and each needs a designated lockpick type (see above). Keep in mind that the lockpicking in The Darkmod is much more involved than in T2 or T3. The player has to listen to sounds or watch a handle or lockbar to know when a lock is pin is picked.

This means that authors can be very evil and really frustrate the player, in which case their missions will probably not be played. So be nice to the player and don't waste your time. Use simple locks for the most part and save complicated locks for important sections and to build tension. Don't make the player have 20 pins to pick all with different lockpicks. In most cases 1 or 2 pins will suffice and it isn't necessary to use both lockpicks on every lock.
Also try to include a lock lever on lockboxes or chests, door handles will rotate as the pins are being picked. This gives the player visual clues to help with the picking (and essential in noisy environments where you can't hear the clicks.)
IMO this system is a huge leap foward for lockpicking but also has the ability to completely frustrate the player as stated above. Keep this in mind when designing your lockpick systems.

These props go on the door itself, or the lid of a chest, eg,
*'''lock_pins''' 1327
*'''lock_picktype''' stts

The lock_pins property specifies how many pins each lockpicktype has.
The lockpick_type property specifies how many times the player has to switch picks and which pick they have to use. You can see there must always be an equal number of lock_pins and lock_picktypes specified

So looking at the example above we have lockpick_type s(snake), t(triangular), t(triangular), and s(snake). The player will have to use these lockpicks in this order. Once the snake lockpick's pins are open the player can advance to the triangular pick and so forth.
5 is added to every click sequence so 5 is the minimum click pattern even if you set it to 0.
In the example above the lockpins specify in order which pick types have how many pins, so the s pick has 1 + 5 = 6 clicks, the t pick has 8 and so on.
The above is a difficult lock and to avoid annoying the player it is best only used rarely on a special lock like an important big vault door. Ordinary footlockers and common doors can be just 1 or 2 click sequences, eg, lock_pins 2 and lock_picktype t means the player uses one pick and listens for the end of one sequence of 7 clicks.

lockpick_rotate - is placed on the door. It is the amount the visible rotating handle or pin rotates while picking. For a rotating handle or lockbar normally ignore this and leave the default. During lockpicking it oscillates and progresses to the normal full turn of the handle. Example 0 45 0.

lockpick_translate - is placed on the door. It is the amount the visible handle or pin moves in a straight line while picking. Use this if you have eg, a lockbar that you want to move in a straight line and not rotate, eg sliding catch. Example 0 -5 0

By default, doors are pickable. If you don't set up the above lockpick spawnargs then it can't be picked. So there is normally no need to enable lockpicking - just set up the above spawnargs. There is a ''pickable'' spawnarg set to 1 by default. If set to 0 then the door becomes unpickable. But hard to think of an application except in testing or perhaps a special custom situation where it is switched by script perhaps.

===Open, Partially Open, or Closed Door at Game Start===

By default, doors are closed at game start. If you want a door to be already open or partially open then do the following.

'''Note well: Create all doors in their ''closed'' position. Adjust as follows and they will automatically be at the open position when game starts.'''

Already Open Rotating Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and tick the check button
* The door will now be fully open at game start.

* If you want it only partly open:
* Make sure its ''open'' property is set to 1 as above.
* Right click the entity inspector and select ''add property''
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* scroll down, select ''start_rotate'' then click {{ok}}
* This adds it to the property list.
* Now select ''start_rotate'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the angle you want in the same form as described in the ''Rotate Direction and Open Angle'' section. So for example, to have a door that has a fully open default ''rotate'' value of 0 90 0 to start only half open you would give it a ''start_rotate'' value of 0 45 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

Already Open Sliding Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and click {{check}} or press {{key-enter}}
* The door will now be fully open at game start.

* If you want it only partly open:
* Right click the entity inspector and select ''add property''
* Make sure its ''open'' property is set to 1
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder.
* scroll down, select ''start_position'' then click OK. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* This adds it to the property list.
* Now select ''start_position'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the position you want in the same form as described in the ''Sliding (Translation) Amount and Direction'' section. So for example, to have a door that has a fully open default ''translate'' value of 0 50 0 to start only half open you would give it a ''start_position'' value of 0 25 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

===Rotation Centre, Pivot, Hinge point===

The centre of rotation of a door is at the origin point of its entity and the door rotates with reference to the orientation of that origin point, not the world map. See ''Rotate Direction...'' for more about that. This section only deals with the ''position'' of the rotation centre in the door.

Model Door Centre of Rotation: 
The centre of rotation of a model door cannot be changed within Dark Radiant. Because a model door rotates around the centre 'spine' of its back edge this will cause clipping (penetration into solid) as in this example (where the door is set to open to 89 degrees for clarity): [[Image:modelClipping.jpg]] So care is needed with placement. You will not normally position a door right next to a wall as in the example but against a shallow frame so clipping will barely be noticeable but either way it can be fixed. You can correct it by adding a translation (see ''Sliding (Translation) Directions'') value of half the door width in the direction of the door handle. This will gently move the door out as it rotates to clear any solid on that side as in this diagram: 
[[Image:DoorClip.jpg]] 
Half a door width will typically be about 2. Any 'attachments' such as door handles will still synchronize with the door movement whether the door is rotating, sliding, or both.

Brush Door Centre of Rotation: 
The centre of rotation of a brush door ''can'' be changed. The default origin point of a brush is at its centre. Therefore a default rotating brush door will rotate around its centre when you first create it. So, mappers will commonly need to move that rotation point to a corner or even to some other offset position for example, for an openable window using the door function.

Put simply, to move the rotation point of a brush door you need to move the entity origin relative to the brush(es.)

Moving the entity origin (centre of rotation) relative to a brush door:

* Select the brush door
* Select ''Vertices mode'' (default shortcut key is {{key|name=V}} or button on top toolbar 'Select Vertices')
* Drag the door's entity origin to the point where you want the door to rotate. This should be on the corner on the leading edge side (the side to where the door is opening.) to avoid clipping as in this diagram....
[[Image:getCorner.jpg]]
* You should now find that door rotates around that point.

===Rotate Direction and Open Angle===

By default, rotating doors open anti-clockwise (viewed from above) by 90 degrees from the start orientation. If you want to change this edit the ''rotate'' property in the entity inspector. Don't confuse this ''rotate'' property with the ''rotation'' property. In the entity inspector remember that to see the inherited rotate property you must check the box 'Show inherited properties'.

The three values shown in the rotate property are degrees from the closed position around Y Z X (absolute map axes Front, Top, Side views in DR's ortho view.)

* Positive Y = Open clockwise (Dark Radiant grid front view, looking north)
* Negative Y = Open anti-clockwise (Dark Radiant grid front view, looking north)

* Positive Z = Open anti-clockwise (Dark Radiant grid top view, looking down)
* Negative Z = Open clockwise (Dark Radiant grid top view, looking down)

* Positive X = Open anti-clockwise (Dark Radiant grid side view, looking west)
* Negative X = Open clockwise (Dark Radiant grid side view, looking west)

There is a problem when you come to rotations that are not around the main Y Z X axes of the map, for instance a drawbridge that lowers down to the south east. You might think you can combine Y Z X values to get the result you want - and this can be done (for south east use 45 45 90) but it is a bit of a kludge and the drawbridge twists eccentrically as it lowers (though it arrives correctly!)

The values are in the range -179 to +180. Positive values give an anti-clockwise opening rotation (looking down from above) and negative values give a clockwise opening rotation. The value 180 is unique in that it continues in an anti-clockwise rotation when closing rather than returning clockwise so might be used if you can think of some object that might need such a motion when frobbed!

Edit the rotate value by selecting it and using the input box at the bottom and clicking the check(tick) button. That will change the angle the door will open to. Note that the line with the original default of 0 90 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Examples:
* 0 90 0 = Opens anti-clockwise round the entity's 'vertical' to 90 degrees - typical default vertical door.
* 0 0 90 = Lowers a drawbridge from the entity 'vertical' to horizontal.
* 0 0 -45 = Opens clockwise by 45 degrees viewed from the east side. This might suit a skylight in a sloping roof.

'rotate' cannot be combined with translate motions (see [[#Sliding (Translation) Amount and Direction]]) in one door; you need to bind one door to another and link they by targetting one to the other. By that means you can produce exotic and useful motions. A door opening against an upward-sloping floor can thus have a ''lifting hinge'' and raise up slightly to clear the floor; a door can rotate towards you and slide back to one side very effectively.

===Sliding (Translation) Amount and Direction===

By default a Dark Mod door will rotate open. For most sliding doors you want to stop them rotating as well as make them slide. You cannot delete (remove) the ''rotate'' property - you have to set the ''rotate'' property to 0 0 0 to stop a door rotating (see ''Rotate Direction and Open Angle''.)

Now edit the ''translate'' property value by selecting it (remember to have inherited properties box checked) and using the input box at the bottom and clicking the check(tick) button. That will change the distance the door will slide to. Note that the line with the original default of 0 0 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Typically (but not always) you will want your sliding door to slide the width of the door. The three values in the translate property by default are 0 0 0 and are X Y Z ''absolute map'' values (irrespective of door orientation) where:

* Positive X = Slide East (Right side of Dark Radiant grid in top view)
* Negative X = Slide West (Left side of Dark Radiant grid in top view)
* Positive Y = Slide North (top of Dark Radiant grid in top view)
* Negative Y = Slide South (bottom of Dark Radiant grid in top view)
* Positive Z = Slide Up (Top of Dark Radiant grid in side views)
* Negative Z = Slide Down (Bottom of Dark Radiant grid in side views)

So for a 50 unit wide door you want to slide fully to the east you would use 50 0 0 for the translate property values. A 100 unit portcullis sliding vertically up would need 0 0 100 to be fully raised.

=== Doors Collision/Push Behaviour ===
Doors are pushing all entities by default, except for the player. Doors will also stop moving when anything blocks their movement. However, this default behaviour can be changed by setting the according spawnargs:

Set '''push_player''' to '''1''' to let the player be pushed by this door:
"push_player" "1" // Push the player too (default is off)

By default '''stop_when_blocked''' is set to 1 and if a door is blocked by an entity then even if the entity is removed afterwards, the door stays still. The next frob will close the door.

Set '''stop_when_blocked''' to '''0''' to prevent the door from ending the opening sequence when anything blocks its way. It will still pause - but continue to open if the block is removed.
"stop_when_blocked" "0" // door keeps moving after being blocked (default is off)
With this setting, doors will still stop at blocking entities (the player, for instance), but will continue to move when the entity clears the way.

There is another spawnarg which stops a door pushing a moveable. Apply this to the ''moveable'' not the door...

"notPushable" "1"

===Door Sounds===

The sound of doors opening and closing is set in the snd_open and snd_close properties. You can silence them by setting the following properties as shown:

''snd_open nosound'' 
''snd_close nosound''

Don't just use a dash - as it seems to cause a sound of its own.

The above sounds are triggered as the door begins to open (eg, unlatch sound) and when it finally closed (eg, slam.) For special doors that need an on-going sound, eg, a big stone slab that moves slowly, then use:

''snd_move''

''snd_locked'' 
The sound played when a player tries to open a locked door.

''snd_unlock string'' 
The sound played when a player unlocks a door.

===Sound Propagation through Doors and Doorways===

The sound volume reduction to the player (ie, the sound the player hears) is fixed and constant in a cvar which adds a distance factor to the original sound. It is recommended that you do not change that because it will affect other FMs. Currently there is no way to change the way that sound to the player is reduced through doors and doorways.

Sound propagation to AI, eg, impact sounds or guard yells is treated separately:

Sound propagation to AI relies on visportals. For details study [[Sound Propagation: Part 1]] and [[Sound Propagation: Part 2]] as well as [[Visportals]] This tutorial will just cover the relevant sound and sound propagation ''properties'' of doors. If you set the ''show inherited properties'' box in the entity inspector you can see them as described here.

Remember, the following have no effect on what the player hears through a door or doorway.

''loss_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through an open door. (default 1dB)

''loss_closed'' 
Drop in sound volume in dB propagated to AI (not player) when going through a closed door. (default 15dB) You would want to set this very high to block all sound with a thick door but very low for a barred gate for example.

''loss_double_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through double doors when only one is open. (default 1dB)

There are also various sound properties for lockpicking: 
''snd_lockpick_pin_1 through 14'' and ''snd_lockpick_pin_success''

===Speed of Door Opening and Closing===

Rotating Door Speed: 
At the time of writing, the time a rotating door takes to open or close is set in the ''move_time'' property whatever its maximum open angle. So with rotation set at say 150 degrees the door just opens faster than at say 80 degrees. This is likely to be changed to a constant angular velocity so check to see if there a new property added if the following no longer works. The problem is that if an interruptable (see Extra Notes) door is frobbed while in motion it stops; another frob will reverse the motion - so even if the door is only open a crack it will still take the full time to close and vice versa.

To change the time a rotating door takes to open or close, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''move_time''
* Edit the second line of the input box ''below'' the properties window to the time you want.
* The time is in seconds and decimal fractions can be used.
* The default is 1 second and if set to this then the door opens and closes in one second whatever the maximum open angle, great or small.

Sliding Door Speed: 
The speed of a sliding door is set in the ''translate_speed'' property. To add this, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''translate_speed''
* Edit the second line of the input box ''below'' the properties window to the speed you want.
* The speed is in Dark Radiant grid units per second.
* The default is 0 and if set to this then the door slides open in one second whatever the distance, great or small.
* CAUTION: If you later change the door back to a rotating door then delete the ''translate_speed'' property or ensure it is set to 0 as (at the time of writing but this will be fixed) a bug makes rotating doors open and close instantly. (Note: you can still mix sliding with rotating but check - this bug might only be if ''translate'' is set to 0 0 0)

===Visportals and Doors===

A visportal face surrounded by solid at its edges and in contact with a door is closed when the door is closed and enabled when the door is open. In most cases you will place a visportal in contact with a working door unless you can see through the door (such as a true glass door or barred gate.) For full details see [[Visportals]].

==Auto-Closing/Opening Doors==
Doors that automatically close after being open for some time are easy to setup: Each frobmover entity supports these spawnargs:

;"auto_close_time":Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
;"auto_open_time":"Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

Old text:

Note that auto-closing doors and AI closing doors behind them, is very much work in progress at the time of writing, so for now, this is another method that works. Check first if true AI closing of doors is working yet before bothering with this!

I have one door that I particularly want the AI to close as there is a bit of frame lag inside if not. So I set this up and it works good as an auto-closing door - not as good as a true AI closing door as it will auto close when the player goes through as well but it does look very effective to see AI going through and closing the door behind them. Not tested exhaustively so I don't know if there could be any downside. Here's what to do....

First a quick summary to make it more clear:

'''''A trigger_relay is used both as a relay AND carries a stim. We put the trigger_relay with its stim in the path of the open door. The door has a response property. When it opens and contacts the stim its response is to send a signal back to the relay. The relay pauses then closes the door...'''''

* First, optionally give your door a suitable name like autodoor1, whatever.
* Copy that name to the clipboard.

Next we need a relay with a delay:

* Create entity > darkmod > trigger_relay

* Place it roughly at the position the door will be at when open and to be on the safe side 3/4th of the way to the far end of the door (not the hinge end) to give max distance from the close door.

* Add the property 'target' and paste in the door name you just copied.

* Give the relay itself a name, eg, autoDoor_relay_1, and copy that name to the clipboard, you'll need that too in a bit.

* Add the property delay and the value 3 - this is the delay in seconds before the door will close; 3 seems about right but 2 might be worth a try because to that 3 is added a random value between 0 to 0.5 seconds from the Time Interval we entered for the stim firings.

* Add the property 'wait' and the value 3. This is the time before it can work again in seconds. If you set it too low then in theory the door might trigger again but in this situation I don't think it's possible. Too long, eg, one minute, and it won't work if the AI goes back through the door before then. If this value is -1 then the whole thing will only work ONCE so might be used for an AI who goes through once, closes it behind him, but you don't want it to be an autodoor thereafter.

That's the relay, now we add a stim to it:

* Still with the trigger relay selected, go to {{menu|Entity|Stim/Response}}

* Custom stim tab.

* Click Add stim type, select the new custom stim type you just made at the bottom of the list and type in eg, autoDoorStim at top right in the input box.

* Click the stim tab and the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Select the new autoDoorStim in the list and on the right you need only type in the radius box 15.0 There is quite a lot of room for error. I had it working on 10 and also on 25. The value should be less than the distance to the closed door else it will trigger open! But no so small that the door might not reach it.

* Select the check box for Time Interval and enter 500 (millisecs.) This is so it doesn't keep firing more frequently than is necessary. This stim will be firing all through your mission whether the door is used or not so if you had dozens of these then maybe it would affect performance. Too big a number and there may be a long delay before the door shuts - but it will be random depending on the next time the stim happens to fire. We'll control the delay we want more precisely later.

* Click {{ok}} to confirm it.

That's the stim set up, now for the response to it which is put on the door....

* Select the doorm, then use {{menu|Entity|Stim/response}} and select the response tab.

* Click the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Right click in the big ''Response Effects'' box on the bottom right of the panel.

* Add New Effect and you should get a default 'Activate Response' response added to the list. Double click it.

* In the Effect selector at the stop select 'Trigger'

* in the Target box, paste in the name of the relay you copied or you can select it from the list at the little arrow.

* Leave the Activator box empty.

* Click {{apply}} and then {{ok}} on the main S & R panel bottom right.

It should now work. No need to wait for an AI, just frob the door and watch it close itself. If not, check the position of the stim brush is close to where the door stops when open.

==AI Door management==

See also [[#Keys_carried_by_AI]] above.

By default AI will open doors and close them behind them. Here are some spawnargs the mapper can use to modify that behaviour:

;"ai_should_not_handle" :If set to 1, AI will not attempt to handle it and add it to the forbidden areas when closed (so that it doesn't try to path through). They might still walk through the door when it is open though. Useful if you have some special use door that you don't want the AI to operate.

;"ai_should_not_close" :If set to 1, AI will not close the door behind them unless it obstructs them.

To get AI to unlock/relock specific doors there are two methods currently:

1. add the following spawnarg/value to the AI:

;"can_unlock1" ''<doorname>''

'''Do NOT use can_unlock_1.'''

For additional doors on the same AI use ''can_unlock2 doorname'' etc.

2. In the editor position an actual key that works for that door on the AI and also add to the key bind <AIname> and also bindToJoint LeftHips_Dummy (see other joints names elsewhere in wiki.) Currently, if the player pickpockets the key then the AI seeks an alternate route but otherwise does nothing (?) This may be upgraded in the future to better strategies.

3. There is the possibility in the future of an additional method which would just use special attach spawnargs to make the above easier. The key would spawn at the correct position at game start. Watch this space.

'''Door handling positions'''

It is also possible to set custom door handling positions for the AI. This is especially useful when the standard routine that lets the AI choose their standing positions while opening and closing the door fails, leaving them circling around in front of the door helplessly.

Place a movers > atdm:door_handling_position entity where you want the AI to stand while opening/closing the door from this side.(it can be found in the movers folder in the entity chooser)

On the door, you need to set the spawn arg "door_handle_position" "name_of_door_handling_position" You can also place a door handling position on each side of the door, the AI should automatically choose the right one. In this case, you need to set spawn args with "door_handle_position_1" etc and the corresponding names of the door handling position entities on the door.

The door handling positions can also carry spawn args that define the behaviour of the AI, which are useful for example for doors that can only be openend or locked from one side:

'''"ai_no_open"''' If set to true, the AI will not try to open the door from this side (but still walk through when the door is already open)

'''"ai_no_close"''' If set to true, the AI will not attempt to close the door from this side

'''"ai_no_unlock"''' If set true, the AI will not be able to unlock the door from this side, but still use it when it is not locked.

'''"ai_no_lock"''' If this is set true, the AI will not lock the door from this side.

==Doors as Triggers==

''by Ishtvan & greebo''

Doors (or any binary frob mover, buttons, levers, etc) now have the option to trigger their target on closing or opening. (For definition purposes, a button is defined as "closed" in the state when it starts out and "open" in the state you press it down to. I know that's a little non-intuitive, but it came from deriving from doors).

New spawnargs on frob movers:
;"trigger_on_open" :If set to 1, this binary mover will trigger its targets when it starts out completely closed and is opened.
;"trigger_when_opened":If set to 1, this binary mover will trigger its targets when it is completely opened. Code defaults to 0.
;"trigger_on_close":If set to 1, this binary mover will trigger its targets when it completely closes after being open.

==Skins: A Wide Variety of Door Textures==

This is to remind you that as with many Dark Mod models, there is a wide range of extras skins (textures) available for door models. There are now several basic door entities of different sizes so choose your size first. Then enter the spawnarg: skin with any temporary value. Now select it and click the skin button at the bottom of Dark Radiant's Entity Inspector and you will find a large of range of skin textures from which to select to give you a choice of appearances for your door.

==Extra Notes==
The property ''interruptable'' determines whether a door can be stopped by frobbing while it is opening or closing. So by frobbing then frobbing again, the player can open a door to any position, eg, slightly ajar to peek through.

''func_darkmod_door'' is no longer used (just in case you come across it in the Dark Mod forums or wiki.) The Doom func_door is still available but for Dark Mod, but <code>atdm:mover_door</code> is the entity to use.

{{tutorial-editing}}

Conversion of Game Units

2011-04-12T14:49:12Z

Fidcal: I removed my tip section because it was totally wrong

{{Things-To-Remember|1=1.1 Doom units = 1 inch}}

See also: [[Limits, Max, Min, Stats, etc]].

== Blender ==
To match Blender's grid with the Radiant grid, go to "View"->"View Properties"->"Grid:Spacing" and set it to '''10'''. This matches the DarkRadiant grid set to "1". Usually it's better to just turn on the edge length rendering: (Buttons view: '''Mesh Tools 1 > Edge Length''') to see how large the objects really are.

== Discussion notes ==

{{Original_Reference|Fingernail, Ishtvan, Demigod|1774}}

* 1 DromEd unit is roughly 1 foot.
* 1 DromEd unit is roughly 12 UnrealEd units.
* 1 Doom Unit is approximately an inch.

Demigod found that 90 doom units = 8 dromed units. It may feel slightly to small height wise but in third person looks spot on.

The average dromed door being 8 by 4 units or 90/45 doom3 units. All the conversion I've done on this map so far uses 90/8*dromedsize = doom3 size.

Note by Ishtvan:
* 1 Doom unit is supposed to be exactly 1 inch (I've seen in the code where it says "Doom to meters: 0.0254").
* 1 DromEd unit is I guess approximately 1 foot, so it should be approximately 12 Doom units to 1 DromEd unit.

Note by Springheel:
* Despite what it says in the code, the agreed upon standard is that 1.1 Doom units basically equals 1 inch. This and looks best in game.

This scale makes 1 Doom unit equal to 2.309 cm.

[[Category:Editing]]

AI Relations (Editing)

2011-03-10T08:53:03Z

Fidcal: /* Changing Team Relationship Info in the Editor */

{{Original_Reference|Ishtvan|1636}}, ''additions by greebo & fidcal 2009-03-13''

==AI Types (Teams)==

Different AI types are defined by their '''''team''''' property. Put simply, AI on one team will generally be friendly to each other and antagonistic to AI on some other teams and tolerate yet others. Some AI teams are passive and will flee; others will attack. These are the default values for the '''''team''''' property and their team type:

* 0 = player
* 1 = builders
* 2 = city watch, houseguards
* 3 = nobility, commoners
* 4 = inventors/engineers
* 5 = street people, beggars
* 6 = criminals
* 7 = pagans
* 8 = mages
* 9 = revenants, zombies, skeletons
* 10 = ghosts
* 11 = werebeasts
* 12 = spiders & spider queen
* 13 = belchers
* 14 = rats & other passive animals
* 15 = elementals
* 16 = steambots

Mappers can change the team of individual AI entities by setting the ''team'' property to a new value but this is generally for special situations where for example, an individual(s) from one team is meant to have 'joined' another group. But to change the relationship ''between'' teams, eg, two normally friendly teams become enemies or vice versa, see the following sections.

== Definition of Relationship Types ==

The three types of relationships are ''Friends, enemies, and neutrals''. When assigning relations they take the values 1, -1, and 0.

* '''''1: Friends''''' will
** come to the aid of another friend who is alerted.
** commence searching or attacking in that friend's vicinity or flee depending on AI type.
** Be alerted if finding a body of a friend.
* '''''-1: Enemies''''' will
** Attack other enemies they become aware of.
** Ignore other enemy and neutral bodies
* '''''0: Neutrals''''' will
** ignore calls of distress from those they are neutral to.
** Ignore all bodies they are neutral to.

== Default Relationships ==
Even if you're starting your map from scratch, at map start the game will always load a set of default relationships from the entityDef '''atdm:team_relations_default'''. Any relationships not defined in there are automatically made enemies ''between'' teams and friends ''within'' teams (members of Team 2 are friendly to other members of Team 2).

In addition, any relations defined within '''atdm:team_relations_default''' work both ways. So if Team 1 is set to regard Team 2 as friendly then Team 2 also regards Team 1 as friendly. '''''Note that this only true for these definitions that are read in from the default file and not for any custom definitions.'''''

You can view this set by opening the <tt>tdm_team_relations.def</tt> file, but '''do not alter''' these values. See the next section about how to specify custom team relations.

Here is a summary of default Dark Mod team relationships:
* All are friendly to others within their own team.
* Builders are friends to 'normal' humans but neutral to beggars, criminals, pagans, mages.
* Guards are friends to 'normal' humans, pagans, and mages but neutral to beggars, criminals.
* Other 'normal' humans are friends back to builders and guards
* Beggars are neutral to all including the player but not monsters.
* Criminals, pagans, and mages are neutral to all except the player and monsters.
* All monster teams are neutral to each other.
* Rats and any other passive animals are neutral to all.
* Elementals are enemies of all.

== Changing Team Relationship Info in the Editor ==
The default Dark Mod team relationships cover normal situations so the mapper usually need do nothing about them. In special situations you might need to change relationships between teams. This can be done both at map start and dynamically (see [[#Changing Relationships during the Game]]) changed during play.

To specify changes to the default relationships at the start of your own mission, create an entity '''internal > atdm:team_relations''' in your map. (A small rectangular entity will show up.) Override certain default relationships by adding spawnargs to this entity in the following way:

"rel 0,2" "1"

The left-hand key holds a pair of numbers defining the team numbers the relationship refers to, the right-hand value holds the type of relationship. Read this spawnarg like this:
''Team '''0''' considers Team '''2''' as '''friendly'''.''
As you might suspect, the right-hand value has the following convention:
* Negative (value < 0): '''hostile'''
* 0 is '''neutral'''
* Positive (value > 0): '''values'''

{{Important|headline=Important|text=The above spawnarg does '''not''' imply that team 2 regards team 0 as friendly too. This has to be specified explicitly, defining the asymmetric matrix element.}}
To define the relationship for the reverse (team 2 => team 0), add a spawnarg like this:
"rel 2,0" "1"
Note that it is indeed possible to define a different relationship for 0 => 2 than for 2 => 0. Also, it's possible to define the relationship between members within a team itself, like
"rel 2,2" "-1"
This lets members of team 2 consider all members of the same team as hostile (see [[#Why change relations within a team?]]

One small note about the '''atdm:team_relations''' entity: this entity will pass its spawnargs to the relationship manager at spawn time and remove itself immediately afterwards, so that you don't have an unnecessary entity floating around your map.

== Why change relations ''within'' a team? ==
It might seem weird to define a team's relationship with itself by setting "rel 1,1" to something, but later on we might want to have a "rogue team," like beasts that attack everyone, even other members of the "beast" team (eg, a cannibalistic predator or something). Also, the team's relationship with itself can be thought of as "morale," and we can maybe check this number to see how likely they are to come to each other's aid in combat and stuff like that.

Just to emphasize, you don't normally change the default friendliness of team members for each other but only in very special situations. If you want team X "every man for himself" and attack its own members, set "rel X,X" explicitly to a negative value.

== Changing Relationships during the Game ==
To let relationships change during runtime, you can use triggers or scripts. There is a trigger entity called '''target_tdm_setrelations''' which can hold the same type of relationship spawnargs as described above. To activate these settings, just trigger this entity. Note that you can even trigger this entity multiple times, so you can re-use it, if you ever wanted to.

If you're switching teams to friendly, remember to define both directions of the relationship on these types of entities ("0,2" as well as "2,0").

== What happens if a Team is not mentioned at all? ==
If an AI is present in the map (or maybe is spawned by script later during the game), whose team is not mentioned in the matrix (like, say, team 60), the relationship code will handle this gracefully and consider this team as hostile to all the other teams. Still, members of team 60 are friendly to all other members of team 60 by default.

== Debugging Relationships ==
Use the following console command to dump the current values of the relationship matrix to the console:
tdm_ai_rel_print
This will produce a rather long list, so you might want to use the <tt>condump</tt> command to write the console output to a file for later studying.

Also, watch out for console warnings during map start, which might indicate syntax errors of your spawnargs. Finally, it's also possible to use the log file. Activate the AI log class to see any messages coming from the relationship code.

== See also ==
* [[AI Relations (Scripting)]]

[[Category:AI]]
[[Category:Editing]]

Grass Edges

2011-02-22T19:07:49Z

Fidcal: /* Basic grass edge for all three grass types */

===Introduction===

''written by Fidcal''

This is about the grass edges, patches, and paths textures in update 1.03.

These are all textures under nature > grass > grass_edge.

I've not done prefabs at this time and I'm not sure it's worth it. The final versions consist of three types:

===Basic grass edge for all three grass types===

This is an endless 2-sided grass strip that you overlay over the hard join between grass and any other surface. You need to scale it approximately to the same as the grass but it does not need to be aligned with the grass particularly as its grass edge side blends in. You only need align the visible grass edge where you want it. There is a lot of space on this 1024 x 1024 tile, virtually half. This makes it easier to align (I tried using a 1024 x 512 tile without the space but however I adjusted and tweaked it was a nuisance to align.) You can also use this edge up against a wall by bevelling that edge a tiny amount up the wall. You can see many examples in the little courtyard in Biker's St. Alban's cathedral.

It's simple but hard to explain. Here is a guide: A summary would be create a long north south patch the same scale and alignment as your grass and give it the grass edge decal texture you want (making sure the white grass runs down the middle of the patch) then turn and move it to overlap the edge between your grass and any other surface. The patch needs to be a func_static with the property shaderparm3 and value 0.01 (thin) to 0.99 (thick) (0.5 is normally fine.)

* You start with a grass-textured surface and any other surface side by side, let's use dirt and dark grass as an example.
* So you have a straight hard edge between them.
* Select one of the surfaces.
* Menu > Brush > Create Decal Patches
* If this is flush with the surface (depends on your setting) set grid size 0.125 and raise the patch just clear.
* Leave the texture as _default or any texture for now.
* Move the patch so it overlaps the join between the grass surface and the dirt and covers the length you want to cover.
* The width depends on the texture scale. For 0.25 it is roughly between 48 and 64.
* 64 is the width of one tile of the grass edge texture at that scale.
* About half of that is blank to give you plent of room to manoeuvre.
* If your patch is bigger than 64 then you will get part of the next tile so that is the max.
* If you go too small, say 32 or less then you won't get all the texture.
* So keep the patch width between 48 and 64 for texture scale 0.25
* Rotate the patch temporarily so it lies north south length-wise
* Copy and paste from the dark grass surface to the patch.
* It should now be textured the same texture and scale as the grass and blend in perfectly with the grass.
* Now give the patch the texture: textures/darkmod/nature/grass/grass_edge/short_dry_grass_dark_edge
* You should see a long strip of white grass on black.
* All the white should be within the patch and not overlap the edge (so there is full black on both the east and west edges with the white in the middle.)
* If the white overlaps either edge then move the patch along and repeat the paste texture and retexture.
* Now move and rotate the patch to overlap the grass and dirt edge you want to blend.
* The full white centre should go over the centre join.
* The blurred edge normally goes on the grass side and the grass blade edge over the dirt but you can do it the other way for a softer edge.
* When in position it is OK to make slight adjustments of resizing but not large.
* You need to make the patch a func_static
* Then give it the property shaderparm3 with value 0.5
* The value can be anywhere between 0.01 (thin) to 0.99 (thick)
* When you first change it to func_static you need to dmap again.
* Once dmapped you don't need to dmap again if you just change the shaderparm3 value
* In game, the white parts should show as grass that blends with your brush grass and the black is transparent.

===Grass patch===

This is like a woolly bath mat. Place it over alignment errors, path ends, or just as a stand-alone grass patch.

===Instant paths===

These are endless 2-sided strips but they are the reverse of the above. They consist of many dirt and stone textures with grass blade alpha edges that blend into any grass texture. Just drop a patch onto any grass surface and give it one of these path textures and you've got a path with a soft edge. Width is limited to texture scale is the downside but at least once you've made the path you can stretch it sideways somewhat within reason. The long ends of these paths are hard so either you end them at some other surface like another path or doorstep or alternatively drop a grass patch over the end. I have provided all that seemed appropriate of our current dirt and cobble floor textures but it is relatively easy to copy one of those and make a new type if you need it. This path type might also work with materials other than grass to soften the edges but they are not random crumb; they are rough grass blade alpha. But you find dirt on straw or dirt on dirt stone on dirt might work I don't know.

When would you use one rather than another? The edges are more versatile and are not limited to just paths whereas the path types are quicker.

You can bend and twist both in all 3 directions so you can have a winding concave path with a dip in the middle up a curving hill. But the path type you cannot really make them go narrower or wider because the patch itself is the path whereas with the edge type they form a path by surrounding some other surface.

[[Category:Editing]]

Grass Edges

2011-02-22T19:05:45Z

Fidcal: /* Basic grass edge for all three grass types */

===Introduction===

''written by Fidcal''

This is about the grass edges, patches, and paths textures in update 1.03.

These are all textures under nature > grass > grass_edge.

I've not done prefabs at this time and I'm not sure it's worth it. The final versions consist of three types:

===Basic grass edge for all three grass types===

This is an endless 2-sided grass strip that you overlay over the hard join between grass and any other surface. You need to scale it approximately to the same as the grass but it does not need to be aligned with the grass particularly as its grass edge side blends in. You only need align the visible grass edge where you want it. There is a lot of space on this 1024 x 1024 tile, virtually half. This makes it easier to align (I tried using a 1024 x 512 tile without the space but however I adjusted and tweaked it was a nuisance to align.) You can also use this edge up against a wall by bevelling that edge a tiny amount up the wall. You can see many examples in the little courtyard in Biker's St. Alban's cathedral.

It's simple but hard to explain. Here is a guide: A summary would be create a long north south patch the same scale and alignment as your grass and give it the grass edge decal texture you want (making sure the white grass runs down the middle of the patch) then turn and move it to overlap the edge between your grass and any other surface.

* You start with a grass-textured surface and any other surface side by side, let's use dirt and dark grass as an example.
* So you have a straight hard edge between them.
* Select one of the surfaces.
* Menu > Brush > Create Decal Patches
* If this is flush with the surface (depends on your setting) set grid size 0.125 and raise the patch just clear.
* Leave the texture as _default or any texture for now.
* Move the patch so it overlaps the join between the grass surface and the dirt and covers the length you want to cover.
* The width depends on the texture scale. For 0.25 it is roughly between 48 and 64.
* 64 is the width of one tile of the grass edge texture at that scale.
* About half of that is blank to give you plent of room to manoeuvre.
* If your patch is bigger than 64 then you will get part of the next tile so that is the max.
* If you go too small, say 32 or less then you won't get all the texture.
* So keep the patch width between 48 and 64 for texture scale 0.25
* Rotate the patch temporarily so it lies north south length-wise
* Copy and paste from the dark grass surface to the patch.
* It should now be textured the same texture and scale as the grass and blend in perfectly with the grass.
* Now give the patch the texture: textures/darkmod/nature/grass/grass_edge/short_dry_grass_dark_edge
* You should see a long strip of white grass on black.
* All the white should be within the patch and not overlap the edge (so there is full black on both the east and west edges with the white in the middle.)
* If the white overlaps either edge then move the patch along and repeat the paste texture and retexture.
* Now move and rotate the patch to overlap the grass and dirt edge you want to blend.
* The full white centre should go over the centre join.
* The blurred edge normally goes on the grass side and the grass blade edge over the dirt but you can do it the other way for a softer edge.
* When in position it is OK to make slight adjustments of resizing but not large.
* You need to make the patch a func_static
* Then give it the property shaderparm3 with value 0.5
* The value can be anywhere between 0.01 (thin) to 0.99 (thick)
* When you first change it to func_static you need to dmap again.
* Once dmapped you don't need to dmap again if you just change the shaderparm3 value
* In game, the white parts should show as grass that blends with your brush grass and the black is transparent.

===Grass patch===

This is like a woolly bath mat. Place it over alignment errors, path ends, or just as a stand-alone grass patch.

===Instant paths===

These are endless 2-sided strips but they are the reverse of the above. They consist of many dirt and stone textures with grass blade alpha edges that blend into any grass texture. Just drop a patch onto any grass surface and give it one of these path textures and you've got a path with a soft edge. Width is limited to texture scale is the downside but at least once you've made the path you can stretch it sideways somewhat within reason. The long ends of these paths are hard so either you end them at some other surface like another path or doorstep or alternatively drop a grass patch over the end. I have provided all that seemed appropriate of our current dirt and cobble floor textures but it is relatively easy to copy one of those and make a new type if you need it. This path type might also work with materials other than grass to soften the edges but they are not random crumb; they are rough grass blade alpha. But you find dirt on straw or dirt on dirt stone on dirt might work I don't know.

When would you use one rather than another? The edges are more versatile and are not limited to just paths whereas the path types are quicker.

You can bend and twist both in all 3 directions so you can have a winding concave path with a dip in the middle up a curving hill. But the path type you cannot really make them go narrower or wider because the patch itself is the path whereas with the edge type they form a path by surrounding some other surface.

[[Category:Editing]]

Grass Edges

2011-02-21T19:23:45Z

Fidcal:

===Introduction===

''written by Fidcal''

This is about the grass edges, patches, and paths textures in update 1.03.

These are all textures under nature > grass > grass_edge.

I've not done prefabs at this time and I'm not sure it's worth it. The final versions consist of three types:

===Basic grass edge for all three grass types===

This is an endless 2-sided grass strip that you overlay over the hard join between grass and any other surface. You need to scale it approximately to the same as the grass but it does not need to be aligned with the grass particularly as its grass edge side blends in. You only need align the visible grass edge where you want it. There is a lot of space on this 1024 x 1024 tile, virtually half. This makes it easier to align (I tried using a 1024 x 512 tile without the space but however I adjusted and tweaked it was a nuisance to align.) You can also use this edge up against a wall by bevelling that edge a tiny amount up the wall. You can see many examples in the little courtyard in Biker's St. Alban's cathedral.

It's simple but hard to explain. Here is a guide: A summary would be create a long north south patch the same scale and alignment as your grass and give it the grass edge decal texture you want (making sure the white grass runs down the middle of the patch) then turn and move it to overlap the edge between your grass and any other surface.

* You start with a grass-textured surface and any other surface side by side, let's use dirt and dark grass as an example.
* So you have a straight hard edge between them.
* Select one of the surfaces.
* Menu > Brush > Create Decal Patches
* If this is flush with the surface (depends on your setting) set grid size 0.125 and raise the patch just clear.
* Leave the texture as _default or any texture for now.
* Move the patch so it overlaps the join between the grass surface and the dirt and covers the length you want to cover.
* The width depends on the texture scale. For 0.25 it is roughly between 48 and 64.
* 64 is the width of one tile of the grass edge texture at that scale.
* About half of that is blank to give you plent of room to manoeuvre.
* If your patch is bigger than 64 then you will get part of the next tile so that is the max.
* If you go too small, say 32 or less then you won't get all the texture.
* So keep the patch width between 48 and 64 for texture scale 0.25
* Rotate the patch temporarily so it lies north south length-wise
* Copy and paste from the dark grass surface to the patch.
* It should now be textured the same texture and scale as the grass and blend in perfectly with the grass.
* Now give the patch the texture: textures/darkmod/nature/grass/grass_edge/short_dry_grass_dark_edge
* You should see a long strip of white grass on black.
* All the white should be within the patch and not overlap the edge (so there is full black on both the east and west edges with the white in the middle.)
* If the white overlaps either edge then move the patch along and repeat the paste texture and retexture.
* Now move and rotate the patch to overlap the grass and dirt edge you want to blend.
* The full white centre should go over the centre join.
* The blurred edge normally goes on the grass side and the grass blade edge over the dirt but you can do it the other way for a softer edge.
* When in position it is OK to make slight adjustments of resizing but not large.
* In game, the white parts should show as grass that blends with your brush grass and the black is transparent.

===Grass patch===

This is like a woolly bath mat. Place it over alignment errors, path ends, or just as a stand-alone grass patch.

===Instant paths===

These are endless 2-sided strips but they are the reverse of the above. They consist of many dirt and stone textures with grass blade alpha edges that blend into any grass texture. Just drop a patch onto any grass surface and give it one of these path textures and you've got a path with a soft edge. Width is limited to texture scale is the downside but at least once you've made the path you can stretch it sideways somewhat within reason. The long ends of these paths are hard so either you end them at some other surface like another path or doorstep or alternatively drop a grass patch over the end. I have provided all that seemed appropriate of our current dirt and cobble floor textures but it is relatively easy to copy one of those and make a new type if you need it. This path type might also work with materials other than grass to soften the edges but they are not random crumb; they are rough grass blade alpha. But you find dirt on straw or dirt on dirt stone on dirt might work I don't know.

When would you use one rather than another? The edges are more versatile and are not limited to just paths whereas the path types are quicker.

You can bend and twist both in all 3 directions so you can have a winding concave path with a dip in the middle up a curving hill. But the path type you cannot really make them go narrower or wider because the patch itself is the path whereas with the edge type they form a path by surrounding some other surface.

[[Category:Editing]]

Text Decals for Signs etc.

2011-02-21T15:29:17Z

Fidcal: /* The Decal */

==Introduction==

This article describes how to add non-graphic simple text to signs, signposts, walls etc. using gui decals. In this image you can see some examples. This method only provides the application of the text itself (ie, does not include the signs, signposts etc.)

<center>[[Image:text_decals.jpg]]</center> 

The assets used are provided from Dark Mod update 1.03 onward. But that is just a convenience; you can create your own easily (see [[#Customising and Making your own]] below.)

For other types of in-game text see [[Text]]

==Ready-made Prefabs==

This is by far the easiest method. You simply insert a prefab and change the default text and size to what you want:

* This is described for the Dark Radiant editor.
* For general use all you need do is to find or make your blank wall, sign, etc.
* RMB in grid view and select insert prefab
* Select eg, prefabs/readables/sign_text_decals/sign_text_carleton.pfb
* The font choices are shown in [[Fonts Screenshots]]. Note that not all Dark Mod fonts are set up for this but see [[#Customising and Making your own]] below for how to do this.

* You now have a working text decal.
* To set your text change the spawnarg value gui_parm1 in Entity Inspector to whatever you want.
* To change the size of the text;
* just resize the patch. To do this, first press the TAB key. Remember to press it again to get back.
* An alternative is to rescale the texture in Surface Inspector
* It is important to note that by default the full surface may hold several lines of text so if your text is eg, just a street sign then it may only use the top line so you will need to drag resize the patch to cover a larger area than the visible sign. The decal patch is non-solid and invisible except for the text itself so can overlap any visible surface with no problem.
* The defaults are all black text with 66% transparency so they blend well onto most surfaces but see [[#Customising and Making your own]] below for how to change this.

==Customising and Making your own==

To make your own text decals or customise the ones provided:

===The Decal===

* Create a patch and give it the texture: textures/darkmod/decals/signs/decal_gui . This is only available fromDark Mod update 1.03 onward but if you want it earlier this is what to do:
** Use textures/common/entityGui instead if it doesn't matter if the decal is solid.
** Create the custom texture listed below at [[#Custom Texture]]
* In Surface Inspector, use these in order: natural, fit, flip horizontal, rotate left 180 degrees.
* You should now see a single occurrence of the words Entity GUI on the patch and the words should be upright and not mirrored. If not, adjust, rotate, until they do.
* Note that the text size will be affected by the size of the patch
* Convert the patch to a func_static entity
* Give it the spawnarg gui with the path and name of your gui (see [[#The Gui]] below as its value.
* Give it the spawnarg gui_parm1 with your own text as its value.

===The Gui===

This is the gui file that defines the font. If you have Dark Mod update 1.03 you can modify an existing one. Alternatively, just copy and paste the one below into a text file and save it with your map in a guis folder as eg, my_stone_text.gui. You will need to add that path and name to the gui spawnarg of the decal entity above, eg, gui guis/my_stone_text.gui

windowDef Desktop
{
rect 0, 0, 640, 480
backcolor 0, 0, 0, 0

windowDef SignText
{
rect 0, 0, 640,480
backcolor 0, 0, 0, 0
text "gui::gui_parm1"
font "fonts/stone"
textscale 2
forecolor 0, 0, 0, 0.8
visible 1
}
}

In the above definition, these are some of the things you can change:

* Set your font in the font line as shown. It must be in quotation marks as above. Font choices are shown in [[Fonts Screenshots]].
* Change the font size in textscale. Fractions can be used, eg, 1.5 but remember, resizing the patch or texture scale in Dark Radiant also changes the font size.
* Change the colour and transparency of the text in the forecolor line. Because of the way Doom 3 blends imagery, for all practical purposes this is limited to very dark colours because they do not react to local game lighting. If you choose lighter colours then they will glow in the dark. (it might be possible to match a colour to a static light situation.) The forecolor values are:
** red, green, blue, transparency; each in the range 0 to 1.
** For colours, 0 to 1 is zero to full intensity; for transparency it is invisible (0) to fully opaque (1)
** For example:
*** 0.9, 0.9, 0, 1 would be high red, high green, no blue, and fully opaque. Red and green light make yellow so this would give glowing yellow text that would not blend well with its background.
*** 0.1, 0, 0, 0.66 This is more practical and would give a dark red that blends well onto its background with 66% opacity.
* A background colour can be set with the backcolor line exactly the same as for forecolor but is probably of limited use for our purposes. 0.9, 0.9, 0, 1 would have the text on a solid bright yellow background that glows in the dark. 0, 0.1,0, 0.33 would give a faint green background of 33% opacity.

===The Texture===

This is the non-solid decal gui texture. Copy and paste it into a text file and save it with your map in a materials folder as eg, mymap.mtr. You will need to reload shaders if you already have Dark Radiant running before you can select it.

textures/mymap/decals/signs/decal_gui
{
qer_editorimage textures/editor/entityGui.tga
DECAL_MACRO
noShadows
nonsolid
noimpact
discrete
guiSurf entity
}

[[Category:Editing]]

Material Files

2011-02-04T18:15:34Z

Fidcal: /* Add the Ambient Light Stage */

{{Original_Reference|Fingernail & greebo|127}}

== What the Heck is a Material File? ==
The material files (.mtr) contain lists of 'material definitions' that tell the engine where to find the source files for the specified textures and what features it should have. All material files should be located in the '''darkmod/materials''' folder and have the extension '''.mtr'''.

In fact, it's the material (=shader) which gets applied to surfaces of brushes, patches and models, not the actual TGA/DDS texture image. A TGA file cannot be applied to surfaces, it's the shader name which gets used.

Polygons ==> Shader ==> Image(s) + Processing => Appearance

Material definitions apply to a single 'texture', though it may be made up of multiple texture files blended together. A simple material definition looks like this:

textures/darkmod/stone/brick/redbrick_with_mortar
{
qer_editorimage textures/darkmod/custom/redbrick_ed
diffusemap textures/darkmod/custom/redbrick
bumpmap textures/darkmod/custom/redbrick_local
specularmap textures/darkmod/custom/redbrick_s
}

If you're using the ''material'' called '''textures/darkmod/stone/brick/redbrick_with_mortar''' in your map, Doom looks up the name in the material definition and loads the according image files (as specified by the [[Map Expressions]]). Note that you '''don't''' need to specify the file extension, the engine is automatically adding it (depending on your quality setting) and finds the according texture file. You also don't need to include the '''dds/''' prefix in the path, this is also added automatically.

A single material file contains lots of material definitions. This is useful as textures that logically belong to each other are summarized in one material file (e.g. '''materials/tdm_stone_brick.mtr''')

The .mtr files are read upon launching Doom 3 - changing your material file therefore requires either restarting Doom or typing '''reloadDecls''' in the console.

== Create a new Texture Definition ==
Provided you already saved your texture source file (the .tga or .dds) in the appropriate folder, you can go on and create your texture definition. You cannot use your textures without this step.

Open up or create your personal material file with a text editor. There are existing guidelines for where texture definitions should go, for the sake of organization, but the engine doesn't care what the filename is as long as it's in the materials folder and has a .mtr extension.

First, specify the name of your new material. If it is not a model texture, then the name should include the path to the texture files used. Example:

textures/darkmod/stone/brick/redbrick_with_mortar

'''Note:''' Do not use special characters for your shader name or the Doom 3 parser might complain (e.g. no & characters)

Then, open up a squiggly bracket ({), and start to fill in the texture paths as below, changing the paths and names for your texture.

textures/darkmod/stone/brick/redbrick_with_mortar
{
qer_editorimage textures/darkmod/stone/brick/redbrick_with_mortar_ed // editor image
diffusemap textures/darkmod/stone/brick/redbrick_with_mortar // diffuse map
bumpmap textures/darkmod/stone/brick/redbrick_with_mortar_local // normal map
specularmap textures/darkmod/stone/brick/redbrick_with_mortar_s // specular map
}

Close the definition with a close squiggly bracket (}).

Save the file. Now you can load your new texture in DoomEdit or [[DarkRadiant]] provided you did it all correctly.

Alternatively you can also have a look a the existing material files and learn from them.

== Add the Ambient Light Stage ==

This should go on all Dark Mod textures (see [[Virtual Ambient Light Textures]])

note that if there is no specular map then substitute _black
and if there is no bumpmap then use _flat

<pre>
// TDM Ambient Method Related
{
if (global5 == 1)
blend add
map <mappath/name>
scale 1, 1
red global2
green global3
blue global4
}
{
if (global5 == 2)
blend add
program ambientEnvironment.vfp
vertexParm 0 1, 1, 1, 1 // UV Scales for Diffuse and Bump
vertexParm 1 1, 1, 1, 1 // (X,Y) UV Scale for specular
vertexParm 2 global2, global3, global4, 1

fragmentMap 0 cubeMap env/gen1
fragmentMap 1 <mappath/name>_local // Bump
fragmentMap 2 <mappath/name> // Diffuse
fragmentMap 3 _black // Specular
}
</pre>

== Add the Frob Highlight Stage ==

All materials need to have a conditional shader stage added to let the material highlight when the objects are frobbed. The technical details are of minor interest here, just copy and paste such a stage from other materials and adjust the diffusemap and bumpmap references.

== Full example ==

Here is the full example with the final material definition:

<pre>
textures/darkmod/stone/brick/redbrick_with_mortar
{
// Use on of the predefined surface types like stone, glass, wood
stone

qer_editorimage textures/darkmod/stone/brick/redbrick_with_mortar_ed
bumpmap textures/darkmod/stone/brick/redbrick_with_mortar_local
diffusemap textures/darkmod/stone/brick/redbrick_with_mortar
specularmap textures/darkmod/stone/brick/redbrick_with_mortar_s

// This is the code required for frob highlighting this texture
{
if ( parm11 > 0 )
blend gl_dst_color, gl_one
map _white.tga
rgb 0.40 * parm11
}
{
if ( parm11 > 0 )
blend add
map textures/darkmod/stone/brick/redbrick_with_mortar
rgb 0.15 * parm11
}

// TDM Ambient Method Related
{
if (global5 == 1)
blend add
map textures/darkmod/stone/brick/redbrick_with_mortar
scale 1, 1
red global2
green global3
blue global4
}
{
if (global5 == 2)
blend add
program ambientEnvironment.vfp
vertexParm 0 1, 1, 1, 1 // UV Scales for Diffuse and Bump
vertexParm 1 1, 1, 1, 1 // (X,Y) UV Scale for specular
vertexParm 2 global2, global3, global4, 1

fragmentMap 0 cubeMap env/gen1
fragmentMap 1 textures/darkmod/stone/brick/redbrick_with_mortar_local // Bump
fragmentMap 2 textures/darkmod/stone/brick/redbrick_with_mortar // Diffuse
fragmentMap 3 _black // Specular
}
}
</pre>

== See also ==
* [[Texture Guidelines]]
* [[How to add Textures to The Dark Mod]]
* [[Texture Creation - Basic Tutorial]]

{{tutorial-textures|sort=Material}}

Doors

2011-02-02T10:31:15Z

Fidcal: /* Sounds and Sound Propagation through Doors and Doorways */

{{todo}}
''Written by Fidcal'' ''edit Baddcog''

==Quick Summary==

Quick way to get an unlocked door in your map:

* Insert one of the prefab doors complete with handles and select its skin property and click the button to change its skin appearance to whatever you want. Set any other properties you need.

Alternatively,

* Create a door from the entity list
* Use the "skin" spawnarg on the door to change its appearance.
* Create a handle from the entity list
* Add the ''door_handle'' property to the door and give it the name of the handle
* To the door handle add the value frob_peer and use the name of the door.
* To open clockwise, change the ''rotate'' property from <code>0 90 0</code> to <code>0 -90 0</code>

==Introduction==

This tutorial explains how to put doors into your map using Dark Radiant, as well as adjust them and their properties.

The rest of this tutorial assumes that you have a basic understanding of using DarkRadiant. If you haven't done so, please go read the [[Dark Radiant Must Know Basic Intro]] article first.

Additionally:

* Up, down, left, and right in Dark Radiant's ''top'' orthoview are regarded here as the standard map directions of North, South, East, and West where useful for clarity.
* Where the term ''brush'' is used with a door it mostly also applies to a door made up of a group of brushes and/or patches.
* Where the term ''door'' is used it often will also apply to any object you wish to rotate when frobbed, for instance an openable window, box lid, or even more exotic objects that the imaginative mapper might conceive like a signal, engine part, toy, or whatever. So long as it needs to turn or slide just a fixed amount when frobbed then return when frobbed again then the following applies.

==Door types==

All tangible objects in Dark Mod are ''entities'', having either a pre-made model shape or else brush/patch(es). So there are two ways to create a door in Dark Radiant: as a model door or a textured brush door (or a hybrid of the two).

Models are ready made door objects but cannot within Dark Radiant (at the time of writing) be resized, rescaled, cropped or clipped whereas brushes are very flexible in that respect and can be worked into custom shapes for your map, including secret doors that blend into walls and other surfaces.

Most of the current door models are found in two places along with the door handles.
*Model Viewer: doors created from here will be static in the world and have no props other than material type.
You can add any props to them to make them working doors. If nothing else it is a good place to view the different size and skin options for the doors.
*Entity List: most of the door models can be found here. These doors have properties already assigned so they are ready to be used. Only one base door of each type is listed, create the size/hinge count door you want (2 hinge doors have a 'no hinge' skin). You can choose a skin for the door once it has been created in the editor with the "skin" spawnarg (use the model name of the door you want, taken from the model list, as its value). This is the easiest way to create a door. The same goes for door handles.

Remember also that door functions may be applied to objects other than doors for instance to openable windows, drawbridges, gates, in fact anything that needs a partial rotation or slide when frobbed then return when frobbed again such as a signal device. Lockboxes and chests use similar properties.

Door/handle prefabs seem to crash Doom3 when trying to reload a map so far now just create and link each door/handle. You can create one set and copy/paste them, but you need to take great care that all the name props are changed to match each clone. Otherwise you get handles that fly off with a distant door and handles that don't move.

==Creating a Door==

Put simply, to make a door you will be creating an 'entity with model' or 'entity with brush' or some variation thereof.

===Creating a Model Door===

There are several approaches to making a model door; the simplest is to create a door from the entity list; or create a door from the model viewer (good for static unusable prop doors).

'''Entity List''':

*Deselect everything in editor by hitting the Esc button
*Right-click an ortho view and select Create Entity
*Navigate to darkmod/movers/''atdm:door_...'', choose the door you want
*Click Add
*To change its appearance, add a "skin" spawnarg to the door, with the value being the model name of the door you want.

You now have a workable door in your level.

'''Model Viewer''':

* Right click in the orthoview, select ''Create Model'' then <code>darkmod</code> and select a door.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* Click [[Image:Button ok.png]] and you have a static door.
* If you want to make it work (openable, frobbable) then:
** Select the entity inspector,
** Select the top classname line so it highlights
** Select the func_static line in the input box ''below'' the properties window.
** Edit <code>func_static</code> to <code>atdm:mover_door</code>
** Click {{check}} or press {{key-enter}}

Alternatively you can do it the old way:

* Create any temporary brush
* Right click in orthoview and select <code>Create Entity</code> then <code>atdm:mover_door</code>.
* Left lick the model name line in the entity inspector.
* Below it on the ''Entity Inspector'' panel you should now see a button 'Choose Model'
* Left click it, select a door model from the darkmod group.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* The temporary brush was deleted.

In all three instances, you now have a working door with default properties.

Name your door by adding the prop (or modifing it) to name ''My_Door_1''. You can use any name that you feel is appropriate but all doors with handles attached ''must'' have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below).

To add a handle and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

===Creating a Textured Brush Door===

'''Tip:''' If unsure of size then you might insert a temporary human AI first to get a sense of height.

==== The simplest brush door: ====

* Drag out a new brush to the size required, eg, a seven foot high door is 84" x 1.1 = about 90 units in Dark Radiant.
* Give it a door texture from the texture browser (or wall texture for a secret door)
* Right click in orthoview and select ''Create Entity'' then <code>atdm:mover_door</code>
* You now have a default door that rotates around its center.

To move the rotation point to the door edge and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

==== Multi-brush doors: ====

More complex multi-brush doors can be created using the [[Clipper]] tool, CSG, etc. - this is not covered in this tutorial. Then assign <code>atdm:mover_door</code> for that whole brush structure. Also you can collect various brushes positioned together in relation to one another as needed, select them all, then assign <code>atdm:mover_door</code> for the group. All the brushes will be children of the <code>atdm:mover_door</code> entity and will rotate and be frobbable, etc. as one unit, as one door. To add further brushes or even model shapes later see the section on [[#Adding handles and other items to doors]].

Name your door by adding the prop (or modifing it) to name My_Door_1. You can use any name that you feel is appropriate but all doors with handles attached must have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below). (repeated from above in case you didn't choose to create a model door)

=== Double Doors ===
Double doors are automatically recognised by the code when the doors are spawned. The prerequisite is that both doors are sharing/touching the same visportal. The spawnarg ''auto_setup_double_door'' (which defaults to "1") will take care of setting up the open/lock peer relationship between the two doors. The doors will open/close and lock/unlock along with each other as a result.

What happens behind the scenes: the doors are adding each other to their internal open_peer and lock_peer list, which causes the double doors to perform the same action when frobbed or used.

Note that ''auto_setup_double_door'' will not set the frob_peer relationship, i.e. each door will frob-highlight on its own without highlighting the other door. You'll need to add that spawnarg manually if you want to highlight the entire double door as one.

==Customising and Adjusting Door Properties==

Handles, lockplates, etc. can be added to doors and door properties can be adjusted for rotation, sliding, locking, and more.

Some of the door models have hinge plates and lockboxes that are reskinnable with a good variety of skins.

===Door handles and other door attachments===

Summary: just add the property ''bind'' with the door's name to the attachment and position it where you want it on the door. If it's a ''atdm:mover_door_handle'' then it automatically will work as a handle but you can bind virtually anything.
You can add handles and other items to doors such that they move correctly with the door whether rotating, sliding, or both and even if the door is not vertical such as a skylight or trapdoor.
Handle models come in two types, ''single handles'' and ''double handles''. A single handle is one sided, this means the handle will be inside the door or outside the door, but not both. A double handle has a lever on the inside of the door and a handle on the outside of the door. Each has benefits.

*'''''Single door handles''''':
Single door handles can be used on a static door, a door that's just for show that no AI's or the player can use. In this case you should just create a door handle from the model viewer, it will be static and have no properties such as scripts. It is for looks only.

Single handles can also be used inside AND outside of the same door to save on rendering. Unlike the double handles the handle on the inside of a portal won't render. The curved handle is only about 130 polys per side, but if you have a large area and 10 handles you can save 1,000 polys from being rendered. Everything counts when it comes to performance.
I will call this ''multiple handles'', see more below.

These can also be useful on brush doors created in the editor that may be very thin or very wide.

*'''''Double door handles''''':
These are models have have a handle inside and outside. The bonus is that they only use one entity. Maps are limited to about 4,000 entities but when you count lights, AI, sound speakers, ect... you can run out of entities quickly on a large map. If you plan on building a large map this is the way to go, even in a small map they have benefits, namely that you only have to attach one handle per door.

Whether you decide to use a single handle or a double handle you must first follow the instructions below and attach one handle first. If you choose a double handle, follow the instructions below and you are done. If you choose a single handle type follow the instructions then also follow the ''multiple handle'' instructions for the second handle.

Both single and double handle types can be found in two places. The model viewer which will create a static model good for show, you can manually add props to make them work OR you can look in the entity browser.
Using a handle from the entity browser saves you a little bit of time as some props are already added, you just need to add the frob_peer names for the doors/handles and the door_handle name to the door.

=== Adding a working model door handle===

Quick summary:
* Create a model or brush handle and make it an ''atdm:mover_door_handle'' entity.
* Position it on your door. Use the opposite side from the door's multicolor X-Y-Z indicator (highlight the door to see it) if it's not obvious which side it goes on.
* '''Bind''' the handle to the door (bind <doorname>)
* It should now be a working handle though may need adjustments of rotation etc. see later.

Important: read preceding section on door handle types and performance issues first.

This works with both a model door and a brush door:

'''Rotation''':
* By default the door handle entity rotates ''anti-clockwise'' (looked at from the front) then springs back. A ''double handle'' model is OK but two singles (see ''Multiple door handles'' below) need more care as only one is the functioning entity and the other is just attached to it. So anti-clockwise is fine for a door with its hinge on the left and the handle on the right - the handle will rotate down then spring back. If you put the functioning door handle on the other side you will have to change the default ''rotate'' property from -45 0 0 to 45 0 0. '''''Therefore it is easier to generally put this handle on the side of the door where the hinge is on the left and the non-functioning attachment handle on the other side.'''''
*If your door only needs one handle, eg, a cupboard door, and from outside its hinge is on the right then you will need to change the ''rotate'' property of the handle as described above.

'''''The functioning handle entity:'''''
* Create an entity door handle (movers folder) or create a brush or model handle and assign it the entity ''atdm:mover_door_handle''.
* Position it where you wish on your door.
* '''Bind''' the handle to the door, by adding the "bind" spawnarg to the handle.

You now have a working door handle with default properties.

*'''Multiple door handles''':
Now that you've got a handle attached to one side of the door it is time to add one to the other side (unless you used a double handle).
* Create the new handle. The single handles come in left and right persuasions. A door needs a left facing handle on one side and a right facing handle on the other, so if you have already added the left handle create a right handle and line it up on the other side of the door.
* Name this handle. I prefer to keep a naming convention for each door and it's respective handles, it makes things alot easier. The door is named '''My_Door_1''', the first handle is named '''My_Handle_1''' so name the second handle '''My_Handle_1_1'''. This will make it stay with the first handle in the entity list. This is important to keep organized. If you name it My_Handle_2 then when you get to another door named My_Door_2 you'll be confused.
* Place and '''bind''' that handle to your door.

You now have two single door handles on either side of the door that rotate together as if they were physically attached.

'''To add a brush to a brush door''':
* Select the new brush ''and'' the brush door all together; ''the entity '''must''' be selected '''last'''.''
* Use {{menu|Edit|Reparent primitives}}. This ensures the parent entity adopts the new item(s).
* If you have trouble selecting them in the orthoview because other brushes, etc. get selected then try in the camera view or as a last resort move them temporarily to an open area (but keep them in the same positions relative to each other.) Use {{key-shift}}+{{LMB}} on new item(s) then {{key-shift}}+{{LMB}} on main entity. Once they are all selected, use the {{menu|Edit|Reparent primitives}}.

'''To add ''model'' static items''': knockers, hinges, static handles etc. to a ''Model Door'':
* Select item
* Right click in orthoview and select ''Create Entity'' then <code>entity func_static</code>
* Position it where you wish on your door.
* To synchronize this with your particular door you need to add the property ''bind'' and the individual door name to the brush entity. To do this...
** Select the model door.
** In the entity inspector, select the ''name'' line
** Select the bottom line in the input box ''below'' the properties window.
** Copy the name
** Deselect the door with {{key-esc}}
** Select the brush entity
** Add a property "bind" to it.
** Change the value of the property by pasting in the door name
** Click {{check}} or press {{key-enter}}

'''To add ''brush'' static items''': knockers, hinges, static handles to a Model Door:
* This method is not ideal but it seems to work OK.
* Select the brush.
* Right click in orthoview and select Create Entity then ''atdm:mover_door_handle''
* Position it where you wish on your door.

To synchronize this with your particular door you need to add the property ''door_handle'' on the door, and give as the value the name of the brush you just created.

This brush turns like a handle. To stop it:

* Adding ''rotate 0 0 0'' or disabling the handle script won't help.
* Add a real working handle (as in the section above ''To add a working model door handle...'' and it must be added LAST.)

If you don't want too see a real working handle added maybe try another tiny brush with the handle function and hide it inside the door?

===Locking Doors===

To lock a door check the ''show inherited properties'' in the entity inspector for a ''atdm:mover_door'' entity and you should see the ''locked'' property. Select it and in the input box below the properties you can change its value:

* 0 = unlocked (default)
* 1 = locked

If locked it will require an entity that is associated with it to be able to act as a key to unlock it.

Currently door handles on locked doors will rotate when frobbed, they will bounce back though and the door will stay locked until unlocked.

===Keys===

Assigning specific keys to specific doors is simple.

* It is recommended that you create an existing key entity. These keys have all required props, they just need to be named.

Alternatively you can create a key from the Model Viewer and want it to be useable
* Make sure it has the properties:
useable 1 [so it can be used by the door]
frobable 1
inv_name <unique name>
inv_category Keys
inv_target player1
inv_icon guis/assets/hud/inventory_icons/<icon name>
inv_stackable 0 or 1 where 1 can be used on all copies of the same key so they show as one entry in the inventory with a total.

Add to the door the property <code>used_by</code> with the name of the key as the value. Multiple keys can open the same door by using several <tt>used_by</tt> spawnargs:

"used_by" "doorkey_1"
"used_by1" "doorkey_2

==== Keys carried by AI ====

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see [[Attaching Props to AI]].

*"def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
*"pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
*"name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
*"set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
*"set name on door_key" "door_key" //here it gets a name to be used in the map in general.

updated by bikerdude.

====Master Key for Testing====

By default, ALL locks can be opened by any key named ''key_master''. Just create a key in your map, name it ''key_master'' and it becomes a master key for use while testing. Add inv_map_start 1 to it so it is in the player inventory at game start. Remember to delete it when your mission is finished.

===Lockpicks===
''by Baddcog''

There are two lock pick types.
*'''s'''=snake
*'''t'''=triangular

A lock can be set with many pins. Each pin has a click sequence and each needs a designated lockpick type (see above). Keep in mind that the lockpicking in The Darkmod is much more involved than in T2 or T3. The player has to listen to sounds or watch a handle or lockbar to know when a lock is pin is picked.

This means that authors can be very evil and really frustrate the player, in which case their missions will probably not be played. So be nice to the player and don't waste your time. Use simple locks for the most part and save complicated locks for important sections and to build tension. Don't make the player have 20 pins to pick all with different lockpicks. In most cases 1 or 2 pins will suffice and it isn't necessary to use both lockpicks on every lock.
Also try to include a lock lever on lockboxes or chests, door handles will rotate as the pins are being picked. This gives the player visual clues to help with the picking (and essential in noisy environments where you can't hear the clicks.)
IMO this system is a huge leap foward for lockpicking but also has the ability to completely frustrate the player as stated above. Keep this in mind when designing your lockpick systems.

These props go on the door itself, or the lid of a chest, eg,
*'''lock_pins''' 1327
*'''lock_picktype''' stts

The lock_pins property specifies how many pins each lockpicktype has.
The lockpick_type property specifies how many times the player has to switch picks and which pick they have to use. You can see there must always be an equal number of lock_pins and lock_picktypes specified

So looking at the example above we have lockpick_type s(snake), t(triangular), t(triangular), and s(snake). The player will have to use these lockpicks in this order. Once the snake lockpick's pins are open the player can advance to the triangular pick and so forth.
5 is added to every click sequence so 5 is the minimum click pattern even if you set it to 0.
In the example above the lockpins specify in order which pick types have how many pins, so the s pick has 1 + 5 = 6 clicks, the t pick has 8 and so on.
The above is a difficult lock and to avoid annoying the player it is best only used rarely on a special lock like an important big vault door. Ordinary footlockers and common doors can be just 1 or 2 click sequences, eg, lock_pins 2 and lock_picktype t means the player uses one pick and listens for the end of one sequence of 7 clicks.

lockpick_rotate - is placed on the door. It is the amount the visible rotating handle or pin rotates while picking. For a rotating handle or lockbar normally ignore this and leave the default. During lockpicking it oscillates and progresses to the normal full turn of the handle. Example 0 45 0.

lockpick_translate - is placed on the door. It is the amount the visible handle or pin moves in a straight line while picking. Use this if you have eg, a lockbar that you want to move in a straight line and not rotate, eg sliding catch. Example 0 -5 0

By default, doors are pickable. If you don't set up the above lockpick spawnargs then it can't be picked. So there is normally no need to enable lockpicking - just set up the above spawnargs. There is a ''pickable'' spawnarg set to 1 by default. If set to 0 then the door becomes unpickable. But hard to think of an application except in testing or perhaps a special custom situation where it is switched by script perhaps.

===Open, Partially Open, or Closed Door at Game Start===

By default, doors are closed at game start. If you want a door to be already open or partially open then do the following.

'''Note well: Create all doors in their ''closed'' position. Adjust as follows and they will automatically be at the open position when game starts.'''

Already Open Rotating Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and tick the check button
* The door will now be fully open at game start.

* If you want it only partly open:
* Make sure its ''open'' property is set to 1 as above.
* Right click the entity inspector and select ''add property''
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* scroll down, select ''start_rotate'' then click {{ok}}
* This adds it to the property list.
* Now select ''start_rotate'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the angle you want in the same form as described in the ''Rotate Direction and Open Angle'' section. So for example, to have a door that has a fully open default ''rotate'' value of 0 90 0 to start only half open you would give it a ''start_rotate'' value of 0 45 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

Already Open Sliding Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and click {{check}} or press {{key-enter}}
* The door will now be fully open at game start.

* If you want it only partly open:
* Right click the entity inspector and select ''add property''
* Make sure its ''open'' property is set to 1
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder.
* scroll down, select ''start_position'' then click OK. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* This adds it to the property list.
* Now select ''start_position'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the position you want in the same form as described in the ''Sliding (Translation) Amount and Direction'' section. So for example, to have a door that has a fully open default ''translate'' value of 0 50 0 to start only half open you would give it a ''start_position'' value of 0 25 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

===Rotation Centre, Pivot, Hinge point===

The centre of rotation of a door is at the origin point of its entity and the door rotates with reference to the orientation of that origin point, not the world map. See ''Rotate Direction...'' for more about that. This section only deals with the ''position'' of the rotation centre in the door.

Model Door Centre of Rotation: 
The centre of rotation of a model door cannot be changed within Dark Radiant. Because a model door rotates around the centre 'spine' of its back edge this will cause clipping (penetration into solid) as in this example (where the door is set to open to 89 degrees for clarity): [[Image:modelClipping.jpg]] So care is needed with placement. You will not normally position a door right next to a wall as in the example but against a shallow frame so clipping will barely be noticeable but either way it can be fixed. You can correct it by adding a translation (see ''Sliding (Translation) Directions'') value of half the door width in the direction of the door handle. This will gently move the door out as it rotates to clear any solid on that side as in this diagram: 
[[Image:DoorClip.jpg]] 
Half a door width will typically be about 2. Any 'attachments' such as door handles will still synchronize with the door movement whether the door is rotating, sliding, or both.

Brush Door Centre of Rotation: 
The centre of rotation of a brush door ''can'' be changed. The default origin point of a brush is at its centre. Therefore a default rotating brush door will rotate around its centre when you first create it. So, mappers will commonly need to move that rotation point to a corner or even to some other offset position for example, for an openable window using the door function.

Put simply, to move the rotation point of a brush door you need to move the entity origin relative to the brush(es.)

Moving the entity origin (centre of rotation) relative to a brush door:

* Select the brush door
* Select ''Vertices mode'' (default shortcut key is {{key|name=V}} or button on top toolbar 'Select Vertices')
* Drag the door's entity origin to the point where you want the door to rotate. This should be on the corner on the leading edge side (the side to where the door is opening.) to avoid clipping as in this diagram....
[[Image:getCorner.jpg]]
* You should now find that door rotates around that point.

===Rotate Direction and Open Angle===

By default, rotating doors open anti-clockwise (viewed from above) by 90 degrees from the start orientation. If you want to change this edit the ''rotate'' property in the entity inspector. Don't confuse this ''rotate'' property with the ''rotation'' property. In the entity inspector remember that to see the inherited rotate property you must check the box 'Show inherited properties'.

The three values shown in the rotate property are degrees from the closed position around Y Z X ''entity origin axes'' (NOT absolute map axes) and so include any start ''rotation''. So the Z value is the axis vertical to the entity origin. If you tilt a model door over in Dark Radiant then its entity origin tilts too so the Z axis is tilted too (with respect to the world map vertical.) So with a normally opening model door if you lay it flat on its back it will open upwards and not rotate around on the floor. But a brush door must be treated differently...

If you turn a brush door using the normal Dark Radiant rotate tool or the Transform Dialog (accessed via a shortcut key) then it only turns the brush ''relative'' to the entity. So, because the entity origin is by default aligned with the world map then ''in most cases'' you can regard a brush door as rotating with respect to the world map if you wish. But there will be a problem when you come to rotations that are not around the main Y Z X axes of the map, for instance a drawbridge that lowers down to the south east. You might think you can combine Y Z X values to get the result you want - and this can be done (for south east use 45 45 90) but it is a bit of a kludge and the drawbridge twists eccentrically as it lowers (though it arrives correctly!) So for such cases you need to turn the entity itself so its start position is facing south east. You can then just use 0 0 90 to lower the drawbridge perfectly because its Y axis is now pointing south east. To turn the entity you must type or paste the rotation values in directly because using the Dark Radiant rotation tool or Transform Dialog will only turn the brush not the entity. The values are rather lengthy (south east is 0.707107 0.707107 0 -0.707107 0.707107 0 0 0 1) so probably the easiest way is to create a temporary model door, turn it how you want, then select its rotation property. If you now deselect and re-select your brush door then that property will still be in the entity inspector input box and you need only click the check(tick) box to add it to the brush door. NOTE: ''neither the entity nor the brush will show as turned in Dark Radiant.'' Only the rotation property in the entity inspector will indicate the orientation. Instead of a rotated ''construction'', regard it as a rotation ''instruction'' for when the map is compiled.

These are the rotate property fields. Remember they are all with reference to the door's entity ''not'' the world map. Since there is no absolute frame of reference I indicate them here as if the entity is aligned with the world map axes...

* Positive Y = Open clockwise (Dark Radiant grid front view, looking north)
* Negative Y = Open anti-clockwise (Dark Radiant grid front view, looking north)

* Positive Z = Open anti-clockwise (Dark Radiant grid top view, looking down)
* Negative Z = Open clockwise (Dark Radiant grid top view, looking down)

* Positive X = Open anti-clockwise (Dark Radiant grid side view, looking west)
* Negative X = Open clockwise (Dark Radiant grid side view, looking west)

The values are in the range -179 to +180. Positive values give an anti-clockwise opening rotation (looking down from above) and negative values give a clockwise opening rotation. The value 180 is unique in that it continues in an anti-clockwise rotation when closing rather than returning clockwise so might be used if you can think of some object that might need such a motion when frobbed!

Edit the rotate value by selecting it and using the input box at the bottom and clicking the check(tick) button. That will change the angle the door will open to. Note that the line with the original default of 0 90 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Examples:
* 0 90 0 = Opens anti-clockwise round the entity's 'vertical' to 90 degrees - typical default vertical door.
* 0 0 90 = Lowers a drawbridge from the entity 'vertical' to horizontal.
* 0 0 -45 = Opens clockwise by 45 degrees viewed from the east side. This might suit a skylight in a sloping roof.

Combinations can be used and also combined with slide motions (see '''Sliding (Translation) Directions''') to produce exotic and useful motions. A door opening against an upward-sloping floor can thus have a ''lifting hinge'' and raise up slightly to clear the floor; a door can rotate towards you and slide back to one side very effectively.

===Sliding (Translation) Amount and Direction===

By default a Dark Mod door will rotate open. For most sliding doors you want to stop them rotating as well as make them slide. You cannot delete (remove) the ''rotate'' property - you have to set the ''rotate'' property to 0 0 0 to stop a door rotating (see ''Rotate Direction and Open Angle''.)

Now edit the ''translate'' property value by selecting it (remember to have inherited properties box checked) and using the input box at the bottom and clicking the check(tick) button. That will change the distance the door will slide to. Note that the line with the original default of 0 0 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Typically (but not always) you will want your sliding door to slide the width of the door. The three values in the translate property by default are 0 0 0 and are X Y Z ''absolute map'' values (irrespective of door orientation) where:

* Positive X = Slide East (Right side of Dark Radiant grid in top view)
* Negative X = Slide West (Left side of Dark Radiant grid in top view)
* Positive Y = Slide North (top of Dark Radiant grid in top view)
* Negative Y = Slide South (bottom of Dark Radiant grid in top view)
* Positive Z = Slide Up (Top of Dark Radiant grid in side views)
* Negative Z = Slide Down (Bottom of Dark Radiant grid in side views)

So for a 50 unit wide door you want to slide fully to the east you would use 50 0 0 for the translate property values. A 100 unit portcullis sliding vertically up would need 0 0 100 to be fully raised.

=== Doors Collision/Push Behaviour ===
Doors are pushing all entities by default, except for the player. Doors will also stop moving when anything blocks their movement. However, this default behaviour can be changed by setting the according spawnargs:

Set '''push_player''' to '''1''' to let the player be pushed by this door:
"push_player" "1" // Push the player too (default is off)

By default '''stop_when_blocked''' is set to 1 and if a door is blocked by an entity then even if the entity is removed afterwards, the door stays still. The next frob will close the door.

Set '''stop_when_blocked''' to '''0''' to prevent the door from ending the opening sequence when anything blocks its way. It will still pause - but continue to open if the block is removed.
"stop_when_blocked" "0" // door keeps moving after being blocked (default is off)
With this setting, doors will still stop at blocking entities (the player, for instance), but will continue to move when the entity clears the way.

There is another spawnarg which stops a door pushing a moveable. Apply this to the ''moveable'' not the door...

"notPushable" "1"

===Door Sounds===

The sound of doors opening and closing is set in the snd_open and snd_close properties. You can silence them by setting the following properties as shown:

''snd_open nosound'' 
''snd_close nosound''

Don't just use a dash - as it seems to cause a sound of its own.

The above sounds are triggered as the door begins to open (eg, unlatch sound) and when it finally closed (eg, slam.) For special doors that need an on-going sound, eg, a big stone slab that moves slowly, then use:

''snd_move''

''snd_locked'' 
The sound played when a player tries to open a locked door.

''snd_unlock string'' 
The sound played when a player unlocks a door.

===Sound Propagation through Doors and Doorways===

The sound volume reduction to the player (ie, the sound the player hears) is fixed and constant in a cvar which adds a distance factor to the original sound. It is recommended that you do not change that because it will affect other FMs. Currently there is no way to change the way that sound to the player is reduced through doors and doorways.

Sound propagation to AI, eg, impact sounds or guard yells is treated separately:

Sound propagation to AI relies on visportals. For details study [[Sound Propagation: Part 1]] and [[Sound Propagation: Part 2]] as well as [[Visportals]] This tutorial will just cover the relevant sound and sound propagation ''properties'' of doors. If you set the ''show inherited properties'' box in the entity inspector you can see them as described here.

Remember, the following have no effect on what the player hears through a door or doorway.

''loss_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through an open door. (default 1dB)

''loss_closed'' 
Drop in sound volume in dB propagated to AI (not player) when going through a closed door. (default 15dB) You would want to set this very high to block all sound with a thick door but very low for a barred gate for example.

''loss_double_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through double doors when only one is open. (default 1dB)

There are also various sound properties for lockpicking: 
''snd_lockpick_pin_1 through 14'' and ''snd_lockpick_pin_success''

===Speed of Door Opening and Closing===

Rotating Door Speed: 
At the time of writing, the time a rotating door takes to open or close is set in the ''move_time'' property whatever its maximum open angle. So with rotation set at say 150 degrees the door just opens faster than at say 80 degrees. This is likely to be changed to a constant angular velocity so check to see if there a new property added if the following no longer works. The problem is that if an interruptable (see Extra Notes) door is frobbed while in motion it stops; another frob will reverse the motion - so even if the door is only open a crack it will still take the full time to close and vice versa.

To change the time a rotating door takes to open or close, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''move_time''
* Edit the second line of the input box ''below'' the properties window to the time you want.
* The time is in seconds and decimal fractions can be used.
* The default is 1 second and if set to this then the door opens and closes in one second whatever the maximum open angle, great or small.

Sliding Door Speed: 
The speed of a sliding door is set in the ''translate_speed'' property. To add this, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''translate_speed''
* Edit the second line of the input box ''below'' the properties window to the speed you want.
* The speed is in Dark Radiant grid units per second.
* The default is 0 and if set to this then the door slides open in one second whatever the distance, great or small.
* CAUTION: If you later change the door back to a rotating door then delete the ''translate_speed'' property or ensure it is set to 0 as (at the time of writing but this will be fixed) a bug makes rotating doors open and close instantly. (Note: you can still mix sliding with rotating but check - this bug might only be if ''translate'' is set to 0 0 0)

===Visportals and Doors===

A visportal face surrounded by solid at its edges and in contact with a door is closed when the door is closed and enabled when the door is open. In most cases you will place a visportal in contact with a working door unless you can see through the door (such as a true glass door or barred gate.) For full details see [[Visportals]].

==Auto-Closing/Opening Doors==
Doors that automatically close after being open for some time are easy to setup: Each frobmover entity supports these spawnargs:

;"auto_close_time":Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
;"auto_open_time":"Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

Old text:

Note that auto-closing doors and AI closing doors behind them, is very much work in progress at the time of writing, so for now, this is another method that works. Check first if true AI closing of doors is working yet before bothering with this!

I have one door that I particularly want the AI to close as there is a bit of frame lag inside if not. So I set this up and it works good as an auto-closing door - not as good as a true AI closing door as it will auto close when the player goes through as well but it does look very effective to see AI going through and closing the door behind them. Not tested exhaustively so I don't know if there could be any downside. Here's what to do....

First a quick summary to make it more clear:

'''''A trigger_relay is used both as a relay AND carries a stim. We put the trigger_relay with its stim in the path of the open door. The door has a response property. When it opens and contacts the stim its response is to send a signal back to the relay. The relay pauses then closes the door...'''''

* First, optionally give your door a suitable name like autodoor1, whatever.
* Copy that name to the clipboard.

Next we need a relay with a delay:

* Create entity > darkmod > trigger_relay

* Place it roughly at the position the door will be at when open and to be on the safe side 3/4th of the way to the far end of the door (not the hinge end) to give max distance from the close door.

* Add the property 'target' and paste in the door name you just copied.

* Give the relay itself a name, eg, autoDoor_relay_1, and copy that name to the clipboard, you'll need that too in a bit.

* Add the property delay and the value 3 - this is the delay in seconds before the door will close; 3 seems about right but 2 might be worth a try because to that 3 is added a random value between 0 to 0.5 seconds from the Time Interval we entered for the stim firings.

* Add the property 'wait' and the value 3. This is the time before it can work again in seconds. If you set it too low then in theory the door might trigger again but in this situation I don't think it's possible. Too long, eg, one minute, and it won't work if the AI goes back through the door before then. If this value is -1 then the whole thing will only work ONCE so might be used for an AI who goes through once, closes it behind him, but you don't want it to be an autodoor thereafter.

That's the relay, now we add a stim to it:

* Still with the trigger relay selected, go to {{menu|Entity|Stim/Response}}

* Custom stim tab.

* Click Add stim type, select the new custom stim type you just made at the bottom of the list and type in eg, autoDoorStim at top right in the input box.

* Click the stim tab and the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Select the new autoDoorStim in the list and on the right you need only type in the radius box 15.0 There is quite a lot of room for error. I had it working on 10 and also on 25. The value should be less than the distance to the closed door else it will trigger open! But no so small that the door might not reach it.

* Select the check box for Time Interval and enter 500 (millisecs.) This is so it doesn't keep firing more frequently than is necessary. This stim will be firing all through your mission whether the door is used or not so if you had dozens of these then maybe it would affect performance. Too big a number and there may be a long delay before the door shuts - but it will be random depending on the next time the stim happens to fire. We'll control the delay we want more precisely later.

* Click {{ok}} to confirm it.

That's the stim set up, now for the response to it which is put on the door....

* Select the doorm, then use {{menu|Entity|Stim/response}} and select the response tab.

* Click the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Right click in the big ''Response Effects'' box on the bottom right of the panel.

* Add New Effect and you should get a default 'Activate Response' response added to the list. Double click it.

* In the Effect selector at the stop select 'Trigger'

* in the Target box, paste in the name of the relay you copied or you can select it from the list at the little arrow.

* Leave the Activator box empty.

* Click {{apply}} and then {{ok}} on the main S & R panel bottom right.

It should now work. No need to wait for an AI, just frob the door and watch it close itself. If not, check the position of the stim brush is close to where the door stops when open.

==AI Door management==

See also [[#Keys_carried_by_AI]] above.

By default AI will open doors and close them behind them. Here are some spawnargs the mapper can use to modify that behaviour:

;"ai_should_not_handle" :If set to 1, AI will not attempt to handle it and add it to the forbidden areas when closed (so that it doesn't try to path through). They might still walk through the door when it is open though. Useful if you have some special use door that you don't want the AI to operate.

;"ai_should_not_close" :If set to 1, AI will not close the door behind them unless it obstructs them.

To get AI to unlock/relock specific doors there are two methods currently:

1. add the following spawnarg/value to the AI:

;"can_unlock1" ''<doorname>''

'''Do NOT use can_unlock_1.'''

For additional doors on the same AI use ''can_unlock2 doorname'' etc.

2. In the editor position an actual key that works for that door on the AI and also add to the key bind <AIname> and also bindToJoint LeftHips_Dummy (see other joints names elsewhere in wiki.) Currently, if the player pickpockets the key then the AI seeks an alternate route but otherwise does nothing (?) This may be upgraded in the future to better strategies.

3. There is the possibility in the future of an additional method which would just use special attach spawnargs to make the above easier. The key would spawn at the correct position at game start. Watch this space.

'''Door handling positions'''

It is also possible to set custom door handling positions for the AI. This is especially useful when the standard routine that lets the AI choose their standing positions while opening and closing the door fails, leaving them circling around in front of the door helplessly.

Place a movers > atdm:door_handling_position entity where you want the AI to stand while opening/closing the door from this side.(it can be found in the movers folder in the entity chooser)

On the door, you need to set the spawn arg "door_handle_position" "name_of_door_handling_position" You can also place a door handling position on each side of the door, the AI should automatically choose the right one. In this case, you need to set spawn args with "door_handle_position_1" etc and the corresponding names of the door handling position entities on the door.

The door handling positions can also carry spawn args that define the behaviour of the AI, which are useful for example for doors that can only be openend or locked from one side:

'''"ai_no_open"''' If set to true, the AI will not try to open the door from this side (but still walk through when the door is already open)

'''"ai_no_close"''' If set to true, the AI will not attempt to close the door from this side

'''"ai_no_unlock"''' If set true, the AI will not be able to unlock the door from this side, but still use it when it is not locked.

'''"ai_no_lock"''' If this is set true, the AI will not lock the door from this side.

==Doors as Triggers==

''by Ishtvan & greebo''

Doors (or any binary frob mover, buttons, levers, etc) now have the option to trigger their target on closing or opening. (For definition purposes, a button is defined as "closed" in the state when it starts out and "open" in the state you press it down to. I know that's a little non-intuitive, but it came from deriving from doors).

New spawnargs on frob movers:
;"trigger_on_open" :If set to 1, this binary mover will trigger its targets when it starts out completely closed and is opened.
;"trigger_when_opened":If set to 1, this binary mover will trigger its targets when it is completely opened. Code defaults to 0.
;"trigger_on_close":If set to 1, this binary mover will trigger its targets when it completely closes after being open.

==Skins: A Wide Variety of Door Textures==

This is to remind you that as with many Dark Mod models, there is a wide range of extras skins (textures) available for door models. There are now several basic door entities of different sizes so choose your size first. Then enter the spawnarg: skin with any temporary value. Now select it and click the skin button at the bottom of Dark Radiant's Entity Inspector and you will find a large of range of skin textures from which to select to give you a choice of appearances for your door.

==Extra Notes==
The property ''interruptable'' determines whether a door can be stopped by frobbing while it is opening or closing. So by frobbing then frobbing again, the player can open a door to any position, eg, slightly ajar to peek through.

''func_darkmod_door'' is no longer used (just in case you come across it in the Dark Mod forums or wiki.) The Doom func_door is still available but for Dark Mod, but <code>atdm:mover_door</code> is the entity to use.

{{tutorial-editing}}

List of shaderParm variables

2011-01-30T20:09:32Z

Fidcal: /* List of shaderParms */

Variables named '''shaderParm0''' to '''shaderParm11''' influence the rendering of certain materials. They are either set once in the map editor for some specific entity, or at run-time by various scripts or the C++ code.

Inside material definitions, these can be accessed via '''parm0''' ... '''parm11'''.

The parms are on a per-entity base, so you can f.i. influence the material (and thus color) of entities or the color of the light.

See also the [[list of global variables]].

== List of shaderParms ==

{|border=1 cellpadding=5 cellspacing=0

|-
!bgcolor=#ffdead|#
!bgcolor=#ffdead|Value
!bgcolor=#ffdead|Used by
!bgcolor=#ffdead|Type

|-
|0
|0.00 to 1.00
|Red value set by [[_color]] spawnarg in the editor
|once

|-
|1
|0.00 to 1.00
|Green value set by [[_color]] spawnarg in the editor
|once

|-
|2
|0.00 to 1.00
|Blue value set by [[_color]] spawnarg in the editor
|once

|-
|3
|0.00 to 1.00 (or to X.yz)
Set by spawnarg shaderParm3 on the entity in the editor.
|Materials: Alpha (transparency) value, eg, alphatest 0.8. Also used in some LOD materials as the alpha threshold, in this case the engine adjusts the value between 0 and 1.0 at runtime depending on distance to the player.
Foglights: Distance in units beyond which fog is completely opaque (so higher values make fog thinner.)
|once run-time

|-
|4
|0 to 1
|set shaderparm4 on flickering lights with a value 0 to 1 to vary the flicker offset so they don't all flicker in sync.
|?

|-
|5
|about 0.05 .. 0.5
|Used by [[atdm:liquid_water]] entities to control the (translation) speed of the water waves. Default is 0.1.
|once

|-
|6
|about 0.5 .. 3
|Used by [[atdm:liquid_water]] entities to control the hight of the vertex waves. Default is 1.5.
|once

|-
|7
|0..1 (brightness)

0..1 (speed)
|Used by the moon-light textures in <code>textures/darkmod/sfx/</code>

Also used by some tree entities to vary leaf movement speed, eg, for wind. See [[Trees and how to make custom ones]]
|once

|-
|8
|0..360
|Used by the clock hand decals to mimick time-keeping
|run-time by script

|-
|9
|?
|?
|?

|-
|10
|?
|?
|?

|-
|11
|0 or 1
|non-zero when something is highlighted for frob. This is used by material definitions to make materials "light up" when entities are in the frob-highlight.
|run-time

|}

== See also ==

* The [[list of global variables]]
* [[:Category:Spawnargs|List of all spawnargs]]

{{tutorial-editing}}

Shop

2011-01-24T14:15:50Z

Fidcal: /* Preventing the player dropping critical items */

{{todo}} 
''originally posted by joebarnin''

Click here for a [[default purchasable items]] template.

==How to NOT show the shop==

The shop shows by default at mission start. If you don't want it then add this spawnarg and value to your map's worldspawn:

shop_skip 1

==Notes==

I added code support for shop entities to be placed the map, like difficulty settings or objectives entities.

- The entity is called atdm:shop.
- The spawnarg format is the same as for the worldspawn.
- Settings on Worldspawn are still supported, for "backwards" compatibility.
- Multiple atdm:shop entities can be added to the map, all of them are considered.

Additionally, I refactored the shop parsing code, so that a "gap" in the spawnarg numbering doesn't stop the parser. For instance, it's now possible to do something like this:

"shopItem_1_0_item" "atdm:weapon_broadhead"
"shopItem_1_0_qty" "10"
"shopItem_3_0_item" "atdm:weapon_waterarrow"
"shopItem_3_0_qty" "10"

Note the missing "2" in the indexing. The parser just continues, which should make prefabbing easier and set up more robust against user errors.

==Setting up Shop==

Add an atdm:shop entity to your map (probably in the "blue room"). You can add the following lines in the editor, but it might be easier to load up your map file in a text editor, find the adtm:shop entity, and cut and paste.

"shop_gold_start" "700"
"shopItem_1_item" "atdm:playertools_flashbomb"
"shopItem_1_qty" "5"
"shopItem_2_item" "atdm:weapon_waterarrow"
"shopItem_2_0_qty" "5"
"shopItem_2_1_qty" "3"
"shopItem_2_2_qty" "1"
"shopItem_2_cost" "225"
"startingItem_1_item" "atdm:weapon_broadsword"
"startingItem_1_qty" "1"
"startingItem_2_item" "atdm:weapon_blackjack"
"startingItem_2_qty" "1"
"startingItem_3_item" "atdm : playertools_health_potion" (remove the spaces around the colon)
"startingItem_3_0_qty" "2"
"startingItem_3_1_qty" "1"
"startingItem_3_2_qty" "0"

_# : item number, starting from 1. No gaps.
_#_X: X is the skill (difficulty) level this value applies to. So in the above example, the shop contains 5 water arrows at
easy, 3 at medium, 1 at hard (difficulty goes from 0 (easy) to 2 (hard)). If you leave off a skill, quantity zero is assumed
(e.g., if there was no "shopItem_2_2_qty", then there would be zero arrows for sale at hard level). Note you can have cost
vary by difficulty as well. And starting item quantities too.
_item: the "classname" listed in the entitydef (see tdm_shopitems.def).
_qty: how many are for sale (or, if a starting item, how many to start with)
_cost field is optional (otherwise it uses the default cost defined in tdm shopitems.def).

Okay, now you've updated your map with something like this, so get back to the Shop and buy what you want. Start the mission. You should have the appropriate number of items.

tdm-shopitems.def defines the list of the common items that can be purchased (or that can be in the Starting Items list). This file documents the format of ShopItem entityDefs, so if you want to add unique items to your own .def file, you can.

shop.cpp and shop.h are new files that define CShop and CShopItems, classes for dealing with the Shop screen.

player.cpp was updated to create the purchased items

game_local.cpp was modified to handle the Main Menu commands. This was the only way I could figure out to have the shop talk to our code. Apparently the id code behaves differently when your in the main menu.

==Preventing the player dropping critical items==

There is a cannot drop' option for start items, eg, a spawnarg, "startingitem_15_2_candrop" "0". For use with mission-critical items (like lockpicks) so full start equipment can be shown in the shop without risk the player will drop something crucial.

{{tutorial-scripting}}

Voices

2011-01-22T19:50:07Z

Fidcal: /* AI Characters */

== AI Vocal Sets ==

Although AI come with a default vocal set, mappers can easily modify what kind of voice each AI uses.

== AI Characters ==

In order to create a variety of character types, vocal sets have been created for various "characters". A character, in this sense, is a distinctive voice, personality, and way of speaking. The vocal set of any particular character can technically be used for any AI type, though some have been tailored to suit particular AI better than others.

By designing 'character' voices, mappers have the freedom to give voices to AI based on their personality rather than just their entity type.

== Changing the voice an AI ==

There are two ways to change the voice of an AI.

===Dark Radiant's Voice Selector & Preview===

* In Dark Radiant, select the AI and check the 'show inherited properties' checkbox at the top of Entity Inspector.
* Scroll down to "def_vocal_set" and select it
* A button should now show at the bottom of Entity Inspector 'Select Vocal Set'
* Click that button and select a voice.
* You can use the 'play' button shown in that selector to hear samples of the voices.

===Manually typing the voice name===

To change the voice of any AI add the following spawnarg to the AI in your map:

"def_vocal_set" "[name of vocal set from list below]"

== Vocal Sets ==

The available character vocals are listed below. Each set has a "guard" and "civilian" version. Choose the civilian version for unarmed characters.

Vocal sets are defined in darkmod/def/tdm_ai_vocal_sets.def

1. '''"The Thug"''' -- crude and crass; uneducated; violent; threatening voice, talks about gambling, bullying, whoring, and bodily functions; swears a lot (suits guards, commoners, thieves)

* '''atdm:ai_vocal_set_thug_guard_01'''
* '''atdm:ai_vocal_set_thug_civilian_01'''

[http://www.mindplaces.com/save/thug_ex.wav Hear Example]

2. '''"The Grumbler"''' -- a bored, seen-it-all character with a gravelly voice; complains a lot; uneducated; gruff, talks about his aches, pains, hunger, boredom, losing at gambling, etc (suits guards, forger, servants, commoners)

* '''atdm:ai_vocal_set_grumbler_guard_01'''
* '''atdm:ai_vocal_set_grumbler_civilian_01'''

[http://www.mindplaces.com/save/grumbler_ex.wav Hear Example]

3. '''"The Pro"''' -- professional, cool; uneducated but experienced; man of few words, very aware of his surroundings, often predicts the player's behaviour; talks about doing his job well (suits guards, elite guards, mages, thieves, inventors, nobles)

* '''atdm:ai_vocal_set_pro_guard_01'''
* '''atdm:ai_vocal_set_pro_civilian_01'''

[http://www.mindplaces.com/save/pro_ex.wav Hear Example]

4. '''"The Mature Builder"''' -- strong voice, experienced, determined; archaic language; patient and somewhat monitone, talks about servitude, orthodoxy (suits builder guards, forgers, inquisitors, priests)

* '''atdm:ai_vocal_set_builder_03_guard'''
* '''atdm:ai_vocal_set_builder_03_civilian'''

[http://www.mindplaces.com/save/builder3_ex.wav Hear Example]

5. '''"The Young Builder"''' -- young; overzealous; slips out of archaic language sometimes; cliché scriptures, full of faith and burning with confidence, talks about doing great things. (suits builder guards, acolytes)

* '''atdm:ai_vocal_set_builder_04_guard'''
* '''atdm:ai_vocal_set_builder_04_civilian'''

[http://www.mindplaces.com/save/builder4_ex.wav Hear Example]

6. '''"The Lord"''' -- strong voice; educated; arrogant and cold; dismissive, talks about himself and his own power/money. The Lord is used to being obeyed. (suits noblemen, elite guards, mages, inventor scientists)

* '''atdm:ai_vocal_set_lord_guard_01'''
* '''atdm:ai_vocal_set_lord_civilian_01'''

[http://www.mindplaces.com/save/lord_ex.wav Hear Example]

7. '''"The Simpleton"''' -- a simple, unintelligent character, who speaks in a slow, measured voice. He goes about his life dealing with the here and now, and doesn’t think much about anything beyond what he’s doing. Tends to state the obvious. (suits commoners, generic guards)

* '''atdm:ai_vocal_set_simpleton_guard_01'''
* '''atdm:ai_vocal_set_simpleton_civilian_01'''

[http://www.mindplaces.com/save/simpleton_ex.wav Hear Example]

8. '''"Average Jack"''' -- (added 1.02) a generic character, tends to complain. (suits commoners, generic guards)

''each 'type' below is basically the same, but with slightly different idle lines.
''
* '''atdm:ai_vocal_set_jack_guard_01'''
* '''atdm:ai_vocal_set_jack_civilian_01'''
* '''atdm:ai_vocal_set_jack_beggar_01'''
* '''atdm:ai_vocal_set_jack_cook_01'''
* '''atdm:ai_vocal_set_jack_labourer_01'''
* '''atdm:ai_vocal_set_jack_merchant_01'''

===Incomplete vocal sets:===

* '''atdm:ai_vocal_set_builder_01''' -- contains only a builder conversation

* '''atdm:ai_vocal_set_builder_02''' -- about 3/4 complete at present, barely usable.
[http://www.mindplaces.com/save/builder2_ex.wav Hear Example]

[[Category:Editing]]

Moveables

2011-01-22T17:15:34Z

Fidcal: /* Create a Collision Model (CM) */

{{Original_Reference|SneaksieDave & Ishtvan|3968}}

Physics fans rejoice! If you want an object (whether a model or multi-brush/patch) to be moveable (pick up and carry, push, float, shoot, etc.), even though it wasn't designed to be used that way, there is a way to do it anyway, and all within the editor.

==Models==

In summary you need to create the model, make it moveable, and make sure a collision model exists for it...

=== Create a Moveable Model ===

# Create a brush, convert it to a moveable_base entity, and assign it the model you want to use.
# You only need one collision model file no matter how many instances of this moveable you make in your map so check if it has already been created (a .cm file of the same name as the model and in the same folder.) If not..

=== Create a Collision Model (CM) ===

In DarkRadiant:
# '''Important''': Make sure the model is not rotated in any way.
# Drag a new temporary brush over the model, roughly covering it.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Any texture will do on any surface.
# Convert to func_static (any entity will do)
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game. If they do not coincide then either move the brush so it coincides and resize the brush or key V and drag the origin into position.
# Use the {{menu|File|Save selection as collision model}} menu entry:
# The model selector dialog appears, Select the correct model. Click {{ok}}.
# A .cm should have now been saved in the same folder as the model and with the same name as the model.
# You can now delete the temporary collision model brush entity.

In DoomEd:

# Drag a new temporary brush over the model, roughly covering it. This will be the collision hull, so get it as close as you can.
# Clip the shape if necessary, or convert it eg, to pyramid or whatever to best fit the model.
# Convert that brush to '''func_clipmodel'''.
# Check the origin of the brush entity is in the same place as the model's origin because that is where its origin will be in-game.
# Texture it with '''common/collision'''.
# With that brush still selected, do '''Selected->Export->To CM'''. Locate the model for which it will stand as a clipmodel, and save with the same name. The path and name are vital. Don't worry, DoomEd will automatically name it .cm instead by of your model's extension, so it shouldn't overwrite anything.
# You can now delete the temporary collision model brush entity.

==Brush/Patch Moveables==

You can make virtually any brush/patch construction into a moveable. At its core must be a simple brush to form the collision shape. I've had a brush with 12 surfaces as a moveable OK. I don't know if there is a limit but it's my belief that it won't work if too complicated a shape. However, we can get round that and produce very complex moveables such as a stepladder with multiple steps and ladder surface. We do that by binding the construction to a single central collision shape brush which is the actual moveable entity.

===Simple brush moveables===

First let's take the simplest of brush moveables: a stone block. It is not uncommon in FMs to have a hole in a wall filled with stone blocks or rubble the player can move or push out of the way. So first make your brush stone block from the same texture as your wall so it will match perfectly (if desired.) If it is a broken block (rubble) then you can cut pieces off the basic rectangular block but I would get it all working first and save it then gradually cut piecess off and save the early versions. You might find if you have too many surfaces it might not work. (I am still unsure about this.) I have not tried with patches but it should work. In any event you can certainly bind a patch to an unrendered block to get what you want.

* Make the brush an atdm:moveable_base entity. Later a proper entity inheriting from atdm:moveable_base might be made up with the following spawnargs to save time. (I couldn't get this to work with the custom entities which have to use a model.)
* Give it mass (in kilos)
* No need to give it density as this is now calculated from its volume and mass.
* Give it friction (0 to 1) I usually aim low about 0.1 else it can be 'sticky'
* Give it snd_bounce as the sound it will make on impact. Example: med_metal_impact. I suggest you look at what some already existing moveable of a similar size and material is using.
* Give it an alert size and hardness. This determines how AI will react to its sound. If you don't then it will default to medium size and hard so if your object is about that then you need do nothing. Otherwise, give it these two spawnargs/values. These are the possibles:
** spr_object_hardness - can be soft, medium, or hard
** spr_object_size - can be small, medium, or large

By default, the above will highlight and can be pushed about, frobbed and picked up, carried, and manipulated by the player.

If you want it only to be pushed but not picked up then give it frobable 0.

If you want it to go in the inventory:
* Give it inv_category. This can be eg, Special, Tools, Keys. (look at currentsimilar objects)
* Give it inv_name with the value of whatever name you want it show in the inventory.
* Give it inv_icon with the value guis/assets/hud/inventory_icons/default which will show blank (otherwise you get a black square.) If you can create your own icon then even better.
* Give it snd_acquire with the value tool_pickup is a good default (the sound it makes when the player gets it.)

===Remake the map cm file if console error===

'''IMPORTANT!''' This caused me a lot of headaches over a couple of years until I realized so memorize this even if you forget everything else. When you first make a brush moveable it might work fine but later you get a console error: 'cannot load collision model'. You might get this if you rename the entity or import it as a prefab into another map. What you must do is DELETE the map cm file (in maps folder mymap.cm) then DMAP again. Dmap doesn't know if you changed anything so you need to force it to recreate the map collision file.

===More complex brush and patch moveables===

To make complex brush moveables like a stepladder you first create a simple brush moveable as described above and texture it with textures/common/collision. Size and shape this brush to approximate the basic size and shape of the object you are making. Try to avoid over-complexity of this shape; it only needs to determine collisions. For example, for the stepladder I made an upright right-angled triangle shape. This is the core of the stepladder; the actual moveable entity as described in the above section. You then make your more complex shape(s) into func_static(s) and bind to the collision shape to get the best fit. The collision shape is what the player picks up but it is not visible of course.

==== Making frobable ====

The above is OK for pushing around but if you want to be able to pick up the object it needs to be frobable. At this point only the invisible collision moveable is frobable but its highlight is invisible! To make the visible object frobable do the following:

To the invisible moveable add the property/value:

''frob_peer'' <name of visible object>.

To the visible object add the properties/vaues:

''frobable'' 1

''frob_distance'' 1 (do NOT use 0 or it defaults to the normal distance.)

What the above does is allow the visible object to highlight but not directly frobable. Instead when it highlights it means you are focused on the invisible moveable which is what you want - and it highlights the visible object through the frob_peer.

===Model/Brush hybrid===

In the earlier sections on making a moveable model is described how to make an external model cm file. In some situations you might instead bind a static model to a brush moveable as described above. In some cases you might make the brush moveable visible or some surfaces visible. An example makes it easier to understand: I took a model chest body. Made a rectangular brush moveable to completely fill it. I textured it with textures/common/collision but the top surface I gave it the texture that the chest used. When aligned carefully it complete sealed the top so it looks like a new luggable crate. Then bind the chest model to the brush moveable. To make it frobable see above [[#Making frobable]]

== Complete List of Default Key/Values for Moveable entities==
"Moveable object. Will drop to the floor and rest until activated."
"The visual model set with the 'model' key can also be used for"
"collision detection. However the model may not be too complex."
"max vertices = 32"
"max edges = 32"
"max polygons = 16"
""max edges per polygon = 16"
"The collision model must be an enclosed hull. Dangling polygons or"
"edges are not allowed. If the visual model is too complex or does"
"not meet these requirements it can be contained in a less complex"
"model for collision detection. Such a collision model is specified with the"
"'clipmodel' key."

"editor_var density" "Volume of the object times the density is the mass."
"editor_var friction" "Friction with contacting surfaces in the range [0-1] where 0 is no friction."
"editor_var bouncyness" "How much the object bounces in the range [0-1] where 0 is no bounce."

"editor_var mass" "Mass of the object (overrides density)."

"editor_model clipmodel" "Model to be used for collision detection."
"editor_var clipshrink" "Shrink the visual model with an epsilon and use it as a clip model."
"editor_var allowStep" "Set to 0 to prevent monsters from ever walking over this object."
"editor_var nonsolid" "Make the object non-solid."

"editor_bool nodrop" "Do not drop to the floor."
"editor_bool noimpact" "Do not activate by the impact of other objects."
"editor_bool notpushable" "Do not allow to be pushed."

"editor_bool unbindondeath" "Unbind entity when health drops down to or below zero."

"editor_var health" "If set the visual model changes to 'broken' when the health drops down to or below zero."

"editor_model broken" "Visual model to be used when the health drops down to or below zero."
"editor_bool explode" "If set to 1 the moveable explodes and is removed when the health drops down to or below zero."

"editor_var init_velocity" "Initial linear velocity set when activated."
"editor_var init_avelocity" "Initial angular velocity set when activated."

"editor_var init_velocityDelay" "Delay in seconds before the initial linear velocity is set after being activated."
"editor_var init_avelocityDelay" "Delay in seconds before the initial angular velocity is set after being activated."

"editor_var initialSplineTime" "Number of milliseconds the moveable should follow the initial spline path."

"editor_var damage" "Damage definition if it damages things it collides with"
"editor_var damageWhenActive" "Only damage when active ( currently for the vagary and influence stuff )"

"editor_var fx_collide" "FX system to start at impact position when object collides."

== Default Settings ==
"density" "0.5"
"friction" "0.05"
"bouncyness" "0.6"
"explode" "0"
"unbindondeath" "0"
"health" "0"
"nodrop" "0"
"noimpact" "0"
"notPushable" "0"
"clipshrink" "0"
"allowStep" "1"
"snd_bounce" "smallpanel_impact "

== See also ==
* [[Pushing]] of moveables.

[[Category:Editing]]

Doors

2011-01-18T06:45:37Z

Fidcal: /* Sounds and Sound Propagation through Doors and Doorways */

{{todo}}
''Written by Fidcal'' ''edit Baddcog''

==Quick Summary==

Quick way to get an unlocked door in your map:

* Insert one of the prefab doors complete with handles and select its skin property and click the button to change its skin appearance to whatever you want. Set any other properties you need.

Alternatively,

* Create a door from the entity list
* Use the "skin" spawnarg on the door to change its appearance.
* Create a handle from the entity list
* Add the ''door_handle'' property to the door and give it the name of the handle
* To the door handle add the value frob_peer and use the name of the door.
* To open clockwise, change the ''rotate'' property from <code>0 90 0</code> to <code>0 -90 0</code>

==Introduction==

This tutorial explains how to put doors into your map using Dark Radiant, as well as adjust them and their properties.

The rest of this tutorial assumes that you have a basic understanding of using DarkRadiant. If you haven't done so, please go read the [[Dark Radiant Must Know Basic Intro]] article first.

Additionally:

* Up, down, left, and right in Dark Radiant's ''top'' orthoview are regarded here as the standard map directions of North, South, East, and West where useful for clarity.
* Where the term ''brush'' is used with a door it mostly also applies to a door made up of a group of brushes and/or patches.
* Where the term ''door'' is used it often will also apply to any object you wish to rotate when frobbed, for instance an openable window, box lid, or even more exotic objects that the imaginative mapper might conceive like a signal, engine part, toy, or whatever. So long as it needs to turn or slide just a fixed amount when frobbed then return when frobbed again then the following applies.

==Door types==

All tangible objects in Dark Mod are ''entities'', having either a pre-made model shape or else brush/patch(es). So there are two ways to create a door in Dark Radiant: as a model door or a textured brush door (or a hybrid of the two).

Models are ready made door objects but cannot within Dark Radiant (at the time of writing) be resized, rescaled, cropped or clipped whereas brushes are very flexible in that respect and can be worked into custom shapes for your map, including secret doors that blend into walls and other surfaces.

Most of the current door models are found in two places along with the door handles.
*Model Viewer: doors created from here will be static in the world and have no props other than material type.
You can add any props to them to make them working doors. If nothing else it is a good place to view the different size and skin options for the doors.
*Entity List: most of the door models can be found here. These doors have properties already assigned so they are ready to be used. Only one base door of each type is listed, create the size/hinge count door you want (2 hinge doors have a 'no hinge' skin). You can choose a skin for the door once it has been created in the editor with the "skin" spawnarg (use the model name of the door you want, taken from the model list, as its value). This is the easiest way to create a door. The same goes for door handles.

Remember also that door functions may be applied to objects other than doors for instance to openable windows, drawbridges, gates, in fact anything that needs a partial rotation or slide when frobbed then return when frobbed again such as a signal device. Lockboxes and chests use similar properties.

Door/handle prefabs seem to crash Doom3 when trying to reload a map so far now just create and link each door/handle. You can create one set and copy/paste them, but you need to take great care that all the name props are changed to match each clone. Otherwise you get handles that fly off with a distant door and handles that don't move.

==Creating a Door==

Put simply, to make a door you will be creating an 'entity with model' or 'entity with brush' or some variation thereof.

===Creating a Model Door===

There are several approaches to making a model door; the simplest is to create a door from the entity list; or create a door from the model viewer (good for static unusable prop doors).

'''Entity List''':

*Deselect everything in editor by hitting the Esc button
*Right-click an ortho view and select Create Entity
*Navigate to darkmod/movers/''atdm:door_...'', choose the door you want
*Click Add
*To change its appearance, add a "skin" spawnarg to the door, with the value being the model name of the door you want.

You now have a workable door in your level.

'''Model Viewer''':

* Right click in the orthoview, select ''Create Model'' then <code>darkmod</code> and select a door.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* Click [[Image:Button ok.png]] and you have a static door.
* If you want to make it work (openable, frobbable) then:
** Select the entity inspector,
** Select the top classname line so it highlights
** Select the func_static line in the input box ''below'' the properties window.
** Edit <code>func_static</code> to <code>atdm:mover_door</code>
** Click {{check}} or press {{key-enter}}

Alternatively you can do it the old way:

* Create any temporary brush
* Right click in orthoview and select <code>Create Entity</code> then <code>atdm:mover_door</code>.
* Left lick the model name line in the entity inspector.
* Below it on the ''Entity Inspector'' panel you should now see a button 'Choose Model'
* Left click it, select a door model from the darkmod group.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* The temporary brush was deleted.

In all three instances, you now have a working door with default properties.

Name your door by adding the prop (or modifing it) to name ''My_Door_1''. You can use any name that you feel is appropriate but all doors with handles attached ''must'' have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below).

To add a handle and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

===Creating a Textured Brush Door===

'''Tip:''' If unsure of size then you might insert a temporary human AI first to get a sense of height.

==== The simplest brush door: ====

* Drag out a new brush to the size required, eg, a seven foot high door is 84" x 1.1 = about 90 units in Dark Radiant.
* Give it a door texture from the texture browser (or wall texture for a secret door)
* Right click in orthoview and select ''Create Entity'' then <code>atdm:mover_door</code>
* You now have a default door that rotates around its center.

To move the rotation point to the door edge and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

==== Multi-brush doors: ====

More complex multi-brush doors can be created using the [[Clipper]] tool, CSG, etc. - this is not covered in this tutorial. Then assign <code>atdm:mover_door</code> for that whole brush structure. Also you can collect various brushes positioned together in relation to one another as needed, select them all, then assign <code>atdm:mover_door</code> for the group. All the brushes will be children of the <code>atdm:mover_door</code> entity and will rotate and be frobbable, etc. as one unit, as one door. To add further brushes or even model shapes later see the section on [[#Adding handles and other items to doors]].

Name your door by adding the prop (or modifing it) to name My_Door_1. You can use any name that you feel is appropriate but all doors with handles attached must have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below). (repeated from above in case you didn't choose to create a model door)

=== Double Doors ===
Double doors are automatically recognised by the code when the doors are spawned. The prerequisite is that both doors are sharing/touching the same visportal. The spawnarg ''auto_setup_double_door'' (which defaults to "1") will take care of setting up the open/lock peer relationship between the two doors. The doors will open/close and lock/unlock along with each other as a result.

What happens behind the scenes: the doors are adding each other to their internal open_peer and lock_peer list, which causes the double doors to perform the same action when frobbed or used.

Note that ''auto_setup_double_door'' will not set the frob_peer relationship, i.e. each door will frob-highlight on its own without highlighting the other door. You'll need to add that spawnarg manually if you want to highlight the entire double door as one.

==Customising and Adjusting Door Properties==

Handles, lockplates, etc. can be added to doors and door properties can be adjusted for rotation, sliding, locking, and more.

Some of the door models have hinge plates and lockboxes that are reskinnable with a good variety of skins.

===Door handles and other door attachments===

Summary: just add the property ''bind'' with the door's name to the attachment and position it where you want it on the door. If it's a ''atdm:mover_door_handle'' then it automatically will work as a handle but you can bind virtually anything.
You can add handles and other items to doors such that they move correctly with the door whether rotating, sliding, or both and even if the door is not vertical such as a skylight or trapdoor.
Handle models come in two types, ''single handles'' and ''double handles''. A single handle is one sided, this means the handle will be inside the door or outside the door, but not both. A double handle has a lever on the inside of the door and a handle on the outside of the door. Each has benefits.

*'''''Single door handles''''':
Single door handles can be used on a static door, a door that's just for show that no AI's or the player can use. In this case you should just create a door handle from the model viewer, it will be static and have no properties such as scripts. It is for looks only.

Single handles can also be used inside AND outside of the same door to save on rendering. Unlike the double handles the handle on the inside of a portal won't render. The curved handle is only about 130 polys per side, but if you have a large area and 10 handles you can save 1,000 polys from being rendered. Everything counts when it comes to performance.
I will call this ''multiple handles'', see more below.

These can also be useful on brush doors created in the editor that may be very thin or very wide.

*'''''Double door handles''''':
These are models have have a handle inside and outside. The bonus is that they only use one entity. Maps are limited to about 4,000 entities but when you count lights, AI, sound speakers, ect... you can run out of entities quickly on a large map. If you plan on building a large map this is the way to go, even in a small map they have benefits, namely that you only have to attach one handle per door.

Whether you decide to use a single handle or a double handle you must first follow the instructions below and attach one handle first. If you choose a double handle, follow the instructions below and you are done. If you choose a single handle type follow the instructions then also follow the ''multiple handle'' instructions for the second handle.

Both single and double handle types can be found in two places. The model viewer which will create a static model good for show, you can manually add props to make them work OR you can look in the entity browser.
Using a handle from the entity browser saves you a little bit of time as some props are already added, you just need to add the frob_peer names for the doors/handles and the door_handle name to the door.

=== Adding a working model door handle===

Quick summary:
* Create a model or brush handle and make it an ''atdm:mover_door_handle'' entity.
* Position it on your door. Use the opposite side from the door's multicolor X-Y-Z indicator (highlight the door to see it) if it's not obvious which side it goes on.
* '''Bind''' the handle to the door (bind <doorname>)
* It should now be a working handle though may need adjustments of rotation etc. see later.

Important: read preceding section on door handle types and performance issues first.

This works with both a model door and a brush door:

'''Rotation''':
* By default the door handle entity rotates ''anti-clockwise'' (looked at from the front) then springs back. A ''double handle'' model is OK but two singles (see ''Multiple door handles'' below) need more care as only one is the functioning entity and the other is just attached to it. So anti-clockwise is fine for a door with its hinge on the left and the handle on the right - the handle will rotate down then spring back. If you put the functioning door handle on the other side you will have to change the default ''rotate'' property from -45 0 0 to 45 0 0. '''''Therefore it is easier to generally put this handle on the side of the door where the hinge is on the left and the non-functioning attachment handle on the other side.'''''
*If your door only needs one handle, eg, a cupboard door, and from outside its hinge is on the right then you will need to change the ''rotate'' property of the handle as described above.

'''''The functioning handle entity:'''''
* Create an entity door handle (movers folder) or create a brush or model handle and assign it the entity ''atdm:mover_door_handle''.
* Position it where you wish on your door.
* '''Bind''' the handle to the door, by adding the "bind" spawnarg to the handle.

You now have a working door handle with default properties.

*'''Multiple door handles''':
Now that you've got a handle attached to one side of the door it is time to add one to the other side (unless you used a double handle).
* Create the new handle. The single handles come in left and right persuasions. A door needs a left facing handle on one side and a right facing handle on the other, so if you have already added the left handle create a right handle and line it up on the other side of the door.
* Name this handle. I prefer to keep a naming convention for each door and it's respective handles, it makes things alot easier. The door is named '''My_Door_1''', the first handle is named '''My_Handle_1''' so name the second handle '''My_Handle_1_1'''. This will make it stay with the first handle in the entity list. This is important to keep organized. If you name it My_Handle_2 then when you get to another door named My_Door_2 you'll be confused.
* Place and '''bind''' that handle to your door.

You now have two single door handles on either side of the door that rotate together as if they were physically attached.

'''To add a brush to a brush door''':
* Select the new brush ''and'' the brush door all together; ''the entity '''must''' be selected '''last'''.''
* Use {{menu|Edit|Reparent primitives}}. This ensures the parent entity adopts the new item(s).
* If you have trouble selecting them in the orthoview because other brushes, etc. get selected then try in the camera view or as a last resort move them temporarily to an open area (but keep them in the same positions relative to each other.) Use {{key-shift}}+{{LMB}} on new item(s) then {{key-shift}}+{{LMB}} on main entity. Once they are all selected, use the {{menu|Edit|Reparent primitives}}.

'''To add ''model'' static items''': knockers, hinges, static handles etc. to a ''Model Door'':
* Select item
* Right click in orthoview and select ''Create Entity'' then <code>entity func_static</code>
* Position it where you wish on your door.
* To synchronize this with your particular door you need to add the property ''bind'' and the individual door name to the brush entity. To do this...
** Select the model door.
** In the entity inspector, select the ''name'' line
** Select the bottom line in the input box ''below'' the properties window.
** Copy the name
** Deselect the door with {{key-esc}}
** Select the brush entity
** Add a property "bind" to it.
** Change the value of the property by pasting in the door name
** Click {{check}} or press {{key-enter}}

'''To add ''brush'' static items''': knockers, hinges, static handles to a Model Door:
* This method is not ideal but it seems to work OK.
* Select the brush.
* Right click in orthoview and select Create Entity then ''atdm:mover_door_handle''
* Position it where you wish on your door.

To synchronize this with your particular door you need to add the property ''door_handle'' on the door, and give as the value the name of the brush you just created.

This brush turns like a handle. To stop it:

* Adding ''rotate 0 0 0'' or disabling the handle script won't help.
* Add a real working handle (as in the section above ''To add a working model door handle...'' and it must be added LAST.)

If you don't want too see a real working handle added maybe try another tiny brush with the handle function and hide it inside the door?

===Locking Doors===

To lock a door check the ''show inherited properties'' in the entity inspector for a ''atdm:mover_door'' entity and you should see the ''locked'' property. Select it and in the input box below the properties you can change its value:

* 0 = unlocked (default)
* 1 = locked

If locked it will require an entity that is associated with it to be able to act as a key to unlock it.

Currently door handles on locked doors will rotate when frobbed, they will bounce back though and the door will stay locked until unlocked.

===Keys===

Assigning specific keys to specific doors is simple.

* It is recommended that you create an existing key entity. These keys have all required props, they just need to be named.

Alternatively you can create a key from the Model Viewer and want it to be useable
* Make sure it has the properties:
useable 1 [so it can be used by the door]
frobable 1
inv_name <unique name>
inv_category Keys
inv_target player1
inv_icon guis/assets/hud/inventory_icons/<icon name>
inv_stackable 0 or 1 where 1 can be used on all copies of the same key so they show as one entry in the inventory with a total.

Add to the door the property <code>used_by</code> with the name of the key as the value. Multiple keys can open the same door by using several <tt>used_by</tt> spawnargs:

"used_by" "doorkey_1"
"used_by1" "doorkey_2

==== Keys carried by AI ====

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see [[Attaching Props to AI]].

*"def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
*"pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
*"name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
*"set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
*"set name on door_key" "door_key" //here it gets a name to be used in the map in general.

updated by bikerdude.

====Master Key for Testing====

By default, ALL locks can be opened by any key named ''key_master''. Just create a key in your map, name it ''key_master'' and it becomes a master key for use while testing. Add inv_map_start 1 to it so it is in the player inventory at game start. Remember to delete it when your mission is finished.

===Lockpicks===
''by Baddcog''

There are two lock pick types.
*'''s'''=snake
*'''t'''=triangular

A lock can be set with many pins. Each pin has a click sequence and each needs a designated lockpick type (see above). Keep in mind that the lockpicking in The Darkmod is much more involved than in T2 or T3. The player has to listen to sounds or watch a handle or lockbar to know when a lock is pin is picked.

This means that authors can be very evil and really frustrate the player, in which case their missions will probably not be played. So be nice to the player and don't waste your time. Use simple locks for the most part and save complicated locks for important sections and to build tension. Don't make the player have 20 pins to pick all with different lockpicks. In most cases 1 or 2 pins will suffice and it isn't necessary to use both lockpicks on every lock.
Also try to include a lock lever on lockboxes or chests, door handles will rotate as the pins are being picked. This gives the player visual clues to help with the picking (and essential in noisy environments where you can't hear the clicks.)
IMO this system is a huge leap foward for lockpicking but also has the ability to completely frustrate the player as stated above. Keep this in mind when designing your lockpick systems.

These props go on the door itself, or the lid of a chest, eg,
*'''lock_pins''' 1327
*'''lock_picktype''' stts

The lock_pins property specifies how many pins each lockpicktype has.
The lockpick_type property specifies how many times the player has to switch picks and which pick they have to use. You can see there must always be an equal number of lock_pins and lock_picktypes specified

So looking at the example above we have lockpick_type s(snake), t(triangular), t(triangular), and s(snake). The player will have to use these lockpicks in this order. Once the snake lockpick's pins are open the player can advance to the triangular pick and so forth.
5 is added to every click sequence so 5 is the minimum click pattern even if you set it to 0.
In the example above the lockpins specify in order which pick types have how many pins, so the s pick has 1 + 5 = 6 clicks, the t pick has 8 and so on.
The above is a difficult lock and to avoid annoying the player it is best only used rarely on a special lock like an important big vault door. Ordinary footlockers and common doors can be just 1 or 2 click sequences, eg, lock_pins 2 and lock_picktype t means the player uses one pick and listens for the end of one sequence of 7 clicks.

lockpick_rotate - is placed on the door. It is the amount the visible rotating handle or pin rotates while picking. For a rotating handle or lockbar normally ignore this and leave the default. During lockpicking it oscillates and progresses to the normal full turn of the handle. Example 0 45 0.

lockpick_translate - is placed on the door. It is the amount the visible handle or pin moves in a straight line while picking. Use this if you have eg, a lockbar that you want to move in a straight line and not rotate, eg sliding catch. Example 0 -5 0

By default, doors are pickable. If you don't set up the above lockpick spawnargs then it can't be picked. So there is normally no need to enable lockpicking - just set up the above spawnargs. There is a ''pickable'' spawnarg set to 1 by default. If set to 0 then the door becomes unpickable. But hard to think of an application except in testing or perhaps a special custom situation where it is switched by script perhaps.

===Open, Partially Open, or Closed Door at Game Start===

By default, doors are closed at game start. If you want a door to be already open or partially open then do the following.

'''Note well: Create all doors in their ''closed'' position. Adjust as follows and they will automatically be at the open position when game starts.'''

Already Open Rotating Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and tick the check button
* The door will now be fully open at game start.

* If you want it only partly open:
* Make sure its ''open'' property is set to 1 as above.
* Right click the entity inspector and select ''add property''
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* scroll down, select ''start_rotate'' then click {{ok}}
* This adds it to the property list.
* Now select ''start_rotate'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the angle you want in the same form as described in the ''Rotate Direction and Open Angle'' section. So for example, to have a door that has a fully open default ''rotate'' value of 0 90 0 to start only half open you would give it a ''start_rotate'' value of 0 45 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

Already Open Sliding Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and click {{check}} or press {{key-enter}}
* The door will now be fully open at game start.

* If you want it only partly open:
* Right click the entity inspector and select ''add property''
* Make sure its ''open'' property is set to 1
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder.
* scroll down, select ''start_position'' then click OK. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* This adds it to the property list.
* Now select ''start_position'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the position you want in the same form as described in the ''Sliding (Translation) Amount and Direction'' section. So for example, to have a door that has a fully open default ''translate'' value of 0 50 0 to start only half open you would give it a ''start_position'' value of 0 25 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

===Rotation Centre, Pivot, Hinge point===

The centre of rotation of a door is at the origin point of its entity and the door rotates with reference to the orientation of that origin point, not the world map. See ''Rotate Direction...'' for more about that. This section only deals with the ''position'' of the rotation centre in the door.

Model Door Centre of Rotation: 
The centre of rotation of a model door cannot be changed within Dark Radiant. Because a model door rotates around the centre 'spine' of its back edge this will cause clipping (penetration into solid) as in this example (where the door is set to open to 89 degrees for clarity): [[Image:modelClipping.jpg]] So care is needed with placement. You will not normally position a door right next to a wall as in the example but against a shallow frame so clipping will barely be noticeable but either way it can be fixed. You can correct it by adding a translation (see ''Sliding (Translation) Directions'') value of half the door width in the direction of the door handle. This will gently move the door out as it rotates to clear any solid on that side as in this diagram: 
[[Image:DoorClip.jpg]] 
Half a door width will typically be about 2. Any 'attachments' such as door handles will still synchronize with the door movement whether the door is rotating, sliding, or both.

Brush Door Centre of Rotation: 
The centre of rotation of a brush door ''can'' be changed. The default origin point of a brush is at its centre. Therefore a default rotating brush door will rotate around its centre when you first create it. So, mappers will commonly need to move that rotation point to a corner or even to some other offset position for example, for an openable window using the door function.

Put simply, to move the rotation point of a brush door you need to move the entity origin relative to the brush(es.)

Moving the entity origin (centre of rotation) relative to a brush door:

* Select the brush door
* Select ''Vertices mode'' (default shortcut key is {{key|name=V}} or button on top toolbar 'Select Vertices')
* Drag the door's entity origin to the point where you want the door to rotate. This should be on the corner on the leading edge side (the side to where the door is opening.) to avoid clipping as in this diagram....
[[Image:getCorner.jpg]]
* You should now find that door rotates around that point.

===Rotate Direction and Open Angle===

By default, rotating doors open anti-clockwise (viewed from above) by 90 degrees from the start orientation. If you want to change this edit the ''rotate'' property in the entity inspector. Don't confuse this ''rotate'' property with the ''rotation'' property. In the entity inspector remember that to see the inherited rotate property you must check the box 'Show inherited properties'.

The three values shown in the rotate property are degrees from the closed position around Y Z X ''entity origin axes'' (NOT absolute map axes) and so include any start ''rotation''. So the Z value is the axis vertical to the entity origin. If you tilt a model door over in Dark Radiant then its entity origin tilts too so the Z axis is tilted too (with respect to the world map vertical.) So with a normally opening model door if you lay it flat on its back it will open upwards and not rotate around on the floor. But a brush door must be treated differently...

If you turn a brush door using the normal Dark Radiant rotate tool or the Transform Dialog (accessed via a shortcut key) then it only turns the brush ''relative'' to the entity. So, because the entity origin is by default aligned with the world map then ''in most cases'' you can regard a brush door as rotating with respect to the world map if you wish. But there will be a problem when you come to rotations that are not around the main Y Z X axes of the map, for instance a drawbridge that lowers down to the south east. You might think you can combine Y Z X values to get the result you want - and this can be done (for south east use 45 45 90) but it is a bit of a kludge and the drawbridge twists eccentrically as it lowers (though it arrives correctly!) So for such cases you need to turn the entity itself so its start position is facing south east. You can then just use 0 0 90 to lower the drawbridge perfectly because its Y axis is now pointing south east. To turn the entity you must type or paste the rotation values in directly because using the Dark Radiant rotation tool or Transform Dialog will only turn the brush not the entity. The values are rather lengthy (south east is 0.707107 0.707107 0 -0.707107 0.707107 0 0 0 1) so probably the easiest way is to create a temporary model door, turn it how you want, then select its rotation property. If you now deselect and re-select your brush door then that property will still be in the entity inspector input box and you need only click the check(tick) box to add it to the brush door. NOTE: ''neither the entity nor the brush will show as turned in Dark Radiant.'' Only the rotation property in the entity inspector will indicate the orientation. Instead of a rotated ''construction'', regard it as a rotation ''instruction'' for when the map is compiled.

These are the rotate property fields. Remember they are all with reference to the door's entity ''not'' the world map. Since there is no absolute frame of reference I indicate them here as if the entity is aligned with the world map axes...

* Positive Y = Open clockwise (Dark Radiant grid front view, looking north)
* Negative Y = Open anti-clockwise (Dark Radiant grid front view, looking north)

* Positive Z = Open anti-clockwise (Dark Radiant grid top view, looking down)
* Negative Z = Open clockwise (Dark Radiant grid top view, looking down)

* Positive X = Open anti-clockwise (Dark Radiant grid side view, looking west)
* Negative X = Open clockwise (Dark Radiant grid side view, looking west)

The values are in the range -179 to +180. Positive values give an anti-clockwise opening rotation (looking down from above) and negative values give a clockwise opening rotation. The value 180 is unique in that it continues in an anti-clockwise rotation when closing rather than returning clockwise so might be used if you can think of some object that might need such a motion when frobbed!

Edit the rotate value by selecting it and using the input box at the bottom and clicking the check(tick) button. That will change the angle the door will open to. Note that the line with the original default of 0 90 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Examples:
* 0 90 0 = Opens anti-clockwise round the entity's 'vertical' to 90 degrees - typical default vertical door.
* 0 0 90 = Lowers a drawbridge from the entity 'vertical' to horizontal.
* 0 0 -45 = Opens clockwise by 45 degrees viewed from the east side. This might suit a skylight in a sloping roof.

Combinations can be used and also combined with slide motions (see '''Sliding (Translation) Directions''') to produce exotic and useful motions. A door opening against an upward-sloping floor can thus have a ''lifting hinge'' and raise up slightly to clear the floor; a door can rotate towards you and slide back to one side very effectively.

===Sliding (Translation) Amount and Direction===

By default a Dark Mod door will rotate open. For most sliding doors you want to stop them rotating as well as make them slide. You cannot delete (remove) the ''rotate'' property - you have to set the ''rotate'' property to 0 0 0 to stop a door rotating (see ''Rotate Direction and Open Angle''.)

Now edit the ''translate'' property value by selecting it (remember to have inherited properties box checked) and using the input box at the bottom and clicking the check(tick) button. That will change the distance the door will slide to. Note that the line with the original default of 0 0 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Typically (but not always) you will want your sliding door to slide the width of the door. The three values in the translate property by default are 0 0 0 and are X Y Z ''absolute map'' values (irrespective of door orientation) where:

* Positive X = Slide East (Right side of Dark Radiant grid in top view)
* Negative X = Slide West (Left side of Dark Radiant grid in top view)
* Positive Y = Slide North (top of Dark Radiant grid in top view)
* Negative Y = Slide South (bottom of Dark Radiant grid in top view)
* Positive Z = Slide Up (Top of Dark Radiant grid in side views)
* Negative Z = Slide Down (Bottom of Dark Radiant grid in side views)

So for a 50 unit wide door you want to slide fully to the east you would use 50 0 0 for the translate property values. A 100 unit portcullis sliding vertically up would need 0 0 100 to be fully raised.

=== Doors Collision/Push Behaviour ===
Doors are pushing all entities by default, except for the player. Doors will also stop moving when anything blocks their movement. However, this default behaviour can be changed by setting the according spawnargs:

Set '''push_player''' to '''1''' to let the player be pushed by this door:
"push_player" "1" // Push the player too (default is off)

By default '''stop_when_blocked''' is set to 1 and if a door is blocked by an entity then even if the entity is removed afterwards, the door stays still. The next frob will close the door.

Set '''stop_when_blocked''' to '''0''' to prevent the door from ending the opening sequence when anything blocks its way. It will still pause - but continue to open if the block is removed.
"stop_when_blocked" "0" // door keeps moving after being blocked (default is off)
With this setting, doors will still stop at blocking entities (the player, for instance), but will continue to move when the entity clears the way.

There is another spawnarg which stops a door pushing a moveable. Apply this to the ''moveable'' not the door...

"notPushable" "1"

===Sounds and Sound Propagation through Doors and Doorways===

Sound propagation relies on visportals. For details study [[Sound Propagation: Part 1]] and [[Sound Propagation: Part 2]] as well as [[Visportals]] This tutorial will just cover the relevant sound and sound propagation ''properties'' of doors. If you set the ''show inherited properties'' box in the entity inspector you can see them as described here.

The sound of doors opening and closing is set in the snd_open and snd_close properties. You can silence them by setting the following properties as shown:

''snd_open nosound'' 
''snd_close nosound''

Don't just use a dash - as it seems to cause a sound of its own.

''snd_locked'' 
The sound played when a player tries to open a locked door.

''snd_unlock string'' 
The sound played when a player unlocks a door.

''loss_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through an open door. (default 1dB)

''loss_closed'' 
Drop in sound volume in dB propagated to AI (not player) when going through a closed door. (default 15dB) You would want to set this very high to block all sound with a thick door but very low for a barred gate for example.

''loss_double_open'' 
Drop in sound volume in dB propagated to AI (not player) when going through double doors when only one is open. (default 1dB)

There are also various sound properties for lockpicking: 
''snd_lockpick_pin_1 through 14'' and ''snd_lockpick_pin_success''

===Speed of Door Opening and Closing===

Rotating Door Speed: 
At the time of writing, the time a rotating door takes to open or close is set in the ''move_time'' property whatever its maximum open angle. So with rotation set at say 150 degrees the door just opens faster than at say 80 degrees. This is likely to be changed to a constant angular velocity so check to see if there a new property added if the following no longer works. The problem is that if an interruptable (see Extra Notes) door is frobbed while in motion it stops; another frob will reverse the motion - so even if the door is only open a crack it will still take the full time to close and vice versa.

To change the time a rotating door takes to open or close, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''move_time''
* Edit the second line of the input box ''below'' the properties window to the time you want.
* The time is in seconds and decimal fractions can be used.
* The default is 1 second and if set to this then the door opens and closes in one second whatever the maximum open angle, great or small.

Sliding Door Speed: 
The speed of a sliding door is set in the ''translate_speed'' property. To add this, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''translate_speed''
* Edit the second line of the input box ''below'' the properties window to the speed you want.
* The speed is in Dark Radiant grid units per second.
* The default is 0 and if set to this then the door slides open in one second whatever the distance, great or small.
* CAUTION: If you later change the door back to a rotating door then delete the ''translate_speed'' property or ensure it is set to 0 as (at the time of writing but this will be fixed) a bug makes rotating doors open and close instantly. (Note: you can still mix sliding with rotating but check - this bug might only be if ''translate'' is set to 0 0 0)

===Visportals and Doors===

A visportal face surrounded by solid at its edges and in contact with a door is closed when the door is closed and enabled when the door is open. In most cases you will place a visportal in contact with a working door unless you can see through the door (such as a true glass door or barred gate.) For full details see [[Visportals]].

==Auto-Closing/Opening Doors==
Doors that automatically close after being open for some time are easy to setup: Each frobmover entity supports these spawnargs:

;"auto_close_time":Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
;"auto_open_time":"Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

Old text:

Note that auto-closing doors and AI closing doors behind them, is very much work in progress at the time of writing, so for now, this is another method that works. Check first if true AI closing of doors is working yet before bothering with this!

I have one door that I particularly want the AI to close as there is a bit of frame lag inside if not. So I set this up and it works good as an auto-closing door - not as good as a true AI closing door as it will auto close when the player goes through as well but it does look very effective to see AI going through and closing the door behind them. Not tested exhaustively so I don't know if there could be any downside. Here's what to do....

First a quick summary to make it more clear:

'''''A trigger_relay is used both as a relay AND carries a stim. We put the trigger_relay with its stim in the path of the open door. The door has a response property. When it opens and contacts the stim its response is to send a signal back to the relay. The relay pauses then closes the door...'''''

* First, optionally give your door a suitable name like autodoor1, whatever.
* Copy that name to the clipboard.

Next we need a relay with a delay:

* Create entity > darkmod > trigger_relay

* Place it roughly at the position the door will be at when open and to be on the safe side 3/4th of the way to the far end of the door (not the hinge end) to give max distance from the close door.

* Add the property 'target' and paste in the door name you just copied.

* Give the relay itself a name, eg, autoDoor_relay_1, and copy that name to the clipboard, you'll need that too in a bit.

* Add the property delay and the value 3 - this is the delay in seconds before the door will close; 3 seems about right but 2 might be worth a try because to that 3 is added a random value between 0 to 0.5 seconds from the Time Interval we entered for the stim firings.

* Add the property 'wait' and the value 3. This is the time before it can work again in seconds. If you set it too low then in theory the door might trigger again but in this situation I don't think it's possible. Too long, eg, one minute, and it won't work if the AI goes back through the door before then. If this value is -1 then the whole thing will only work ONCE so might be used for an AI who goes through once, closes it behind him, but you don't want it to be an autodoor thereafter.

That's the relay, now we add a stim to it:

* Still with the trigger relay selected, go to {{menu|Entity|Stim/Response}}

* Custom stim tab.

* Click Add stim type, select the new custom stim type you just made at the bottom of the list and type in eg, autoDoorStim at top right in the input box.

* Click the stim tab and the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Select the new autoDoorStim in the list and on the right you need only type in the radius box 15.0 There is quite a lot of room for error. I had it working on 10 and also on 25. The value should be less than the distance to the closed door else it will trigger open! But no so small that the door might not reach it.

* Select the check box for Time Interval and enter 500 (millisecs.) This is so it doesn't keep firing more frequently than is necessary. This stim will be firing all through your mission whether the door is used or not so if you had dozens of these then maybe it would affect performance. Too big a number and there may be a long delay before the door shuts - but it will be random depending on the next time the stim happens to fire. We'll control the delay we want more precisely later.

* Click {{ok}} to confirm it.

That's the stim set up, now for the response to it which is put on the door....

* Select the doorm, then use {{menu|Entity|Stim/response}} and select the response tab.

* Click the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Right click in the big ''Response Effects'' box on the bottom right of the panel.

* Add New Effect and you should get a default 'Activate Response' response added to the list. Double click it.

* In the Effect selector at the stop select 'Trigger'

* in the Target box, paste in the name of the relay you copied or you can select it from the list at the little arrow.

* Leave the Activator box empty.

* Click {{apply}} and then {{ok}} on the main S & R panel bottom right.

It should now work. No need to wait for an AI, just frob the door and watch it close itself. If not, check the position of the stim brush is close to where the door stops when open.

==AI Door management==

See also [[#Keys_carried_by_AI]] above.

By default AI will open doors and close them behind them. Here are some spawnargs the mapper can use to modify that behaviour:

;"ai_should_not_handle" :If set to 1, AI will not attempt to handle it and add it to the forbidden areas when closed (so that it doesn't try to path through). They might still walk through the door when it is open though. Useful if you have some special use door that you don't want the AI to operate.

;"ai_should_not_close" :If set to 1, AI will not close the door behind them unless it obstructs them.

To get AI to unlock/relock specific doors there are two methods currently:

1. add the following spawnarg/value to the AI:

;"can_unlock1" ''<doorname>''

'''Do NOT use can_unlock_1.'''

For additional doors on the same AI use ''can_unlock2 doorname'' etc.

2. In the editor position an actual key that works for that door on the AI and also add to the key bind <AIname> and also bindToJoint LeftHips_Dummy (see other joints names elsewhere in wiki.) Currently, if the player pickpockets the key then the AI seeks an alternate route but otherwise does nothing (?) This may be upgraded in the future to better strategies.

3. There is the possibility in the future of an additional method which would just use special attach spawnargs to make the above easier. The key would spawn at the correct position at game start. Watch this space.

'''Door handling positions'''

It is also possible to set custom door handling positions for the AI. This is especially useful when the standard routine that lets the AI choose their standing positions while opening and closing the door fails, leaving them circling around in front of the door helplessly.

Place a movers > atdm:door_handling_position entity where you want the AI to stand while opening/closing the door from this side.(it can be found in the movers folder in the entity chooser)

On the door, you need to set the spawn arg "door_handle_position" "name_of_door_handling_position" You can also place a door handling position on each side of the door, the AI should automatically choose the right one. In this case, you need to set spawn args with "door_handle_position_1" etc and the corresponding names of the door handling position entities on the door.

The door handling positions can also carry spawn args that define the behaviour of the AI, which are useful for example for doors that can only be openend or locked from one side:

'''"ai_no_open"''' If set to true, the AI will not try to open the door from this side (but still walk through when the door is already open)

'''"ai_no_close"''' If set to true, the AI will not attempt to close the door from this side

'''"ai_no_unlock"''' If set true, the AI will not be able to unlock the door from this side, but still use it when it is not locked.

'''"ai_no_lock"''' If this is set true, the AI will not lock the door from this side.

==Doors as Triggers==

''by Ishtvan & greebo''

Doors (or any binary frob mover, buttons, levers, etc) now have the option to trigger their target on closing or opening. (For definition purposes, a button is defined as "closed" in the state when it starts out and "open" in the state you press it down to. I know that's a little non-intuitive, but it came from deriving from doors).

New spawnargs on frob movers:
;"trigger_on_open" :If set to 1, this binary mover will trigger its targets when it starts out completely closed and is opened.
;"trigger_when_opened":If set to 1, this binary mover will trigger its targets when it is completely opened. Code defaults to 0.
;"trigger_on_close":If set to 1, this binary mover will trigger its targets when it completely closes after being open.

==Skins: A Wide Variety of Door Textures==

This is to remind you that as with many Dark Mod models, there is a wide range of extras skins (textures) available for door models. There are now several basic door entities of different sizes so choose your size first. Then enter the spawnarg: skin with any temporary value. Now select it and click the skin button at the bottom of Dark Radiant's Entity Inspector and you will find a large of range of skin textures from which to select to give you a choice of appearances for your door.

==Extra Notes==
The property ''interruptable'' determines whether a door can be stopped by frobbing while it is opening or closing. So by frobbing then frobbing again, the player can open a door to any position, eg, slightly ajar to peek through.

''func_darkmod_door'' is no longer used (just in case you come across it in the Dark Mod forums or wiki.) The Doom func_door is still available but for Dark Mod, but <code>atdm:mover_door</code> is the entity to use.

{{tutorial-editing}}

Limits, Max, Min, Stats, etc

2011-01-13T22:18:12Z

Fidcal: /* Slopes and Steps */

''Written by Fidcal''

This is a collection of game and map limits, maximums and minimums, etc. for the mapper to reference.

'''Note that some values might change as many features are still work in progress.'''

All units used here are Dark Radiant grid units (same as Doom 3 units.)

==Conversion of game units==

''Main article: [[Conversion of Game Units]]''

* 1.1 DarkRadiant grid units = 1 inch = 2.54 cm
* 1 DarkRadiant unit = 0.909 inches = 2.309 cm

==Grid Size==

Grid size is 131,072 x 131,072 units x 131,072 (inches) or about 2 x 2 x 2 miles

Theoretically a map might be made with about 50 stacks of 2 x 2 miles each about 200 foot high that's 100 x 100 miles or 10,000 square miles. Problem is handling the file size but it illustrates that the only limit is labour, imagination, RAM size, etc.

==Entities Max in Map==

The limit is 8192 entities. However, maps should not get too close to this limit, as headroom for entities spawned at runtime has to be left (projectiles and such).

Runtime entities are f.i. the player character, weapons, projectiles you shoot. The biggest source of "hidden entities spawned at runtime" are the combo entities. F.i. each candle or torch spawns at least a flame, fireplaces spawn the flame and possible extra wood piles, candle holders spawn a candle and the flame, a chandelier might spawn 3 candles and 3 flames etc. Note that the flames are spawned even if the entity is not lit, to allow the player relighting it.

So keep your entities well below 7000 or even 6000.

It's possible to raise the entity limit in the SDK, but usually we won't do that until it's absolutely necessary. The bonehoard has about 700 entities currently, but angua is really saving them.

==Player Limits==

===Doorways, gaps===

* Minimum width a player can squeeze through = 33
* Minimum width a player can lean into = 20
* Minimum height a player can walk under = 75
* Minimum height a player can crouch through is 39
* Minimum square hole to drop into/mantle out of is 39 (length) x 33 (width.) Note that this is difficult (impossible?) to mantle up through if no sides in hole to align to (ie if just a hole in a ceiling rather than a 39 x 33 shaft, see below)
* Minimum oval hole to drop into/mantle out of is 39 (length) x 33 (width.) Note that this is extremely difficult for the player to align to even to drop down, see below.
* Minimum circular hole to drop into/mantle out of is 39 x 39 Note that this is presumed and not tested and likely to be extremely difficult for the player to align to even to drop down, see below

'''ADDITIONAL NOTES:'''

# Ladders need significant extra space so allow for that and test. Sometimes a ladder does not need to go through an opening but only up to it. See also the following note.
# Smaller gaps can be simulated by lining the opening with entity brush(es)/patch(es) and giving it/them the property/value: solid 0. But you need to consider the player's vision clipping into that 'simulated solid' and test this. This same technique can also be used to simulate even legitimate small/minimum sizes (ie, make the actual solid gap larger) in order to make them easier (and probably less frustrating) for the player.

===Mantling, Jumping===

* MaximComfortable mantle
* Maximum normal mantle, standing, walking, or running = 134
* Maximum jump mantle, standing, walking, or running = 182
* Minimum height to mantle onto = 1
* Minimum width to mantle onto = 1
* Minimum open wall depth to mantle onto = 1
* Minimum shelf depth to jump mantle onto from front = 16
* Minimum shelf depth to jump mantle onto from side = 16
* Minimum ledge depth to mantle or jump mantle onto from front = 16
* Minimum ledge depth to mantle or jump mantle onto from side = 16
* Minimum height of bottom of shelf to normal mantle onto = 74
* Minimum height of bottom of shelf to jump mantle onto = 122
* Maximum gap to run jump mantle over = 176
* Maximum fall without damage = 186

==AI limits==

This varies with the different types of AI.

Minimum doorway width a normal humanoid AI can go through = 48
Minimum doorway height a normal humanoid AI can go under = 96?

==Slopes and Steps==

The maximum slope for an AI is approximately 40 degrees from the horizontal but varies upon the situation and the AI.

The player can walk without slipping off on slopes no steeper than 45 degrees from the horizontal. If the terrain is rough this could be frustratingly difficult, however. By default, the player cannot mantle on slopes steeper than 45 degrees either (this is intended to avoid continuous-mantling exploits).

The maximum step height for AI and player is 16 though some AI cannot step up over 14 and perhaps less. But the minimum depth from front to back of a step is only 1 and this can be used to get extreme slopes and very steep steps - even near vertical walls (see [[Pathfinding]])

==Weapons and Items==
* Maximum length of rope attached to the rope arrow = ~400

[[Category:Editing]]

Sleeping AI

2010-12-30T18:46:27Z

Fidcal: /* Sleeping position in the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

===Sleeping position in the bed===

====Head to Toe====

Stand the AI close to the bed facing away from it and about half way between the head and the foot; adjust as needed towards the head or foot direction of the bed.

====Sideways====

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Monster clip the bed or not?==

Yes, monster clip should not directly effect the sleep animation and the bed should normally be monsterclipped anyway. The only way it might affect it is if the clip sticks out too far and stops the AI getting near enough. In that case reduce narrow the clip close to the bed edge and/or adjust the slide value (see [[#Sleeping position in the bed]]

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

===AI lays wrong way head to foot===

If the AI is laying the wrong way with his head at the foot of the bed and his feet at the head then see [[#Direction]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:45:01Z

Fidcal: /* Monster clip the bed or not? */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

===Sleeping position in the bed===

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Monster clip the bed or not?==

Yes, monster clip should not directly effect the sleep animation and the bed should normally be monsterclipped anyway. The only way it might affect it is if the clip sticks out too far and stops the AI getting near enough. In that case reduce narrow the clip close to the bed edge and/or adjust the slide value (see [[#Sleeping position in the bed]]

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

===AI lays wrong way head to foot===

If the AI is laying the wrong way with his head at the foot of the bed and his feet at the head then see [[#Direction]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:43:57Z

Fidcal: /* Sleeping position in the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

===Sleeping position in the bed===

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Monster clip the bed or not?==

Yes, monster clip should not directly effect the sleep animation and the bed should normally be monsterclipped anyway. The only way it might affect it is if the clip sticks out too far and stops the AI getting near enough. In that case reduce narrow the clip close to the bed edge and/or adjust the slide value

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

===AI lays wrong way head to foot===

If the AI is laying the wrong way with his head at the foot of the bed and his feet at the head then see [[#Direction]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:43:20Z

Fidcal: /* Sleeping position in the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Monster clip the bed or not?==

Yes, monster clip should not directly effect the sleep animation and the bed should normally be monsterclipped anyway. The only way it might affect it is if the clip sticks out too far and stops the AI getting near enough. In that case reduce narrow the clip close to the bed edge and/or adjust the slide value

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

===AI lays wrong way head to foot===

If the AI is laying the wrong way with his head at the foot of the bed and his feet at the head then see [[#Direction]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:38:49Z

Fidcal: /* AI lays down too far to one side of the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

===AI lays wrong way head to foot===

If the AI is laying the wrong way with his head at the foot of the bed and his feet at the head then see [[#Direction]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:37:21Z

Fidcal: /* Setting up */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed.

===Direction===

If you want the AI to start from the left side of the bed (as you look towards the head of the bed) then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:33:07Z

Fidcal: /* Sleeping position in the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed. If you want the AI to start from the other side then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:32:50Z

Fidcal: /* Sleeping position in the bed */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed. If you want the AI to start from the other side then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

(note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:31:20Z

Fidcal: /* Known bugs */

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed. If you want the AI to start from the other side then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

===AI lays down too far to one side of the bed===

To move an AI across the bed see [[#Sleeping position in the bed]]

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

Sleeping AI

2010-12-30T18:27:46Z

Fidcal:

==Introduction==

Sleeping AI are (mostly) working now. They can either put themselves to bed at map start and remain there (unless alerted) or else patrol there, sleep for a while, then patrol again.

==Non-patrolling sleepers==

These are defined as sleepers at the start and immediately lay down. They only will get up if alerted.

Set on the AI the spawn arg:

''sleeping 1''

==Patrol sleepers==

This is done by targetting a path_sleep entity which then targets a path_wait to define how long they will sleep before getting up again.

==Setting up==

By default, place the AI on the right side of the bed (as you look towards the head of the bed) and '''facing away''' from the bed. If you want the AI to start from the other side then add:

''lay_down_left 0'' (note this goes on the AI if the AI is using sleeping 1 BUT on the path_sleep if you are using a path_sleep)

==Sleeping position in the bed==

Stand the AI close to the bed about half way between the head and the foot; adjust as needed.

The distance the AI slides across onto the bed can be controlled by

''lay_down_slide_dist 16'' (default)

==Problems, Troubleshooting==

There are a few known problems:

===AI is sinking into the bed or floating high===

AI animate to the same height so if they are slightly high the first thing to check is the bed surface height. Most Dark Mod beds are a standard height which is correct for sleepers. One known bed (at time of writing) is a little high so AI will animate into it so be sunk a little low. This bed can be sunk a little into the floor to compensate. If they are floating slightly high then the bed can be lifted a little and perhaps some wood brushes under the legs make it right.

If the AI are floating '''very''' high then this is most likely caused by the AI clipping into the bed at the start so they are lifted up to stand on its edge before they animate. They then animate up even higher. Solution: move them further out at the start. Note: this problem probably only affects AI that start off sleeping rather than patrol to a bed.

==Known bugs==

AI have their eyes closed now while sleeping. This is using the pain anim as a place holder at the moment, since we don't have a suitable anim yet (sleeping looks like a quite painful experience now...)

Another problem is that the bounding box stays behind and is solid when the AI goes to bed.

When you KO a sleeping AI, they may drop down through the bed, pop back to standing, like they did in Thief,

Also this is probably unrelated but might be contributing to this problem: I'm noticing that KO'd AI are sometimes(?) flashing into the AF pose for just a frame, then back to the pose they were in before KO'ing. You can see it if you watch really closely.

There is also a problem when they see the player while laying down - they jump up for a moment, then finsih putting themselves to bed and then finally get up to chase the player.

{{tutorial-ai}}

FAQ

2010-12-26T06:48:19Z

Fidcal: /* The briefing is very fuzzy */

{{important|headline=Important|text=This FAQ relates to the full TDM release version only. For players of the pre-release demos such as '''[[Thief's Den]]''' and '''[[Saint_Lucia|Tears of Saint Lucia]]''' please refer to the '''[[FAQ (Demo Releases)|Demo FAQ]]'''.'''}}

== What Doom versions are supported? ==

=== Can I use the Demo version of Doom 3? ===

No, sorry.

=== Can I use it with the Doom 3 expansion Resurrection of Evil? ===

No, sorry.

=== Does it run with the Steam version of Doom 3? ===

Yes :) You need to install the mod into the directory where Steam put Doom3, this might be under:

C:\Program Files\Steam\steamapps\common\doom 3

or a similiar folder.

'''Important:''' Create a shortcut on your desktop and set it to the following:

steam.exe -applaunch 9050 +set fs_game_base darkmod

This ensures that when you start Steam, it will launch TDM and not Doom 3 without TDM.

== Patching Doom 3 to verson 1.3.1.1304 ==

=== How can I check whether my Doom 3 is correctly patched? ===

Open Doom 3 and hit {{key|Ctrl}}+{{key|Alt}}+{{key|~}} (tilde, {{key|^}} on German keyboards) to open the console. You'll see the version printed in the lower left corner of the console. It should read '''1.3.1.1304'''. If your version is ending on 1302, you've got the wrong patch installed.

=== Where can I get the right patch? ===

We have the patch hosted on our FTP. See the [[Installation]] article to find a link to it.

If you have version 1.3.1.1302, you may need to uninstall and reinstall before patch 1.3.1.1304 will let you apply it.

=== What's that issue with the 1.3.1 patch? ===

When the 1.3.1 patch was released by Id, they released it a bit too early. Some download sites picked it up quite fast though and started to distribute it. The problem is, that Id replaced that patch with a different one, and, probably thinking that it hadn't spread yet, didn't bother to change the version number. However, you can still find "wrong" 1.3.1 patches and these will not work with the mod. That's why it is important to check the version number in the console to make sure that the right 1.3.1 patch is installed if the mod doesn't work. The link provided here on our own page points to the correct patch, so if you downloaded it from here you don't need to worry about it.

== Supported Operating Systems ==

=== Which Windows versions can I use? ===

The following versions of windows have been tested and are known to work : Windows 2000, Windows XP, Windows Vista, Windows 7, Windows Server 2008, Windows Server 2003 in both 32bit and 64bit flavours.

=== Does it run in Linux? ===
Yes, Linux is supported.

=== Does it run in 64 Bit Linux? ===
Yes, Linux 64 bit is supported. In addition to the steps above, you need 32 bit compatibility libraries, since Doom3 is 32 bit only:
* On '''SuSE''', they should be included.
* On Ubuntu/Kubuntu, install the package '''ia32'''.

For TDM after 1.0, this step should be '''no''' longer neccessary:

* Since you cannot install 32 bit libraries on a 64 bit system with the normal package manager, you should use [http://ubuntuforums.org/showthread.php?t=474790 getlibs] to install '''libmng''' and the boost filesystem lib:
:<code>getlibs libmng.so.1</code>
:<code>getlibs -l libboost-filesystem1.34.1</code>

=== What about Gentoo? ===
Yes. It's not "officially" supported (the team doesn't test it specifically), however several users have reported success running TDM under Gentoo.

=== What about Ubuntu 8.10? ===
Yes. As of this writing you will need to install the '''libboost-filesystem''' package.

=== GLIBCXX_3.4.9 errors ===

If you receive an error about <tt>GLIBCXX_3.4.9</tt>, delete or rename the files <code>/usr/local/games/doom3/libstdc++.so.6</code> and <code>/usr/local/games/doom3/libgcc_s.so.1.</code>

If this doesn't resolve the error and you have an old version of GCC, then you may have to upgrade. It has been [http://modetwo.net/darkmod/index.php?/topic/9982-the-dark-mod-doom3-in-linux/ confirmed] that, at least under Gentoo, GCC 4.1 does not work with TDM but GCC 4.3 and GCC 4.4 are compatible.

=== Does it run on Mac OS X?===
No. Or at least not yet. The Doom 3 game itself does support Mac OS X, but The Dark Mod currently does not because we don't have any developers who use Macs. If you can help us getting it to run on OS X, please [http://modetwo.net/darkmod/index.php?showforum=11 let us know on the forum].

Since TDM works on Linux already, getting it working on OS X should not be too difficult for anyone with experience programming for that platform. In theory it's just a question of figuring out how to build the mod, sorting out dependencies, and writing a few pieces of platform-specific code.

== Graphics ==

=== Does TDM support widescreen resolutions? ===

Yes. Choose "16:9" or "16:10" in the in-game ''Settings'' menu, and select the appropriate resolution. Note that you need to restart the game to have the new setting in effect.

If the native resolution of your wide screen monitor is not listed, you can enter it into '''DoomConfig.cfg''' by changing the following entries like so:

set r_mode -1
set r_customwidth 1280
set r_customheight 800

Note that if you get performance problems, please consider using a lower resolution and taking a look at [[Performance Tweaks]].

== Troubleshooting ==

It is hard to answer question on why something fails, because wildly different systems cause wildy different symptoms. If the following section does not help you, please ask at out our [http://www.modetwo.net/darkmod forums].

=== Updater (tdm_update.exe) closes almost as soon as it's started ===

See the [[Tdm_update#Updater_closes_almost_as_soon_as_it.27s_started|main article on tdm_update]].

=== Windows 2000: freeaddrinfo cannot be found in WS2_32.DLL ===
Please refer to the main article [[TDM in Windows 2000]] to work around this problem.

===FM won't install manually===

If you are running Dark Mod under Linux and have edited the file darkmod/currentfm.txt this might prevent the FM from installing. This may be fixed in an update but apparently editing using notepad under Wine works OK.

=== FMs downloaded but don't show in menu list===

You have download some FMs but they don't show on Dark Mod's New Missions list. Possible causes:

* You must not extract the pk4s or zip files but put them into the darkmod/fms folder (or alternatively you can create the FM folder in there eg, darkmod/fms/chalice for chalice.pk4 or chalice.zip.
* Early versions of Dark Mod cannot handle zip suffixes. Solution: rename to .pk4 or run tdm_update to get the latest version of Dark Mod.
* If you are running Linux then Doom 3 MUST be installed in a .doom3 folder. Note the dot before .doom3.

=== FM downloaded but won't play ===

If you have downloaded an FM you might see it in the New Missions List but can't get it to play. These are almost always an install problem. These are some of the causes and cures:

FMs (fan missions) are archives and in early versions of Dark Mod MUST be suffixed .pk4 not zip. Apparently Internet Explorer 8 may change it from pk4 to zip during download without telling you. You need to rename it back if running an early version of Dark Mod else run tdm_update to update and then zip files are OK.

You MUST use doom3\darkmod\tdmlauncher.exe to run Dark Mod in Windows and NOT Doom3.exe.

You do NOT need to extract the pk4 archives to install or play. Just download into or move the pk4 into the darkmod\fms folder. Optionally you can create a folder of the same name as the map and put it in there, eg, darkmod\fms\chalice but there is no need because Dark Mod will create that automatically. Just make sure your pk4 goes, unopened, into the fms folder then run tdmlauncher.exe

If you have done the above but see for example, a blank objectives screen and no briefing then it is still almost certainly an install error. I recommend you do a clean sweep if in doubt:
* Exit Dark Mod
* Delete doom3\darkmod\currentfm.txt (this just uninstalls any FM)
* Delete the map game folder (if any) This is NOT the folder in fms but the folder in doom3 of the same name as the FM, eg, doom3\chalice. Note: this has savegames and screenshots in so check and move them out if you want to preserve them. However, if you can't get the game to play it's likely you don't have any yet. If you can't see the folder don't worry. The folder name is normally the same as the pk4 but it might not be. Strictly speaking it must be the same as the name in startingmap.txt inside the pk4 archive. You might see this file in fms.
* Move the pk4 into the darkmod\fms folder if it is not already there.
* Delete the darkmod\fms\FMname folder if any, eg, darkmod\fms\chalice. Don't worry if there isn't one; it will be created automatically later.

So all that is left is the pk4 in the fms folder. Now run tdmlauncher.exe. The FM should be in the list in the New Missions menu. Re-install it and you should now be able to play it.

=== The game crashes on load ===
Make sure that:
* You installed [[#Patching_Doom_3_to_verson_1.3.1.1304|the correct version]] of the Doom 3 1.3.1 patch.
* Your system meets at least the minimum system specs.
* You have enough free main memory. Try closing a few running programs like Outlook, Anti-Virus or torrent clients.

==== Unknown event 'moveToCoverFrom'" ====
If you get a message like:

ERROR: Error: file script\doom_events.script, line 1038: Unknown event 'moveToCoverFrom'

or see this in the log:

found DLL in pak file: C:\Program Files\Doom 3\darkmod\tdm_game01.pk4/gamex86.dll
copy gamex86.dll to C:\Program Files\Doom 3\darkmod\gamex86.dll
could not create destination file

Try extracting that gamex86.dll manually from '''tdm_game01.pk4''' with Winzip or a similiar program into that folder.

The reason is very probably that you installed Doom3 into a folder with a space in it, and it seems Doom3 does not like that. Sorry.

=== Unknown event 'setEntityRelation' ===
The game is crashing to a small blue screen on startup:

[[Image:ErrorSetEntityRelation.jpg]]

The reason for this error is most likely an old version of gamex86.dll (or gamex86.so) lying around in your Doom 3 folder. Delete that file and try again.

=== Textures are missing, screen mostly black ===

[[Image:Tdm missing textures.jpg|right|240px|Black textures]]

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the following settings are like shown below:

<pre style="max-width:35em">
seta image_usePrecompressedTextures "1"
seta image_useNormalCompression "2"
seta image_useAllFormats "1"
seta image_useCompression "0"
seta image_preload "1"
</pre>

=== Textures are missing, shadows are pitch black ===

Try disabling the AGP surface accelerator in DXDIAG

=== Graphic Corruption ===

One report we had was for a Radeon ATI HD 4650, catalyst 10.9. This screen corruption as I understand it was heavy pixelation even on the menus. Closing down Xfire fixed it so clearly to do with that. "I fiddled with the xfire Doom 3 configuration through the xfire_games.ini, and determined it has to do with InGameFlags portion.. For some reason the settings in that were interfering with doom 3, and after I removed some things from there, I was still able to run xfire, and doom 3 was still able to look proper"

=== The briefing is very fuzzy ===

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the following settings are like shown below:

seta image_roundDown "1"
seta image_forceDownSize "0"
seta image_downSize "0"

=== The sky is corrupted ===

You either see black sky, or fragments of other textures. This seems only to happen on Geforce 6800 cards.

There are two fixes for this:

As a quick fix you can rename the following folder:

env/skyboxes/skybox_darkland_ne

to an different name. That will result in black sky.

Alternatively, edit the file <tt>materials/tdm_sky.mtr</tt> with '''Wordpad''' or a different editor and
find the sky material named '''textures/darkmod/nature/skybox/skybox_darkland_NE''':

<pre>
//Author: Dram
//skybox_ocean with ocean replaced with dark land
//Moon moved to north east by Fidcal
textures/darkmod/nature/skybox/skybox_darkland_NE
{
qer_editorimage env/skyboxes/skybox_ocean/ocean_ed
noFragment
noshadows
noimpact
nooverlays
forceOpaque
{
forceHighQuality
blend add
cameraCubeMap env/skyboxes/skybox_darkland_ne/darkland_NE
texgen skybox
texgen wobblesky .0 .0 .0
}
}
</pre>

In this declaration, comment out the line that reads '''forceHighQuality''' by adding <tt>//</tt> in front of it:

// forceHighQuality

That should fix the sky and make it render correctly.

=== The Sky rotates ===

This problem only affects FMs with a dynamic sky (eg, moving clouds etc.)

If you see the sky spinning it may be an ATI graphics card problem. One report says this was cured by turning off Catalyst AI. Also gives better loading times and cures bloom problem.

If that doesn't fix it then try this. Note that it replaces dynamic sky with a static clear one so might look odd in a stormy FM for example but better than a spinning sky:

* Create a new folder in your darkmod folder called materials.
* Within it create a plain text file named no_skybox.mtr
* Paste in the following:

textures/smf/portal_sky
{
qer_editorimage env/skyboxes/skybox_ocean/ocean_ed
noFragment

noimpact
nooverlays
forceOpaque
noShadows
{
forceHighQuality
blend add
cameraCubeMap env/skyboxes/skybox_darkland_ne/darkland_NE
texgen skybox
texgen wobblesky .0 .0 .0
}
}

=== Bloom problems ===

Bloom has been removed as a default option, if you wish to use it try using r_bloom 1/0; The reasoning behind the change is that it creates lighting situations which are unintended and result in over-bright lights or problems with water textures etc - It is strongly discouraged to use it and should be disabled if you are running an old build from when it was a default. If have a problem with bloom it may be an ATI graphics card problem. One report says this was cured by turning off Catalyst AI. Also gives better loading times and cures spinning sky problem.

===Underwater performance poor===

If you get very low framerates underwater then try turning off bloom.

===Upside-down screen===

If you get an upside-down screen, you can either turn off Catalyst AI if you have an ati card or try turning off bloom.

To turn off Catalyst AI, open your Catylist control panel, go to 'graphics' up the top left, select '3d' from the dropdown list and on the new menu below, select the 'AI'
Now select the 'Disable Catalyst A.I.' checkbox.

To turn off bloom, enter the console and type "set r_bloom 0" (remove quotes)
Then type "vid_restart" (remove quotes) to refresh the graphics.

=== The game is '''very''' slow! ===

If you get less than 10 FPS, or the game even stutters, please try this:

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the
following settings are like shown below:

<pre style="max-width:35em">
seta image_usePrecompressedTextures "1"
seta image_useNormalCompression "2"
seta image_useAllFormats "1"
seta image_useCompression "1"
seta image_preload "1"
</pre>

If that doesn't help, your system might run out of memory. Either upgrade to more than 1 Gbyte memory,
or try to close some other applications before playing.

Please see also the article about [[Performance Tweaks]] to improve the performance.

=== Slow loading times ===

If you find an FM is very slow to load it may be an ATI graphics card problem. One report says this was cured by turning off Catalyst AI. Also cures bloom and spinning sky problem.

Changing the following settings to 0 will also reduce loading time, but be warned...if you have a lower end system, poor graphics card, or low ram...you will likely notice a performance hit ingame since you will now be using uncompressed textures.
<pre style="max-width:35em">
seta image_useNormalCompression "0"
seta image_useCompression "0"
</pre>

===Game freezes for several seconds when opening doors===
The following problems :

A) "game freezes and loads some data from hard drive while opening doors"
B) "while loading mission you are returned to the menu and need to restart loading"

Are often resolved by disabling EAX 4.0 HD in Audio Settings menu.

===Game exits to menu after mission load, with renderpipe error in console===

'''Symptoms:''' Missions are installed properly and will load, but after they reach 100% you are returned to the main menu or objectives screen. If you open the console (Ctrl-Alt-~ on US keyboards), you see one/both of these errors:

ERROR: Failed to open \\.\pipe\dm_renderpipe

or

ERROR: idRenderSystemLocal::uncrop currentcrop <1

'''Solution:''' Some firewalls, notably ''Sunbelt Firewall'' (aka ''Kerio Firewall'') are known to interfere with TDM's lightgem, ''even when "disabled"''. To fix this problem, completely uninstall the firewall, and get a different one instead.

==="COULD NOT FIND TDMLAUNCHER" when installing an FM===

If you receive this error message you should check the start-arguments of DOOM3.exe / tdmlauncher.exe. Arguments are stored in darkmod/dmargs.txt and a faulty syntax e.g. a missing "+" before a "set"-command, will lead to this error message. Steam-users are advised to remove any launch-options from Doom.

===The sound lags behind the picture===

This seems to happen on Linux with certain ALSA drivers. You can try to disable "Dolby Surround" (switch to "Stereo") or just use OSS instead:

Put the following setting on your tdmlauncher.linux command line:

+set s_driver oss

and use "Stereo".

On some Ubuntu systems, applications using ALSA are re-directed to "pulseaudio" which causes a lack of syncrony between sound and image. Simply removing "pulseaudio" should get your sound back in syncrony:

sudo apt-get purge pulseaudio

=== Changing the screen resolution/aspect ratio does nothing!? ===

These changes require a restart of Doom to work.

=== Steam launches D3, not TDM ===

Whenever you start Steam and it does launch vanilla Doom instead of TDM, make sure you
follow this advice:

'''Important:''' Create a shortcut on your desktop and set it to the following:

steam.exe -applaunch 9050 +set fs_game_base darkmod

This ensures that when you start Steam, it will launch TDM and not Doom 3 without TDM.

== Known bugs ==
See article [[Known Bugs]].

[[Category:General]] [[Category:Installation]]

Path Nodes

2010-12-25T06:22:37Z

Fidcal: /* Variation and Randomness */

''originally written by Springheel''

For more information on pathfinding, see [[Pathfinding]].

= What are Path Nodes? =

Path entities (or path nodes) are the things that you use to make your AI move (patrol) around the map. Placing path nodes can take a little getting used to; hopefully this article will help (I'm far from an expert, but here's what I've discovered so far).

There are lots of different kinds of path nodes. It can sometimes help to think of them as "travel nodes" (nodes that AI will travel to) and "behaviour nodes" (nodes that tell AI how to behave at a certain point).

Although path nodes have a directional arrow in the editor, it has no impact on most nodes. Rotating the node does add a corresponding "angle" property to the entity (matching the direction of the arrow). Certain nodes (path_anim, path_wait, and path_turn, for example) are affected by the "angle" property, but most will ignore it.

= How to use Path Nodes =

Path nodes are placed like any other entity (RMB and select "add entity", then scroll to "paths"). They show up as a coloured box with an arrow in the editor (colour varies depending on config.)

Path nodes are useless if they are not linked to another entity (either an AI or another node). In order to link them, you use the "target" property. This tells the AI what path node they should go to (or act on) next. If you type "target" "path_corner_1" in your AI property list, then your AI will walk to "path_corner_1" when the map starts. Without a "target" property, your AI will not go anywhere. Once you add a "target" property to either your AI or another node, you should see a colored line connecting the two entities.

Behaviour nodes activate behaviour in order. In other words, if you want an AI to reach a path_corner, then turn to face a direction, then wait for a time, then play an animation, you need to link the nodes in that order.

path_corner ---> path_turn ----> path_wait ----> path_cycleanim -----> next path_corner

== Variation and Randomness ==

It is also possible to target multiple nodes (using "target_1", "target_2" etc. spawn args). In this case, the AI will choose one of these nodes with equal probability.
If the '''"chance"''' spawn arg (between 0 and 1) is set on a node, it defines the probability for the AI to choose this path node next when multiple path nodes are targetted. The chances at any point must not add to greater than 1, or it won't work properly. For example, if a path_corner targets two different nodes, you could set "chance" ".75" on one and "chance" ".25" on the other. This will result in AI choosing the first path 3/4 of the time.

There are now two new spawnargs, '''"alert_idle_only"''' and '''"idle_only"''' that can be set on path nodes. The nodes are then only chosen when the AI is in that state. For example, if you set a path_corner as "idle_only", then the AI will no longer go to that path node when it has been alerted. This allows the mapper to set a complete set of alternate patrols and actions for AI who have been alerted (like sending them to guard important areas).

Nodes that make the AI walk to a specified location (currently the only one that does this is the path_corner) can have an '''"move_to_position_tolerance"''' spawn arg, which defines how close the AI has to be to the destination point to determine the position as reached. Normally, the AI considers the position reached as soon as it is inside its bounding box (most of our humanoid AI are using aas32, so the point would need to be within 16 units from the AI's origin). This is not always accurate enough, for example when a path_corner is placed in front of a chair where the AI is supposed to sit down, making the AI place half of their back next to the chair.

[Fidcal: I believe the accuracy spawnarg is replaced by the move_to_position_tolerance above. The following likely applies to the new spawnarg anyway.]
Setting the accuracy spawn arg will change the horizontal size of the bounding box used for checking. If the accuracy is set to negative values (default is -1), the standard bounding box will be used as before.

This spawnarg is available for all entities and can also affect AIs moving towards levers or buttons.

== path_corner ==
Probably the most common path node, this is a "travel node". AI will walk from their current position to this node in as straight a line as possible. This node must be on the ground and in an area AI can reach. See [[Pathfinding]] for more information on how to help AI go from one node to another.

To make AI patrol an area, each path_corner node can target the next one in sequence. If AI reach a node that does not target anything, they will stop there and no longer move without player interaction. It is possible for two path_nodes to target each other, which means the AI will walk from one to the other and back again endlessly.

A single entity (path node or AI) can target more than one path_corner; D3 will randomly choose between the targetted nodes. Use the following syntax: ''(actually this syntax needs to be double checked)''

target path_corner_1
target_2 path_corner_2

''(At the moment, targetting more than 2 path_corners from the same entity does not seem to work (possibly a DR bug).''

In the example below, both A and B are path_corner nodes. On map start, the AI will walk to A, then turn and walk to B, then stop.

[[image:pathfinding2.jpg]]

Extra note: To make an AI run on patrol add the property/value : "run" "1" to a path_corner on the AI's patrol and the AI will run to it (then resume walking after it if the next path_corner does not have that property set.)

'''Note that an AI will return to a path_corner ''(does it choose the nearest or most recent?)'' after a failed search. If you do not have at least one path_corner, the AI will stop wherever they are when their search is complete.'''

== path_wait ==

This is a behaviour node. It does not tell an AI to move anywhere. This node tells an AI to wait in an idle state for a given amount of time. Once that time is up, the AI will proceed to whatever the next target is (a path_wait with no target is pretty pointless).

A path_wait node appears as a small orange box. It has a directional arrow, but that has no affect on which direction the AI faces in the first place. However, you can set the angle key on the path either by rotating the entity or by setting the key directly to make the AI turn and face this direction before starting to wait. '''Important:''' If the angle is 0 make sure it is actually on the entity and not just default.

A path_wait node should have a "wait" property, with the number of seconds the AI should wait there before proceeding. It can also have a "wait_max" property which will vary the repeat time. So for example...

* wait 30
* wait_max 40

...will cause the AI to wait between 30 to 40 seconds before proceeding. If wait_max is set to 0, the AI will always wait exactly the time specified in wait before proceeding. If you set wait to 0, the AI will wait between 0 seconds and the time specified in wait_max. Default values are 2 seconds for wait, and 0 seconds for wait_max, so the AI will always wait exactly 2 seconds.

In the following example, A and B are path_corners, and the small orange box is a path_wait entity. On map start, the AI will walk to A and wait there for the required amount of time, then turn and proceeds to B.

[[image:pathfinding3.jpg]]

Note that it does not matter '''where''' the path_wait node is placed. The AI does not actually follow the orange lines (this is not really intuitive, I know). The example below would cause the exact same behaviour as the example above--in both cases the AI will walk directly from A to B.

[[image:pathfinding4.jpg]]

Another useful example for path_wait is that of the stationary guard who turns to look in different directions periodically. This can be schematically represented (arrows indicate target links) as:

AI -> path_corner1 -> path_wait1 -> path_wait2 -> path_corner1

Example properties for the path_wait are:
wait: 5 (minimum time to wait on action)
wait_max: 10 (maximum time to wait on action)
angle: 0 ('''Important''': this property is essential for proper function even if the angle is 0)

The AI walks to or stands at the path_corner. The next action is to do what is indicated by the first path_wait. In this example, it tells the AI to face a particular direction for a certain period of time. This then targets a second path_wait which has the AI face a different direction for a certain period of time. To complete the cycle, the second path_wait then targets the original path_corner. The path_corners are necessary because again, the path_wait doesn't contain pathing or location information. Without the path_corner, if the AI is caused to wander (e.g. becomes alerted), it might not return to the original standing spot, and instead will do the look angles right where it stands. The path_corner assures the AI returns to its original position.

== path_turn ==

This behaviour node tells an AI to turn in place to face a chosen direction. It does not make the AI walk anywhere. This is the one node where the directional arrow does seem to matter--the AI turns to face the same direction as the arrow. Alternately, you can use the property "angle" and the values below:

* 0 = East (X)
* 90 = North (Y)
* 180 = West (-X)
* 270 = South (-Y)
* 360 = East(X)

(Actually, to be more accurate, rotating the entity automatically adds the "angle" property to the entity. If you just leave the arrow facing the way it is when you create the entity, there will be no "angle" property, and therefore the AI will not turn.)

== path_anim ==

This is a behaviour node that makes the AI play an animation, once. When that animation is done, it proceeds to the next target (if any). This could be used to make an AI walk over to a bookshelf and play a 'reaching out' animation, for example.

The syntax proper syntax is:

anim [animation name]

You can see the list of animations names here: [[Animation List]]. Do not use the name of the actual animation file.

A path_anim can have only one animation, but it is possible for a single entity to target more than one path_anim. The AI will pick one of the path_anim nodes at random and play that animation.

When you first create the path_anim entity, the directional arrow is meaningless. However, if you rotate the entity, the "angle" property is added to the entity and is updated based on which direction the arrow is pointing. That property indicates the direction the AI will face while playing the animation. '''This value appears to be necessary to make the animation work.'''

== path_sit ==

This is a behaviour node that makes the AI sit down at its current location. See [[Sitting Behaviour for AI]] for more information.

= Flee Points =

Do NOT target the AI to a flee point; AI will automatically go to a flee point if in danger. Just make available path_flee_point entities at suitable places where you would like your AI to flee to.

On the path_flee_point entity:

"is_guarded" A fleeing AI, eg, a civilian, would give this preference (but it is up to the mapper to actually provide a guard there.)

"team" Only AI on this team would use this flee point.

* This is how the code works:
* The AI tries to determine the nearest friendly guarded flee point and flee to it.
* If there is no friendly guarded flee point, the AI tries to find the nearest friendly flee point (on friendly team) and run to it.
* If this also fails, the AI tries to find an AAS area far from the enemy and run there.
* If the enemy is still visible when the AI reaches his destination, he chooses the farthest friendly guarded flee point to run to,
* if this fails, the farthest friendly flee point,
* and if this also fails falls back to choosing an AAS area far from the enemy to run to.
* So neither the priority nor the target spawn arg have any function here, it is not possible to weight the flee points. The AI will choose one automatically.

A problem occurs when the AI doesn't find any appropriate flee points but also no AAS area that is far away enough from the enemy. In this case, he will just stand there. Maybe he should either cower and be afraid in this case or just run around like a mad chicken?

Whether a fleeing AI passes on info to other AI as to the source of their alert (ie so armed guard would go to investigate to the right place whereas another civilan might also flee to the farthest point.)
Yes, they do. The cry for help bark is propagated to other AI and carries information about the last alert position.

Armed AI will also flee if their health points drop to a certain level? Where is that determined?
This is determined by the health_critical spawn arg.

== path_interact ==

This lets the AI interact with an entity (for example a button) in a similar way to frobbing. This will only work for buttons etc, not for inventory items and moveables. The AI will stop and look at the entiy while interacting, but not walk to it, so a path_corner next to the entity is required. AI will use normal doors and elevators without needing a path_interact (confirmation needed). However, this could be used to make AI turn on lightswitches, open mechanical doors, etc.

You need to add these spawnargs to the path_interact entity:

ent <name of entity to be frobbed by AI>

target <next path entity (if any)>

= Untested Nodes =

I have not personally tested the following, so I'm just going by their editor descriptions. They may or may not work as described.

== path_cycleanim ==

The AI stays in place and loops the selected animation, either for a specified amount of time (using the 'wait' property) or until triggered. Syntax needed.

== path_lookat ==

This does not stop the AI, but they will turn their head and look somewhere specific as they walk to their next target. For the next ''wait'' seconds, turn head to look at the entity given by the ''focus'' spawnarg (defaults to looking at the path_lookat entity itself). This is useful if you want to make sure an AI is looking at a specific spot (or away from a certain spot) during their patrol.

== path_waitfortrigger ==

Waits at a given place until triggered, then proceeds to the next target. This is useful if you want some control over exactly where the AI is when the players first see it.

== path_hide ==

Supposedly deactivates and stops rendering the AI.

Turns out this doesn't work well with TDM...makes AI invisible but they still talk and occupy space. To remove an AI from the map, try grayman's approach:

I wrapped the AI's final path corner in a trigger_once_entityname and gave the trigger the keyword pair "entityname <AI_name>". (The docs don't tell you about this key, but the game will error out if it's not there, and tell you it's missing. A classic "trial by error".)

The trigger targets a func_remove, which has the key "target <AI_name>".

So when he reaches the last path_corner, the trigger recognizes him and tells the func_remove, which takes him out of the game.

== path_show ==

Starts rendering the AI. I would assume this one would be linked to a path_waitfortrigger, to create AI that spawn when triggered. This could be used to create the effect that an AI just came through a doorway or around a corner.

== path_attack ==

Used to script AI attacking a particular enemy, for scripted sequences I guess. AI will continue on to the next path entity if it kills the enemy.

Questions: How do you define who the AI attacks?

[Fidcal]: Just found this - "Character will attack the character specified by 'enemy' key. Character will go to next path when enemy dies or when activated." Not tested.

{{tutorial-editing}}

Sitting Behaviour for AI

2010-12-25T06:10:05Z

Fidcal: /* Sitting at Map Start */

There are two different ways to get AI to sit in your map; pick the one that best suits your needs.

==Sitting at Map Start==
The easier of the two options. Just set the spawnarg "sitting" "1" on the AI, and the AI will sit down immediately at map start. They will stay this way until alerted to the point of searching, at which point they will get up. After calming down, they will go back and sit again.

You must place the AI next to the chair, facing away from the direction you want him to sit (or use angles, see below). '''Important:''' If the angle is 0 make sure it is actually on the entity and not just default. It is not enough to have it on a path_wait after the path_sit. The code does not detect the surface the AI sits on, so he will sit on thin air if there is no stool or chair there.

==Sitting During Patrol==
It is now possible to have the AI sitting down and getting up during patrolling, using a '''path_sit''' entity. You must place the path_sit next to the chair, angled away from the direction you want him to sit.

You can set "wait" and/or "wait_max" to let the AI wait and get up after that time. "Wait" is a minimum wait time, so if you set "wait" to 5 seconds and "wait_max" to 10 seconds, the AI will wait between 5 and 10 seconds every time. If you only set "wait", the AI will always wait exactly 5 seconds. If you only set "wait_max", the AI will wait between 0 and 10 seconds.

If you don't set either one, the AI will stay seated and you can also do path_anims and path_waits for example (they'll play that animation on the torso channel while sitting).

The AI will get up if alerted to searching state or if it has to move to another position.

Example: If you want an AI to sit, and then play a warm hands after 20 seconds, you would use a path_sit without a wait spawnarg (AI sits down, the path_sit task is terminated and the AI stays seated), then a path_wait for 20 seconds, then a path_anim, then another path_wait, and then a path_corner or something (AI gets up and walks to path_corner).

If you have any path problems, eg, with AI clipping into Monsterclip on chair, then make the chair a moveable and add frobable 0 and notPushable 1 and remove the monsterclip. It is effectively static but the AI will path it correctly without monsterclip.

== Sitting Angles ==

Mappers may want more control over where AI face after sitting down. By default, AI stand directly in front of the chair when sitting or standing. This doesn't work well if you want AI to sit close to a table, however. The solution is to use a "sit_down_angle" spawnarg on the AI (if AI has 'sitting' spawnarg but on the path_sit if that is used.) This will cause the AI to spin in the chair after sitting until they face the direction listed. They will turn back when it is time to stand up.

Note that the angles are relative to the world, not the AI.

Other sitting spawnargs include:

"sit_down_slide_dist", which is currently 8; controls how far AI slide back onto the chair when sitting down.

"sitting_turn_pivot" "The offset of the pivot for turning while seated."

{{tutorial-ai}}

Path Nodes

2010-12-25T06:05:55Z

Fidcal: /* path_wait */

''originally written by Springheel''

For more information on pathfinding, see [[Pathfinding]].

= What are Path Nodes? =

Path entities (or path nodes) are the things that you use to make your AI move (patrol) around the map. Placing path nodes can take a little getting used to; hopefully this article will help (I'm far from an expert, but here's what I've discovered so far).

There are lots of different kinds of path nodes. It can sometimes help to think of them as "travel nodes" (nodes that AI will travel to) and "behaviour nodes" (nodes that tell AI how to behave at a certain point).

Although path nodes have a directional arrow in the editor, it has no impact on most nodes. Rotating the node does add a corresponding "angle" property to the entity (matching the direction of the arrow). Certain nodes (path_anim, path_wait, and path_turn, for example) are affected by the "angle" property, but most will ignore it.

= How to use Path Nodes =

Path nodes are placed like any other entity (RMB and select "add entity", then scroll to "paths"). They show up as a coloured box with an arrow in the editor (colour varies depending on config.)

Path nodes are useless if they are not linked to another entity (either an AI or another node). In order to link them, you use the "target" property. This tells the AI what path node they should go to (or act on) next. If you type "target" "path_corner_1" in your AI property list, then your AI will walk to "path_corner_1" when the map starts. Without a "target" property, your AI will not go anywhere. Once you add a "target" property to either your AI or another node, you should see a colored line connecting the two entities.

Behaviour nodes activate behaviour in order. In other words, if you want an AI to reach a path_corner, then turn to face a direction, then wait for a time, then play an animation, you need to link the nodes in that order.

path_corner ---> path_turn ----> path_wait ----> path_cycleanim -----> next path_corner

== Variation and Randomness ==

It is also possible to target multiple nodes (using "target_1", "target_2" etc. spawn args). In this case, the AI will choose one of these nodes with equal probability.
If the '''"chance"''' spawn arg (between 0 and 1) is set on a node, it defines the probability for the AI to choose this path node next when multiple path nodes are targetted. The chances at any point must not add to greater than 1, or it won't work properly. For example, if a path_corner targets two different nodes, you could set "chance" ".75" on one and "chance" ".25" on the other. This will result in AI choosing the first path 3/4 of the time.

There are now two new spawnargs, '''"alert_idle_only"''' and '''"idle_only"''' that can be set on path nodes. The nodes are then only chosen when the AI is in that state. For example, if you set a path_corner as "idle_only", then the AI will no longer go to that path node when it has been alerted. This allows the mapper to set a complete set of alternate patrols and actions for AI who have been alerted (like sending them to guard important areas).

Nodes that make the AI walk to a specified location (currently the only one that does this is the path_corner) can have an '''"move_to_position_tolerance"''' spawn arg, which defines how close the AI has to be to the destination point to determine the position as reached. Normally, the AI considers the position reached as soon as it is inside its bounding box (most of our humanoid AI are using aas32, so the point would need to be within 16 units from the AI's origin). This is not always accurate enough, for example when a path_corner is placed in front of a chair where the AI is supposed to sit down, making the AI place half of their back next to the chair.
Setting the accuracy spawn arg will change the horizontal size of the bounding box used for checking. If the accuracy is set to negative values (default is -1), the standard bounding box will be used as before.

This spawnarg is available for all entities and can also affect AIs moving towards levers or buttons.

== path_corner ==
Probably the most common path node, this is a "travel node". AI will walk from their current position to this node in as straight a line as possible. This node must be on the ground and in an area AI can reach. See [[Pathfinding]] for more information on how to help AI go from one node to another.

To make AI patrol an area, each path_corner node can target the next one in sequence. If AI reach a node that does not target anything, they will stop there and no longer move without player interaction. It is possible for two path_nodes to target each other, which means the AI will walk from one to the other and back again endlessly.

A single entity (path node or AI) can target more than one path_corner; D3 will randomly choose between the targetted nodes. Use the following syntax: ''(actually this syntax needs to be double checked)''

target path_corner_1
target_2 path_corner_2

''(At the moment, targetting more than 2 path_corners from the same entity does not seem to work (possibly a DR bug).''

In the example below, both A and B are path_corner nodes. On map start, the AI will walk to A, then turn and walk to B, then stop.

[[image:pathfinding2.jpg]]

Extra note: To make an AI run on patrol add the property/value : "run" "1" to a path_corner on the AI's patrol and the AI will run to it (then resume walking after it if the next path_corner does not have that property set.)

'''Note that an AI will return to a path_corner ''(does it choose the nearest or most recent?)'' after a failed search. If you do not have at least one path_corner, the AI will stop wherever they are when their search is complete.'''

== path_wait ==

This is a behaviour node. It does not tell an AI to move anywhere. This node tells an AI to wait in an idle state for a given amount of time. Once that time is up, the AI will proceed to whatever the next target is (a path_wait with no target is pretty pointless).

A path_wait node appears as a small orange box. It has a directional arrow, but that has no affect on which direction the AI faces in the first place. However, you can set the angle key on the path either by rotating the entity or by setting the key directly to make the AI turn and face this direction before starting to wait. '''Important:''' If the angle is 0 make sure it is actually on the entity and not just default.

A path_wait node should have a "wait" property, with the number of seconds the AI should wait there before proceeding. It can also have a "wait_max" property which will vary the repeat time. So for example...

* wait 30
* wait_max 40

...will cause the AI to wait between 30 to 40 seconds before proceeding. If wait_max is set to 0, the AI will always wait exactly the time specified in wait before proceeding. If you set wait to 0, the AI will wait between 0 seconds and the time specified in wait_max. Default values are 2 seconds for wait, and 0 seconds for wait_max, so the AI will always wait exactly 2 seconds.

In the following example, A and B are path_corners, and the small orange box is a path_wait entity. On map start, the AI will walk to A and wait there for the required amount of time, then turn and proceeds to B.

[[image:pathfinding3.jpg]]

Note that it does not matter '''where''' the path_wait node is placed. The AI does not actually follow the orange lines (this is not really intuitive, I know). The example below would cause the exact same behaviour as the example above--in both cases the AI will walk directly from A to B.

[[image:pathfinding4.jpg]]

Another useful example for path_wait is that of the stationary guard who turns to look in different directions periodically. This can be schematically represented (arrows indicate target links) as:

AI -> path_corner1 -> path_wait1 -> path_wait2 -> path_corner1

Example properties for the path_wait are:
wait: 5 (minimum time to wait on action)
wait_max: 10 (maximum time to wait on action)
angle: 0 ('''Important''': this property is essential for proper function even if the angle is 0)

The AI walks to or stands at the path_corner. The next action is to do what is indicated by the first path_wait. In this example, it tells the AI to face a particular direction for a certain period of time. This then targets a second path_wait which has the AI face a different direction for a certain period of time. To complete the cycle, the second path_wait then targets the original path_corner. The path_corners are necessary because again, the path_wait doesn't contain pathing or location information. Without the path_corner, if the AI is caused to wander (e.g. becomes alerted), it might not return to the original standing spot, and instead will do the look angles right where it stands. The path_corner assures the AI returns to its original position.

== path_turn ==

This behaviour node tells an AI to turn in place to face a chosen direction. It does not make the AI walk anywhere. This is the one node where the directional arrow does seem to matter--the AI turns to face the same direction as the arrow. Alternately, you can use the property "angle" and the values below:

* 0 = East (X)
* 90 = North (Y)
* 180 = West (-X)
* 270 = South (-Y)
* 360 = East(X)

(Actually, to be more accurate, rotating the entity automatically adds the "angle" property to the entity. If you just leave the arrow facing the way it is when you create the entity, there will be no "angle" property, and therefore the AI will not turn.)

== path_anim ==

This is a behaviour node that makes the AI play an animation, once. When that animation is done, it proceeds to the next target (if any). This could be used to make an AI walk over to a bookshelf and play a 'reaching out' animation, for example.

The syntax proper syntax is:

anim [animation name]

You can see the list of animations names here: [[Animation List]]. Do not use the name of the actual animation file.

A path_anim can have only one animation, but it is possible for a single entity to target more than one path_anim. The AI will pick one of the path_anim nodes at random and play that animation.

When you first create the path_anim entity, the directional arrow is meaningless. However, if you rotate the entity, the "angle" property is added to the entity and is updated based on which direction the arrow is pointing. That property indicates the direction the AI will face while playing the animation. '''This value appears to be necessary to make the animation work.'''

== path_sit ==

This is a behaviour node that makes the AI sit down at its current location. See [[Sitting Behaviour for AI]] for more information.

= Flee Points =

Do NOT target the AI to a flee point; AI will automatically go to a flee point if in danger. Just make available path_flee_point entities at suitable places where you would like your AI to flee to.

On the path_flee_point entity:

"is_guarded" A fleeing AI, eg, a civilian, would give this preference (but it is up to the mapper to actually provide a guard there.)

"team" Only AI on this team would use this flee point.

* This is how the code works:
* The AI tries to determine the nearest friendly guarded flee point and flee to it.
* If there is no friendly guarded flee point, the AI tries to find the nearest friendly flee point (on friendly team) and run to it.
* If this also fails, the AI tries to find an AAS area far from the enemy and run there.
* If the enemy is still visible when the AI reaches his destination, he chooses the farthest friendly guarded flee point to run to,
* if this fails, the farthest friendly flee point,
* and if this also fails falls back to choosing an AAS area far from the enemy to run to.
* So neither the priority nor the target spawn arg have any function here, it is not possible to weight the flee points. The AI will choose one automatically.

A problem occurs when the AI doesn't find any appropriate flee points but also no AAS area that is far away enough from the enemy. In this case, he will just stand there. Maybe he should either cower and be afraid in this case or just run around like a mad chicken?

Whether a fleeing AI passes on info to other AI as to the source of their alert (ie so armed guard would go to investigate to the right place whereas another civilan might also flee to the farthest point.)
Yes, they do. The cry for help bark is propagated to other AI and carries information about the last alert position.

Armed AI will also flee if their health points drop to a certain level? Where is that determined?
This is determined by the health_critical spawn arg.

== path_interact ==

This lets the AI interact with an entity (for example a button) in a similar way to frobbing. This will only work for buttons etc, not for inventory items and moveables. The AI will stop and look at the entiy while interacting, but not walk to it, so a path_corner next to the entity is required. AI will use normal doors and elevators without needing a path_interact (confirmation needed). However, this could be used to make AI turn on lightswitches, open mechanical doors, etc.

You need to add these spawnargs to the path_interact entity:

ent <name of entity to be frobbed by AI>

target <next path entity (if any)>

= Untested Nodes =

I have not personally tested the following, so I'm just going by their editor descriptions. They may or may not work as described.

== path_cycleanim ==

The AI stays in place and loops the selected animation, either for a specified amount of time (using the 'wait' property) or until triggered. Syntax needed.

== path_lookat ==

This does not stop the AI, but they will turn their head and look somewhere specific as they walk to their next target. For the next ''wait'' seconds, turn head to look at the entity given by the ''focus'' spawnarg (defaults to looking at the path_lookat entity itself). This is useful if you want to make sure an AI is looking at a specific spot (or away from a certain spot) during their patrol.

== path_waitfortrigger ==

Waits at a given place until triggered, then proceeds to the next target. This is useful if you want some control over exactly where the AI is when the players first see it.

== path_hide ==

Supposedly deactivates and stops rendering the AI.

Turns out this doesn't work well with TDM...makes AI invisible but they still talk and occupy space. To remove an AI from the map, try grayman's approach:

I wrapped the AI's final path corner in a trigger_once_entityname and gave the trigger the keyword pair "entityname <AI_name>". (The docs don't tell you about this key, but the game will error out if it's not there, and tell you it's missing. A classic "trial by error".)

The trigger targets a func_remove, which has the key "target <AI_name>".

So when he reaches the last path_corner, the trigger recognizes him and tells the func_remove, which takes him out of the game.

== path_show ==

Starts rendering the AI. I would assume this one would be linked to a path_waitfortrigger, to create AI that spawn when triggered. This could be used to create the effect that an AI just came through a doorway or around a corner.

== path_attack ==

Used to script AI attacking a particular enemy, for scripted sequences I guess. AI will continue on to the next path entity if it kills the enemy.

Questions: How do you define who the AI attacks?

[Fidcal]: Just found this - "Character will attack the character specified by 'enemy' key. Character will go to next path when enemy dies or when activated." Not tested.

{{tutorial-editing}}

Doors

2010-12-24T18:33:43Z

Fidcal: /* AI Door management */

{{todo}}
''Written by Fidcal'' ''edit Baddcog''

==Quick Summary==

Quick way to get an unlocked door in your map:

* Insert one of the prefab doors complete with handles and select its skin property and click the button to change its skin appearance to whatever you want. Set any other properties you need.

Alternatively,

* Create a door from the entity list
* Use the "skin" spawnarg on the door to change its appearance.
* Create a handle from the entity list
* Add the ''door_handle'' property to the door and give it the name of the handle
* To the door handle add the value frob_peer and use the name of the door.
* To open clockwise, change the ''rotate'' property from <code>0 90 0</code> to <code>0 -90 0</code>

==Introduction==

This tutorial explains how to put doors into your map using Dark Radiant, as well as adjust them and their properties.

The rest of this tutorial assumes that you have a basic understanding of using DarkRadiant. If you haven't done so, please go read the [[Dark Radiant Must Know Basic Intro]] article first.

Additionally:

* Up, down, left, and right in Dark Radiant's ''top'' orthoview are regarded here as the standard map directions of North, South, East, and West where useful for clarity.
* Where the term ''brush'' is used with a door it mostly also applies to a door made up of a group of brushes and/or patches.
* Where the term ''door'' is used it often will also apply to any object you wish to rotate when frobbed, for instance an openable window, box lid, or even more exotic objects that the imaginative mapper might conceive like a signal, engine part, toy, or whatever. So long as it needs to turn or slide just a fixed amount when frobbed then return when frobbed again then the following applies.

==Door types==

All tangible objects in Dark Mod are ''entities'', having either a pre-made model shape or else brush/patch(es). So there are two ways to create a door in Dark Radiant: as a model door or a textured brush door (or a hybrid of the two).

Models are ready made door objects but cannot within Dark Radiant (at the time of writing) be resized, rescaled, cropped or clipped whereas brushes are very flexible in that respect and can be worked into custom shapes for your map, including secret doors that blend into walls and other surfaces.

Most of the current door models are found in two places along with the door handles.
*Model Viewer: doors created from here will be static in the world and have no props other than material type.
You can add any props to them to make them working doors. If nothing else it is a good place to view the different size and skin options for the doors.
*Entity List: most of the door models can be found here. These doors have properties already assigned so they are ready to be used. Only one base door of each type is listed, create the size/hinge count door you want (2 hinge doors have a 'no hinge' skin). You can choose a skin for the door once it has been created in the editor with the "skin" spawnarg (use the model name of the door you want, taken from the model list, as its value). This is the easiest way to create a door. The same goes for door handles.

Remember also that door functions may be applied to objects other than doors for instance to openable windows, drawbridges, gates, in fact anything that needs a partial rotation or slide when frobbed then return when frobbed again such as a signal device. Lockboxes and chests use similar properties.

Door/handle prefabs seem to crash Doom3 when trying to reload a map so far now just create and link each door/handle. You can create one set and copy/paste them, but you need to take great care that all the name props are changed to match each clone. Otherwise you get handles that fly off with a distant door and handles that don't move.

==Creating a Door==

Put simply, to make a door you will be creating an 'entity with model' or 'entity with brush' or some variation thereof.

===Creating a Model Door===

There are several approaches to making a model door; the simplest is to create a door from the entity list; or create a door from the model viewer (good for static unusable prop doors).

'''Entity List''':

*Deselect everything in editor by hitting the Esc button
*Right-click an ortho view and select Create Entity
*Navigate to darkmod/movers/''atdm:door_...'', choose the door you want
*Click Add
*To change its appearance, add a "skin" spawnarg to the door, with the value being the model name of the door you want.

You now have a workable door in your level.

'''Model Viewer''':

* Right click in the orthoview, select ''Create Model'' then <code>darkmod</code> and select a door.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* Click [[Image:Button ok.png]] and you have a static door.
* If you want to make it work (openable, frobbable) then:
** Select the entity inspector,
** Select the top classname line so it highlights
** Select the func_static line in the input box ''below'' the properties window.
** Edit <code>func_static</code> to <code>atdm:mover_door</code>
** Click {{check}} or press {{key-enter}}

Alternatively you can do it the old way:

* Create any temporary brush
* Right click in orthoview and select <code>Create Entity</code> then <code>atdm:mover_door</code>.
* Left lick the model name line in the entity inspector.
* Below it on the ''Entity Inspector'' panel you should now see a button 'Choose Model'
* Left click it, select a door model from the darkmod group.
* Note that you can left drag the image in the ''Choose Model'' dialog to rotate it around.
* The temporary brush was deleted.

In all three instances, you now have a working door with default properties.

Name your door by adding the prop (or modifing it) to name ''My_Door_1''. You can use any name that you feel is appropriate but all doors with handles attached ''must'' have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below).

To add a handle and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

===Creating a Textured Brush Door===

'''Tip:''' If unsure of size then you might insert a temporary human AI first to get a sense of height.

==== The simplest brush door: ====

* Drag out a new brush to the size required, eg, a seven foot high door is 84" x 1.1 = about 90 units in Dark Radiant.
* Give it a door texture from the texture browser (or wall texture for a secret door)
* Right click in orthoview and select ''Create Entity'' then <code>atdm:mover_door</code>
* You now have a default door that rotates around its center.

To move the rotation point to the door edge and other adjustments, see [[#Customising and Adjusting Door Properties]] below.

==== Multi-brush doors: ====

More complex multi-brush doors can be created using the [[Clipper]] tool, CSG, etc. - this is not covered in this tutorial. Then assign <code>atdm:mover_door</code> for that whole brush structure. Also you can collect various brushes positioned together in relation to one another as needed, select them all, then assign <code>atdm:mover_door</code> for the group. All the brushes will be children of the <code>atdm:mover_door</code> entity and will rotate and be frobbable, etc. as one unit, as one door. To add further brushes or even model shapes later see the section on [[#Adding handles and other items to doors]].

Name your door by adding the prop (or modifing it) to name My_Door_1. You can use any name that you feel is appropriate but all doors with handles attached must have their own specific name. Use the name My_Door_1 for your first attempt as it will be referenced when you get around to attaching handles (see below). (repeated from above in case you didn't choose to create a model door)

=== Double Doors ===
Double doors are automatically recognised by the code when the doors are spawned. The prerequisite is that both doors are sharing/touching the same visportal. The spawnarg ''auto_setup_double_door'' (which defaults to "1") will take care of setting up the open/lock peer relationship between the two doors. The doors will open/close and lock/unlock along with each other as a result.

What happens behind the scenes: the doors are adding each other to their internal open_peer and lock_peer list, which causes the double doors to perform the same action when frobbed or used.

Note that ''auto_setup_double_door'' will not set the frob_peer relationship, i.e. each door will frob-highlight on its own without highlighting the other door. You'll need to add that spawnarg manually if you want to highlight the entire double door as one.

==Customising and Adjusting Door Properties==

Handles, lockplates, etc. can be added to doors and door properties can be adjusted for rotation, sliding, locking, and more.

Some of the door models have hinge plates and lockboxes that are reskinnable with a good variety of skins.

===Door handles and other door attachments===

Summary: just add the property ''bind'' with the door's name to the attachment and position it where you want it on the door. If it's a ''atdm:mover_door_handle'' then it automatically will work as a handle but you can bind virtually anything.
You can add handles and other items to doors such that they move correctly with the door whether rotating, sliding, or both and even if the door is not vertical such as a skylight or trapdoor.
Handle models come in two types, ''single handles'' and ''double handles''. A single handle is one sided, this means the handle will be inside the door or outside the door, but not both. A double handle has a lever on the inside of the door and a handle on the outside of the door. Each has benefits.

*'''''Single door handles''''':
Single door handles can be used on a static door, a door that's just for show that no AI's or the player can use. In this case you should just create a door handle from the model viewer, it will be static and have no properties such as scripts. It is for looks only.

Single handles can also be used inside AND outside of the same door to save on rendering. Unlike the double handles the handle on the inside of a portal won't render. The curved handle is only about 130 polys per side, but if you have a large area and 10 handles you can save 1,000 polys from being rendered. Everything counts when it comes to performance.
I will call this ''multiple handles'', see more below.

These can also be useful on brush doors created in the editor that may be very thin or very wide.

*'''''Double door handles''''':
These are models have have a handle inside and outside. The bonus is that they only use one entity. Maps are limited to about 4,000 entities but when you count lights, AI, sound speakers, ect... you can run out of entities quickly on a large map. If you plan on building a large map this is the way to go, even in a small map they have benefits, namely that you only have to attach one handle per door.

Whether you decide to use a single handle or a double handle you must first follow the instructions below and attach one handle first. If you choose a double handle, follow the instructions below and you are done. If you choose a single handle type follow the instructions then also follow the ''multiple handle'' instructions for the second handle.

Both single and double handle types can be found in two places. The model viewer which will create a static model good for show, you can manually add props to make them work OR you can look in the entity browser.
Using a handle from the entity browser saves you a little bit of time as some props are already added, you just need to add the frob_peer names for the doors/handles and the door_handle name to the door.

=== Adding a working model door handle===

Quick summary:
* Create a model or brush handle and make it an ''atdm:mover_door_handle'' entity.
* Position it on your door. Use the opposite side from the door's multicolor X-Y-Z indicator (highlight the door to see it) if it's not obvious which side it goes on.
* '''Bind''' the handle to the door (bind <doorname>)
* It should now be a working handle though may need adjustments of rotation etc. see later.

Important: read preceding section on door handle types and performance issues first.

This works with both a model door and a brush door:

'''Rotation''':
* By default the door handle entity rotates ''anti-clockwise'' (looked at from the front) then springs back. A ''double handle'' model is OK but two singles (see ''Multiple door handles'' below) need more care as only one is the functioning entity and the other is just attached to it. So anti-clockwise is fine for a door with its hinge on the left and the handle on the right - the handle will rotate down then spring back. If you put the functioning door handle on the other side you will have to change the default ''rotate'' property from -45 0 0 to 45 0 0. '''''Therefore it is easier to generally put this handle on the side of the door where the hinge is on the left and the non-functioning attachment handle on the other side.'''''
*If your door only needs one handle, eg, a cupboard door, and from outside its hinge is on the right then you will need to change the ''rotate'' property of the handle as described above.

'''''The functioning handle entity:'''''
* Create an entity door handle (movers folder) or create a brush or model handle and assign it the entity ''atdm:mover_door_handle''.
* Position it where you wish on your door.
* '''Bind''' the handle to the door, by adding the "bind" spawnarg to the handle.

You now have a working door handle with default properties.

*'''Multiple door handles''':
Now that you've got a handle attached to one side of the door it is time to add one to the other side (unless you used a double handle).
* Create the new handle. The single handles come in left and right persuasions. A door needs a left facing handle on one side and a right facing handle on the other, so if you have already added the left handle create a right handle and line it up on the other side of the door.
* Name this handle. I prefer to keep a naming convention for each door and it's respective handles, it makes things alot easier. The door is named '''My_Door_1''', the first handle is named '''My_Handle_1''' so name the second handle '''My_Handle_1_1'''. This will make it stay with the first handle in the entity list. This is important to keep organized. If you name it My_Handle_2 then when you get to another door named My_Door_2 you'll be confused.
* Place and '''bind''' that handle to your door.

You now have two single door handles on either side of the door that rotate together as if they were physically attached.

'''To add a brush to a brush door''':
* Select the new brush ''and'' the brush door all together; ''the entity '''must''' be selected '''last'''.''
* Use {{menu|Edit|Reparent primitives}}. This ensures the parent entity adopts the new item(s).
* If you have trouble selecting them in the orthoview because other brushes, etc. get selected then try in the camera view or as a last resort move them temporarily to an open area (but keep them in the same positions relative to each other.) Use {{key-shift}}+{{LMB}} on new item(s) then {{key-shift}}+{{LMB}} on main entity. Once they are all selected, use the {{menu|Edit|Reparent primitives}}.

'''To add ''model'' static items''': knockers, hinges, static handles etc. to a ''Model Door'':
* Select item
* Right click in orthoview and select ''Create Entity'' then <code>entity func_static</code>
* Position it where you wish on your door.
* To synchronize this with your particular door you need to add the property ''bind'' and the individual door name to the brush entity. To do this...
** Select the model door.
** In the entity inspector, select the ''name'' line
** Select the bottom line in the input box ''below'' the properties window.
** Copy the name
** Deselect the door with {{key-esc}}
** Select the brush entity
** Add a property "bind" to it.
** Change the value of the property by pasting in the door name
** Click {{check}} or press {{key-enter}}

'''To add ''brush'' static items''': knockers, hinges, static handles to a Model Door:
* This method is not ideal but it seems to work OK.
* Select the brush.
* Right click in orthoview and select Create Entity then ''atdm:mover_door_handle''
* Position it where you wish on your door.

To synchronize this with your particular door you need to add the property ''door_handle'' on the door, and give as the value the name of the brush you just created.

This brush turns like a handle. To stop it:

* Adding ''rotate 0 0 0'' or disabling the handle script won't help.
* Add a real working handle (as in the section above ''To add a working model door handle...'' and it must be added LAST.)

If you don't want too see a real working handle added maybe try another tiny brush with the handle function and hide it inside the door?

===Locking Doors===

To lock a door check the ''show inherited properties'' in the entity inspector for a ''atdm:mover_door'' entity and you should see the ''locked'' property. Select it and in the input box below the properties you can change its value:

* 0 = unlocked (default)
* 1 = locked

If locked it will require an entity that is associated with it to be able to act as a key to unlock it.

Currently door handles on locked doors will rotate when frobbed, they will bounce back though and the door will stay locked until unlocked.

===Keys===

Assigning specific keys to specific doors is simple.

* It is recommended that you create an existing key entity. These keys have all required props, they just need to be named.

Alternatively you can create a key from the Model Viewer and want it to be useable
* Make sure it has the properties:
useable 1 [so it can be used by the door]
frobable 1
inv_name <unique name>
inv_category Keys
inv_target player1
inv_icon guis/assets/hud/inventory_icons/<icon name>
inv_stackable 0 or 1 where 1 can be used on all copies of the same key so they show as one entry in the inventory with a total.

Add to the door the property <code>used_by</code> with the name of the key as the value. Multiple keys can open the same door by using several <tt>used_by</tt> spawnargs:

"used_by" "doorkey_1"
"used_by1" "doorkey_2

==== Keys carried by AI ====

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see [[Attaching Props to AI]].

*"def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
*"pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
*"name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
*"set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
*"set name on door_key" "door_key" //here it gets a name to be used in the map in general.

updated by bikerdude.

====Master Key for Testing====

By default, ALL locks can be opened by any key named ''key_master''. Just create a key in your map, name it ''key_master'' and it becomes a master key for use while testing. Add inv_map_start 1 to it so it is in the player inventory at game start. Remember to delete it when your mission is finished.

===Lockpicks===
''by Baddcog''

There are two lock pick types.
*'''s'''=snake
*'''t'''=triangular

A lock can be set with many pins. Each pin has a click sequence and each needs a designated lockpick type (see above). Keep in mind that the lockpicking in The Darkmod is much more involved than in T2 or T3. The player has to listen to sounds or watch a handle or lockbar to know when a lock is pin is picked.

This means that authors can be very evil and really frustrate the player, in which case their missions will probably not be played. So be nice to the player and don't waste your time. Use simple locks for the most part and save complicated locks for important sections and to build tension. Don't make the player have 20 pins to pick all with different lockpicks. In most cases 1 or 2 pins will suffice and it isn't necessary to use both lockpicks on every lock.
Also try to include a lock lever on lockboxes or chests, door handles will rotate as the pins are being picked. This gives the player visual clues to help with the picking (and essential in noisy environments where you can't hear the clicks.)
IMO this system is a huge leap foward for lockpicking but also has the ability to completely frustrate the player as stated above. Keep this in mind when designing your lockpick systems.

These props go on the door itself, or the lid of a chest, eg,
*'''lock_pins''' 1327
*'''lock_picktype''' stts

The lock_pins property specifies how many pins each lockpicktype has.
The lockpick_type property specifies how many times the player has to switch picks and which pick they have to use. You can see there must always be an equal number of lock_pins and lock_picktypes specified

So looking at the example above we have lockpick_type s(snake), t(triangular), t(triangular), and s(snake). The player will have to use these lockpicks in this order. Once the snake lockpick's pins are open the player can advance to the triangular pick and so forth.
5 is added to every click sequence so 5 is the minimum click pattern even if you set it to 0.
In the example above the lockpins specify in order which pick types have how many pins, so the s pick has 1 + 5 = 6 clicks, the t pick has 8 and so on.
The above is a difficult lock and to avoid annoying the player it is best only used rarely on a special lock like an important big vault door. Ordinary footlockers and common doors can be just 1 or 2 click sequences, eg, lock_pins 2 and lock_picktype t means the player uses one pick and listens for the end of one sequence of 7 clicks.

lockpick_rotate - is placed on the door. It is the amount the visible rotating handle or pin rotates while picking. For a rotating handle or lockbar normally ignore this and leave the default. During lockpicking it oscillates and progresses to the normal full turn of the handle. Example 0 45 0.

lockpick_translate - is placed on the door. It is the amount the visible handle or pin moves in a straight line while picking. Use this if you have eg, a lockbar that you want to move in a straight line and not rotate, eg sliding catch. Example 0 -5 0

By default, doors are pickable. If you don't set up the above lockpick spawnargs then it can't be picked. So there is normally no need to enable lockpicking - just set up the above spawnargs. There is a ''pickable'' spawnarg set to 1 by default. If set to 0 then the door becomes unpickable. But hard to think of an application except in testing or perhaps a special custom situation where it is switched by script perhaps.

===Open, Partially Open, or Closed Door at Game Start===

By default, doors are closed at game start. If you want a door to be already open or partially open then do the following.

'''Note well: Create all doors in their ''closed'' position. Adjust as follows and they will automatically be at the open position when game starts.'''

Already Open Rotating Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and tick the check button
* The door will now be fully open at game start.

* If you want it only partly open:
* Make sure its ''open'' property is set to 1 as above.
* Right click the entity inspector and select ''add property''
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* scroll down, select ''start_rotate'' then click {{ok}}
* This adds it to the property list.
* Now select ''start_rotate'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the angle you want in the same form as described in the ''Rotate Direction and Open Angle'' section. So for example, to have a door that has a fully open default ''rotate'' value of 0 90 0 to start only half open you would give it a ''start_rotate'' value of 0 45 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

Already Open Sliding Door:
* Select the door.
* Select the entity inspector
* Check ''show inherited properties''
* Select the ''open'' property
* Edit the value to 1 in the input box below and click {{check}} or press {{key-enter}}
* The door will now be fully open at game start.

* If you want it only partly open:
* Right click the entity inspector and select ''add property''
* Make sure its ''open'' property is set to 1
* Click the + sign on the left of the top line where atdm:mover_door is listed to open the folder.
* scroll down, select ''start_position'' then click OK. (if atdm:mover_door is not listed then the entity was likely changed from eg, func_static. If so, save the map and reload to update the add property list)
* This adds it to the property list.
* Now select ''start_position'' in the property list.
* Edit the bottom line of the input box ''below'' the properties window to the position you want in the same form as described in the ''Sliding (Translation) Amount and Direction'' section. So for example, to have a door that has a fully open default ''translate'' value of 0 50 0 to start only half open you would give it a ''start_position'' value of 0 25 0.
* In a similar way add the property ''first_frob_open".
* Set it to 1 and a partly open door should then open fully on the first frob.
* Set it to 0 and a partly open door should close on the first frob.

===Rotation Centre, Pivot, Hinge point===

The centre of rotation of a door is at the origin point of its entity and the door rotates with reference to the orientation of that origin point, not the world map. See ''Rotate Direction...'' for more about that. This section only deals with the ''position'' of the rotation centre in the door.

Model Door Centre of Rotation: 
The centre of rotation of a model door cannot be changed within Dark Radiant. Because a model door rotates around the centre 'spine' of its back edge this will cause clipping (penetration into solid) as in this example (where the door is set to open to 89 degrees for clarity): [[Image:modelClipping.jpg]] So care is needed with placement. You will not normally position a door right next to a wall as in the example but against a shallow frame so clipping will barely be noticeable but either way it can be fixed. You can correct it by adding a translation (see ''Sliding (Translation) Directions'') value of half the door width in the direction of the door handle. This will gently move the door out as it rotates to clear any solid on that side as in this diagram: 
[[Image:DoorClip.jpg]] 
Half a door width will typically be about 2. Any 'attachments' such as door handles will still synchronize with the door movement whether the door is rotating, sliding, or both.

Brush Door Centre of Rotation: 
The centre of rotation of a brush door ''can'' be changed. The default origin point of a brush is at its centre. Therefore a default rotating brush door will rotate around its centre when you first create it. So, mappers will commonly need to move that rotation point to a corner or even to some other offset position for example, for an openable window using the door function.

Put simply, to move the rotation point of a brush door you need to move the entity origin relative to the brush(es.)

Moving the entity origin (centre of rotation) relative to a brush door:

* Select the brush door
* Select ''Vertices mode'' (default shortcut key is {{key|name=V}} or button on top toolbar 'Select Vertices')
* Drag the door's entity origin to the point where you want the door to rotate. This should be on the corner on the leading edge side (the side to where the door is opening.) to avoid clipping as in this diagram....
[[Image:getCorner.jpg]]
* You should now find that door rotates around that point.

===Rotate Direction and Open Angle===

By default, rotating doors open anti-clockwise (viewed from above) by 90 degrees from the start orientation. If you want to change this edit the ''rotate'' property in the entity inspector. Don't confuse this ''rotate'' property with the ''rotation'' property. In the entity inspector remember that to see the inherited rotate property you must check the box 'Show inherited properties'.

The three values shown in the rotate property are degrees from the closed position around Y Z X ''entity origin axes'' (NOT absolute map axes) and so include any start ''rotation''. So the Z value is the axis vertical to the entity origin. If you tilt a model door over in Dark Radiant then its entity origin tilts too so the Z axis is tilted too (with respect to the world map vertical.) So with a normally opening model door if you lay it flat on its back it will open upwards and not rotate around on the floor. But a brush door must be treated differently...

If you turn a brush door using the normal Dark Radiant rotate tool or the Transform Dialog (accessed via a shortcut key) then it only turns the brush ''relative'' to the entity. So, because the entity origin is by default aligned with the world map then ''in most cases'' you can regard a brush door as rotating with respect to the world map if you wish. But there will be a problem when you come to rotations that are not around the main Y Z X axes of the map, for instance a drawbridge that lowers down to the south east. You might think you can combine Y Z X values to get the result you want - and this can be done (for south east use 45 45 90) but it is a bit of a kludge and the drawbridge twists eccentrically as it lowers (though it arrives correctly!) So for such cases you need to turn the entity itself so its start position is facing south east. You can then just use 0 0 90 to lower the drawbridge perfectly because its Y axis is now pointing south east. To turn the entity you must type or paste the rotation values in directly because using the Dark Radiant rotation tool or Transform Dialog will only turn the brush not the entity. The values are rather lengthy (south east is 0.707107 0.707107 0 -0.707107 0.707107 0 0 0 1) so probably the easiest way is to create a temporary model door, turn it how you want, then select its rotation property. If you now deselect and re-select your brush door then that property will still be in the entity inspector input box and you need only click the check(tick) box to add it to the brush door. NOTE: ''neither the entity nor the brush will show as turned in Dark Radiant.'' Only the rotation property in the entity inspector will indicate the orientation. Instead of a rotated ''construction'', regard it as a rotation ''instruction'' for when the map is compiled.

These are the rotate property fields. Remember they are all with reference to the door's entity ''not'' the world map. Since there is no absolute frame of reference I indicate them here as if the entity is aligned with the world map axes...

* Positive Y = Open clockwise (Dark Radiant grid front view, looking north)
* Negative Y = Open anti-clockwise (Dark Radiant grid front view, looking north)

* Positive Z = Open anti-clockwise (Dark Radiant grid top view, looking down)
* Negative Z = Open clockwise (Dark Radiant grid top view, looking down)

* Positive X = Open anti-clockwise (Dark Radiant grid side view, looking west)
* Negative X = Open clockwise (Dark Radiant grid side view, looking west)

The values are in the range -179 to +180. Positive values give an anti-clockwise opening rotation (looking down from above) and negative values give a clockwise opening rotation. The value 180 is unique in that it continues in an anti-clockwise rotation when closing rather than returning clockwise so might be used if you can think of some object that might need such a motion when frobbed!

Edit the rotate value by selecting it and using the input box at the bottom and clicking the check(tick) button. That will change the angle the door will open to. Note that the line with the original default of 0 90 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Examples:
* 0 90 0 = Opens anti-clockwise round the entity's 'vertical' to 90 degrees - typical default vertical door.
* 0 0 90 = Lowers a drawbridge from the entity 'vertical' to horizontal.
* 0 0 -45 = Opens clockwise by 45 degrees viewed from the east side. This might suit a skylight in a sloping roof.

Combinations can be used and also combined with slide motions (see '''Sliding (Translation) Directions''') to produce exotic and useful motions. A door opening against an upward-sloping floor can thus have a ''lifting hinge'' and raise up slightly to clear the floor; a door can rotate towards you and slide back to one side very effectively.

===Sliding (Translation) Amount and Direction===

By default a Dark Mod door will rotate open. For most sliding doors you want to stop them rotating as well as make them slide. You cannot delete (remove) the ''rotate'' property - you have to set the ''rotate'' property to 0 0 0 to stop a door rotating (see ''Rotate Direction and Open Angle''.)

Now edit the ''translate'' property value by selecting it (remember to have inherited properties box checked) and using the input box at the bottom and clicking the check(tick) button. That will change the distance the door will slide to. Note that the line with the original default of 0 0 0 will still be there but your new entry will be added on a separate line and that is the one that will work in the game. CAUTION: when adjusting later make sure you have your new line selected and not the original! If you do it will appear to change but your first setting will remain unaltered.

Typically (but not always) you will want your sliding door to slide the width of the door. The three values in the translate property by default are 0 0 0 and are X Y Z ''absolute map'' values (irrespective of door orientation) where:

* Positive X = Slide East (Right side of Dark Radiant grid in top view)
* Negative X = Slide West (Left side of Dark Radiant grid in top view)
* Positive Y = Slide North (top of Dark Radiant grid in top view)
* Negative Y = Slide South (bottom of Dark Radiant grid in top view)
* Positive Z = Slide Up (Top of Dark Radiant grid in side views)
* Negative Z = Slide Down (Bottom of Dark Radiant grid in side views)

So for a 50 unit wide door you want to slide fully to the east you would use 50 0 0 for the translate property values. A 100 unit portcullis sliding vertically up would need 0 0 100 to be fully raised.

=== Doors Collision/Push Behaviour ===
Doors are pushing all entities by default, except for the player. Doors will also stop moving when anything blocks their movement. However, this default behaviour can be changed by setting the according spawnargs:

Set '''push_player''' to '''1''' to let the player be pushed by this door:
"push_player" "1" // Push the player too (default is off)

By default '''stop_when_blocked''' is set to 1 and if a door is blocked by an entity then even if the entity is removed afterwards, the door stays still. The next frob will close the door.

Set '''stop_when_blocked''' to '''0''' to prevent the door from ending the opening sequence when anything blocks its way. It will still pause - but continue to open if the block is removed.
"stop_when_blocked" "0" // door keeps moving after being blocked (default is off)
With this setting, doors will still stop at blocking entities (the player, for instance), but will continue to move when the entity clears the way.

There is another spawnarg which stops a door pushing a moveable. Apply this to the ''moveable'' not the door...

"notPushable" "1"

===Sounds and Sound Propagation through Doors and Doorways===

Sound propagation relies on visportals. For details study [[Sound Propagation: Part 1]] and [[Sound Propagation: Part 2]] as well as [[Visportals]] This tutorial will just cover the relevant sound and sound propagation ''properties'' of doors. If you set the ''show inherited properties'' box in the entity inspector you can see them as described here.

The sound of doors opening and closing is set in the snd_open and snd_close properties. You can silence them by setting the following properties as shown:

''snd_open nosound'' 
''snd_close nosound''

Don't just use a dash - as it seems to cause a sound of its own.

''snd_locked'' 
The sound played when a player tries to open a locked door.

''snd_unlock string'' 
The sound played when a player unlocks a door.

''loss_open'' 
Drop in sound volume in dB when going through an open door. (default 1dB)

''loss_closed'' 
Drop in sound volume in dB when going through a closed door. (default 15dB) You would want to set this very high to block all sound with a thick door but very low for a barred gate for example.

''loss_double_open'' 
Drop in sound volume in dB when going through double doors when only one is open. (default 1dB)

There are also various sound properties for lockpicking: 
''snd_lockpick_pin_1 through 14'' and ''snd_lockpick_pin_success''

===Speed of Door Opening and Closing===

Rotating Door Speed: 
At the time of writing, the time a rotating door takes to open or close is set in the ''move_time'' property whatever its maximum open angle. So with rotation set at say 150 degrees the door just opens faster than at say 80 degrees. This is likely to be changed to a constant angular velocity so check to see if there a new property added if the following no longer works. The problem is that if an interruptable (see Extra Notes) door is frobbed while in motion it stops; another frob will reverse the motion - so even if the door is only open a crack it will still take the full time to close and vice versa.

To change the time a rotating door takes to open or close, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''move_time''
* Edit the second line of the input box ''below'' the properties window to the time you want.
* The time is in seconds and decimal fractions can be used.
* The default is 1 second and if set to this then the door opens and closes in one second whatever the maximum open angle, great or small.

Sliding Door Speed: 
The speed of a sliding door is set in the ''translate_speed'' property. To add this, make sure the door is selected then...

* Right click the entity inspector and check ''show inherited properties''
* Scroll down, select ''translate_speed''
* Edit the second line of the input box ''below'' the properties window to the speed you want.
* The speed is in Dark Radiant grid units per second.
* The default is 0 and if set to this then the door slides open in one second whatever the distance, great or small.
* CAUTION: If you later change the door back to a rotating door then delete the ''translate_speed'' property or ensure it is set to 0 as (at the time of writing but this will be fixed) a bug makes rotating doors open and close instantly. (Note: you can still mix sliding with rotating but check - this bug might only be if ''translate'' is set to 0 0 0)

===Visportals and Doors===

A visportal face surrounded by solid at its edges and in contact with a door is closed when the door is closed and enabled when the door is open. In most cases you will place a visportal in contact with a working door unless you can see through the door (such as a true glass door or barred gate.) For full details see [[Visportals]].

==Auto-Closing/Opening Doors==
Doors that automatically close after being open for some time are easy to setup: Each frobmover entity supports these spawnargs:

;"auto_close_time":Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
;"auto_open_time":"Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

Old text:

Note that auto-closing doors and AI closing doors behind them, is very much work in progress at the time of writing, so for now, this is another method that works. Check first if true AI closing of doors is working yet before bothering with this!

I have one door that I particularly want the AI to close as there is a bit of frame lag inside if not. So I set this up and it works good as an auto-closing door - not as good as a true AI closing door as it will auto close when the player goes through as well but it does look very effective to see AI going through and closing the door behind them. Not tested exhaustively so I don't know if there could be any downside. Here's what to do....

First a quick summary to make it more clear:

'''''A trigger_relay is used both as a relay AND carries a stim. We put the trigger_relay with its stim in the path of the open door. The door has a response property. When it opens and contacts the stim its response is to send a signal back to the relay. The relay pauses then closes the door...'''''

* First, optionally give your door a suitable name like autodoor1, whatever.
* Copy that name to the clipboard.

Next we need a relay with a delay:

* Create entity > darkmod > trigger_relay

* Place it roughly at the position the door will be at when open and to be on the safe side 3/4th of the way to the far end of the door (not the hinge end) to give max distance from the close door.

* Add the property 'target' and paste in the door name you just copied.

* Give the relay itself a name, eg, autoDoor_relay_1, and copy that name to the clipboard, you'll need that too in a bit.

* Add the property delay and the value 3 - this is the delay in seconds before the door will close; 3 seems about right but 2 might be worth a try because to that 3 is added a random value between 0 to 0.5 seconds from the Time Interval we entered for the stim firings.

* Add the property 'wait' and the value 3. This is the time before it can work again in seconds. If you set it too low then in theory the door might trigger again but in this situation I don't think it's possible. Too long, eg, one minute, and it won't work if the AI goes back through the door before then. If this value is -1 then the whole thing will only work ONCE so might be used for an AI who goes through once, closes it behind him, but you don't want it to be an autodoor thereafter.

That's the relay, now we add a stim to it:

* Still with the trigger relay selected, go to {{menu|Entity|Stim/Response}}

* Custom stim tab.

* Click Add stim type, select the new custom stim type you just made at the bottom of the list and type in eg, autoDoorStim at top right in the input box.

* Click the stim tab and the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Select the new autoDoorStim in the list and on the right you need only type in the radius box 15.0 There is quite a lot of room for error. I had it working on 10 and also on 25. The value should be less than the distance to the closed door else it will trigger open! But no so small that the door might not reach it.

* Select the check box for Time Interval and enter 500 (millisecs.) This is so it doesn't keep firing more frequently than is necessary. This stim will be firing all through your mission whether the door is used or not so if you had dozens of these then maybe it would affect performance. Too big a number and there may be a long delay before the door shuts - but it will be random depending on the next time the stim happens to fire. We'll control the delay we want more precisely later.

* Click {{ok}} to confirm it.

That's the stim set up, now for the response to it which is put on the door....

* Select the doorm, then use {{menu|Entity|Stim/response}} and select the response tab.

* Click the little drop down arrow against the 'type' selector at bottom left and you should see your new custom stim name. Select it.

* Right click in the big ''Response Effects'' box on the bottom right of the panel.

* Add New Effect and you should get a default 'Activate Response' response added to the list. Double click it.

* In the Effect selector at the stop select 'Trigger'

* in the Target box, paste in the name of the relay you copied or you can select it from the list at the little arrow.

* Leave the Activator box empty.

* Click {{apply}} and then {{ok}} on the main S & R panel bottom right.

It should now work. No need to wait for an AI, just frob the door and watch it close itself. If not, check the position of the stim brush is close to where the door stops when open.

==AI Door management==

See also [[#Keys_carried_by_AI]] above.

By default AI will open doors and close them behind them. Here are some spawnargs the mapper can use to modify that behaviour:

;"ai_should_not_handle" :If set to 1, AI will not attempt to handle it and add it to the forbidden areas when closed (so that it doesn't try to path through). They might still walk through the door when it is open though. Useful if you have some special use door that you don't want the AI to operate.

;"ai_should_not_close" :If set to 1, AI will not close the door behind them unless it obstructs them.

To get AI to unlock/relock specific doors there are two methods currently:

1. add the following spawnarg/value to the AI:

;"can_unlock1" ''<doorname>''

'''Do NOT use can_unlock_1.'''

For additional doors on the same AI use ''can_unlock2 doorname'' etc.

2. In the editor position an actual key that works for that door on the AI and also add to the key bind <AIname> and also bindToJoint LeftHips_Dummy (see other joints names elsewhere in wiki.) Currently, if the player pickpockets the key then the AI seeks an alternate route but otherwise does nothing (?) This may be upgraded in the future to better strategies.

3. There is the possibility in the future of an additional method which would just use special attach spawnargs to make the above easier. The key would spawn at the correct position at game start. Watch this space.

'''Door handling positions'''

It is also possible to set custom door handling positions for the AI. This is especially useful when the standard routine that lets the AI choose their standing positions while opening and closing the door fails, leaving them circling around in front of the door helplessly.

Place a movers > atdm:door_handling_position entity where you want the AI to stand while opening/closing the door from this side.(it can be found in the movers folder in the entity chooser)

On the door, you need to set the spawn arg "door_handle_position" "name_of_door_handling_position" You can also place a door handling position on each side of the door, the AI should automatically choose the right one. In this case, you need to set spawn args with "door_handle_position_1" etc and the corresponding names of the door handling position entities on the door.

The door handling positions can also carry spawn args that define the behaviour of the AI, which are useful for example for doors that can only be openend or locked from one side:

'''"ai_no_open"''' If set to true, the AI will not try to open the door from this side (but still walk through when the door is already open)

'''"ai_no_close"''' If set to true, the AI will not attempt to close the door from this side

'''"ai_no_unlock"''' If set true, the AI will not be able to unlock the door from this side, but still use it when it is not locked.

'''"ai_no_lock"''' If this is set true, the AI will not lock the door from this side.

==Doors as Triggers==

''by Ishtvan & greebo''

Doors (or any binary frob mover, buttons, levers, etc) now have the option to trigger their target on closing or opening. (For definition purposes, a button is defined as "closed" in the state when it starts out and "open" in the state you press it down to. I know that's a little non-intuitive, but it came from deriving from doors).

New spawnargs on frob movers:
;"trigger_on_open" :If set to 1, this binary mover will trigger its targets when it starts out completely closed and is opened.
;"trigger_when_opened":If set to 1, this binary mover will trigger its targets when it is completely opened. Code defaults to 0.
;"trigger_on_close":If set to 1, this binary mover will trigger its targets when it completely closes after being open.

==Skins: A Wide Variety of Door Textures==

This is to remind you that as with many Dark Mod models, there is a wide range of extras skins (textures) available for door models. There are now several basic door entities of different sizes so choose your size first. Then enter the spawnarg: skin with any temporary value. Now select it and click the skin button at the bottom of Dark Radiant's Entity Inspector and you will find a large of range of skin textures from which to select to give you a choice of appearances for your door.

==Extra Notes==
The property ''interruptable'' determines whether a door can be stopped by frobbing while it is opening or closing. So by frobbing then frobbing again, the player can open a door to any position, eg, slightly ajar to peek through.

''func_darkmod_door'' is no longer used (just in case you come across it in the Dark Mod forums or wiki.) The Doom func_door is still available but for Dark Mod, but <code>atdm:mover_door</code> is the entity to use.

{{tutorial-editing}}

Grime Corners

2010-12-22T16:14:41Z

Fidcal: New page: ''written by Fidcal'' ==Introduction== Grime corners are material shaders that give impressions of dirt and shadow at the edges and corners of surfaces. They are decals which need to be ...

''written by Fidcal''

==Introduction==

Grime corners are material shaders that give impressions of dirt and shadow at the edges and corners of surfaces. They are decals which need to be applied as patches over brush surfaces.

Use of grime corners decals can be time-consuming and tricky so it is not recommended you attempt to apply to every surface throughout your FM. Instead focus on dirty rooms such as cellars, dungeons; showcase rooms where you want them to look the best in the FM; and barely lit areas that have mostly or only ambient light - these areas can be 'lifted' and enhanced without needing lights so they don't look so flat and uninteresting. You need to consider where 'grimed' areas meet non-grimed areas. A non-grimed area can look odd next to a heavily grimed area that ends abruptly. Try to fade out the grime as best you can in-between.

==Application==

This is basically how to apply grime corners decals....

Select some brush surface(s)
Menu > Create decal patch will cover them with a patch.
While still all selected pick a texture from:
darkmod > decals > dirt > grime.... *see below
Then while still selected hit 'fit' on the surface inspector.
Now individually you need to adjust them.
Some patches exactly fit the visible surface, say a blank wall or ceiling in a room.
Others are on walls that are divided into different brushes. These need stretching to cover the wall.
Others go on surfaces that go partly behind other brushes. These need resizing too to drag the edges of the grime patch to reach the edges of the visible surface

==Different types==

Most of these materials give a transparent rectangle that fades to dark at the edges and corners. Or if you like, it's a dark rectangle that fades to transparency in the middle.

===grime_corners_light===

I recommend for most cases use grime_corners_light for a reasonable average grime.

===grime_corners===

The original grime_corners if very dark; only use that in the grimmest darkest dirtiest places because it is completely black at the edges.

===grime_corners_medium===

grime_corners_medium is a colorme. Ideally it would be named textures/darkmod/decals/dirt/grime_corners_medium_colorme I think but it cannot be changed now or it would break maps. What this means is you apply it then make the patch (or patches) a func_static. Then it is essential (or it won't show at all) to give the func_static entity the property _color and values like a light (can't use the color picker though) 3 values from 0 to 1. They are reversed brightness so 1 is black and 0 is invisible. You would use eg, 0.9 0.9 0.9 for fairly dark and say 0. 4 0.4 0.4 for light (it does depend where used how dark/light it looks though.) In addition you can set it's color. In Heart there are some pillars in the main hall that are a bit greeny as I recall. The color also is reversed. What you do is set say 0.99 0.99 0.99 (RGB) which is almost black. Then say you want the shadow/grime to be brown (dark red) you would turn DOWN the red component (which means you are turning it up from black you are adding a bit of red. So 0.7 0.99 0.99 might be dark brown.

===grime_full_light===

grime_full_light is the same as light above but constant throughout the rectangle. It does not fade to light. Sometimes useful for plugging a gap in a doorway between two rooms that have grime_corners_light on the floor ending abruptly at the doorway. We really need a new one that is colorme.

===grime_corners_square_colorme===

grime_corners_square_colorme is an inverse one and the dark area is in the middle fading to light at the edges. This is suitable for placing under pillars (and at the top) and also under some items of furniture etc to give a false shadow especially where there is only ambient light. For example, you might have an outdoor area with an old table in a gloomy corner with only ambient light. The floor under the table and the wall behind might look rather light because the human eye expects it to be darker even in ambient light. Like 'medium' it's a colorme and the same rules apply - you need to give it _color.

==Hints and tips==

A great many applications of the above materials need some imagination and improvisation to scroll and rescale the texture where appropriate. Often you want just grime in one corner so have to enlarge the scale of the texture (not the patch) in surface inspector. Not that currently with Dark Radiant you *reduce* the scale to increase it on patches. As you do this one side of the shadow moves off past the edge. You might need to scroll it around if its the wrong edge or even rotate the patch.

Moderately small windows in the middle of a wall you can put the patch over the whole wall because the transparent part is over the window(s). Doorways are tricky. Sometimes you can improvise with three patches around the door. Other times it is best to bend one patch around the door (see [[Patches#Bend L Shapes]]) Note that after fitting such a patch, exit vertex mode then use 'fit' again on Surface Inspector.

L or U shaped rooms use the same method as around doorways.

[[Category:Editing]]

What's new in TDM 1.03

2010-12-21T06:43:48Z

Fidcal: /* Textures/Skins */

See also the changelog on our bugtracker page: [http://bugs.angua.at/changelog_page.php?version_id=43 Changelog].

== Release Date ==
Version 1.03 of The Dark Mod has '''not yet''' been released.

== Changes / Features / Issues fixed ==

* [http://bugs.angua.at/view.php?id=837 #837]: Arrows don't stick into attachments on living AI (Coding)
* [http://bugs.angua.at/view.php?id=1181 #1181]: When mantling onto a moving object the mantle process is stationary, often the object is long gone (Coding)
* [http://bugs.angua.at/view.php?id=1254 #1254]: Cannot see objectives or why failed after mission end (GUI)
* [http://bugs.angua.at/view.php?id=1421 #1421]: Arrows can stick in broken arrows (Physics)
* [http://bugs.angua.at/view.php?id=1422 #1422]: Arrows can stick in arrows sticking in AI (Physics)
* [http://bugs.angua.at/view.php?id=1697 #1697]: AI errors when alerted by melee damage (AI)
* [http://bugs.angua.at/view.php?id=1851 #1851]: Bug when "using" AI with "shoulderable" set to "0". (Coding)
* [http://bugs.angua.at/view.php?id=1960 #1960]: No error message when failing to install FM package (GUI)
* [http://bugs.angua.at/view.php?id=2065 #2065]: Discarding articles when sorting Missions in the "New Mission"-menu (GUI)
* [http://bugs.angua.at/view.php?id=2169 #2169]: Strange AI behaviour/death when underwater (Coding)
* [http://bugs.angua.at/view.php?id=2198 #2198]: Finish "reaction" soundshaders (Sound)
* [http://bugs.angua.at/view.php?id=2210 #2210]: Savegame trying to restore Doom3 objectiveSystem (Saving/Loading)
* [http://bugs.angua.at/view.php?id=2218 #2218]: "idle_animations_torso" causes crash (Coding)
* [http://bugs.angua.at/view.php?id=2225 #2225]: path_anim won't work without an "angle" property (Coding)
* [http://bugs.angua.at/view.php?id=2226 #2226]: Lanternbots turn invisible when slain (Coding)
* [http://bugs.angua.at/view.php?id=2229 #2229]: Conversations only playing once (Coding)
* [http://bugs.angua.at/view.php?id=2234 #2234]: Weapon scrolling broken (Coding)
* [http://bugs.angua.at/view.php?id=2236 #2236]: atdm:ai_townsfolk_commoner_armed def vocal set typo (Def / Setup)
* [http://bugs.angua.at/view.php?id=2237 #2237]: Need generic text guis for signs etc (Feature proposal)
* [http://bugs.angua.at/view.php?id=2241 #2241]: gameLocal.m_StimTimer is not cleared between maps (Coding)
* [http://bugs.angua.at/view.php?id=2242 #2242]: Stim/Response Code Cleanup (Coding)
* [http://bugs.angua.at/view.php?id=2243 #2243]: Crash in func_shooter entity when def_projectile is wrong (Coding)
* [http://bugs.angua.at/view.php?id=2244 #2244]: Invalid tokens in ASE files (errors in NAHT) (Script/Def)
* [http://bugs.angua.at/view.php?id=2255 #2255]: New Mission menu GUI improvements. (GUI)
* [http://bugs.angua.at/view.php?id=2257 #2257]: Curtain prefab and fabrics (Textures)
* [http://bugs.angua.at/view.php?id=2258 #2258]: Climbing chains sounds like rope (Coding)
* [http://bugs.angua.at/view.php?id=2260 #2260]: Easier override option for main menu music (GUI)
* [http://bugs.angua.at/view.php?id=2261 #2261]: in 16:9 aspect resolutions, 1280x720 and 1366x768 are reversed (GUI)
* [http://bugs.angua.at/view.php?id=2262 #2262]: Restart Game button for settings menu (GUI)
* [http://bugs.angua.at/view.php?id=2265 #2265]: Console commands to mark missions as played/completed (Coding)
* [http://bugs.angua.at/view.php?id=2268 #2268]: No need to extract startingmap.txt file from mission PK4 (Coding)
* [http://bugs.angua.at/view.php?id=2269 #2269]: Response Effect Knockout not working (Script/Def)
* [http://bugs.angua.at/view.php?id=2269 #2270]: Ambient music volume levels (Sound system)
* [http://bugs.angua.at/view.php?id=2280 #2280]: Mission version check is bound to fail on next major version (GUI)
* [http://bugs.angua.at/view.php?id=2281 #2281]: No physics for dropped pickpocketed objects (Physics)
* [http://bugs.angua.at/view.php?id=2287 #2287]: no_random_headturning Not Working (Animation)
* [http://bugs.angua.at/view.php?id=2308 #2308]: Mission Download Manager (Coding)
* [http://bugs.angua.at/view.php?id=2309 #2309]: Support for replace_anim_* spawnargs directly on AI (Coding)
* [http://bugs.angua.at/view.php?id=2319 #2319]: Bump tdm_lg_crouch_modifier to -2 (Coding)
* [http://bugs.angua.at/view.php?id=2324 #2324]: Water should decrease visibility: add Lightgem modifier (Coding)
* [http://bugs.angua.at/view.php?id=2326 #2326]: Location settings broken if player enters undefined area (Coding)
* [http://bugs.angua.at/view.php?id=2337 #2337]: Add a falloff to the dynamic ambient light (Coding)
* [http://bugs.angua.at/view.php?id=2342 #2341]: "No_dups" not working for vocal barks (Sound engine)
* [http://bugs.angua.at/view.php?id=2342 #2342]: idRotator reverses direction each time it is triggered (Coding)
* [http://bugs.angua.at/view.php?id=2343 #2343]: Split Action/Inventoy menu and add keybinds for Spyglass/Cycle Readables (GUI)
* [http://bugs.angua.at/view.php?id=2344 #2344]: Elevator button double firing (Def / Setup)
* [http://bugs.angua.at/view.php?id=2352 #2352]: Arrows stick into player head (Coding)
* [http://bugs.angua.at/view.php?id=2362 #2362]: Water texture/wobble is too fast (Coding)
* [http://bugs.angua.at/view.php?id=2369 #2369]: Horse - skins (Graphis)
* [http://bugs.angua.at/view.php?id=2377 #2377]: Add Sotha's skybox decals (Textures/Materials)
* [http://bugs.angua.at/view.php?id=2379 #2379]: New golden Ingots as loot items (Models)
* [http://bugs.angua.at/view.php?id=2380 #2380]: CObjectiveLocation doesn't recognize absence of deleted entities. (Design/Coding)
* [http://bugs.angua.at/view.php?id=2385 #2385]: AI playing cards: some sit_down_angles unusable (AI)
* [http://bugs.angua.at/view.php?id=2392 #2392]: Patrolling AI get up immediately after path_sleep (AI)
* [http://bugs.angua.at/view.php?id=2396 #2396]: Add the Bloom settings to the menu (GUI)
* [http://bugs.angua.at/view.php?id=2408 #2408]: Sleepers "seeing" bodies (AI)
* [http://bugs.angua.at/view.php?id=2414 #2414]: Problems caused by interleaved thinking (AI)
* [http://bugs.angua.at/view.php?id=2417 #2417]: Ambient sounds lost after loading (Coding)
* [http://bugs.angua.at/view.php?id=2424 #2424]: Click in menu causes game action (Coding/GUI)
* [http://bugs.angua.at/view.php?id=2426 #2426]: TDM Updater improvements (Coding)
* [http://bugs.angua.at/view.php?id=2430 #2430]: If shouldered entity is removed from game, stuck shouldering forever (Coding)
* [http://bugs.angua.at/view.php?id=2438 #2438]: Norman shield texture error (Textures)
* [http://bugs.angua.at/view.php?id=2440 #2440]: Unlit electric lights not switchable (stay dark) (Coding)
* [http://bugs.angua.at/view.php?id=2443 #2443]: Sconscript deprecation warnings (Design/Coding)
* [http://bugs.angua.at/view.php?id=2446 #2446]: Double check spider death animation (AI)
* [http://bugs.angua.at/view.php?id=2450 #2450]: Unknown Pause before Purchase Menu (GUI)
* [http://bugs.angua.at/view.php?id=2458 #2458]: Test female sleeping behaviour (Animation)
* [http://bugs.angua.at/view.php?id=2461 #2461]: Black wheelbarrow (Models)
* [http://bugs.angua.at/view.php?id=2465 #2465]: Wench eyes not closing when asleep (Animation)



== AI ==

* Spiders have been significantly upgraded: all-new animations (including death animation), new spider types, new behavior (ceiling hang) and quieter footsteps
* Three new female characters: noblewoman, wench, and rogue. [http://modetwo.net/darkmod/index.php?/topic/11535-new-female-characters/]
* New animations for female characters
* Lowered volume of zombie foot-drag (again)
* Implemented run animation for characters with weapons (so they don't stab their head while running)
* New "Werebeast" monster added
* several varied pain animations
* Horse AI

== GUI ==

* A "Restart game" button now in the "Settings menu" (Greebo)
* The "New mission" menu has been greatly improved and has new features like tracking which mission(s) you played before, how long it took etc. (Greebo)
* Built-in version check, so TDM can tell you when an update is available. (Greebo)
* The "Actions/Inventory" menu has been split into "Actions" and "Inventory" (Tels). This makes room for:
** It is now possible to bind keys for "Spyglass" and "Cycle Readables" from the menu (Tels)
* The menu now supports three ambient methods (New Horizon):
** '''Normal''' (uses interaction shader to calculate ambient),
** '''Fast''' (JC's enhanced texture based ambient),
** '''Fastest''' (our original texture based ambient)
* The menu now has an "Object Details" setting, which can influence the amount and detail of objects. It supports the settings of "Lowest", "Low", "Normal", "High" and "Highest". (Tels)

== Sounds ==
* <s>Added a new Builder vocal set -- the Strong Builder</s> -- Postponed -- (Mortem Desino)
* Added two new vocal sets: "Wench" and "Lady"
* AI no longer play the same vocal bark twice in a row, and play a wider range of vocals (you should notice quite a change!)
* several footstep sounds have been modified
* ambient sound will no longer be lost on reloading
* AI vocals have been adjusted to allow for better ability to determine direction of the sound

== Textures/Skins ==

* A new yellow skin for the lily model has been added (Tels)
* Yellow and brown skins for our grass, as well as a dense and a ''colored'' variant of these has been added (Tels)
* Grass skins can now be used on all bush models, turning them into grass or plants with long leaves.
* It is possible to set a list of skins, from which one will be chosen '''randomly''' at entity spawn time, see: [[random_skin]]
* A few building/tree skybox facade textures (Sotha)
* Copper clad roof texture and old oxidised copper texture, good for statue skins (Serpentine)
* Two higher res loose stone wall textures (Seperntine)
* The red-shingles-with-stripes texture has now twice the resolution and much better details (Arcturus)
* New ladder variants with sounds for chain, foliage (ivy) rope, metal, nosound (silent)

{|
|-
|[[Image:Three lilies.jpg|200px|Three lilies]]
|[[Image:grass_skins.jpg|200px|Grass variants]]
|}

== Models ==

* Aphrodite statue (Arcturus)
* New carrot stub/turnip stub (Baddcog) and moveables/eaten versions based on them
* Gold bar model with various sizes (Fidcal & Greebo)
* a few new [[LOD]] models, which are considerable simpler (and thus render faster) than their originals

{|
|-
|[[Image:Eaten.jpg|200px|Eaten carrot and turnip]]
|[[Image:Ingame side by side.jpg|200px|Left: LOD, Right: Original]]
|[[Image:Lily_after_colorcorrect.png|200px|Left: LOD, Right: Original]]
|}

== Physics ==

Formerly, mantling (jump, grab ledge, then pull yourself up) only worked for stationary or moving (translating) objects. Ishtvan now implemented mantling onto rotating objects, too. This [http://www.youtube.com/watch?v=EMyHMeuikc8 video] demonstrates nicely the effect and possibilities. Btw, the map is called [http://thedarkmod.com/fmdetails.php?id=33 Swing] and is a contest map that confines the player into a 1280x1280 (unlimited height) cube, and if you watch the video, you will see that the map certainly feels way bigger. A clever trick :)

== Code ==

'''id Software''' had the habit to add a small class for almost each feature needed, instead of combining the features into one class. This leads to situation where one entity can do X, the next can do Y, but none can do X and Y at the same time. Before we only added code to the code base, and fixed bugs. With v1.03 we also
started an effort on C++ code cleanup. That means:

* combining features into one spawnclass instead of distributing it over or duplicating it at several
* removing unnec. classes (idFuncRadioChatter, idDoor, idElevator, idTarget_EnableStamina, idAFEntity_ClawFourFingers, anything related to the PDA, idTarget_Tip etc.)
* adding small utility functions (like ToString() to the idBounds class)
* improving the performance of idlib classes (the idList class has seen improvements upon adding another list to it, f.i.)
* We also no longer include and use some AI scripts from the base,working towards our goal of a D3-free TDM

This is ongoing work, but it will contribute to making TDM better overall, in small steps.

{{whatsnew}}

Mission Design Tips

2010-12-19T15:59:07Z

Fidcal: /* The Start Place */

= Mission Design Tips =
While the technical aspects of a mission creation is well covered by Fidcal's excellent A-Z map creation tutorial, there are other non-technical things to be considered when creating a TDM mission. I'll try to point out these things in this article. I welcome others to add more to this. And please note that some things herein are a matter of taste. The idea is more to make people think about these design elements. -Sotha

== Preparing for mission building ==
If you are a novice mapper, going forth to create your very first map, start small, fun and simple. Look at the Thief's Den 1, the Outpost and the Pandora's Box. Small, fun and excellent. Try not to create something really ambitious. Do something like that once you've more experience and confidence in your mapping skills. There are many things to be learned through trial and error.

It is always a good idea to think in advance how your mission flows. You should have a general idea what you're doing before you start mapping. Have a scetchy floorplan. Find some images for inspiration from the net. It is much easier to create a scene from an image than from your mind. Think about the plot. If you want an elaborate plot, you should think some kind of beginning, a turning point (the point of no return) and the ending. This about the map difficulty. How to place zones of low, medium and high tension. You do not need to think everything before mapping, but when your mapping project has a good foundation it is much more easy to stay on target and not get lost in trivialities. With a good plan, you *will* save time and your nerves. Remember nothing forces you to stick with the plan if you have an even better idea. But in order to get something done, it is better to stick with the plan and record the brilliant idea somewhere so you can use it in a later mission.

==Creating Basic Geometry==
Try to avoid linear maps. Make the maps such that you can access common areas through multiple routes. The critical areas probably have smaller amount of entries. Supercritical places like bank vaults should have high tension guarding and security. Only one entry way.

It might be a good idea to lay in few brushes according to your floorplan and check how it is going to work. Place an AI as reference so you see how the floorplan scales to a human being.

While mapping, write down all ideas you get while working on your map. You might get some cool location or plot elements, which would be a shame if you forgot them.

When building the geometry or planning it, try to make it realistic. If people live in the region you create, there should be conveniences people require: sustenance, shelter and convenience. Create the rooms in a purposeful, logical locations. Like in real life, each room serve some kind of purpose. Try to relay the meaning to the player. Doing this makes your locale believable, which is important for immersion.

If you find this difficult, check the net for castle/manor/crypt floorplans. Note that which rooms are where. This will get you on the right track.

==Difficulty==
Once the basic level geometry is created and you're starting to add details, you should rethink about the mission difficulty. Basically you need to have your map bright enough so that the AI has possibility of seeing the player. Also you need to have enough AI's to challenge the player. It is boring to have a pitch black mission, where the player can just waltz through everything without the need of considering blackjacking or other use of equipment. On the other hand, you must not make the mission too difficult with many bright lights and too many AI.

Try to add much variations in your map: there should be low tension zones with darkness (cellars, attics), medium tension zones (corridors with occasional patrols) and high tension zones with constantly present danger (barracks, the vault, the trophy room, the lords study). A constant tension throughout the mission is not a good idea.

Typically decent difficulty is achieved by thinking about the mission as in "light, but with islands of darkness the player can hide in." Islands of darkness may also mean objects the player can hide behind.

The difficulty is probably too low, if you can effortlessly walk in shadow all the time and through the mission. If you need to make quick rushes from a dark spot to another while the guard looks the other way, you're probably at correct difficulty. Also remember that the game has equipment. Set the mission difficulty so that the clever use of equipment is rewarded with success. In an excellent mission, the player is given options how to proceed and some equipment should be consumed to make progress.

==The Plot==
Good missions usually have a plot, a story being told by the location the player is in. The plot (in addition to the geometry) sets the mood and atmosphere of your map. A desperate survival story in a haunted tower? Political intrigue and blackmailing? A common burglary? A setup? An ambush? A pickpocketing heist amidst celebrating nobility?

To create a solid plot you need to answer the following questions, some questions deserve multiple answers:
What is the mission about? Where is it located? Why these things happen? When? Who is involved? Why should the player / main character care?

When you have a good idea what is going on, you need to convey the plot somehow to the player. Place readables, maybe AI conversations. Put in clues in your rooms. Have the villain AI slay the prince as soon as the player sneaks by. Let the villain drop the piece of parchment. The plot should steadily build up tension until the final clue hammers in with it's horrific implications. Remember to place the plot elements logically and realistically.

Try to create such a plot it does not require you to limit player progress too much. Do not let the plot ruin player/gameplay fun. The plot is there as an fun amplifier.

Note that the mission might not have a plot per se. If the player explores an interesing location, the plot might be the location telling it's story. Why was the underground temple built? Who does that mysterious statue portray? Providing such information increases your maps suspension of disbelief, making it far more interesting than just another place to loot.

Try not to cram one mission too full of plot. Why not divide the plot over two short missions? Remember, while a single Thief 1 mission had it's own plot, it progressed a bigger plot that overarched through the whole game. Typically the single mission length plot is not very long or complex.

==Gameplay and Design==
Your mission is for a game. Games should be fun, not frustrating. When creating something, ask yourself: "If I was playing this and I didn't know whats coming, would this be fun?" If the result is a 'no', then modify until you get a 'yes.' Ask this question very often. This question is probably the most important advice in this article. Write it down somewhere and look at it when you map. ;-D

==The Start Place==

Provide some imaginary way that the player has arrived at the start. This might be by starting in mid air near an unclimbable wall so at the start it is as if he just climbed and dropped over from the other side. Another common alternative is a closed, unopenable door or gate behind the player as if the player entered that way.

Some FMs can take a while to load first time, especially big FMs on low-end systems. It is highly recommended that you start the player where he cannot be seen, heard (dropping off a wall, or felt (yes, Dark Mod AI can 'feel' the player if they bump into him/her,) by enemy right at the start. If there is a special case such as the start of Alchemist then warn players in advance. Otherwise the player might not be attentive or even gone for a coffee and come back to find the FM not only started but failed already!

==Secrets==
How to do secret compartments and rooms? The player needs to be somehow able to find your secrets. You need to set clues to nudge the player to the correct direction. This essentially breaks into two categories: written clues and visual clues. Other types are possible, but these are probably the most common ones.

If there is no written clue to the secret, put in visual clues. Generally visual clue tells the observant player that there is something odd in the room, hinting that there most likely is a secret there. If done properly, no written clue is needed. The player will notice the visual clue, and starts systematically search the room until the secret is found. Examples of visual clues are strangely placed furniture, odd details like hinges or rails on a bookshelf, or a scratch decal caused by the secret door movement on the floor. If the secret is behind a painting, put the painting a bit skewed, so it looks it was tampered with recently.

The other type of clue is the readable clue. In it's simplest form, you say in a readable "there is a secret in this and that room," then you can hide the secret without any visual clues. You need to be specific enough in your clue that the area to be searched is roughly the size of one room. "There is a secret in the mansion" clue would be useless. Note also that the player can not then find the secret if he cannot find the readable.

Whatever clues you give to the player, always bet on stupidity and don't make them too cryptic. If the objective attached to the secret is optional, when there is no limits for your deviousness.

Also, most players do not have eidetic memory, so it would be nice to have the written clues to be moveable so the players can take them with them and re-examine them if they need to do so.

==Puzzles and Hidden Objects==
Always bet on stupidity. People will misunderstand clues and riddles, so make them seem easier rather than difficult. What seems too easy for the map creator typically is challenging for the player. If it is challenging for the mapper it is most likely impossible for the player. I am not implying players are dumber than the mappers! Mappers know their own creation very well, and it is difficult for them to estimate whether their creation is challenging enough when viewed from the outside. Usually external view is more difficult than the mapper view. Take this into account when creating puzzles, hidden compartments and hidden keys.

Puzzles and riddles should be solvable using game world help and assets. It is not a good idea to design a puzzle which requires the player to stop playing, quit and search the internet to solve the problem. This only breaks the playing session and frustrates people. If you put a latin text in your mission, you should put a latin dictionary in your mission, rather than expect the player to stop playing an grabbing a dictionary!

There is a way to make as difficult puzzles as you like. Make the objective optional! Doing so you will reward the clever players who crack your difficult puzzle, but on the other hand the players who are already challenged by your map can enjoy it, without the map getting too rough for them.

==Non-Pickable Doors, Keys and Mission Critical Objects==
Non-pickable locked doors are very dangerous elements. You can ruin your mission with these. Use them sparingly! This kind of door is a plot/mapper imposed obstacle, which requires the player to do things in the order the mapper wants. It may be vital for the plot, but remember that the player *will* be frustrated if he misses the key. Put in clues to lead the player to the key. Put the key in an obvious place so the player will not miss it. Put some kind of light to make the object more visible. Put the key in a logical place! The same advise applies to any kind of Mission Critical Object the player must possess to make progress. Do not have the player walk all the way to Mordor only to realize he left the hidden One Ring back in the Shire.

Think about other options: you could put a difficult pickable door instead of the non-pickable one, place a guard and a nonextinguishable light. Have the guard go for a short patrol, but so short the door cannot be picked while he is gone. Let the patrol be long enough for the player to easily open the door with a key. The player can go there if he/she wishes, but it is much easier with the key. Let the player enjoy your location in the order he chooses. Give player options, but have the options have consequences.

==Ladders==
Since AI cannot use ladders, they are a player breather element: a place to run away. Thus they should be used sparingly. Alternatively, you could use monsterclip brushes to allow the AI to follow the player. Keep in mind the opposite when designing your mission: the player should have at least some kind of escape and hiding place if things go awry.

{{tutorial-editing}}

Mission Design Tips

2010-12-19T15:55:30Z

Fidcal: /* Secrets */

= Mission Design Tips =
While the technical aspects of a mission creation is well covered by Fidcal's excellent A-Z map creation tutorial, there are other non-technical things to be considered when creating a TDM mission. I'll try to point out these things in this article. I welcome others to add more to this. And please note that some things herein are a matter of taste. The idea is more to make people think about these design elements. -Sotha

== Preparing for mission building ==
If you are a novice mapper, going forth to create your very first map, start small, fun and simple. Look at the Thief's Den 1, the Outpost and the Pandora's Box. Small, fun and excellent. Try not to create something really ambitious. Do something like that once you've more experience and confidence in your mapping skills. There are many things to be learned through trial and error.

It is always a good idea to think in advance how your mission flows. You should have a general idea what you're doing before you start mapping. Have a scetchy floorplan. Find some images for inspiration from the net. It is much easier to create a scene from an image than from your mind. Think about the plot. If you want an elaborate plot, you should think some kind of beginning, a turning point (the point of no return) and the ending. This about the map difficulty. How to place zones of low, medium and high tension. You do not need to think everything before mapping, but when your mapping project has a good foundation it is much more easy to stay on target and not get lost in trivialities. With a good plan, you *will* save time and your nerves. Remember nothing forces you to stick with the plan if you have an even better idea. But in order to get something done, it is better to stick with the plan and record the brilliant idea somewhere so you can use it in a later mission.

==Creating Basic Geometry==
Try to avoid linear maps. Make the maps such that you can access common areas through multiple routes. The critical areas probably have smaller amount of entries. Supercritical places like bank vaults should have high tension guarding and security. Only one entry way.

It might be a good idea to lay in few brushes according to your floorplan and check how it is going to work. Place an AI as reference so you see how the floorplan scales to a human being.

While mapping, write down all ideas you get while working on your map. You might get some cool location or plot elements, which would be a shame if you forgot them.

When building the geometry or planning it, try to make it realistic. If people live in the region you create, there should be conveniences people require: sustenance, shelter and convenience. Create the rooms in a purposeful, logical locations. Like in real life, each room serve some kind of purpose. Try to relay the meaning to the player. Doing this makes your locale believable, which is important for immersion.

If you find this difficult, check the net for castle/manor/crypt floorplans. Note that which rooms are where. This will get you on the right track.

==Difficulty==
Once the basic level geometry is created and you're starting to add details, you should rethink about the mission difficulty. Basically you need to have your map bright enough so that the AI has possibility of seeing the player. Also you need to have enough AI's to challenge the player. It is boring to have a pitch black mission, where the player can just waltz through everything without the need of considering blackjacking or other use of equipment. On the other hand, you must not make the mission too difficult with many bright lights and too many AI.

Try to add much variations in your map: there should be low tension zones with darkness (cellars, attics), medium tension zones (corridors with occasional patrols) and high tension zones with constantly present danger (barracks, the vault, the trophy room, the lords study). A constant tension throughout the mission is not a good idea.

Typically decent difficulty is achieved by thinking about the mission as in "light, but with islands of darkness the player can hide in." Islands of darkness may also mean objects the player can hide behind.

The difficulty is probably too low, if you can effortlessly walk in shadow all the time and through the mission. If you need to make quick rushes from a dark spot to another while the guard looks the other way, you're probably at correct difficulty. Also remember that the game has equipment. Set the mission difficulty so that the clever use of equipment is rewarded with success. In an excellent mission, the player is given options how to proceed and some equipment should be consumed to make progress.

==The Plot==
Good missions usually have a plot, a story being told by the location the player is in. The plot (in addition to the geometry) sets the mood and atmosphere of your map. A desperate survival story in a haunted tower? Political intrigue and blackmailing? A common burglary? A setup? An ambush? A pickpocketing heist amidst celebrating nobility?

To create a solid plot you need to answer the following questions, some questions deserve multiple answers:
What is the mission about? Where is it located? Why these things happen? When? Who is involved? Why should the player / main character care?

When you have a good idea what is going on, you need to convey the plot somehow to the player. Place readables, maybe AI conversations. Put in clues in your rooms. Have the villain AI slay the prince as soon as the player sneaks by. Let the villain drop the piece of parchment. The plot should steadily build up tension until the final clue hammers in with it's horrific implications. Remember to place the plot elements logically and realistically.

Try to create such a plot it does not require you to limit player progress too much. Do not let the plot ruin player/gameplay fun. The plot is there as an fun amplifier.

Note that the mission might not have a plot per se. If the player explores an interesing location, the plot might be the location telling it's story. Why was the underground temple built? Who does that mysterious statue portray? Providing such information increases your maps suspension of disbelief, making it far more interesting than just another place to loot.

Try not to cram one mission too full of plot. Why not divide the plot over two short missions? Remember, while a single Thief 1 mission had it's own plot, it progressed a bigger plot that overarched through the whole game. Typically the single mission length plot is not very long or complex.

==Gameplay and Design==
Your mission is for a game. Games should be fun, not frustrating. When creating something, ask yourself: "If I was playing this and I didn't know whats coming, would this be fun?" If the result is a 'no', then modify until you get a 'yes.' Ask this question very often. This question is probably the most important advice in this article. Write it down somewhere and look at it when you map. ;-D

==The Start Place==

Provide some imaginary way that the player has arrived at the start. This might be by starting in mid air near an unclimbable wall so at the start it is as if he just climbed and dropped over from the other side. Another common alternative is a closed, unopenable door or gate behind the player as if the player entered that way.

Some FMs can take a while to load first time, especially big FMs on low-end systems. It is highly recommended that you start the player where he cannot be seen, heard (dropping off a wall, or felt (yes, Dark Mod AI can 'feel' the player if they bump into him/her,) by enemy right at the start. If there is a special case such as the start of Alchemist then warn players in advance.

==Secrets==
How to do secret compartments and rooms? The player needs to be somehow able to find your secrets. You need to set clues to nudge the player to the correct direction. This essentially breaks into two categories: written clues and visual clues. Other types are possible, but these are probably the most common ones.

If there is no written clue to the secret, put in visual clues. Generally visual clue tells the observant player that there is something odd in the room, hinting that there most likely is a secret there. If done properly, no written clue is needed. The player will notice the visual clue, and starts systematically search the room until the secret is found. Examples of visual clues are strangely placed furniture, odd details like hinges or rails on a bookshelf, or a scratch decal caused by the secret door movement on the floor. If the secret is behind a painting, put the painting a bit skewed, so it looks it was tampered with recently.

The other type of clue is the readable clue. In it's simplest form, you say in a readable "there is a secret in this and that room," then you can hide the secret without any visual clues. You need to be specific enough in your clue that the area to be searched is roughly the size of one room. "There is a secret in the mansion" clue would be useless. Note also that the player can not then find the secret if he cannot find the readable.

Whatever clues you give to the player, always bet on stupidity and don't make them too cryptic. If the objective attached to the secret is optional, when there is no limits for your deviousness.

Also, most players do not have eidetic memory, so it would be nice to have the written clues to be moveable so the players can take them with them and re-examine them if they need to do so.

==Puzzles and Hidden Objects==
Always bet on stupidity. People will misunderstand clues and riddles, so make them seem easier rather than difficult. What seems too easy for the map creator typically is challenging for the player. If it is challenging for the mapper it is most likely impossible for the player. I am not implying players are dumber than the mappers! Mappers know their own creation very well, and it is difficult for them to estimate whether their creation is challenging enough when viewed from the outside. Usually external view is more difficult than the mapper view. Take this into account when creating puzzles, hidden compartments and hidden keys.

Puzzles and riddles should be solvable using game world help and assets. It is not a good idea to design a puzzle which requires the player to stop playing, quit and search the internet to solve the problem. This only breaks the playing session and frustrates people. If you put a latin text in your mission, you should put a latin dictionary in your mission, rather than expect the player to stop playing an grabbing a dictionary!

There is a way to make as difficult puzzles as you like. Make the objective optional! Doing so you will reward the clever players who crack your difficult puzzle, but on the other hand the players who are already challenged by your map can enjoy it, without the map getting too rough for them.

==Non-Pickable Doors, Keys and Mission Critical Objects==
Non-pickable locked doors are very dangerous elements. You can ruin your mission with these. Use them sparingly! This kind of door is a plot/mapper imposed obstacle, which requires the player to do things in the order the mapper wants. It may be vital for the plot, but remember that the player *will* be frustrated if he misses the key. Put in clues to lead the player to the key. Put the key in an obvious place so the player will not miss it. Put some kind of light to make the object more visible. Put the key in a logical place! The same advise applies to any kind of Mission Critical Object the player must possess to make progress. Do not have the player walk all the way to Mordor only to realize he left the hidden One Ring back in the Shire.

Think about other options: you could put a difficult pickable door instead of the non-pickable one, place a guard and a nonextinguishable light. Have the guard go for a short patrol, but so short the door cannot be picked while he is gone. Let the patrol be long enough for the player to easily open the door with a key. The player can go there if he/she wishes, but it is much easier with the key. Let the player enjoy your location in the order he chooses. Give player options, but have the options have consequences.

==Ladders==
Since AI cannot use ladders, they are a player breather element: a place to run away. Thus they should be used sparingly. Alternatively, you could use monsterclip brushes to allow the AI to follow the player. Keep in mind the opposite when designing your mission: the player should have at least some kind of escape and hiding place if things go awry.

{{tutorial-editing}}

Objectives Editor

2010-12-19T15:44:56Z

Fidcal: /* The standard "exit here when you're done objective" */

''Written by HappyCheeze and Fidcal. Small additions by Sotha.''

==Introduction==

{{clear}}
The objectives editor is a very useful tool located inside Darkradiant (Version 0.9.7 or later) that allows the map author to set objectives or goals that the player must do in order to win the level. The opposite is also true, the author can set restrictions that the player must adhere to, or will fail the mission.

==Adding Objectives Entities==

IMPORTANT: The add objectives entity has been renamed to atdm:target_addobjectives so ignore any reference to the old name target_tdm_addobjectives in the images.

To access the objectives editor once inside Darkradiant, click the pull-down menu Map>Objectives...
[[Image:Objmenu.png]]

Upon clicking you will see a separate window that looks like this.
[[Image:Objedblank.png|left]]

{{clear}}
To start things off, click the
[[Image:%2Badd.png]]Button

[[Image:Msnobjadd.png]]

This will create an Entity that stores all of the objectives information that will you be editing.

Now we've spawned our objectives entity,
{{clear}}
[[Image:Objentity.png]]
{{clear}}
Notice the numbers in the “[]”'s. Those are the entities' coordinates on the map. These numbers will most likely be different from yours. When the objectives entity spawns it is placed randomly around the origin (As of 0.9.7 this is how it is, it might change in future versions, but for now this is how it is).

*Note:Be mindful that sometimes this entity will spawn outside your map and into the void. This will cause a leak, so look around the origin.

**Alternatively you can right-click in an orthogonal view, create entity, Targets/atdm:target_addobjectives. This will create a small yellow box like placing any entity or object. Then when you open the objectives editor it will be in the list. Good to do this where the players starts, it will always be easy to find.

==Adding Objectives==

Now we're ready to start adding some objectives.

Click the second [[Image:%2Badd.png]] Button

[[Image:Newobj1.png|left]]
{{clear}}

Under Objectives you'll notice there's a new Objective. You can add more as needed.

==Editing Objectives==

Click an objective in the list than click [[Image:Edit.png]]

This will bring up this window.
{{clear}}
[[Image:Editobj.png]]

Now we're editing our first objective. It may seem a little confusing at a first glance but a lot of it is self explanitory and a little practice will take you a long way.

So what do all these various lines and checkboxes do?
They effect the objective components at the bottom.

What do they all mean?

'''Description''': This what the player will read in the objectives menu. For example: “Steal the scepter”, “Don't kill any guards”, “Get back to where you entered the warehouse”. Its explaining what you want to player read so he/she knows what to do. A good rule to follow is to make them short and to the point.

'''Difficulty''':These refer to Easy/Medium/Hard difficulty levels. If the author wishes, they can be different for each difficulty. For example: on Hard difficulty the player will have to avoid being seen. On Easy the player will only have to steal 200 gold at the minimum. All Levels means that the objectives that are checked under this will be there regardless of difficulty.

'''Initial State''':This is the condition of the objective at mission start. There are four options. Complete, Incomplete, Invalid, Failed. Typically the objective will be incomplete and the player has to complete it in-game to fulfil the objective.

'''Flags''':

''Mandatory'' means the objective in question is necessary to complete the game. If it is unchecked than the objective will be optional.

''Ongoing'' means that the objective won't show completion until the end of the mission. Use this with do NOT type objectives, eg, do NOT kill.

''Irreversible'' means that once the objective is done it will not UNcheck even if logically in the game it becomes no longer true. Example: get a special object. If the player later drops it normally the objective will then UNcheck because the player no longer has got it. But sometimes you don't want it to reverse. Example: get magic skull. New objective: throw it in magic pool. Player no longer has 'got' the skull so normally it would then UNcheck the objective. Make it irreversible and it won't. Another example is to go to a location. If the player then leaves it would UNcheck so make it irreversible.

''Visible'' means that objective will be visible in the objectives menu ingame. If unchecked than there will be no objective shown. (The objective will still work, it just won't show up in the menu).

'''Enabling Objectives:'''
These are other objectives that must be completed before this objective can be done. Example: ''"When you have completed your main objectives, escape from the castle."'' So, those main objectives would be the enabling objectives and if the player escapes the castle without doing them first then the escape objective does not check off either.

'''Logic Success:'''
These are only needed if you have more than one type component. For example, if you can escape the castle by either of two routes this would be an objective with two go to ''location'' components. These components would be numbered 1 and 2 so the logic success would be 1 OR 2 since either would work. If however you wanted say the player to escape the castle via a special corridor then the player has to go to both corridor location and exit castle location so that would be logic success 1 AND 2. Those components need not necessarily be the same type - the player might be required to pull a lever AND escape for example (even though he could escape without pulling the lever but you don't want him to.)

'''Scripts''': Under Construction

==Components==

'''Components''': These are the type of objective you want, eg, steal, kill - or rather 'types' because each objective can have more than one (eg, go to exit A or go to exit B or it could be go to exit A AND go to exit B! - see logic success) These type components are used by the editor to specify what objectives need to be done. The map author can choose from a variety of options under '''Type''' with varying degrees of specification. For example: Knocking out an AI named "Roy". Not being seen by the ANY enemy. (less examples, should cover this in the coming up tutorial.)

'''Components Flags''':Components have their own special flags as well.

''Satisfied at Start'':For some objectives it makes sense to have them done at start. For example: Not killing anyone.

''Irreversible'':One the objective has reached a certain state, it will stay that way and not change. (more elaboration, an example?)

''Boolean NOT'':Adds "NOT" to your component so the player has to do the opposite of said objective. For example: Do NOT kill any AI on team 2.

''Player Responsible'':The player MUST follow through with the objective himself. For example:The player must kill the zombie to complete the objective, instead of letting something else take care of it.

Now it might seem a bit crazy trying to take all of this in at once, so lets start with something easy.

== Tutorial ==

*Note:This tutorial is assuming you've learned the basics for using Darkradiant.

You should already be in Darkradiant. Start a new map if you're in an existing one.

We'll start with the basic cube room. Nothing fancy, just make a room, stick in a player start, a light and plaster on some textures.
[[Image:cube.png|left]]
{{clear}}
For this tutorial, our player is going to have to knock out a guard and steal a trophy.

So lets start with adding the AI, I chose atdm:ai_citywatch. Select him, go into the entity editor ("N") and change his NAME to "Roy" (without quotes).

Now its time to open up our objectives editor.

[[Image:Objmenu.png|left]]
{{clear}}
Now as you just learned, click add, click the atdm:target_addobjectives_1 and click add again.

The ''Edit Objective'' window should be open now. Clear the text under '''Description''' and type in "Knock out the guard". Set the initial state to 'Complete'. Check the '''Mandatory''' and '''Visible''' flags.

Time for a new step, click the [[Image:%2Badd.png]] button under '''Components''' and the word "Kill" should appear. Select it and you will see some more options. Under '''Type''' select "AI is knocked out".

under '''Knockout target:''' select "Name of single entity" and type in the box to the right of it, "roy" (without quotes). Set amount to 1.

Now compare your screen to this, it should be the same.
[[Image:Editprogress.png|left|]]
{{clear}}
If all looks good than click OK.

Its always a good idea to test things to make sure everything is running right. So save your map, get into TDM and load your map.

First, hit ESC and click ''Objectives''. You should see your objective onscreen.
[[Image:Onjyes.png]]
*NOTE:If you don't see it on screen, you probably forgot to check the '''Visible''' box.

Now its time to test your objective. Exit out of the objectives menu and launch a gas arrow or use the blackjack on poor Roy. When he goes down you should see the words "Objective Complete" appear onscreen and since thats the only objective we've added so far you'll win the mission.
*NOTE:If you don't win nor see the on screen message, go back and try to figure what you did wrong.

If all is well than its time to move on. Exit TDM and go back into Darkradiant.

Now it is time to add the trophy. In your map add a trophy somewhere, I used the entity loot>atdm:loot_trophy_old
change its name to "trophy" and go back into objectives editor.

Add another objective and edit it.
'''Description''' should be ''Steal the Trophy''. State is ''Complete'', '''Flags''' should be ''Mandatory'' and ''Visible''. Click ADD and select '''Player possesses item''. Change '''Item:''' to ''Name of single entity'' and type in the box to right, "trophy". Change the amount to "1".

Your objective should look like this.
[[Image:Trophyedit.PNG|left]]
{{clear}}
Since this is a tutorial this map is very small and very basic so we are tossing all pre-thought and planning for the objectives out the window. As maps get bigger, more elaborate, complex, so too will the objectives be to suit the level. You might want to the trophy in a vault. Maybe the guards will be patrolling.

Save your map and load it up in TDM. Look at the objectives menu to see if the fresh addition is there. And than take it and see if it completes the objective.

Congratulations!

You now have a basic understanding of how the objectives editor works. For more advanced work, look for more tutorials in the future or go on the forums.

== FAQs & Examples ==

===KO objective but AI already dead!===

;*If I kill the guard I don't fail the mission, but I can't complete it either.
:Answer: I'll quote Ishtvan for this one.
:''"The system is not smart enough to know automatically that someone who's killed can't be KO'd later, so if you want it to fail when they're killed, you have to put that in specifically. Note that this doesn't have to be a whole 'nother objective, it can be a component of the KO objective, so you have two components, KO them, and don't kill them. We could potentially make this automatic later on, but that's the way it is right now."''
:Until this is fixed, I'd recommend making a knockout objective optional, unless you want to put in the kill component.

===Kill objective thwarted by another AI===

;*I put a monster in my map and he killed the guard, yet I still passed/failed the objective.
: Answer: Check the '''Player Responsible''' Flag, this means that the player MUST do it himself in order to get credit.

===Leak caused by Objectives Entity===

;*Help! My objectives entity is outside the map and I have a leak! I can't find it! I even used the pointfile!! help!!!!
: Answer: The objectives entity is a very small, yellow cube that is spawned around the origin. Its about the size of a light entity.

===How to directly trigger an objective or component to complete===
If the actions that the player has to do in a mission are not directly covered by the normal objectives properties, for example, the player must open a door, then objectives can be triggered to complete by any target entity.

In the objectives editor, to your objective add a component type : custom script. (this might just say 'custom' or similar.) The objective now just awaits some external trigger or script in the game to set it complete. To do this with a trigger...

* Create a new entity : ''target_tdm_setobjectivestate''
* Give it the properties/values... obj_idN O ... where O is the objective number and N is simply the obj_id number if you want several on the same entity. Just use obj_id1 if you only want one. obj_state 1

You must then target that from some triggering entity like a button, lever, door (see [[Doors]]) or you can trigger it from stims & responses or from a custom script.

In a similar way, you can trigger individual components using entity target_tdm_setobjective_component_state. In this give it the properties/values...

* Create a new entity : target_tdm_setobjective_component_state
* Give it the properties/values... comp_idN C ... where N is just this ID number and C is the component number. obj_state 1

Again, trigger that as above.

===How to make my invisible objective become visible to the player later===

There are two methods. One way ''adds'' a new objective at the end of the current list of objectives. The other way makes an existing objective visible. This is the one for general use because it appears in the position in the list where you first put it rather than on the end. It makes sense to have your objectives in some kind of order so for example, you might have right at the end of the list 'when all else is done, escape from Castle...'

====To make an invisible objective visible later====

* Create a new entity : ''atdm:target_setobjective_visibility''
* Give it the properties/values... obj_idN O ... where O is the objective number and N is simply the obj_id number if you want several on the same entity. Just use obj_id1 if you only want one.

You must then target that from some triggering entity like a button, lever, door (see [[Doors]]) or you can trigger it from stims & responses or from a custom script. Note that sometimes it helps to put in a delay (see below.) It will by default then become visible. You can do it the other way round and make an objective become invisible (remember it is still active by default) by changing the spawnarg value 1 to...

obj_visibility 0

====To add a new objective on the end of the list====

* In the objectives editor use the top Add button to create a new ''atdm:target_addobjectives'' entity.
* Add the new objective(s) just as described above
* Find the atdm:target_addobjectives entity in the map (you normally need to check it is not in the void anyway plus you might like to place it near where it makes sense the new objective shows.
* Add to the atdm:target_addobjectives entity the property ''wait_for_trigger'' and the value 1. Otherwise it will show right at the start of the game.
* You then need to target that atdm:target_addobjectives from some triggering entity like a button, lever, door (see [[Doors]]) or you can trigger it from stims & responses or from a custom script. Note that it may help to include a delay (see below.)
* The new objective(s) will show as added at the end of the list of objectives when triggered.

====Inserting a delay before new objective shows====

It often helps to include a delay from triggering before the ''New Objective'' message shows. To do this:

* Create a ''trigger_relay'' entity.
* Give it the properties:
** ''wait -1''
** ''delay N'' (replace N with delay time in seconds)
** ''target'' <the name of the atdm:target_addobjectives>
** Make your original trigger target this relay instead of the atdm:target_addobjectives directly.

===Completing Objective Components in a Certain Order===

Suppose you want the player to complete two or more parts of an objective but in a certain order. Example : "Close the office door then open the safe." In that example you want the player to close the door first not just do both in any order. If you just make the two components they default to a Success Logic of 1 AND 2 which means the player must do both to complete the objective but it does not matter which order. So if the player opens the safe and then closes the office door then the objective will check off - perhaps not what you want. This is how to do it if you want to force the order in which the player does the components...

There are two possible outcomes :

If you want the mission to '''fail''' set the failure logic for that objective to

''NOT(1) AND 2'', i.e., door is open AND safe is open.

But if you just want the objective to not complete (so the player can try again)...

Make '''two''' objectives, both using the door and safe components - the first is invisible but still active:

# Objective 1: success logic: Door closed, safe not open = 1 AND NOT(2)
# Objective 2: success logic: Door closed, safe open = 1 AND 2 (Objective 2 enabling objectives = 1)

===An Objective to place an object in a Certain Location===

To make an objective where an object has to be placed somewhere:

* Create a brush where you want the object to be put. This might be the size of a room, a street, or a chest or wherever you want the object.
* Texture it with common > clip
* With the brush selected, Create entity > info > info_tdm_objective_location
* Give this entity a name you can remember like BodyDrop. Write it down or in a text editor
* Give your object, eg, a ragdoll, a name, eg, JakesCorpse and note it down.
* If it is not the player, then give it the property objective_ent and set it to 1
* Menu > Map > Objectives
* If you haven't yet got any objectives then click the + Add button at top right.
* This creates a atdm:target_addobjectives entity so later make sure it is not in the void or you get a leak. Put it somewhere convenient. It is not visible in game.
* Select the atdm:target_addobjectives in the Objectives entities list top left
* In the objectives list below click the +Add button on the right.
* This creates a new objective in the objectives list. Select it.
* Click the edit button on the right.
* Type a description near the top, eg, Carry Jake's body back to X and drop it in the soandso
* In the components list further down click the +Add button on the right.
* This creates a default Kill objective. Select it. Click the Edit button.
* Just below it click the Type bar and from the list that show select 'Item is in location'
* Further down click the bar below 'Entity' and select 'Name of single entity'
* On the right of that type or paste in the name of the object (eg ragdoll) entity eg, JakesCorpse
* Below, click the bar below Location and select 'Name of single entity'
* On the right of that type or paste in the location entity name you gave above, eg, BodyDrop
* Click the OK button and OK again and save your map.

=== Optional 'No alerts', KO's, and Kills ===

It is recommended that 'No alerts', KO's, and Kills be optional or at least provide a separate difficulty level that approximates another where these are enforced. Many players find these restrictions limiting and often very annoying. Some will abandon an FM in frustration if they find they can barely move without triggering an alert - mission failed.

=== The standard "exit here when you're done objective" ===
* Place a brush in the location you want to work as the exit.
* Give it texture textures/common/clip
* Make the thing into an entity info_tdm_objective_location
* Give it name player_exit
* Go to objectives editor and make an objective "After you're done, go to the exit" or something like that. Set it to be INCOMPLETE and mandatory.
* Set enabling objectives. Here you need to set which objectives need to be complete for the exit to work. If you have objective numbers 1 and 2 must be completed in order the player to exit, you need to put text "1 AND 2" in the enabling objectives box. If you need to have objectives 1,2 and 5 completed you need to put "1 AND 2 AND 5"
You can check the objective numbers in the objective editor window under "#" mark.
* set the component to be:
* Type: item in location
* Entity: any entity with SDK-level spawnclass idPlayer
* Location: name of single entity player_exit

Please note that you need to create a separate exit objective for each difficulty level, since the enabling objective numbers change with difficulty levels.

===Technical info===

;*I have some other questions about objectives
: Answer:This article talks about more specific, more technical and advanced work. [[Objectives]]

{{tutorial-editing}} {{darkradiant}}

Difficulty Levels

2010-12-19T15:35:24Z

Fidcal: /* Excluding & Restricting Entities from/to Difficulty Levels */

==General information==

You can change what is in your FM and the way it plays on the different difficulty levels.

It is highly recommended that you do not use these methods to exclude entire sections or interesting features unless you declare this somewhere in the objectives text or in the readme. It's also a good idea to declare if the player will ''not'' miss anything whichever difficulty setting he/she chooses.

==Excluding & Restricting Entities from/to Difficulty Levels==

To restrict an entity to a particular difficulty setting you ''exclude'' it from the others, as follows...

To ''exclude'' an entity from a particular difficulty level you set it to not spawn as follows:

* Select the entity
* Add the following property and value:
* diff_N_nospawn 1 ... replace N with...
** 0 = 'Easy'
** 1 = 'Hard'
** 2 = 'Expert'
* The '1' enables it to not spawn and 0 would allow it to spawn (the default)

==Placing Entities at Different Locations on Different Difficulty Settings==

There is a special spawnarg to change the location and rotation of an entity on different difficulty levels:

Examples:

<pre>

"diff_N_change_0" "origin"
"diff_N_arg_0" "-2530 795 -5"

"diff_N_change_1" "rotation"
"diff_N_arg_1" "315"

</pre>

... where N is the difficulty 0, 1, or 2

(note that the number "x" in "change_x" must correspond to the "arg_x" value in the example above)

This is another method but not needed if you use the above...

You can position an entity in different locations on different difficulty levels. To do this...

* Clone the entity so you have one copy for each location you want.
* Optionally rename the entities, eg, sceptor_easy, sceptor_hard, sceptor_expert
* Add the properties and values, eg, for the one to be used on Easy you would exclude Hard(1) and Expert(2)...
** diff_1_nospawn 1
** diff_2_nospawn 1
* Move the entities to the locations you want.

'''Objectives: ''' If the entity is an objective then you will need three objectives each having their own difficulty setting (see [[Objectives]])

'''Inventory Name Clash:''' If testing with no difficulty settings set then all three copies of the entity will appear the in the mission. In that case if the entity can go in the player inventory, each must have an exclusive inventory name or only the first one can be frobbed (if already in inventory at start not sure - maybe error or only one show.) You can get round that by varying the inv_name property on each, eg, 'A sceptor', 'The sceptor', 'Sceptor', 'Lord's sceptor' but you might want to change those back to one name after testing.

==Changing Properties on Entity Instances based on Difficulty Settings==

As an example, say you wanted a statue on medium difficulty to face 90 degrees instead where it faces on easy difficulty, 0 degrees. On that instance of the statue, you could add the properties:

"diff_1_change_0" "angle"
"diff_1_arg_0" "90"

Translated: At difficulty 1 (medium), the first (0) of a possible list of changes, is applied to the property called "angle". The value of the corresponding change is then passed by the arg(ument) keypair, and is "90".

The properties of individual entities can be controlled with difficulty level in this manner, in contrast to the Difficulty Editor, which changes classes instead of instances.

== Relative Changes ==
You can either assign new values to spawnargs (like the "angle" "90" example above) or change spawnargs relatively to the existing values. Both additive and multiplicative changes are possible:

Add 45 degrees to the "angle" property like this:
"diff_1_change_0" "angle"
"diff_1_arg_0" "+45"
Double the "health" property with this:
"diff_1_change_0" "health"
"diff_1_arg_0" "*2"
The important part is to use the asterisk *, plus + or minus - sign to indicate relative changes.

== Changing CVARs ==
You can affect CVARs by placing spawnargs like these on the entities:
"diff_1_cvar_0" "tdm_player_default_health"
"diff_1_arg_0" "40"
"diff_1_cvar_1" "tdm_player_default_height"
"diff_1_arg_1" "+8"
The above two spawnargs will be activated on difficulty level 1 (Hard) and will set the CVARs '''tdm_player_default_health''' to '''40''' and increase '''tdm_player_default_height''' by 8.

==Changing the Difficulty Level Names==
Mappers can change the default names of the difficulty levels, eg, for style, story, or type. For example, suppose in your mission you want one level to include no kills or KOs and add other obstacles so the player has a richer experience playing more stealthily you might want to call it say "Stealthy". Then another difficulty level in your same mission where you put extra enemies in brightly lit areas that the player can only get past by fighting them then you might want to call it say, "Warrior". Another idea you might have would be "Extra Clues". To do this...

* Select any worldspawn brush or patch
* Add the following properties and values:
** diff0default Extra Clues
** diff1default Warrior
** diff2default Stealthy

Other suggested styles :"Assassin", "Ninja", "Key Hunt" and so on.

==Testing Different Difficulty Settings==

To test an uninstalled map on different difficulty levels

* Select any worldspawn brush or patch
* Add the following property and value:
* difficulty N ... replace N with...
** 0 = 'Easy'
** 1 = 'Hard'
** 2 = 'Expert'

There is also a CVAR [[tdm_difficulty]] which can be used to override any map-specific or menu-chosen setting. Set the CVAR
tdm_difficulty 2
in the console before starting the map and it will always be using this level. Set the CVAR back to -1 (default) to disable the override. This setting is not saved between sessions to prevent it from unintentionally overriding your settings.

{{tutorial-editing}} {{darkradiant}}