The name of the response table. This is needed at the end of the rule for the response table to be used.


The scenes used in the particular response table. Many things can be added here along with a particular scene to generate unique responses and even other features of the talker.

Having scenes in this table isn't enough. To string a conversation together, you would need to target an entity to speak the next concept. The valid entities are the following:


- Coach (Coach)
- Gambler (Nick)
- Mechanic (Ellis)
- Producer (Rochelle)
- Biker (Francis)
- Manager (Louis)
- NamVet (Bill)
- TeenGirl (Zoey)
- Any (Any survivor that has a rule/response with the matching concept criteria)
- All (All survivors that had a rule/response with the matching concept criteria)
- Self (The same survivor who is speaking the current response)
- From (The survivor who spoke the previous response in a conversation. For example... If Bill speaks first, and the prompt forces Francis to speak next with From as the next speaker, then from will be Bill who has to speak next if the rule has the appropriate concept)
- Any func_orator entity's targetname (orator, orator_chopper, churchguy, etc)


The concept name you would like to use in your follow-up talker rule. They are one of the two key things that are always a requirement for the response to work. Concepts can be triggered either by the talker script as shown in this example, or they can be fired via entity I/O which will be explained later along with defining the concept in the main talker script.



The context that you would like to apply to the specific entity that fires the specific response. This is almost never used because there is another way that one can apply contexts in the same manner when the talker rule is invoked.


Last thing: Is a timer of when you want the next response for the scene to fire. This can be set as a negative or a positive number.

If the timer is negative, then the response will happen X seconds after the rule is invoked (this includes if the scene is equipped with any pre-delays.

If the timer is positive, then the next response will happen X seconds after that particular scene finishes. Timing is everything when you want a conversation to feel natural.

To get the most information, a different rule will be used as an example.






The name of the rule. It is important to use unique names for every rule to avoid the talker from accidentally issuing the wrong response.



The list of criterion that is needed for the response to fire. *ALL CRITERIA HAS TO BE MET* If even a single one fails, then the response won't fire.

This is the key thing to make a response activate under the context you want. There are plenty of contextual criterions that one can use (But not all may be compatible).

The absolute two criteria types that you need in a rule at all times are "Concept" and "Who".

- Concept is typically what is needed via entity i/o or talker script prompts to fire the next response.
- Who is who the survivor that is speaking is.

More detailed explanations will be given in the Criterion section.


You can optionally apply any amount of contexts here. Some rules may require that a specific context is applied so that the rule will not fire again.

You can separate contexts with a comma between each one.

The context name and the additional values have to be separated by colons.

Typically, they consist of the following:

- The name of the context you wish to apply
- The value of the context name
- The timer (in seconds) to make a context last a certain time. (0 is indefinite)

You can also apply a contextual value as a counter instead of applying a certain value. Instead of the context value and timer, you can simply apply the counter value as follows:

(X meaning the value).

This particular method does not require a timer and is thus applied indefinitely.

Notably, you can also choose to apply the context to the world or to the specific entity that fires the response.

To apply it to the world: Add "applycontexttoworld" below the "ApplyContext" line.

To apply it to the speaking entity: Do not add "applycontexttoworld"


Lastly, this is the response that the rule executes when the criteria is met and the concept is called for. it selects one scene at random from that response table.

- Do NOT require the "Who" criteria.
- Often utilize entity I/O to make the activating survivor say something.

Valid Targets + Compatible parameter(s):

* !Activator and !Caller are also valid targets when trying to target the specific survivor that activated an input

It is set up as follows:


Edit: I have just found that "!Activator", "!Caller", and "!<Survivor name>" are also valid targets.

** !Caller is also a valid target

Valid Traits:

Scenes with this are only used once in a particular response per chapter. (Currently non-functional)


Scenes in a response table with this have that % chance of playing. This is used to make a particular scene in the same response rarer than others.


Scenes with this will not play until a delay of X seconds has passed. You can designate a minimum and maximum time using two values as the example, or you can use a single value for a non-random delay.


One of my personal favorite functionalities. This will trigger an in-map logic_relay entity with the matching targetname after a set timer (In seconds). Unlike the timer mentioned in the first part of this guide, this timer will only accept a positive value. And it starts once the rule/concept has been invoked.




The inputs are:


The quotes for "scene" designate the file path the scene you want to play is located - down to the .vcd, they are typically located in the "left4dead2", "..._dlc1", "..._dlc2", "..._dlc3", and "update" directories.


The quotes for "speak" designate the sound you want to have played without using scene files. They can be found in the appropriate soundscript(s). But it is impossible to have anyone respond to it using "then _"


The quotes for "print" typically designates what gets printed in the console for debugging purposes. But it serves better as a blank response for all entities. As an added bonus, it also doesn't interrupt the survivor's current scene/speech. So this is ideal for silently applying contexts.)


They are:

*
Scenes in a response with this will not repeat. Similar to speakonce, but this is for all scenes. Once all scenes in the response have been used, then they won't be fired in that manner again until the next chapter.

*
Scenes in a response with this will play in top-to-bottom order. There is still a bug where the order resets to the top scene, but it will only play the top scene.



* Sequential and Norepeat can go together.

There can be criterion that uses a string value such as "concept" and "who":


Or even criterion that use numeric values:

**

*


Greater than or equal to X

Greater than X

Less than or equal to X

Less than X

***
Any value other than X


The rule with the greatest combined weight value will be the one that fires. Additionally, you can also assign a specific weight value to a certain rule just before the "Response" line and after the applycontext/applycontexttoworld line.



This is primarily used for Dead Center - Chapter 1 and Chapter 2 for SI callouts.

This Criterion is set up like so:

Notes:

* Certain criteria such as "movementspeed" is tracked individually per survivor.

** Contextual criteria such as this are those that are only applied to the entity that fires the rule/response. Contexts applied to the world will have "world" before its actual name.

*** This is also compatible with string value based criterion, great for "map", etc.

To do this, you would need to change the response issued by all survivor rules that always enable the saferoom intros.

Like this example:



Next, you need to create a response table that fires a specific logic_relay entity in the map. In my addon, I use this single response table from the terror_player.txt script:


The logic_relay entity itself typically deletes any logic_choreographed_scene entity and ambient_generic entity responsible for survivor voicelines. This essentially paves the way for the talker to act like a replacement/accessory for the custom campaign. Whether it be creating custom intros or using custom concepts (as long as they are defined).

It is highly recommend NOT to equip this logic_relay entity to any in-map input. It is only meant to be triggered by the talker scripts so that talker addons can act as an accessory while it is active.