Task Types

DTS supports several types of tasks:

Fixed rate – The task duration is based on a production field (e.g. metres) and a production rate (5m/d)
Fixed duration – The task duration is specified by the planner, and the rate field is not editable
Cyclical – Similar to fixed rate the task duration is based on a production field, but the production rate is calculated from a series of recurring operations assigned to the task (e.g. drill, blast, load, drill, blast, load, ...). A cyclical task models more accurately how work is executed in some scenarios, e.g. development. A cyclical task can also be represented by a large number of smaller tasks (e.g. drill-1, blast-1, load-1, drill-2, blast-2, load-2, ...).
Hammock – The task spans the period between the latest predecessor and earliest successor. Hammocks are used mostly in very special cases. See below for an explanation.
Calculated Rate – Similar to a fixed rate task, but differs in that the rate is calculated based on a user-defined formula. Filters can be applied to create differing formulae. The rate and duration fields are not editable.
Calculated Duration – Similar to a fixed duration task, but differs in that the duration is calculated based on a user-defined formula in the Project Settings|Fields|Internal Fields section. Filters can be applied to create differing formulae. The rate and duration fields are not editable.
Milestone – Tasks can be specified by setting the duration of any fixed rate / duration task to zero.

You can also control the timing of tasks with the constraint type:

As soon as possible – The task can start after the latest of all its predecessor constraints. This is the most common constraint type for tasks.
As late as possible – The task is scheduled to start as late as possible without delaying any of its successors. ALAP tasks will use up all of their free float.
Must start on – The start date of the task is fixed regardless of the times of its predecessors. It requires a constraint date to be set. This option should be used sparingly.
Must finish on – The finish date of the task is fixed regardless of the times of its predecessors or its duration. It requires a constraint date to be set. This option should be used sparingly.
Start no earlier than – The task can start after its latest predecessor as well as the specified constraint date. This is not a hard constraint and the task start can be pushed past the constraint date.
Finish no earlier than – The task finish time is scheduled from its predecessor and duration. If the scheduled finish date is before the constraint date the task is delayed until the finish date is on or past the specified constraint date. This is not a hard constraint and the task finish can be pushed past the constraint date.
Start no later than – The task is treated as ASAP except that as soon as the start date calculated from its predecessors exceeds the constraint date, it is treated as a Must start on task.
Finish no later than – The task is treated as ASAP except that as soon as the finish date calculated from its predecessors and duration exceeds the constraint date, it is treated as a Must finish on task.

Hammock Tasks

Hammock tasks are useful if you need tasks that span between predecessors and successors, but the results can be unexpected, depending on the type of dependency used and if there is indeed a predecessor or successor. Here are a few scenarios to explain this.

This is a typical scenario where a hammock task is linked between 2 other tasks, and it spans this gap. If task 4 is delayed, then the duration of the hammock task is increased to span this gap.

In this scenario there is a start-start constraint between the hammock task and task 3. Consequently the hammock task does not have a successor per se, and its end date stretches to the end of the schedule, which in this case is dicated by task 4.

This scenario is similar to the previous one in that there is a start-start dependency between the hammock task and task 3. The difference is that there is a summary task involved. However, as in the previous case, the hammock task will span to the end of the schedule, and not to the end of the summary bar as may be expected in this simple case. This causes the summary task's effective duration to change as well.

In order to avoid the hammock task from affecting the duration of the summary, it would need to be linked between 2 tasks as shown above.