Combined light entities - Revision history

Frost Salamander: /* Modifying the attached entity/entities */

2023-11-11T16:45:41Z

Modifying the attached entity/entities

← Older revision		Revision as of 16:45, 11 November 2023
Line 204:		Line 204:

	All the other spawnargs have already the right value and can thus be left alone.		All the other spawnargs have already the right value and can thus be left alone.

			== Troubleshooting ==

			=== My light extinguishes on map start ===
			First, ensure that the 'extinguished' spawnarg isn't set to '1'. If it's not that, the cause might be that the light is surrounded by a set of merged water entities and below the water line. In this case, the engine thinks the light is submerged and extinguishes it. A bug report has been raised [https://bugs.thedarkmod.com/view.php?id=6334 here]. As a workaround, ensure all surrounding water entities aren't merged together.

	{{lighting}} {{editing}}		{{lighting}} {{editing}}

Thebigh: /* Introduction */ typo

2021-06-13T20:35:05Z

Introduction: typo

← Older revision		Revision as of 20:35, 13 June 2021
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	Many complex objects in game are ~~build~~ from more than one entity. Others consist of only one entity, but represent different things at the same time.		Many complex objects in game are built from more than one entity. Others consist of only one entity, but represent different things at the same time.

	For instance, a candle consists of two entity: the candle stub, and an attached flame object.		For instance, a candle consists of two entity: the candle stub, and an attached flame object.

SteveL: /* Targeting the (invisible) entity */ Marking this as a 2.03 thing

2014-07-06T18:24:02Z

Targeting the (invisible) entity: Marking this as a 2.03 thing

← Older revision		Revision as of 18:24, 6 July 2014
Line 83:		Line 83:

	=== Targeting the (invisible) entity ===		=== Targeting the (invisible) entity ===
			:''This will work from 2.03 onwards. It doesn't work in 2.02.''
	Simple target the base entity, like the holder or the candle. When triggered, these know how to extingusish or light all attached flames (even tho they don't exist at map load). The holder will then rely the signal to any targeted (either by the holder or by the flames) entities.		Simple target the base entity, like the holder or the candle. When triggered, these know how to extingusish or light all attached flames (even tho they don't exist at map load). The holder will then rely the signal to any targeted (either by the holder or by the flames) entities.

Tels: add note about attachment names

2012-01-08T10:01:49Z

add note about attachment names

← Older revision		Revision as of 10:01, 8 January 2012
Line 169:		Line 169:

	The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.		The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.

			{{infobox\|'''Tip:''' While finding the attachment name can be a bit of a hassle, usually the name is "flame" for anything that has a flame like candles or torches, or "light" for electrical lights. If there are more than one, try "flame1", "flame2" etc.}}

	=== noshadows_lit ===		=== noshadows_lit ===

Fidcal: /* Setting spawnargs */

2011-06-08T13:04:30Z

Setting spawnargs

← Older revision		Revision as of 13:04, 8 June 2011
Line 166:		Line 166:
	</pre>		</pre>

	In DR, enter the spawnarg name and value without the quotes. The above setting will set the spawnarg '_color' on any entity attached that has the attachement name '~~light~~' to "0.2 0.2 09", thus coloring the light blue.		In DR, enter the spawnarg name and value without the quotes. The above setting will set the spawnarg '_color' on any entity attached that has the attachement name 'flame' to "0.2 0.2 09", thus coloring the light blue.

	The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.		The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.

Tels: add noshadows_lit

2011-02-22T06:22:42Z

add noshadows_lit

← Older revision		Revision as of 06:22, 22 February 2011
Line 169:		Line 169:

	The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.		The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.

			=== noshadows_lit ===

			All entities that use the "tdm_light_holder" [[script object]] can use the following combination of spawnargs:

			For starting lit entities:

			"noshadows_lit" "1"
			"noshadows" "1"
			"extinguished" "0"

			and for starting as unlit entites:

			"noshadows_lit" "1"
			"noshadows" "0"
			"extinguished" "1"

			This makes the entity only cast a shadow when the light is off, the switch is done by the light holder script object. This has the effect that when the player turns on the light, or lights the torch/candle, that the model itself does not cast a shadow, preventing it from casting ugly shadows from its own light. However, if the light is off, then other light sources still cast a shadow from the candle holder. This is a compromise between having no shadows or shadows all the time and looks a lot better than just setting "noshadows" to "1" all the time.


	=== Changing attached entities ===		=== Changing attached entities ===

Tels: fix typo

2010-07-04T10:56:06Z

fix typo

← Older revision		Revision as of 10:56, 4 July 2010
Line 103:		Line 103:

	<pre>		<pre>
	entity my_holder = sys.~~findEntity~~("Name_of_the_light_holder");		entity my_holder = sys.getEntity("Name_of_the_light_holder");
	my_holder.LightsOn();		my_holder.LightsOn();
	sys.wait(500);		sys.wait(500);

Tels: put into editing, too

2010-01-03T14:09:21Z

put into editing, too

← Older revision		Revision as of 14:09, 3 January 2010
Line 184:		Line 184:
	All the other spawnargs have already the right value and can thus be left alone.		All the other spawnargs have already the right value and can thus be left alone.

	{{lighting}}		{{lighting}} {{editing}}

Tels: add info

2010-01-03T14:03:28Z

add info

← Older revision		Revision as of 14:03, 3 January 2010
Line 181:		Line 181:
	"def_attach" "light_torchflame_green" // note: the green torch only exists from TDM 1.01 on		"def_attach" "light_torchflame_green" // note: the green torch only exists from TDM 1.01 on
	</pre>		</pre>

			All the other spawnargs have already the right value and can thus be left alone.

	{{lighting}}		{{lighting}}

Tels: expand info

2010-01-03T14:02:28Z

expand info

← Older revision		Revision as of 14:02, 3 January 2010
Line 14:		Line 14:

	* the entityDef (inside a .def file) can specify to spawn and attach a new entity when the first entity is spawned. This typical happens at map loading time, but can also happen later in game when a new base entity is spawned. This is from here one called "def_attached" due to the spawnarg being responsible: [[def_attach]].		* the entityDef (inside a .def file) can specify to spawn and attach a new entity when the first entity is spawned. This typical happens at map loading time, but can also happen later in game when a new base entity is spawned. This is from here one called "def_attached" due to the spawnarg being responsible: [[def_attach]].
	* the mapper can manually add both entities in the map, and then arrange them in the editor so they look bound together. We refer to ~~this~~ from here on as "the manual way".		* the mapper can manually add both entities in the map, and then arrange them in the editor so they look bound together. Additionally, one can use the "bind" or "bindToJoint" spawnargs to make f.i. a key bound to a moving AI. We refer to these ways from here on as "the manual way".

	The ~~second~~ way has several disadvantages but also advantages:		The manual way has several disadvantages but also advantages:

	'''Disadvantages:'''		'''Disadvantages:'''
Line 30:		Line 30:
	# Since the attached entity is already in the editor, its name is known, so it can be easily targeted by scripts and have spawnargs set on it. This is the main disadvantage of def_attaching entities and we see later how we can overcome it.		# Since the attached entity is already in the editor, its name is known, so it can be easily targeted by scripts and have spawnargs set on it. This is the main disadvantage of def_attaching entities and we see later how we can overcome it.

	This article~~, however~~, deals primarily with the ~~first way~~.		This article, deals primarily with the def_attach method.

	== Example entities ==		== Example entities ==
Line 77:		Line 77:

	But since the candle flame does not exist yet, you can't. Here is how you can overcome this:		But since the candle flame does not exist yet, you can't. Here is how you can overcome this:

			=== Linking from the holder entity ===

			If you want, for instance, a second light to go on/off, or a door to open when a candle is extinguished, simply select the candle holder, and the second entity and press {{key\|CTRL}} + {{key\|K}} to link them. The holder will rely on/off signals from itself to the linked entity when the flames are extinguished or relit.

	=== Targeting the (invisible) entity ===		=== Targeting the (invisible) entity ===

	Simple target the base entity, like the holder or the candle. When triggered, these know how to extingusish or light all attached flames (even tho they don't exist at map load).		Simple target the base entity, like the holder or the candle. When triggered, these know how to extingusish or light all attached flames (even tho they don't exist at map load). The holder will then rely the signal to any targeted (either by the holder or by the flames) entities.

	~~'''Note: sombody please test that that actually works!'''~~

	=== Turning lights off/on ===		=== Turning lights off/on ===
Line 143:		Line 145:
	frob_light_holder_light( holder );		frob_light_holder_light( holder );
	}		}
			// better, shorter and more clean, object-oriented way:
			if (holder) { holder.LightsOff(); }
	}		}
	</pre>		</pre>
Line 165:		Line 169:

	The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.		The '''ATTACHMENTNAME''' is defined as '''name_attach''' spawnarg on either the base entity or one of its attached entities.

			=== Changing attached entities ===

			Sometimes you want to change the actual attached entity for another variant, but the specific combination does either not exist yet, or you have made a new entity that you want to attach instead.

			Now you could create the combination entity from scratch, but that can be cumbersome and error prone. Instead, just swap the attached entity.

			Here is how you take a normal combined walltorch+flame and swap the flame for a green variant: Just override the spawnarg "def_attach" with your own version:

			<pre>
			"def_attach" "light_torchflame_green" // note: the green torch only exists from TDM 1.01 on
			</pre>

	{{lighting}}		{{lighting}}