Objectives - Revision history

Datiswous: /* Mission */

2024-04-25T21:38:32Z

Mission

← Older revision		Revision as of 21:38, 25 April 2024
Line 7:		Line 7:

	= Mission =		= 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.		Objectives are stored by entities named ''atdm_target_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.		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.

Geep: /* Non-AI Components */ Change 'OR them together' to 'AND them together'

2020-10-07T15:27:49Z

Non-AI Components: Change 'OR them together' to 'AND them together'

← Older revision		Revision as of 15:27, 7 October 2020
Line 211:		Line 211:

	;*<tt>location</tt> Object in location brush (using info_tdm_objective_location brush)		;*<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.		:A particular item must be in a particular location, defined by an info_tdm_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 AND them together in the objective logic.
	:'''SDK Name''': COMP_LOCATION		:'''SDK Name''': COMP_LOCATION
	:'''Number of Specificatons''': 2 (object entity to check, location entity to check)		:'''Number of Specificatons''': 2 (object entity to check, location entity to check)
Line 218:		Line 218:

	;*<tt>info_location</tt> Object in location area (using info_location entities)		;*<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.		: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 AND 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.		:This check is done periodically. Set spawnarg <tt>clock_interval</tt> to the time in seconds between periodic checks.
	:'''SDK Name''': COMP_INFO_LOCATION		:'''SDK Name''': COMP_INFO_LOCATION

SteveL: /* Notes on using INVALID status */ typos

2015-11-23T17:46:23Z

Notes on using INVALID status: typos

← Older revision		Revision as of 17:46, 23 November 2015
Line 458:		Line 458:
	Note that:		Note that:
	* The mission and any dependent objectives can still be completed, whether or not the invalid objective has been completed.		* The mission and any dependent objectives can still be completed, whether or not the invalid objective has been completed.
	* Players can still complete individual components of your invalid objective. This can cause unexpected behaviour. If the player completes all of the components of an invalid objective and then you set the objective to "incomplete" status, the objective will be marked completed, but not ~~eright asway~~: it'll be marked complete the next time any ''other'' objective gets an update. That's because any objective getting an update causes all objectives to be re-tested for completeness.		* Players can still complete individual components of your invalid objective. This can cause unexpected behaviour. If the player completes all of the components of an invalid objective and then you set the objective to "incomplete" status, the objective will be marked completed, but not right away: it'll be marked complete the next time any ''other'' objective gets an update. That's because any objective getting an update causes all objectives to be re-tested for completeness.

	If you need to avoid the second scenario, you can use a target_setobjective_component_state to uncheck the components when you re-enable the objective.		If you need to avoid the second scenario, you can use a target_setobjective_component_state to uncheck the components when you re-enable the objective.

Grayman at 17:53, 30 October 2015

2015-10-30T17:53:10Z

← Older revision		Revision as of 17:53, 30 October 2015
Line 246:		Line 246:
	:'''Number of Specificatons''': none (see arguments below)		:'''Number of Specificatons''': none (see arguments below)
	:'''Applicable Specifiers''': none		:'''Applicable Specifiers''': none
	:'''Expected Arguments''': string (name of first entity), string (name of second entity), int (maximum distance in doom units)		:'''Expected Arguments''': string (name of first entity), string (name of second entity), int (maximum distance in doom units). If one of the entities is the player, use the string 'player1'.

	;*<tt>readable_opened</tt>		;*<tt>readable_opened</tt>

SteveL: + Notes on using INVALID status

2015-10-08T21:20:13Z

+ Notes on using INVALID status

@@ Line 443: / Line 443: @@
 You would just need to add one variable/if statement for each AI to be affected and run it from the start of the level (i.e. in the void main just have a line that says "thread checkHarm()"). The "FailHarmObjective" is an actual entity in the map which would then fail the relevant objective.
 [[Category:Editing]]
 [[Category:Tutorial]]

RJFerret: /* Using Objectives Creatively */ +harm script

2014-03-12T14:56:01Z

Using Objectives Creatively: +harm script

@@ Line 419: / Line 419: @@
 Note: It's important for the marker objective numbers in the objective editor not to change, or update the non visible completion objective AND logic accordingly.
 [[Category:Editing]]
 [[Category:Tutorial]]

RJFerret: /* Using Objectives Creatively */ +multiple marked areas example

2014-03-07T02:44:12Z

Using Objectives Creatively: +multiple marked areas example

@@ Line 394: / Line 394: @@
 So when the initial AI is knocked out or killed, the objective failure triggers the relay.  It in turns increments the counts and resets the objective to work again.  The first count activates the teleport and triggers the AI to move off it's path_waitfortrigger on to the next path node.  Test and voilà!
 [[Category:Editing]]
 [[Category:Tutorial]]

RJFerret: /* Objectives */ wikilink Triggers & fixed _relay redlink

2014-03-03T04:15:18Z

Objectives: wikilink Triggers & fixed _relay redlink

← Older revision		Revision as of 04:15, 3 March 2014
Line 78:		Line 78:
	*;<tt>objN_target_complete</tt> (string)		*;<tt>objN_target_complete</tt> (string)
	*;<tt>objN_target_failed</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.		:Name of a target entity to [[Triggers\|trigger]] 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 [[Triggers#trigger_relay\|trigger_relay]] entity.

	*;<tt>objN_logic_success</tt> (string)		*;<tt>objN_logic_success</tt> (string)

RJFerret: /* A way to replace AI when others are knocked out or killed. */ +obj_state

2014-02-12T03:14:39Z

A way to replace AI when others are knocked out or killed.: +obj_state

← Older revision		Revision as of 03:14, 12 February 2014
Line 390:		Line 390:
	Have spare AIs isolated in an inaccessible place either of your map, or room off in the void, targeting a path_waitfortrigger which then carries on their path. Have the AI subject to substitution on a unique team in your map (or identify another way), as well as the spare AIs. An objective is set up like the usual fail if you knock out or kill an AI, but not visible, set to the appropriate team. I found I needed multiple Objective Components, the first no knock/no kill set to an amount of one. Then two and three, etc. Take note of what objective number the objective is and plan on not altering that. Set the failure target to a trigger relay, which targets as many trigger_counts as you have replacement AI. That's it for setting up the objective part.		Have spare AIs isolated in an inaccessible place either of your map, or room off in the void, targeting a path_waitfortrigger which then carries on their path. Have the AI subject to substitution on a unique team in your map (or identify another way), as well as the spare AIs. An objective is set up like the usual fail if you knock out or kill an AI, but not visible, set to the appropriate team. I found I needed multiple Objective Components, the first no knock/no kill set to an amount of one. Then two and three, etc. Take note of what objective number the objective is and plan on not altering that. Set the failure target to a trigger relay, which targets as many trigger_counts as you have replacement AI. That's it for setting up the objective part.

	Add the aforementioned trigger relay, trigger_counts, and a target_setobjective_state. Setup the target_setobjective_state with Obj_id0 #, where # is the objective number. Add a matching number of atdm:teleport (in target/) as trigger_counts, each teleport targeting one of the stored AI. The first trigger_count is set to 1, and targets the first teleport and AI (to release it from the path_waitfortrigger). The second trigger_count is set to 2, and targets the next teleport and AI, etc. The trigger_relay targets all the trigger_counts and the target_setobjective_state.		Add the aforementioned trigger relay, trigger_counts, and a target_setobjective_state. Setup the target_setobjective_state with "Obj_id0" #, where # is the objective number noted earlier, and set "obj_state" to "0". Add a matching number of atdm:teleport (in target/) as trigger_counts, each teleport targeting one of the stored AI. The first trigger_count is set to 1, and targets the first teleport and AI (to release it from the path_waitfortrigger). The second trigger_count is set to 2, and targets the next teleport and AI, etc. The trigger_relay targets all the trigger_counts and the target_setobjective_state.

	So when the initial AI is knocked out or killed, the objective failure triggers the relay. It in turns increments the counts and resets the objective to work again. The first count activates the teleport and triggers the AI to move off it's path_waitfortrigger on to the next path node. Test and voilà!		So when the initial AI is knocked out or killed, the objective failure triggers the relay. It in turns increments the counts and resets the objective to work again. The first count activates the teleport and triggers the AI to move off it's path_waitfortrigger on to the next path node. Test and voilà!

RJFerret: /* A way to replace AI when others are knocked out or killed. */ +team specifier

2014-02-12T03:02:37Z

A way to replace AI when others are knocked out or killed.: +team specifier

← Older revision		Revision as of 03:02, 12 February 2014
Line 388:		Line 388:
	==A way to replace AI when others are knocked out or killed.==		==A way to replace AI when others are knocked out or killed.==

	Have spare AIs isolated in an inaccessible place either of your map, or room off in the void, targeting a path_waitfortrigger which then carries on their path. An objective is set up like the usual fail if you knock out or kill an AI, but not visible. I found I needed multiple Objective Components, the first no knock/no kill set to an amount of one. Then two and three, etc. Take note of what objective number the objective is and plan on not altering that. Set the failure target to a trigger relay, which targets as many trigger_counts as you have replacement AI. That's it for setting up the objective part.		Have spare AIs isolated in an inaccessible place either of your map, or room off in the void, targeting a path_waitfortrigger which then carries on their path. Have the AI subject to substitution on a unique team in your map (or identify another way), as well as the spare AIs. An objective is set up like the usual fail if you knock out or kill an AI, but not visible, set to the appropriate team. I found I needed multiple Objective Components, the first no knock/no kill set to an amount of one. Then two and three, etc. Take note of what objective number the objective is and plan on not altering that. Set the failure target to a trigger relay, which targets as many trigger_counts as you have replacement AI. That's it for setting up the objective part.

	Add the aforementioned trigger relay, trigger_counts, and a target_setobjective_state. Setup the target_setobjective_state with Obj_id0 #, where # is the objective number. Add a matching number of atdm:teleport (in target/) as trigger_counts, each teleport targeting one of the stored AI. The first trigger_count is set to 1, and targets the first teleport and AI (to release it from the path_waitfortrigger). The second trigger_count is set to 2, and targets the next teleport and AI, etc. The trigger_relay targets all the trigger_counts and the target_setobjective_state.		Add the aforementioned trigger relay, trigger_counts, and a target_setobjective_state. Setup the target_setobjective_state with Obj_id0 #, where # is the objective number. Add a matching number of atdm:teleport (in target/) as trigger_counts, each teleport targeting one of the stored AI. The first trigger_count is set to 1, and targets the first teleport and AI (to release it from the path_waitfortrigger). The second trigger_count is set to 2, and targets the next teleport and AI, etc. The trigger_relay targets all the trigger_counts and the target_setobjective_state.