File:RIT door guard.png

2012-05-17T07:59:14Z

Sotha:

File:Roaming RIT.png

2012-05-17T07:58:02Z

Sotha:

File:RIT servant.png

2012-05-17T07:57:30Z

Sotha:

2012-03-31T17:43:10Z

Sotha: /* Basic Loot Objects */

Loot

2012-03-31T17:37:38Z

Sotha: Created page with "== Introduction == This wikipage is for general information and guides dealing with loot related things. == Basic Loot Objects == You can add loot into your map by right clicki..."

Path Nodes

2012-01-28T17:35:40Z

Sotha: /* How to Make AI do Random Interesting Things (RIT) */

''originally written by Springheel''

For more information on pathfinding, see [[Pathfinding]]. For more general info on getting your AI to patrol, see [[AI Patrol]].

= 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 "target1", "target2" 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). (for info on how to use Objectives to alter paths, see [[Objectives#Using_Objectives_Creatively]])

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.

= Kinds of Path Nodes =

== 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
target2 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.'''

'''Also note that if the AI is going to stop at a path_corner--perhaps to wait a spell--the path_corner origin should be kept at least 16 horizontal units away from monsterclip and worldspawn brushes. Otherwise, the stopping animation might not look right.'''

== 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. Other possibilities include peering through a window, picking a carrot off a table and eating it, or running to a spot and cowering.

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.'''

Tip: Animation blending doesn't seem to do very much, so AI often "snap" into position from walking to playing the animation. For a more natural look, add a path_wait of a few seconds first, so AI transition to their idle pose before playing the animation.

== 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.

== 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.

The "path_waitfortrigger" basically operates like a wall, blocking the AI from proceeding until triggered.

Here are the steps for future reference. Let's say you want an AI to stand somewhere until a player triggers him, then you want him to walk to path_corner 1.

1. Make a "path_waitfortrigger" pathnode, and have it target "path_corner_1".

2. Have the AI target the "path_waitfortrigger" pathnode.

3. Create a trigger_once entity, and target the AI.

The AI will stand where they are at map start and behave as if there are no pathnodes set (ie, he plays idle animations and can be alerted). When the player goes through the trigger, the "path_waitfortrigger" is cleared and the AI will proceed to path_corner_1.

I've tried a few different setups and gotten unusual results...more testing needed.

== 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)>

= How to Make AI do Random Interesting Things (RIT) =

''by Sotha''

You can use the above to make individual AI seem to do Random Interesting Things (RIT) when entering a room. Note that it will work with basic dendritic AI, so you could have multiple AI's running in several rooms doing things.

1) Build a room with RITs. A statue. A few chairs. Maybe a lit fireplace.

2) On each RIT place the necessary interaction path_nodes to make an AI interact with them: path_corner to walk over to them; path_sit on each of the chairs, path_anims for warming hands at the fireplace and standing in front of the statue and pondering, etc (A, B & C in image).

3) Place two path_waits (1 & 2 in image) on the ceiling of the room. (They could be anywhere in the room, but it is easiest to manage if they are in the ceiling.)

4) Name one of the path_waits "enter_room_decide_what_to_do." (1) From that path_wait target each of the RIT path_corners. Set the path_wait "wait 0". so AI won't stop there. The idea is to use the path_wait as a simple decision making node. Be sure that the path_wait has no angle-spawnarg. If it does, the AI will turn towards the angle each time he targets the node.

5) Name the other path_wait "exit_room_decide_what_to_do." (2) Make each RIT final path_node target this path_wait. Make the path_wait target other rooms with similar decision making path_waits.

6) Done.

[[Image:Rits.jpg]]

AI will come into the room, select A, B or C at random, and then leave. Next time they enter, they'll again pick at random.

This could be used to make servants to run around a mansion, cleaning, making food, taking sitting breaks, visit the toilet, etc. You could build room decision making network separately for different AI. Servants clean, cook and take breaks. Guards patrol, make random deviations once in a while, and of course take breaks. Controlling the RIT path_corner chance-spawnarg gives you control what RITs the AI do more likely.

= 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.

= 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_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:

Create a [b]func_remove[/b] with this spawnarg:

"target" "<AI's name>"

At the point in his path where you want him to disappear, place a [b]trigger_once_entityname[/b] with these spawnargs:

"entityname" "<AI's name>"
"target" "<func_remove's name>"

When the AI walks through the [b]trigger_once_entityname[/b], it recognizes him, triggers the [b]func_remove[/b], and that takes the AI out of the game.

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

== 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}}

Fan Missions for The Dark Mod

2012-01-03T20:46:59Z

Sotha:

__NOTOC__
{{infobox|<center>'''Big Ugly Disclaimer:'''</center> '''The Dark Mod''' team does not necessarily support or endorse content listed here, and only hosts missions listed on the [http://www.thedarkmod.com/ official TDM website]. This is a community maintained list, and an ongoing work in progress. Mission entries which are suspected to violate copyright must be text-only, and cannot contain links. Report and/or remove links found in violation of this rule.}}

* For details about editing this table, see [http://modetwo.net/darkmod/wiki/index.php?title=Fan_Missions_for_The_Dark_Mod#Editing_This_Table below].
* For details about how to install Fan Missions please visit: [[Installing and Running Fan Missions]]
* To sort by a different criterion, click the [[Image:Sort none.gif]] icon in the relevant column header.

{|class="wikitable sortable" border=1 style="border-collapse: collapse;" cellspacing=0 cellpadding=2 width=100%
|-
!bgcolor=#d0d0e0 width="30%"|Fan Mission Title
!bgcolor=#d0d0e0 width="23%"|Author(s)
!bgcolor=#d0d0e0 width="10%" class="unsortable"|Links
!bgcolor=#d0d0e0 width="10%"|First Release
!bgcolor=#d0d0e0 width="7%"|Size (MB)
!bgcolor=#d0d0e0 width="20%"|Series
|-



|-
!align=left|{{TDM-FM|56|House of Theo}}
|Theothesnopp
|{{Bloodgate|houseoftheo.pk4}} {{Mirrorlink|http://www.gamefront.com/files/21053391/houseoftheo__2__2.pk4}} {{Forumlink|http://forums.thedarkmod.com/topic/13242-fan-mission-house-of-theo/}}
|2011-12-04
|6.2
|
|-

|-
!align=left|[http://darkfate.org/view/details/files/projects/darkmod/fm/krysztalowy_grob/KrysztGrob1.zip Krysztalowy Grob (Crystal Grave)]
|ERH+
|{{Mirrorlink|http://darkfate.org/view/details/files/projects/darkmod/fm/krysztalowy_grob/KrysztGrob1.zip}} {{Forumlink|http://forums.thedarkmod.com/topic/13208-fm-crystal-grave-krysztaowy-grob/}} [http://darkfate.org/view/details/files/projects/darkmod/fm/krysztalowy_grob/screenshots Images]
|2011-11-12
|6
|Unknown (Polish language)
|-

|-
!align=left|{{TDM-FM|53|Dragon's Claw}}
|Bikerdude, Flanders (map assets)
|{{Bloodgate|claw.pk4}}{{Mirrorlink|http://www.gamefront.com/files/20948800/claw.pk4}} {{Taffers Paradise|claw.pk4}} {{Forumlink|http://forums.thedarkmod.com/topic/13181-fan-missiondragons-claw-by-b1k3rdude-31102011/}}
|2011-10-31
|98
|HSC 11
|-

|-
!align=left|{{TDM-FM|52|A Night to Remember}}
|Fieldmedic
|{{Bloodgate|antr.pk4}}{{Mirrorlink|http://www.mediafire.com/?d4hch59m4nef3dc}} {{Taffers Paradise|antr.pk4}} {{Forumlink|http://forums.thedarkmod.com/topic/13177-fan-mission-a-night-to-remember-by-fieldmedic-20111030/}}
|2011-10-31
|32
|HSC 11
|-

|-
!align=left|{{TDM-FM|51|The Creeps}}
|Mortem Desino
|{{Bloodgate|thecreeps.pk4}}{{Mirrorlink|http://www.gamefront.com/files/20939925/thecreeps.pk4}} {{Taffers Paradise|thecreeps.pk4}} {{Forumlink|http://forums.thedarkmod.com/topic/13176-fan-mission-creeps-the-20111030-by-mortem-desino/}}
|2011-10-30
|61
|HSC 11
|-

|-
!align=left|{{TDM-FM|50|House in Blackbog Hollow}}
|Stumpy
|{{Bloodgate|blackbog.pk4}}{{Mirrorlink|http://www.bookofages.co.uk/doom3/mods/blackbog.html}} {{Taffers Paradise|blackbog.pk4}} {{Forumlink|http://forums.thedarkmod.com/topic/13172-fan-mission-house-in-blackbog-hollow-by-stumpy-20111028/}}
|2011-10-28
|12
|HSC 11
|-

|-
!align=left|{{TDM-FM|49|Let Sleeping Thieves Lie}}
|Sir Taffsalot, Bikerdude
|{{Bloodgate|lstl.pk4}}{{Mirrorlink|http://www.mediafire.com/?zkd1jn4lpwgioh9}} {{Taffers Paradise|lstl.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/13153-let-sleeping-thieves-lie-by-sir-taffsalot-bikerdude-20102011/}}
|2011-10-20
|13
|
|-

|-
!align=left|{{TDM-FM|48|Samhain Night on Bone Hill}}
|PranQster
|{{Bloodgate|samhain.pk4}}{{Mirrorlink|http://jdchoate.mcn.org/games/darkmod/samhain.zip}} {{Taffers Paradise|samhain.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/13127-fan-mission-samhain-night-on-bone-hill-by-pranqster-20111009/}}
|2011-10-09
|10
|HSC 11
|-

|-
!align=left|{{TDM-FM|47|A Score to Settle}}
|Springheel
|{{Bloodgate|score_to_settle.pk4}}{{Mirrorlink|http://www.mediafire.com/?f3o7hm4h4ew7o3l}} {{Taffers Paradise|score_to_settle.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12894-fan-mission-%2348-a-score-to-settle-by-springheel-20110701/}}
|2011-07-01
|135
|
|-

|-
!align=left|{{TDM-FM|46|Siege Shop}} (v1.2 2011/09/21)
|PranQster
|{{Bloodgate|siegeshop.pk4}}{{Mirrorlink|http://jdchoate.mcn.org/games/darkmod/siegeshop.pk4}} {{Taffers Paradise|siegeshop.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12874-fan-mission-the-siege-shop-by-pranqster-20110626/}}
|2011-06-26
|13
|
|-

|-
!align=left|{{TDM-FM|44|Alberic's Curse}}
|Bikerdude
|{{Bloodgate|alberic.pk4}} {{Mirrorlink|http://www.gamefront.com/files/20459738/alberic.pk4}} {{Taffers Paradise|alberic.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12850-fan-mission-alberics-curse-by-b1k3rdude-20062011/}}
|2011-06-20
|29
|CSC 11 (Winner), T2 FM homage
|-

|-
!align=left|{{TDM-FM|45|Reap as you sow}}
|Fieldmedic
|{{Bloodgate|reap.pk4}} {{Taffers Paradise|reap.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12849-fan-mission-reap-as-you-sow-by-fieldmedic-20110619/}}
|2011-06-19
|52
|CSC 11
|-

|-
!align=left|{{TDM-FM|43|Rake Off}}
|Jesps
|{{Bloodgate|rake_off.pk4}} {{Taffers Paradise|rake_off.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12846-fm-rake-off-19-06-2011/}}
|2011-06-19
|8
|CSC 11, Selis Woderose 2
|-

|-
!align=left|{{TDM-FM|42|Winter Harvest}} (v2.0 2011/07/24 with Bikerdude)
|ShadowHide
|{{Bloodgate|winterharvest.pk4}} {{Taffers Paradise|winterharvest.pk4}} {{Forumlink|http://modetwo.net/darkmod/index.php?/topic/12690-seasons-contest-entry-winter-harvest-by-shadowhide/}}
|2011-05-08
|10
|CSC 11
|-

|-
!align=left|{{TDM-FM|41|Fiasco at Fauchard Street}}
|Melan
|{{Bloodgate|fauchard.pk4}} {{Taffers Paradise|fauchard.pk4}} {{Mirrorlink|https://rapidshare.com/files/460141132/fauchard.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12655-fan-mission-fiasco-at-fauchard-street-by-melan-20110501//}}
|2011-05-01
|62
|Talbot 3
|-

|-
!align=left|{{TDM-FM|40|Mandrasola}}
|Sotha
|{{Bloodgate|mandrasola.pk4}} {{Taffers Paradise|mandrasola.pk4}} {{Mirrorlink|http://www.mediafire.com/?2ox2nbhh796ne71}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12575-fan-mission-mandrasola-by-sotha-20110410/}}
|2011-04-10
|10
|Thomas Porter 0, CSC 11
|-

|-
!align=left|[http://www.gamefront.com/files/20167184/yantdm1.1.pk4 Q4 Conversion: Yan's Test]
|Bikerdude
|{{Mirrorlink|http://www.mediafire.com/?2nona089nzi00sv}} {{Mirrorlink|http://www.gamefront.com/files/20167184/yantdm1.1.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12506-fan-mission-q4-map-conversion-yantdm1-280311/}}
|2011-03-28
|28
|
|-

|-
!align=left|{{TDM-FM|38|The Transaction}}
|Sotha
|{{Bloodgate|transaction.pk4}} {{Taffers Paradise|transaction.pk4}} {{Mirrorlink|http://www.mediafire.com/?ux7mx79wumnvcb6}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12408-fan-mission-the-transaction-by-sotha-20110304/}}
|2011-03-04
|10
|Thomas Porter 4
|-

|-
!align=left|{{TDM-FM|13|Return to the City}} (v2.0 2011/03/01)
|Melan, Bikerdude
|{{Bloodgate|ReturnToTheCityV2.pk4}}{{Mirrorlink|1=http://www.southquarter.com/downloads/2011/ReturnToTheCityV2.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10509-fan-mission-return-to-the-city-by-melan-20100110/}} {{Forumlink|1=http://www.ttlg.com/forums/showthread.php?t=130519/}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12390-fan-mission-return-to-the-city-v2-01032011/}}
|2010-01-10
|26
|Version 1.0, GCC 09 (Winner); Talbot 2
|-

|-
!align=left|{{TDM-FM|39|Lockdown}}
|GameDevGoro Bikerdude Fidcal
|{{Bloodgate|lockdown1_2_1.pk4}} {{Taffers Paradise|lockdown1_2_1.pk4}} {{Mirrorlink|http://www.fidcal.com/darkuser/missions/lockdown1_2_1.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/12064-fm-lockdown-part-1-by-gamedevgoro-and-bikerdude-20101224/}}
|2010-12-25
|3
|Lockdown 1
|-

|-
!align=left|{{TDM-FM|37|Flakebridge Monastery}}
|Jesps
|{{Bloodgate|flakebridge.pk4}} {{Taffers Paradise|flakebridge.pk4}} {{Mirrorlink|http://www.file-upload.net/download-3024426/flakebridge.pk4.html}} {{Mirrorlink|http://rapidshare.com/files/434997519/flakebridge.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11991-fm-flakebridge-monastery-by-jesps/}}
|2010-12-05
|16
|Selis Woderose 1
|-

|-
!align=left|{{TDM-FM|36|Knighton Manor, The}}
|Sotha
|{{Bloodgate|knighton_manor.pk4}} {{Taffers Paradise|knighton_manor.pk4}} {{Mirrorlink|http://www.mediafire.com/?xrdts3j4t2qxre2}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11898-fan-mission-the-knighton-manor-by-sotha-20101109/page__view__getnewpost}}
|2010-11-09
|21
|Thomas Porter 1
|-

|-
!align=left|{{TDM-FM|35|St Albans Cathedral}} (v1.6 2011/03/13)
|Bikerdude
|{{Bloodgate|stac160.pk4}} {{Taffers Paradise|stac160.pk4}} [[http://www.bloodgate.com/fms/stac142.pk4 Classic]] {{Mirrorlink|http://www.filefront.com/17464439/stac141.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11872-fan-mission-st-albans-cathedral-01112010/}} {{Loot|FM:TDM_St_Alban's_Cathedral_-_Bikerdude}}
|2010-11-01
|67
|St Alban
|-

|-
!align=left|{{TDM-FM|33|Swing}}
|Komag
|{{Bloodgate|swing_v1.2.pk4}} {{Taffers Paradise|swing_v1.2.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11660-vertigo-contest-entry-swing-by-komag-20100825/}} {{Loot|FM:TDM_Swing_-_Komag}}
|2010-08-25
|3
|SVC 10

|-
!align=left|{{TDM-FM|32|The Caduceus of St. Alban}} (v.1.5.5 2010/08/26)
|Bikerdude
|{{bloodgate|stalban.pk4}} {{Taffers Paradise|stalban.pk4}} {{Mirrorlink|http://www.filefront.com/17237609/stalban.pk4/}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11644-the-caduceus-of-st-alban-vertical-fm-contest-entry-aug-8th-2010/}}
|2010-08-23
|11.3
|SVC 10/St Alban

|-
!align=left|{{TDM-FM|30|Somewhere Above the City}} (v1.1 2010/08/27)
|Grayman
|{{Bloodgate|somewhere1.1.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11619-vertical-contest-mission-somewhere-above-the-city-by-grayman-aug-20-2010/}} {{Loot|FM:TDM_Somewhere_Above_the_City_-_grayman}}
|2010-08-20
|11
|SVC 10

|-
!align=left|{{TDM-FM|29|Betrayal}} (v.1.1, 2010/09/01)
|Fieldmedic
|{{Bloodgate|betrayal.pk4}} {{Taffers Paradise|betrayal.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11605-betrayal-by-fieldmedic-20100817-summer-fm-vertical-contest-entry/}} {{Loot|FM:TDM_Awaiting_the_Storm_-_HappyCheeze}}
|2010-08-17
|12
|SVC 10

|-
!align=left|{{TDM-FM|31|Rift, The}}
|Baddcog
|{{Bloodgate|rift.pk4}} {{Taffers Paradise|rift.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11599-vert-contest-mission-the-rift-by-baddcog-aug-15-2010/}}
|2010-08-15
|10
|SVC 10

|-
!align=left|{{TDM-FM|34|Illusionist's Tower}}
|stumpy
|{{Bloodgate|holetower.pk4}} {{Taffers Paradise|holetower.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11541-illusionists-tower-by-stumpy-201085-summer-fm-vertical-contest-entry}} {{Forumlink|1=http://www.bookofages.co.uk/doom3/mods/holetower.html}} {{Loot|FM:TDM_Illusionist%27s_Tower_-_stumpy}}
|2010-08-05
|9
|SVC 10

|-
!align=left|{{TDM-FM|28|Mad's Mountain}}
|Jesps
|{{Bloodgate|madmountain.pk4}} {{Taffers Paradise|madmountain.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11510-fan-mission-mads-mountain-by-jesps-20100731}} {{Loot|FM:TDM_Lord_Dufford%27s_-_stumpy}}
|2010-07-31
|2
|SVC 10

|-
!align=left|{{TDM-FM|27|Glenham Tower, The}}
|Sotha
|{{Bloodgate|glenham_tower.pk4}} {{Taffers Paradise|glenham_tower.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11423-fan-mission-the-glenham-tower-by-sotha-20100717}}
|2010-07-17
|5
|Thomas Porter 3, SVC 10 (Winner)

|-
!align=left|{{TDM-FM|25|Pandora's Box}}
|Jesps, Fidcal
|{{Bloodgate|pandoras_box.pk4}} {{Taffers Paradise|pandoras_box.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11381-fan-mission-pandoras-box-by-jesps20100711}} {{Loot|FM:TDM_Pandora%27s_Box_-_Jesps}}
|2010-07-11
|7
|

|-
!align=left|{{TDM-FM|23|Beleaguered Fence, The}}
|Sotha
|{{Bloodgate|beleaguered_fence.pk4}} {{Taffers Paradise|beleaguered_fence.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11298-fan-mission-the-beleaguered-fence-by-sotha-20100623}} {{Loot|FM:TDM_The_Beleaguered_Fence_-_Sotha}}
|2010-06-23
|11
|Thomas Porter 2

|-
!align=left|{{TDM-FM|22|Special Delivery, A}}
|Silencium18
|{{Bloodgate|delivery.pk4}} {{Taffers Paradise|delivery.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11247-fan-mission-a-special-delivery-by-silencium1820100612}} {{Loot|FM:TDM_A_Special_Delivery_-_Silencium18}}
|2010-06-12
|2
|

|-
!align=left|{{TDM-FM|21|Alchemist, The}} (2010/06/04)
|Sotha, Fidcal
|{{Bloodgate|alchemist.pk4}} {{Taffers Paradise|alchemist.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11170-fan-mission-the-alchemist-by-sotha-fidcal20100601}} {{Loot|FM:TDM_The_Alchemist_-_Sotha_%26_Fidcal}}
|2010-06-01
|27
|Thief's Den 4

|-
!align=left|{{TDM-FM|20|Awaiting The Storm}}
|HappyCheeze
|{{Bloodgate|storm.pk4}} {{Taffers Paradise|storm.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11095-fm-awaiting-the-storm-by-happycheeze-20200522}} {{Loot|FM:TDM_Awaiting_the_Storm_-_HappyCheeze}}
|2010-05-22
|4
|

|-
!align=left|{{TDM-FM|18|No Honor Among Thieves}}
|Goldchocobo, RailGun, Mortem Desino
|{{Taffers Paradise|NHAT.zip}} {{Mirrorlink|http://tinyurl.com/2a9mdcs}}{{Mirrorlink|http://www.southquarter.com/downloads/NHAT.zip}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10993-fan-mission-no-honor-among-thieves-20100429}} {{Loot|FM:TDM_No_Honor_Among_Thieves_-_Goldchocobo}}
|2010-04-29
|144
|

|-
!align=left|{{TDM-FM|17|Heart of Lone Salvation, The}} (v.2.0, 2010/04/12)
|Fidcal, Baddcog
|{{Bloodgate|heart.pk4}} {{Taffers Paradise|heart.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10878-fan-mission-the-heart-of-lone-salvation-by-fidcal-baddcog-20100402/}} {{Walkthrough|FM:TDM_The_Heart_of_Lone_Salvation_-_Fidcal_%26_Baddcog}} {{loot|FM:TDM_The_Heart_of_Lone_Salvation_-_Fidcal_%26_Baddcog}}
|2010-04-02
|41
|Thief's Den 3

|-
!align=left|[http://www.bookofages.co.uk/doom3/mods/dufford.pk4 Lord Dufford's]
|stumpy
|{{Taffers Paradise|dufford.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10868-fan-mission-lord-duffords-20100331}} {{Loot|FM:TDM_Lord_Dufford%27s_-_stumpy}}
|2010-03-31
|22
|

|-
!align=left|{{TDM-FM|16|Builder's Influence, The}} (2010/03/23)
|Railgun, Springheel
|{{Bloodgate|builders_influence.pk4}} {{Taffers Paradise|builders_influence.pk4}} {{Mirrorlink|http://www.fidcal.com/darkuser/missions/builders_influence.pk4}}{{Forumlink|http://modetwo.net/darkmod/index.php?/topic/10811-fan-mission-the-builders-influence-20100320/}} {{Loot|FM:TDM_The_Builders_Influence_-_Railgun%26Springheel}}
|2010-03-20
|15
|

|-
!align=left|{{TDM-FM|14|Business as Usual}} (v2.0 2011/09/24)
|Bikerdude
|{{Bloodgate|business.pk4}}{{Mirrorlink|1=http://rapidshare.com/files/335299431/business.pk4.html}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10533-fan-mission-business-as-usual-by-b1k3rdude-14012010-christmas-fm-contest-entry/page__view__findpost__p__207055}}
|2010-01-14
|4
|GCC 09

|-
!align=left|{{TDM-FM|12|Sons of Baltona 1, The}}
|Carnage
|{{Bloodgate|sons_of_baltona_1.pk4}} {{Taffers Paradise|sons_of_baltona_1.pk4}} {{Mirrorlink|1=http://www.mediafire.com/?m4ywobjodm0}}{{Mirrorlink|1=http://www.southquarter.com/downloads/sons_of_baltona_1.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10498-fan-mission-the-sons-of-baltona-1-by-carnage-20100109}}
|2010-01-09
|3
|GCC 09 / Baltona 1

|-
!align=left|{{TDM-FM|11|Living Expenses}}
|Sonosuke
|{{Bloodgate|living_expenses.pk4}} {{Taffers Paradise|living_expenses.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10451-fm-living-expenses-by-sonosuke-2-jan-10/page__view__findpost__p__205386}}
|2010-01-02
|6
|GCC 09

|-
!align=left|{{TDM-FM|10|Trapped!}}
|RailGun
|{{Bloodgate|trapped.pk4}} {{Taffers Paradise|trapped.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10442-fm-trapped-by-railgun-dec-30/page__view__findpost__p__205092}}
|2009-12-30
|6
|

|-
!align=left|{{TDM-FM|8|Parcel, The}}
|Xonze
|{{Bloodgate|parcel.pk4}} {{Taffers Paradise|parcel.pk4}} {{Mirrorlink|1=http://www.southquarter.com/downloads/parcel.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10404-fm-the-parcel-by-xonze-dec-24/page__view__findpost__p__204459}}
|2009-12-24
|7
|GCC 09

|-
!align=left|{{TDM-FM|9|Too Late}}
|Nielsen74
|{{Bloodgate|too_late.pk4}} {{Taffers Paradise|too_late.pk4}} {{Mirrorlink|1=http://www.southquarter.com/downloads/too_late.pk4}}{{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10400-fm-too-late-by-nielsen74-24-dec-09/page__view__findpost__p__204396}}
|2009-12-24
|4
|GCC 09

|-
!align=left|{{TDM-FM|7|Thieves}}
|Silencium, RailGun, Fidcal
|{{Bloodgate|thieves.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10286-fm-the-thieves-nov-2509/}}
|2009-11-26
|9
|

|-
!align=left|{{TDM-FM|6|Patently Dangerous}}
|demagogue
|{{Bloodgate|patently_dangerous.pk4}} {{Taffers Paradise|patently_dangerous.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10125-fm-patently-dangerous-oct3109/page__view__findpost__p__199324/}}
|2009-10-31
|24
|

|-
!align=left|{{TDM-FM|5|Dark Mod Training Mission, The}}
|TDM Team
|{{Bloodgate|training_mission.pk4}} {{Taffers Paradise|training_mission.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/9932-fm-training-mission-17-oct-09/}}
|2009-10-17
|6
|

|-
!align=left|{{TDM-FM|2|Crown of Penitence, The}}
|Jesps
|{{Bloodgate|crow_of_penitence.pk4}} {{Taffers Paradise|crow_of_penitence.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/9934-fm-crown-of-penitence-by-jesps-17-oct-09/}}
|2009-10-16
|12
|

|-
!align=left|{{TDM-FM|3|Chalice of Kings, The}}
|Fidcal
|{{Bloodgate|chalice.pk4}} {{Taffers Paradise|chalice.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/9935-fm-chalice-of-kings-by-fidcal-17-oct-09/}} {{Loot|FM:TDM_Chalice_of_Kings_-_Fidcal}}
|2009-10-15
|3
|Thief's Den 2

|-
!align=left|{{TDM-FM|1|Outpost, The}}
|angua, greebo
|{{Bloodgate|outpost.pk4}} {{Taffers Paradise|outpost.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/9937-fm-the-outpost-by-angua-greebo-17-oct-09/}}
|2008-12-23
|2
|

|-
!align=left|{{TDM-FM|15|Tears of Saint Lucia, The}} (v.1.01, 2010/04/29)
|TDM Team
|{{Bloodgate|saintlucia.pk4}} {{Taffers Paradise|saintlucia.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/10579-fan-mission-the-tears-of-st-lucia-20081021/page__view__findpost__p__207972}} {{Loot|FM:TDM_The_Tears_of_Saint_Lucia_-_jdude}}
|2008-10-21
|18
|

|-
!align=left|{{TDM-FM|24|Thief's Den}} (v.2.0, 2010/07/04)
|Fidcal, greebo
|{{Bloodgate|thiefs_den.pk4}} {{Taffers Paradise|thiefs_den.pk4}} {{Forumlink|1=http://modetwo.net/darkmod/index.php?/topic/11347-fan-mission-thiefs-den-re-release-by-fidcal20100704}} {{Walkthrough|FM:TDM_Thief's_Den_-_Fidcal}} {{Loot|FM:TDM_Thief%27s_Den_-_Fidcal}}
|2008-01-18
|3
|Thief's Den 1
|}

To see a speculative list of Upcoming Fan Missions please visit: [[Upcoming Fan Missions]]

'''Series Key'''

GCC 09: Grand Christmas Contest 2009

SVC 10: Summer Vertical Contest 2010

CSC 11: Community Seasons Contest 2011

HSC 11: Halloween Speed-Build Contest 2011

'''Links Key'''

{{Forumlink|}} : Link to discussion in Forums

{{Mirrorlink|}} : Misc. dowload mirror

{{Bloodgate|}} : Bloodgate download mirror

{{Taffers Paradise|}} : Taffer's Paradise download mirror

{{Loot|}} : Loot list

{{Walkthrough|}} : Walkthrough

== Editing This Table ==
* Please only include playable missions that are fully released, not those currently in development or testing. Tutorials, demos, prefabs, etc. should be listed elsewhere.
* A mission title may be listed in plain text as a record of release, or preferably a link to an information page or primary direct download.
* List by release date descending (newest at the top).
* If a fan mission only has a single mirror/host please consider adding additional mirrors.
{{general|sort=Fan Missions}}
[[Category:Fan Missions]]

Objectives

2012-01-03T15:48:25Z

Sotha: /* Using Objectives Creatively */

{{Original_Reference|Ishtvan|4121}} ''additions by greebo''

This article covers details of the objectives system. Note that mappers can use
DarkRadiant's [[Objectives Editor]] to make it easier to create objectives.

The objectives system exists to determine when the player has completed the mission. At the highest level, a mission consists of a list of objectives to be completed and boolean logic to determine when the mission has succeeded or failed based on which of the objectives are complete. At the objective level, an objective consists of individual components and boolean logic to determine when the objective is completed or failed. At the component level, each component has a type, a specifier, and arguments. These will be explained fully in the components section.

= Mission =
Objectives are stored by entities named [[target_tdm_addobjectives]]. Your mission can have several of these but typically you will only want one for all your objectives.

By default these entities self-trigger (activates themselves) at mission start. If you need to delay this and activate it later (via any trigger entity that can have a target spawnarg) then add the spawnarg ''wait_for_trigger'' with a value of 1.

When triggered, these entities add objectives to the mission based on their spawnargs.

Spawnargs governing mission level behavior may be entered on any target_addobjectives. Non-empty spawnargs will be overwritten by the most recently triggered target_addobjectives (FM authors may want to do this if they add an objective later on and want to change the mission success logic to include that objective, for example). The following is a list of the mission-level spawnargs and what they mean:

== Success/Failure Logic ==
By default, all mandatory objectives need to be completed for mission success. However, it's possible to define a custom success and failure logic string on an objective entity. Be sure to have this addobjectives entity active at map start so that the logic is parsed right at map load.

=== Default Logic ===
*;<tt>mission_logic_success</tt> (string)
:A string of boolean logic applied to individual objective states to determine if the mission succeeds. AND, OR, NOT and parenthesis are available. The FM author can construct strings using these and the integer index for an objective. For example: "1 OR (NOT(2) AND 3)" would complete the mission if either objective 1 is true, or if 2 is false and 3 is true. By default, a mission succeeds when all mandatory objectives are completed.

*;<tt>mission_logic_failure</tt> (string)
:Boolean logic applied to individual objective component states to determine if the mission has failed. By default, if any mandatory objective fails, the mission fails.

=== Difficulty Dependent Logic ===
The above spawnargs apply to all difficulty levels. It's of course possible to override this default for a given difficulty level, by setting these spawnargs. The index N is referring to the difficulty level number (starting from 0 = Easy):

*;<tt>mission_logic_success_diff_N</tt> (string)
:Defines the success logic for the difficulty level N (override the default logic), e.g. "1 AND 2 AND 3".
*;<tt>mission_logic_failure_diff_N</tt> (string)
:Defines the failure logic for the difficulty level N (override the default logic). When this condition is fulfilled, the mission has failed.

If specific logic is not specified for a certain difficulty level, the default spawnargs (without _diff_*) will be used.

= Objectives =
Objectives added by the target_addobjectives each have a unique integer index, starting with objective 1, the first objective. The spawnargs associated with an objective are prefixed in the following manner:
obj<objective index>_<spawnarg name>
Example: ''obj3_desc''

The spawnargs (minus prefix) and meanings for objective attributes are listed below. Each objective also includes a list of components and their attributes, which will be covered in the next section.

*;<tt>objN_desc</tt> (string)
:The description of this objective. This is used to display the objective in the GUI - the user will never see the objective number, only this string. The default value is an empty string.

*;<tt>objN_state</tt> (int) Defines the state of the objective at map start.
:'''Possible Objective States:'''
:* 0 = STATE_INCOMPLETE
:* 1 = STATE_COMPLETE
:* 2 = STATE_INVALID
:* 3 = STATE_FAILED
:Code defaults to 0 = incomplete.

*;<tt>objN_mandatory</tt> (1/0)
:Set to 0 for optional objective that doesn't fail the mission if you fail it. Objective must be completed to complete the mission if 1. Code defaults to 1.

*;<tt>objN_irreversible</tt> (1/0)
:Irreversible objectives lock their state once they're changed to COMPLETE or FAILED. Irreversible components will only change state once and then stay in that state. (Note: There are scriptfunctions to reset irreversible objectives and components if the FM author wants to let them change again for some reason). Code defaults to 0.

*;<tt>objN_ongoing</tt> (1/0)
:If true, this objective is not marked as complete and the player is not informed that it's complete until the end of the mission. Typically used for "do not kill" type objectives, because technically they would be complete right from the beginning, but we don't want to mark them off or tell the player they're complete right at the beginning. Could also be used for "have some item with you when you complete the mission." Code defaults to 0.

*;<tt>objN_visible</tt> (1/0)
:Whether the objective appears in the player's Objectives GUI. Use invalidated and hidden objectives to queue up objectives for later, or hidden but valid objectives as another way of scripting events when the player does a certain thing, since objectives can launch an arbitrary script after they're completed. Code defaults to 1.

*;<tt>objN_difficulty</tt> (integer)
:Space delimited list of difficulty levels that should include this objective. For example, "2 3" would enable this objective at difficulty levels 2 and 3, but not for other difficulty levels. Default value is empty - the objective applies to all difficulty levels.
:''Note:'' When the objective is not active for a given difficutly, it is invalidated and hidden, but it still exists, so the numbering of the next objective should still increase by 1. E.g., objective 5 only appears on hard difficulty, but you still have to call the next objective objective 6, you can't call it objective 5 only appearing on easy or medium difficulty.

*;<tt>objN_enabling_objs</tt> (space-delimited integers)
:This is a list of objectives which must be completed ''before'' this objective can be completed. For example, we shouldn't mark "objective complete" for exiting the mission until all the other mission goals have been completed. An example value for this spawnarg would be "4 6" to let this objective depend on objectives #4 and #6.

*;<tt>objN_script_complete</tt> (string)
*;<tt>objN_script_failed</tt> (string)
:Name of a script to call when this objective is completed or failed. For example, this could be used in campaigns to set up optional objectives in one mission that effect other missions. This feature could also be used as a general scripting aide if the author wants to set up the conditions for something happening using a hidden objective.

*;<tt>objN_target_complete</tt> (string)
*;<tt>objN_target_failed</tt> (string)
:Name of a target entity to call when this objective is completed or failed, similar to the completion/failure script. Only one entity name is allowed here. If you need to trigger multiple entities on objective state change, use a [[trigger_relay]] entity.

*;<tt>objN_logic_success</tt> (string)
:Boolean logic applied to individual objective component states to determine if the objective is complete. The same boolean logic options are available as in the mission-level logic described above. By default, all of the components must be true to complete the objective. In other words, all components are ANDed together (1 AND 2 AND 3...).
*;<tt>objN_logic_failure</tt> (string)
:Boolean logic applied to individual objective component states to determine if the objective is failed. By default, if an objective is ongoing, and any opponent becomes false, that objective will fail.

= Objective Components =
Each objective has an associated list of components and spawnargs defining the attributes of those components. These component spawnargs associated with a given objective are prefixed in the following manner:
obj<objective index>_<component index>_<spawnarg name>
Example: ''obj1_2_state''

In the following, the index N defines the objective number and M refers to the component number. Programmers beware that both numbers start from the value 1.

*;<tt>objN_M_state</tt> (1/0)
:Defines the state of the component at map start, which can only be "1" (complete) or "0" (incomplete). Code defaults to 0.

*;<tt>objN_M_player_responsible</tt> (1/0)
:When true, the player must be responsible for the events that satisfy this component. Events the player is not responsible for are not counted. (e.g., the player kills an AI vs. another AI killing an AI). Code defaults to 1.

*;<tt>objN_M_not</tt> (1/0)
:Code defaults to 0. If true, this component is logically NOTed, so when the conditions described by the type and speifiers are not met, the component state is true, and when they are met, it is false.

*;<tt>objN_M_irreversible</tt> (1/0)
:When the component state changes from its initial state, it will stay in its new state regardless of what happens later. (There is a script event to "unlatch" a latched objective component if needed). Code defaults to 0.

*;<tt>objN_M_type</tt> (string)
:Defines the type of this objective component. See the section [[#Component_Types|Component Types]] below for detailed information.
:'''Possible 'Objective Component' Types:'''
:* kill (also includes non-living things being destroyed)
:* ko
:* ai_find_item (not implemented)
:* ai_find_body (not implemented)
:* alert
:* destroy (inanimate item destroyed ("killed"))
:* item (picked up or dropped an inventory item)
:* pickpocket (inventory item acquired from conscious AI)
:* location (Item A at location B, where "A" is any entity that must have the key "objective_ent" set to "1" on it, and location B is a special entity info_objective_location. Later on we may support using the D3 location system as well)
:* custom (custom component that is set true/false by a map script)
:These components are triggered every N milliseconds by a system clock:
:* custom_clocked (runs a custom map script that should check something and set the objective)
:* info_location (Item A at info_location area B) - TODO: more information needed
:* distance (distance between the origin of entity X and that of entity Y)

Any component can have up to two specifiers, each of which can carry a value. Here, K refers to the number of the specifier, e.g. ("obj2_1_spec4" "name").
*;<tt>objN_M_specK</tt> (string)
:'''Specification Methods:'''
:Specification methods determine what the objective component is looking for. Does it look at how many AI of a specific team you've KO'd, how many humans, how many overall, or whether you've KO'd an AI with a certain name? Each objective component can have up to two of the following specifiers (Not all components can take two specifiers, and not all specifiers make sense for all component types, future documentation will cover that). See the section [[#Specifiers|Specifiers]] below for a detailed description.
:'''The following apply to both AIs and items:'''
:* none
:* name (name of entity)
:* overall (overall count of something: kills, loot, kos, etc)
:* group (inventory group)
:* classname (soft/scripting classname)
:* spawnclass (hard / SDK classname, e.g. "idPlayer")
:'''The following specification methods apply only to AI:'''
:* ai_type (human, beast, undead, bot, etc)
:* ai_team (mapper defined team of the AI)
:* ai_innocence (For distinguishing noncombatants)

*;<tt>objN_M_spec_valK</tt>
:Value that the Kth specifier should match in order to count towards this component. (E.g., an entity name if we specify by name.)

*;<tt>objN_M_args</tt> (space-delimited string)
:'''Integer and String Arguments:'''
:A component can have an arbitrary number of int and string arguments that are fed in space delimited lists. The type of component and specifier determines which args it will use and what it will do with them. For example, the first integer arg is often used to determine how many times something can happen, e.g., the player is only allowed 4 KOs, or must get 500 loot. Not all events are counted up though. The only things that are counted up are things in the mission statistics like loot and kills, so everything else is pretty much a one shot deal where it happens once. Future documentation will detail which objective events are counted up and which are one shots.

*;<tt>objN_M_clock_interval</tt> (float/seconds)
:For clocked components like "custom_clocked" this determines how often they are updated. The value is to be set in seconds.

== Component Types ==
=== AI-Related Components ===
The following specifiers are termed "Standard AI Specifiers": All specifiers minus the <tt>group</tt> specifier.

;*<tt>kill</tt>
:An AI must be killed to satisfy this component.
:'''SDK Name''': COMP_KILL
:'''Number of Specificatons''': 1 (object that must be killed)
:'''Applicable Specifiers''': Standard AI Specifiers
:'''Expected Arguments''': int (number of kills required)

;*<tt>ko</tt> (Knockout)
:An AI must be knocked out by any means (gas, blackjack, other).
:'''SDK Name''': COMP_KO
:'''Number of Specificatons''': 1 (AI that must be KO'd)
:'''Applicable Specifiers''': Standard AI Specifiers
:'''Expected Arguments''': int (number of KOs required)

;*<tt>ai_find_item</tt>
:''not yet implemented''
:'''SDK Name''': COMP_AI_FIND_ITEM
:'''Number of Specificatons''': --
:'''Applicable Specifiers''': --
:'''Expected Arguments''': --

;*<tt>ai_find_body</tt>
:''not yet implemented'' An AI must find a body. Currently, the specifiers apply to the bodies found, and any AI finding the bodies triggers this component. Future revisions might add another specifier for the AI that finds the body.
:'''SDK Name''': COMP_AI_FIND_BODY
:'''Number of Specificatons''': 1 (Type of body that must be found)
:'''Applicable Specifiers''': Standard AI Specifiers
:'''Expected Arguments''': int (number of bodies that must be found)

;*<tt>alert</tt>
:True if an AI or type of AI is alerted. Use the player_responsible flag to determine if this should count alerts not caused by the player's actions (e.g., enemy AI being sighted)
:'''SDK Name''': COMP_ALERT
:'''Number of Specificatons''': 1 (AI that must be alerted)
:'''Applicable Specifiers''': Standard AI Specifiers
:'''Expected Arguments''': int (number of alerts required), int (minimum alert level that counts: 1-5 with 5 being the combat state)

=== Non-AI Components ===

;*<tt>destroy</tt>
:An inanimate item must be destroyed (damage it until its health is lower than zero).
:'''SDK Name''': COMP_DESTROY
:'''Number of Specificatons''': 1 (item to be destroyed)
:'''Applicable Specifiers''': all
:'''Expected Arguments''': int (number of items to be destroyed)

;*<tt>item</tt>
:Completed when the player has this inventory item or loot.
:'''SDK Name''': COMP_ITEM
:'''Number of Specificatons''': 1 (item the player must have)
:'''Applicable Specifiers''': All except AI type, team and innocence.
:'''Expected Arguments''': int (number of items to have, 1 by default)

;*<tt>pickpocket</tt>
:An inventory item must be taken from a conscious AI. Note that it doesn't matter what happens to the item after it is pickpocketed. It could be destroyed or dropped, but as long as it was originally pickpocketed, it counts.
:'''SDK Name''': COMP_PICKPOCKET
:'''Number of Specificatons''': 1 (Item the player must pickpocket)
:'''Applicable Specifiers''': All except AI type, team and innocence
:'''Expected Arguments''': int (number of items to pickpocket, 1 by default)

;*<tt>location</tt> Object in location brush (using info_tdm_objective_location brush)
:A particular item must be in a particular location, defined by an info_objective_location brush. For optimization reasons, the entity or entities to be checked must also have this spawnarg: "objective_ent" set to "1". NOTE: Multiple objects in a single location are not counted up for this component, this is a single-shot objective. If you want the player to put more than one object in a location, you must currently create several of these components, specifying by name, and OR them together in the objective logic.
:'''SDK Name''': COMP_LOCATION
:'''Number of Specificatons''': 2 (object entity to check, location entity to check)
:'''Applicable Specifiers''': For the object to check, all specifiers apply, but multiple objects are not counted up. Typically the objects will be specified by name. For the location to check, it will either be specified by name or by group.
:'''Expected Arguments''': None (if both specifiers match, the objective is completed).

;*<tt>info_location</tt> Object in location area (using info_location entities)
:A particular item must be in a particular location, defined by an info_location area (see vanilla D3 documentation for info_location). Multiple objects in a single location are not counted up for this component, this is a single-shot objective. If you want the player to put more than one object in a location, you must currently create several of these components, specifying by name, and OR them together in the objective logic.
:This check is done periodically. Set spawnarg <tt>clock_interval</tt> to the time in seconds between periodic checks.
:'''SDK Name''': COMP_INFO_LOCATION
:'''Number of Specificatons''': 2 (object entity to check, location entity to check)
:'''Applicable Specifiers''': For the object to check, all specifiers apply, but multiple objects are not counted up. Typically the objects will be specified by name. For the location to check, it will either be specified by name or by group.
:'''Expected Arguments''': None (if both specifiers match, the objective is completed).

;*<tt>custom</tt>
:This custom objective component is only changed when an external script changes it. Otherwise it does nothing.
:'''SDK Name''': COMP_CUSTOM_ASYNC
:'''Number of Specificatons''': none
:'''Applicable Specifiers''': none
:'''Expected Arguments''': none

;*<tt>custom_clocked</tt>
:This component calls a custom script periodically to check some condition. When run, the script is expected to this component true or false based on the custom check. This objective component could also be used as a convenient method to periodically call a script that has nothing to do with objectives.
:Set spawnarg <tt>clock_interval</tt> to the time in seconds between periodic calls of the script.
:'''SDK Name''': COMP_CUSTOM_CLOCKED
:'''Number of Specificatons''': none
:'''Applicable Specifiers''': none
:'''Expected Arguments''': string (name of the script to call periodically)

;*<tt>distance</tt>
:Two entities must be sufficiently close to eachother to satisfy this component. The distance check is done between the origin of the first object and that of the second object. If this distance is below the input maximum distance, the component is set to true.
:This check is done periodically. Set spawnarg "clock_interval" to the time in seconds between periodic checks.
:'''SDK Name''': COMP_DISTANCE
:'''Number of Specificatons''': none (see arguments below)
:'''Applicable Specifiers''': none
:'''Expected Arguments''': string (name of first entity), string (name of second entity), int (maximum distance in doom units)

;*<tt>readable_opened</tt>
:''available since TDM 1.02''
:The player must open a named readable to satisfy this component. This doesn't refer to a specific page, just opening the readable is enough.
:'''SDK Name''': COMP_READABLE_OPENED
:'''Number of Specificatons''': 1 (The name of the readable)
:'''Applicable Specifiers''': name
:'''Expected Arguments''': none

;*<tt>readable_closed</tt>
:''available since TDM 1.02''
:The player must close a named readable to satisfy this component. This doesn't check whether the player has finished reading all pages, just closing the previously opened readable is enough.
:'''SDK Name''': COMP_READABLE_CLOSED
:'''Number of Specificatons''': 1 (The name of the readable)
:'''Applicable Specifiers''': name
:'''Expected Arguments''': none

;*<tt>readable_page_reached</tt>
:''available since TDM 1.02''
:The player must open/read a specific page of a named readable to fulfil this component. Scrolling to the page is enough to trigger this event.
:'''SDK Name''': COMP_READABLE_PAGE_REACHED
:'''Number of Specificatons''': 1 (The name of the readable)
:'''Applicable Specifiers''': name
:'''Expected Arguments''': int (the page number which should be reached, the number 1 refers to the first page)

== Specifiers ==
;*<tt>none</tt>
:No specifier. Component will be completed as soon as any event of that component type happens. (E.g., if you set a KO component type, with specifier none, it would be set to true as soon as soon as the player KO's anyone). This is the default specifier if none is entered. Not very useful, except for blanket "don't do this" objectives. Even then, it is better to use "overall" described below.
:'''SDK Name''': SPEC_NONE
:'''Specifier Argument Type Expected''': No spec argument needed since we don't have to match anything.

;*<tt>name</tt>
:Name of the entity
:'''SDK Name''': SPEC_NAME
:'''Specifier Argument Type Expected''': string

;*<tt>overall</tt>
:In the context of inventory item objectives, this refers to overall loot. In the context of AI objectives, this refers to all AI, regardless of team, type, etc.
:'''SDK Name''': SPEC_OVERALL
:'''Specifier Argument Type Expected''': No spec argument needed since we don't have to match anything.

;*<tt>Group</tt>
:For inventory items, the item's <tt>inv_name</tt> spawnarg value will be used here. For example, if you want the player to get 5 flashbombs, you would use this with group equal to the <tt>inv_name</tt> of flashbombs. As opposed to getting a specific flashbomb in the map, where you would use the <tt>name</tt> specifier instead. If an inventory item is loot, the loot group is used here instead (e.g., <tt>loot_gold</tt>).
:Group is also used for other component types as a convenient way to group things, such as info_objective_location or info_location entities checked by COMP_LOCATION and COMP_INFO_LOCATION, respectively.
:'''SDK Name''': SPEC_GROUP
:'''Specifier Argument Type Expected''': string
:'''Loot group names:''' <tt>loot_gold</tt>, <tt>loot_goods</tt>, <tt>loot_jewels</tt> and <tt>loot_total</tt>

;*<tt>Classname</tt>
:The entityDef classname of the entity. For example: atdm:ai_builder_guard
:'''SDK Name''': SPEC_CLASSNAME
:'''Specifier Argument Type Expected''': string

;*<tt>Spawnclass</tt>
: The SDK classname of the entity. For example: idAI
:'''SDK Name''': SPEC_SPAWNCLASS
:'''Specifier Argument Type Expected''': string

;*<tt>ai_type</tt>
:Type of AI: human, beast, undead, steambot, etc. (reads m_AIType in the SDK, which is set by the "type" spawnarg on idActors. Not sure if this is implemented yet).
:'''SDK Name''': SPEC_AI_TYPE
:'''Specifier Argument Type Expected''': int

;*<tt>ai_team</tt>
:The AI's team integer. This can be set up by the mapper to put AI on arbitrary teams. Mapper can also team up AI for objective purposes, and use this team specifier as a fast way of saying "KO any of these 5 AI." Alternatively, one could use the name specifier and put in multiple components for each of those 5 AI, then OR all the components in the objective success logic. Making a new team may save time over that method.
:'''SDK Name''': SPEC_AI_TEAM
:'''Specifier Argument Type Expected''': int

;*<tt>ai_innocence</tt>
:Differentiates between combatants and non-combatants. A value of 1 = non-combatant, a value of 0 => non-combatant, or otherwise not deemed "innocent" by the FM author.
:'''SDK Name''': SPEC_AI_INNOCENCE
:'''Specifier Argument Type Expected''': int (1 = innocent, 0 = not)

= Objective Conditions =
With the campaign code added to TDM 1.06 a new set of spawnargs can be used to let objectives depend on those in a previous mission. These spawnargs are starting with the <tt>obj_condition</tt> prefix.

Each condition defines the "source" mission and the source objective by number, plus the state of the source objective. It also needs to specify the "target" objective (which is always in the current mission) by number and which action to take. Right now, three different actions are supported:
* Change Objective State (complete, failed, etc.)
* Change the Objective's Visibility (hide or show)
* Change the Objective's Mandatory Flag

== Syntax ==

*;<tt>obj_condition_N_src_mission</tt> (integer)
:Defines the source mission the condition depends on. The integer is 0-based, i.e. the first mission has the number 0. The placeholder N is the number of the condition.

*;<tt>obj_condition_N_src_obj</tt> (integer)
:Defines the number of the source objective in the source mission. The integer is 0-based, i.e. the first objective has the number 0. The placeholder N is the number of the condition.

*;<tt>obj_condition_N_src_state</tt> (integer)
:Defines the state the source objective needs to be in for this condition to apply. The value can be in the same range as the objN_state spawnarg above:
:* 0 = STATE_INCOMPLETE
:* 1 = STATE_COMPLETE
:* 2 = STATE_INVALID
:* 3 = STATE_FAILED

*;<tt>obj_condition_N_target_obj</tt> (integer)
:Defines the number of the target objective in the current mission. The integer is 0-based, i.e. the first objective has the number 0. The placeholder N is the number of the condition.

*;<tt>obj_condition_N_type</tt> (string)
:Defines the action to take if the condition applies. There are three possible action types available:
:* "changestate" Change the state of the target objective.
:* "changevisibility" Change the visibility of the target objective.
:* "changemandatory" Change the mandatory flag of the target objective.
:The combination of this "type" spawnarg and the "value" spawnarg below defines exactly what action is performed on the target objective.

*;<tt>obj_condition_N_value</tt> (integer)
:The meaning and possible values of this spawnarg depend on the "type" spawnarg above. It is used as "parameter" or "argument" for the above action, e.g. the "changevisibility" action needs to know whether to show or hide the target objective. The possible values are listed below:
:* For type "changestate"
:** 0: set to incomplete
:** 1: set to complete
:** 2: set to invalid
:** 3: set to failed
:* For type "changevisibility"
:** 0: set to invisible
:** 1: set to visible
:* For type "changemandatory"
:** 0: clear mandatory flag
:** 1: set mandatory flag

= Conclusion =
Using components that combine component types with up to 2 entity arguments and 2 specifier types, plus objectives that are a boolean combination of those components should hopefully allow for a variety of different objectives.

= Using Objectives Creatively =

'''A method for using objectives to change AI patrols when alert.'''

This works beautifully. The AI are placed at the seats just like in the card player prefab. Each player have "sitting 1" so they sit down at map start. AI's have no targets.

Then I have one unseen objective per player:
Objective component is only "AI is alerted", with the single entity card playing AI name. I can set the minimum alert level required for the AI to react. I set that to 3, so if the AI search actively, he won't be playing cards anymore, but goes patrolling instead.
Basically the objective component says: "Alert entity cardgamer1 1 times to a minimum alert level of 3."

And when that gets satisfied, the objective has completion target gopatrol_start, which is an ordinary trigger_once. This in turn targets a func_static which gives all the cardgamers new targets to their patrol routes.

This is done as follows: Choose any kind of func_static. Open it in the Stim&Response editor. Add response trigger. Add an effect to this response. Choose "Add Target." Put in the entity box the name of the AI. Put in the target box the name of the path_node where the AI should go.

When I make one objective for each player, alerting any single one of them will make everyone of them to go for patrol. And once the trigger_once is gone, further alerting of the AI has no effect.

[[Category:Editing]]
[[Category:Tutorial]]

AI Patrol

2011-01-23T10:58:48Z

Sotha:

== Introduction ==
This article describes the ways how the mapper can get his/her AI's to move around in their map. Regardless of which method you use, you should understand basic [[Pathfinding]]. Read that article first.

There are several methods of getting your AI to move around your map.
*Path_corners
*Conversations
*Scripting

=== Path_corners ===
The typical choice the mappers use path-corners. Using them is quite straight forward. Information how to set up path_corners is given here [[A - Z Beginner Full Guide Page 4]] and here [[Path Nodes]]

=== Conversations ===
Conversation entities can be used to move AI too. See information in the [[Conversation]] article. Note that in TDM v1.03 the AI returns to the original place it was before the conversation, when the conversation end. This means that you can make the AI walk around, but it will not stay there where you sent it when the conversation ends.

===Scripting===
Scripting is a powerful tool to control all kinds of things. AI movement can be also controlled with scripting.
====Example AI control====
*Place an AI in your map. Name it "ai".
*Place a path_corner in your map. Name it "destination".
*Place a atdm:target_callscriptfunction. Name it "call_ai_walk_script". Add spawnarg "call" "ai_walk_script"
*Place a switch in your map, which targets the above atdm:target_callscriptfunction.

*Create an ordinary textfile mymapname.script and place it in your /maps folder.
*Put the following info in the script file:

void ai_walk_script()
{
$ai.moveToEntity($destination);
}

When the player pulls the lever, the AI walks to the entity destination and stays there. You can add more levers which send the AI to different locations. Note: it was observed in TDM v1.03 that sometimes, if a script is called from a conversation, the AI will occasionally not move to the position even if the script is running. This can be fixed by adding a small delay in the beginning of the script (sys.wait(1);).

Mappers can also use $ai_name_here.moveToPosition("123,456,768"); and replace the coordinates where the AI should go. (Not tested.)

Other AI control commands exist, like $ai_name_here.turnToEntity(entityname);, which makes the AI to turn towards the specified entity.

AI Patrol

2011-01-23T09:09:29Z

Sotha:

== Introduction ==
Written by Sotha.

This article describes the ways how the mapper can get his/her AI's to move around in their map. Regardless of which method you use, you should understand basic [[Pathfinding]]. Read that article first.

There are several methods of getting your AI to move around your map.
*Path_corners
*Conversations
*Scripting

=== Path_corners ===
The typical choice the mappers use path-corners. Using them is quite straight forward. Information how to set up path_corners is given here [[A - Z Beginner Full Guide Page 4]] and here [[Path Nodes]]

=== Conversations ===
Conversation entities can be used to move AI too. See information in the [[Conversation]] article. Note that in TDM v1.03 the AI returns to the original place it was before the conversation, when the conversation end. This means that you can make the AI walk around, but it will not stay there where you sent it when the conversation ends.

===Scripting===
Scripting is a powerful tool to control all kinds of things. AI movement can be also controlled with scripting.
====Example AI control====
*Place an AI in your map. Name it "ai".
*Place a path_corner in your map. Name it "destination".
*Place a atdm:target_callscriptfunction. Name it "call_ai_walk_script". Add spawnarg "call" "ai_walk_script"
*Place a switch in your map, which targets the above atdm:target_callscriptfunction.

*Create an ordinary textfile mymapname.script and place it in your /maps folder.
*Put the following info in the script file:

void ai_walk_script()
{
$ai.moveToEntity($destination);
}

When the player pulls the lever, the AI walks to the entity destination and stays there. You can add more levers which send the AI to different locations. Note: it was observed in TDM v1.03 that sometimes, if a script is called from a conversation, the AI will occasionally not move to the position even if the script is running. This can be fixed by adding a small delay in the beginning of the script (sys.wait(1);).

Mappers can also use $ai_name_here.moveToPosition("123,456,768"); and replace the coordinates where the AI should go. (Not tested.)

Other AI control commands exist, like $ai_name_here.turnToEntity(entityname);, which makes the AI to turn towards the specified entity.