Location Settings - Revision history

Thebigh: /* "ambient_light_dist_scale" */ -typo

2023-10-07T00:08:27Z

"ambient_light_dist_scale": -typo

← Older revision		Revision as of 00:08, 7 October 2023
Line 308:		Line 308:
	==== "ambient_light_dist_scale" ====		==== "ambient_light_dist_scale" ====

	A factor to scale the distance before applying a dynamic light falloff. Only used then '''ambient_light_dynamic_falloff''' is not 0. Good ~~valuesa~~ are around 1.0.		A factor to scale the distance before applying a dynamic light falloff. Only used then '''ambient_light_dynamic_falloff''' is not 0. Good values are around 1.0.

	See also the article about [[Dynamic ambient light]].		See also the article about [[Dynamic ambient light]].

Geep: /* See also */ Add additional link

2021-04-30T15:38:58Z

Geep: /* See also */ Debugging a location overlap

2021-04-20T16:12:40Z

Stgatilov: proofread

2021-04-20T01:36:38Z

proofread

← Older revision		Revision as of 01:36, 20 April 2021
Line 130:		Line 130:
	Here are special considerations when placing an info_locationseparator:		Here are special considerations when placing an info_locationseparator:

	* Avoid any visportal that is subdivided by worldspawn. If you really need to separate zones there, break the visportal up into separate ~~entities~~. (Details about this problem and how it affects warnings are below.)		* Avoid any visportal that is subdivided by worldspawn. If you really need to separate zones there, break the visportal up into separate brushes. (Details about this problem and how it affects warnings are below.)
	* It is really the ''axis-aligned bounding box'' of the visportal that is interrogated for touching an info_locationseparator. This can lead to problems in the vicinity of a large, non-axis-aligned portal: some other location separator can be assigned to this visportal, even though you can clearly see in DR that they don't contact.		* It is really the ''axis-aligned bounding box'' of the visportal that is interrogated for touching an info_locationseparator. This can lead to problems in the vicinity of a large, non-axis-aligned portal: some other location separator can be assigned to this visportal, even though you can clearly see in DR that they don't contact.

Line 143:		Line 143:
	WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112		WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112

	This occurs when a separator is applied to a visportal brush that is internally turned into multiple visportals with the same rectangle (or perimeter) and same origin. It happens when opaque geometry splits the visportal face into connected components (two ~~in the~~ example), and these components separate different pairs of visleafs/areas. Note that you cannot reliably detect such situations with console command "r_showPortals 1".		This occurs when a separator is applied to a visportal brush that is internally turned into multiple visportals with the same rectangle (or perimeter) and same origin. It happens when opaque geometry splits the visportal face into connected components (two for example), and these components separate different pairs of visleafs/areas. Note that you cannot reliably detect such situations with console command "r_showPortals 1".

	=== info_location ===		=== info_location ===

Geep: /* info_location */ Add section on Debugging

2021-04-20T01:10:12Z

info_location: Add section on Debugging

← Older revision		Revision as of 01:10, 20 April 2021
Line 124:		Line 124:
	'''{{RMB}} -> Create entity -> Darkmod -> Info -> info_locationseparator'''		'''{{RMB}} -> Create entity -> Darkmod -> Info -> info_locationseparator'''

	If you don't touch a portal with this entity, ~~than~~ it will not register in the game as the boundary to a new zone, and the zone will continue into the area on the other side of the portal. ~~This happens even if you have a second info_location (described below) on the other side (the game will just pick one and use that for the whole zone).~~ This can be a good thing because, say you have a mansion with 30 portals inside. You can cover the whole area inside it by just marking the 2 or 3 portals leading into the mansion area through the doors and open windows, and everything inside that marked area will be counted as one location (just don't miss marking an exit, or have an un-portaled gap to the outside between brushes, or the location will leak outside. It has to be hermetically sealed).		If you don't touch a portal with this entity, then it will not register in the game as the boundary to a new zone, and the zone will continue into the area on the other side of the portal. This can be a good thing because, say you have a mansion with 30 portals inside. You can cover the whole area inside it with one info_location entity, by just marking the 2 or 3 portals leading into the mansion area through the doors and open windows, and everything inside that marked area will be counted as one location (just don't miss marking an exit, or have an un-portaled gap to the outside between brushes, or the location will leak outside. It has to be hermetically sealed).

	To re-iterate, a portal must include an info_locationseparator to mark a location boundary. (It may have been the case that in Doom, a portal merely touched by a door could mark such a boundary, as indicated by early discussions and entityDef comments. This is not true for TDM.)		To re-iterate, a portal must include an info_locationseparator to mark a location boundary. (It may have been the case that in Doom, a portal merely touched by a door could mark such a boundary, as indicated by early discussions and entityDef comments. This is not true for TDM.)
Line 143:		Line 143:
	WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112		WARNING:Separator locationsep_on_double_portal covers both portal 203 at 4 -380 -112 and portal 203 at 4 -380 -112

	This occurs when a separator is applied to a visportal brush that is internally turned into multiple visportals with the same rectangle (or perimeter). It happens when opaque geometry splits the visportal face into connected components (two in the example), and these components separate different pairs of visleafs/areas. Note that you cannot reliably detect such situations with console command "r_showPortals 1".		This occurs when a separator is applied to a visportal brush that is internally turned into multiple visportals with the same rectangle (or perimeter) and same origin. It happens when opaque geometry splits the visportal face into connected components (two in the example), and these components separate different pairs of visleafs/areas. Note that you cannot reliably detect such situations with console command "r_showPortals 1".

	=== info_location ===		=== info_location ===
Line 152:		Line 152:

	Anywhere in the space of the zone is fine. Name it the name of the zone you want (to make it easy to find when you push {{key\|J}}).		Anywhere in the space of the zone is fine. Name it the name of the zone you want (to make it easy to find when you push {{key\|J}}).

			==== Debugging Info_Location Overlaps ====

			If there is more than one info_location in a given zone, there is an overlap. In that case, the game will just pick one and use that for the whole zone; the other will be ignored. This is not ideal.

			At game startup, any such overlap is reported to the console as a warning. The underlying cause may be obvious, but not always. To help with this diagnosis, starting with TDM '''2.10''', a pointfile is generated that runs between the two info_location objects involved in the overlap, via a path within the overlap zone. The filename will be of form:

			pointfile_<info_location_name1>_overlaps_<info_location_name2>.lin

			As with other types of pointfiles, this appears in your FM’s /map/ folder, and should be renamed temporarily to “<FM>.lin” when you want to load it for examination it in DR.

	== Settings per location/zone ==		== Settings per location/zone ==

Geep: /* info_locationseparator */ 2.10 new warning messages, better understanding of error causes

2021-04-19T22:24:55Z

info_locationseparator: 2.10 new warning messages, better understanding of error causes

@@ Line 126: / Line 126: @@
 If you don't touch a portal with this entity, than it will not register in the game as the boundary to a new zone, and the zone will continue into the area on the other side of the portal.  This happens even if you have a second info_location (described below) on the other side (the game will just pick one and use that for the whole zone).  This can be a good thing because, say you have a mansion with 30 portals inside.  You can cover the whole area inside it by just marking the 2 or 3 portals leading into the mansion area through the doors and open windows, and everything inside that marked area will be counted as one location (just don't miss marking an exit, or have an un-portaled gap to the outside between brushes, or the location will leak outside.  It has to be hermetically sealed).
-I have read discussion that a door touching a portal marks it as a location boundary, but in my experiments the door did not create a new location and I still had to use a info_locationseparator over the portal to register it as a boundary.
+To re-iterate, a portal must include an info_locationseparator to mark a location boundary. (It may have been the case that in Doom, a portal merely touched by a door could mark such a boundary, as indicated by early discussions and entityDef comments. This is not true for TDM.)
 === info_location ===

Geep: /* Example script to turn entities on/off when player enters a location */

2021-01-05T04:00:46Z

Example script to turn entities on/off when player enters a location

← Older revision		Revision as of 04:00, 5 January 2021
Line 353:		Line 353:
	*yourscript is the name of your script you call. Its parameter 'zone' has the location entity that called it, either:		*yourscript is the name of your script you call. Its parameter 'zone' has the location entity that called it, either:
	** the location you're entering, when yourscript() is called via a call_on_entry; or		** the location you're entering, when yourscript() is called via a call_on_entry; or
	** the location you're leaving, when ~~yoursecript~~() is called via call_on_exit.		** the location you're leaving, when yourscript() is called via call_on_exit.
	*sys.println is a debug feature which gives the text in console when the script is triggered. You can leave it for testing and remove it before releasing your map.		*sys.println is a debug feature which gives the text in console when the script is triggered. You can leave it for testing and remove it before releasing your map.
	*sys.trigger ($entity_name) replace the entity_name with the entity which you want to be triggered.		*sys.trigger ($entity_name) replace the entity_name with the entity which you want to be triggered.

Geep: /* Script calls */ Simplify & rename 'old_zone' to just 'zone' in 2nd example

2021-01-05T03:59:37Z

Script calls: Simplify & rename 'old_zone' to just 'zone' in 2nd example

← Older revision		Revision as of 03:59, 5 January 2021
Line 287:		Line 287:
	=== Script calls ===		=== Script calls ===

	The next four spawnargs all specify ~~scripts~~ to call when the player enters or exits a zone. Note that the very first zone is also "entered" by the player when the map starts. That means "call_once_on_entry" for the start zone should be called at start-time.		The next four spawnargs all specify script functions to call when the player enters or exits a zone. The call passes the zone as a function parameter. Note that the very first zone is also "entered" by the player when the map starts. That means "call_once_on_entry" for the start zone should be called at start-time.

	==== "call_once_on_exit" ====		==== "call_once_on_exit" ====
Line 342:		Line 342:
	Then go and create in your /maps folder a file yourmapname.script. Put in the following data there:		Then go and create in your /maps folder a file yourmapname.script. Put in the following data there:

	void yourscript(entity ~~old_zone~~)		void yourscript(entity zone)
	{		{
	sys.println("script yourscript running..");		sys.println("script yourscript running..");
Line 351:		Line 351:
	}		}

	*yourscript is the name of your script you call.		*yourscript is the name of your script you call. Its parameter 'zone' has the location entity that called it, either:
			** the location you're entering, when yourscript() is called via a call_on_entry; or
			** the location you're leaving, when yoursecript() is called via call_on_exit.
	*sys.println is a debug feature which gives the text in console when the script is triggered. You can leave it for testing and remove it before releasing your map.		*sys.println is a debug feature which gives the text in console when the script is triggered. You can leave it for testing and remove it before releasing your map.
	*sys.trigger ($entity_name) replace the entity_name with the entity which you want to be triggered.		*sys.trigger ($entity_name) replace the entity_name with the entity which you want to be triggered.
Line 357:		Line 359:
	Now your system works like this:		Now your system works like this:
	*When the player is outside the location everything is normal. Ie sound off, light off, etc.		*When the player is outside the location everything is normal. Ie sound off, light off, etc.
	*When the player enters the location, entity_name gets triggered once. Ie sound on, light on, etc. (NOTE: When yourscript() is called via a call_on_entry, 'entity old_zone' should actually be processed as 'entity new_zone', since you're provided the location entity of the location you're entering, NOT the location entity of the location you're leaving.)		*When the player enters the location, entity_name gets triggered once. Ie sound on, light on, etc.
	*When the player leaves the location, entity_name gets triggered again. Ie sound off, light off, etc.		*When the player leaves the location, entity_name gets triggered again. Ie sound off, light off, etc.

Grayman: /* Example script to turn entities on/off when player enters a location */

2018-10-29T03:42:30Z

Example script to turn entities on/off when player enters a location

← Older revision		Revision as of 03:42, 29 October 2018
Line 357:		Line 357:
	Now your system works like this:		Now your system works like this:
	*When the player is outside the location everything is normal. Ie sound off, light off, etc.		*When the player is outside the location everything is normal. Ie sound off, light off, etc.
	*When the player enters the location, entity_name gets triggered once. Ie sound on, light on, etc.		*When the player enters the location, entity_name gets triggered once. Ie sound on, light on, etc. (NOTE: When yourscript() is called via a call_on_entry, 'entity old_zone' should actually be processed as 'entity new_zone', since you're provided the location entity of the location you're entering, NOT the location entity of the location you're leaving.)
	*When the player leaves the location, entity_name gets triggered again. Ie sound off, light off, etc.		*When the player leaves the location, entity_name gets triggered again. Ie sound off, light off, etc.

Grayman: /* "ambient_light" */

2018-10-28T09:05:57Z

"ambient_light"

← Older revision		Revision as of 09:05, 28 October 2018
Line 227:		Line 227:
	:*You need to set the color values as fractions between 0 and 1, e.g. '''"0.08 0.08 0.02"''' and '''NOT''' as integers like "8 8 2", or it will not work.		:*You need to set the color values as fractions between 0 and 1, e.g. '''"0.08 0.08 0.02"''' and '''NOT''' as integers like "8 8 2", or it will not work.

	:*If the color change between two zones is too big, the fading and change can become obvious to the player and spoil the subtlety. This can happen for instance if you zoom from a bluish-lit outside directly to a reddish-glowing cave inside. To help the transition, consider adding an ~~intermidiate~~ zone with a light color that is either in between the two, or a more neutral grey. Making it not possible to look from one zone to the other also helps; this way the player can't see that f.i. the outside ground suddenly also glows reddish when looking back from the cave entrance to the outside.		:*If the color change between two zones is too big, the fading and change can become obvious to the player and spoil the subtlety. This can happen for instance if you zoom from a bluish-lit outside directly to a reddish-glowing cave inside. To help the transition, consider adding an intermediate zone with a light color that is either between the two, or a more neutral grey. Making it not possible to look from one zone to the other also helps; this way the player can't see that f.i. the outside ground suddenly also glows reddish when looking back from the cave entrance to the outside.

	:*There's a bug with setting ambient_light to 0 0 0 (to be fixed in 2.05), so use 0.004 0.004 0.004 if you want to remove ambient light from a location.		:*There's a bug with setting ambient_light to 0 0 0 (to be fixed in 2.05), so use 0.004 0.004 0.004 if you want to remove ambient light from a location.

← Older revision		Revision as of 15:38, 30 April 2021
Line 397:		Line 397:
	* Debugging a location overlap:		* Debugging a location overlap:
	**Forum posts about pre-2.10 approaches [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=451983 here] and [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=452084 here].		**Forum posts about pre-2.10 approaches [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=451983 here] and [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=452084 here].
	**Features introduced in TDM 2.10 [https://bugs.thedarkmod.com/view.php?id=5354#c13877 responding to bug report 0005354].		**Features introduced in TDM 2.10 [https://bugs.thedarkmod.com/view.php?id=5354#c13877 responding to bug report 0005354] and part of new location diagnostics announced [https://forums.thedarkmod.com/index.php?/topic/20905-210-dmap-locations-diagnostics/ here].

	{{tutorial-sound}}		{{tutorial-sound}}

← Older revision		Revision as of 16:12, 20 April 2021
Line 395:		Line 395:
	* [[Ambient Sounds - Zone (using triggers)]]		* [[Ambient Sounds - Zone (using triggers)]]
	* [[Sound File Formats]]		* [[Sound File Formats]]
			* Debugging a location overlap:
			**Forum posts about pre-2.10 approaches [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=451983 here] and [https://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=452084 here].
			**Features introduced in TDM 2.10 [https://bugs.thedarkmod.com/view.php?id=5354#c13877 responding to bug report 0005354].

	{{tutorial-sound}}		{{tutorial-sound}}