Func Forcefields - Revision history

Geep: /* See also */

2021-12-14T23:15:53Z

Geep: Add link & preamble about Force Fields, revise headings

2021-12-14T23:12:26Z

Add link & preamble about Force Fields, revise headings

← Older revision		Revision as of 23:12, 14 December 2021
Line 1:		Line 1:
			For a more recent and comprehensive introduction to this subject, see [[Force Fields]]. The earlier page here still provides useful insights, particularly about:
			* behavior of AI and cadavers in rivers
			* defining uniform on-axis/off-axis forces
			* affects on performance

	{{Original_Reference\|Ishtvan\|5502}}		{{Original_Reference\|Ishtvan\|5502}}

Line 17:		Line 22:
	A forcefield has a few different modes of directing the force. It can explode out from a point, implode toward a point (both of these things limited in distance by whether objects are actually within the force field brush). Or it can be uniform (force is directed the same within the whole brush). For river current, we want uniform.		A forcefield has a few different modes of directing the force. It can explode out from a point, implode toward a point (both of these things limited in distance by whether objects are actually within the force field brush). Or it can be uniform (force is directed the same within the whole brush). For river current, we want uniform.

			= The "uniform" spawnarg =
	The direction and magnitude of your force field can be set in the "uniform" spawnarg, which is a space-delimited 3d vector. Decide which directions you want your force field to go in on the map. If you're confused about which direction is which, changing views helped me see it, because the views are labeled YZ for example, so I instantly know which direction is the Y direction by looking at the YZ view.		The direction and magnitude of your force field can be set in the "uniform" spawnarg, which is a space-delimited 3d vector. Decide which directions you want your force field to go in on the map. If you're confused about which direction is which, changing views helped me see it, because the views are labeled YZ for example, so I instantly know which direction is the Y direction by looking at the YZ view.

	Once you know, you can put in the force field. If you want a uniform 2d field in one 2d direction, use this equation: Figure out the angle off of the x axis for your direction. For example, y is 90, -y is -90, etc.		Once you know, you can put in the force field. If you want a uniform 2d field in one 2d direction, use this equation: Figure out the angle off of the x axis for your direction. For example, y is 90, -y is -90, etc.

	= In-plane force field (no vertical) =		== In-plane force field (no vertical) ==

	uniform[x] = Mag * cos( theta )		uniform[x] = Mag * cos( theta )
	uniform[y] = Mag * sin( theta )		uniform[y] = Mag * sin( theta )
	uniform[z] = 0		uniform[z] = 0


	Where Mag is the desired magnitude of your force.		Where Mag is the desired magnitude of your force.
Line 32:		Line 37:
	If you want a uniform force in 3d, you also have to figure out roughly the elevation angle off of the XY plane (I'm calling it phi), and use the spherical coordinates formula:		If you want a uniform force in 3d, you also have to figure out roughly the elevation angle off of the XY plane (I'm calling it phi), and use the spherical coordinates formula:

	= Out of plane force field (vertical component to the force) =		== Out of plane force field (vertical component to the force) ==

	uniform[x] = Mag * cos(theta) cos( phi )		uniform[x] = Mag * cos(theta) cos( phi )
Line 45:		Line 50:

	= Other spawnargs of interest =		= Other spawnargs of interest =
	Again these are documented in the usage tabs in the editor~~, but make~~ sure that if you want your force field to always be active, you set:		Again these are documented in the usage tabs in the editor.
			== start_on ==
			Make sure that if you want your force field to always be active, you set:

	"start_on" "1"		"start_on" "1"
Line 51:		Line 58:
	Otherwise, you can trigger it to toggle whether it's active.		Otherwise, you can trigger it to toggle whether it's active.

	= scale_impulse ~~(TDM 1.08+)~~ =		== scale_impulse ==
	Starting with TDM 1.08, a 'scale_impulse' spawnarg has been added to vary the amount of force in an impulse forcefield.		Starting with TDM 1.08, a 'scale_impulse' spawnarg has been added to vary the amount of force in an impulse forcefield.

Line 71:		Line 78:

	= Known bug: AFs in water =		= Known bug: AFs in water =
	If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces ~~AF's~~ masses in water. This makes impulses applied on AFs in water send them flying.		If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces masses of Articulated Figures in water. This makes impulses applied on AFs in water send them flying.

	== See ~~Also =~~=		= See also =
			[[Force Fields]]
	[[Objects_Floating_in_Water]]		[[Objects_Floating_in_Water]]

	{{editing}}		{{editing}}
	{{water}}		{{water}}

Geep: Added See Also with link to new article Objects Floating in Water. Plus water template

2020-03-14T15:34:27Z

Added See Also with link to new article Objects Floating in Water. Plus water template

← Older revision		Revision as of 15:34, 14 March 2020
Line 72:		Line 72:
	= Known bug: AFs in water =		= Known bug: AFs in water =
	If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces AF's masses in water. This makes impulses applied on AFs in water send them flying.		If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces AF's masses in water. This makes impulses applied on AFs in water send them flying.

			== See Also ==
			[[Objects_Floating_in_Water]]

	{{editing}}		{{editing}}
			{{water}}

Grayman: /* Version 1 (TDM 1.08+) */

2012-02-08T15:07:21Z

Version 1 (TDM 1.08+)

← Older revision		Revision as of 15:07, 8 February 2012
Line 51:		Line 51:
	Otherwise, you can trigger it to toggle whether it's active.		Otherwise, you can trigger it to toggle whether it's active.

	= ~~Version 1~~ (TDM 1.08+) =		= scale_impulse (TDM 1.08+) =
	Starting with TDM 1.08, a '~~version~~' spawnarg has been added to vary the amount of force in an impulse forcefield.		Starting with TDM 1.08, a 'scale_impulse' spawnarg has been added to vary the amount of force in an impulse forcefield.

	"~~version~~" "1"		"scale_impulse" "1"

	This linearly scales down the applied force for objects with less mass than the player.		This linearly scales down the applied force for objects with less mass than the player.

	This was introduced so that larger forces--necessary to move the player along--would not cause smaller objects to react in an unrealistic manner. In the interest of not breaking existing missions that use this type of forcefield, the '~~version~~' spawnarg was introduced for mappers ~~that~~ want to use the scaled force.		This was introduced so that larger forces--necessary to move the player along--would not cause smaller objects to react in an unrealistic manner. In the interest of not breaking existing missions that use this type of forcefield, the 'scale_impulse' spawnarg was introduced for mappers who want to use the scaled force.

	= Performance =		= Performance =

Grayman: /* Other spawnargs of interest */

2012-02-07T16:50:35Z

Other spawnargs of interest

← Older revision		Revision as of 16:50, 7 February 2012
Line 50:		Line 50:

	Otherwise, you can trigger it to toggle whether it's active.		Otherwise, you can trigger it to toggle whether it's active.

			= Version 1 (TDM 1.08+) =
			Starting with TDM 1.08, a 'version' spawnarg has been added to vary the amount of force in an impulse forcefield.

			"version" "1"

			This linearly scales down the applied force for objects with less mass than the player.

			This was introduced so that larger forces--necessary to move the player along--would not cause smaller objects to react in an unrealistic manner. In the interest of not breaking existing missions that use this type of forcefield, the 'version' spawnarg was introduced for mappers that want to use the scaled force.

	= Performance =		= Performance =

Tels: wiki formatting

2011-02-19T14:41:12Z

wiki formatting

← Older revision		Revision as of 14:41, 19 February 2011
Line 1:		Line 1:
	{{Original_Reference\|Ishtvan\|5502}}		{{Original_Reference\|Ishtvan\|5502}}

	= Using ~~Func_Forcefields~~ =		= Using func_forcefields =

	The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.		The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.
Line 11:		Line 11:
	Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".		Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".

	It turns out that applyForce doesn't work on AI, and applyVelocity doesn't feel right because your velocity suddenly jumps up, which is unrealistic (that might be okay for some applications). For stuff like river current or wind, I'm recommending applyImpulse, by setting the following:		It turns out that '''applyForce''' doesn't work on AI, and '''applyVelocity''' doesn't feel right because your velocity suddenly jumps up, which is unrealistic (that might be okay for some applications). For stuff like river current or wind, I'm recommending '''applyImpulse''', by setting the following:

	"applyImpulse" "1"		"applyImpulse" "1"
Line 54:		Line 54:
	Because a force field is constantly activating physics objects and evaluating their physics, it could potentially drag down performance. The following are some tips to help keep performance reasonable:		Because a force field is constantly activating physics objects and evaluating their physics, it could potentially drag down performance. The following are some tips to help keep performance reasonable:

	-The more physical objects within the forcefield, the worse the performance.		* The more physical objects within the forcefield, the worse the performance.
			* If you can, place triggers to trigger the force field on or off based on whether the player is entering or leaving the area it's in. This may be difficult in large outdoor maps with large rivers, since you'd have to place huge triggers and those themselves have some impact on performance. In the case of one huge river in a map, it might be better to just write a script that triggers the forcefield or not based on distance to the line of the river.

	~~-If you can, place triggers to trigger~~ the ~~force~~ field ~~on or off based on whether~~ the ~~player is entering or leaving the area~~ it'~~s in. This may be difficult in large outdoor maps with large rivers, since~~ you'd have to ~~place huge triggers and those themselves have some impact on~~ performance. In the ~~case of one huge river in~~ a ~~map~~, ~~it might be better~~ to ~~just write~~ a ~~script~~ that ~~triggers the forcefield~~ or ~~not based on distance to~~ the ~~line~~ of the ~~river~~.		* Make sure the field does not pile up objects somewhere! As long as the field pushes objects out of it, they'll exit the field by themselves and you won't have to worry much about performance. However, if the field goes right up to a wall, and pushes objects against that wall, the objects will not come to rest, they'll keep getting that impulse and keep getting smacked against the wall, using up CPU resources. <br> I'd recommend putting some dropoff or a brush that destroys objects or something at the end of your force field. Keep in mind that even if there is a small space, objects could pile up in that space and the next object would hit that object and still be stuck in the field, so you really have to watch out for this.

	-Make sure the field does not pile up objects somewhere! As long as the field pushes objects out of it, they'll exit the field by themselves and you won't have to worry much about performance. However, if the field goes right up to a wall, and pushes objects against that wall, the objects will not come to rest, they'll keep getting that impulse and keep getting smacked against the wall, using up CPU resources.		* Creative spawning/destroying or teleporting objects: How do you get a large river with random debris floating down it, when eventually all the debris will get pushed to the end? Well, you could do some scripting, spawn objects at one end of the river, and delete objects at the other end. Or, you could set up a brush to teleport the objects back to the start of the river and keep the same objects. A Prey-style portal would be ideal here, but those don't work in D3 without a lot of SDK modification.

	I'd recommend putting some dropoff or a brush that destroys objects or something at the end of your force field. Keep in mind that even if there is a small space, objects could pile up in that space and the next object would hit that object and still be stuck in the field, so you really have to watch out for this.

	-Creative spawning/destroying or teleporting objects: How do you get a large river with random debris floating down it, when eventually all the debris will get pushed to the end? Well, you could do some scripting, spawn objects at one end of the river, and delete objects at the other end. Or, you could set up a brush to teleport the objects back to the start of the river and keep the same objects. A Prey-style portal would be ideal here, but those don't work in D3 without a lot of SDK modification.

	= Known bug: AFs in water =		= Known bug: AFs in water =
	If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces AF's masses in water. This makes impulses applied on AFs in water send them flying.		If you try to set up a river and there's a dead body in it, it will probably take off like a bat out of hell, because there's currently a bug/hack in the water physics code that reduces AF's masses in water. This makes impulses applied on AFs in water send them flying.

	~~[[Category:Editing]]~~		{{editing}}
	~~[[Category:Tutorial]]~~

Crispy: /* Out of plane force field (vertical component to the force) */ formatting

2009-11-29T11:02:44Z

Out of plane force field (vertical component to the force): formatting

← Older revision		Revision as of 11:02, 29 November 2009
Line 36:		Line 36:
	uniform[x] = Mag * cos(theta) cos( phi )		uniform[x] = Mag * cos(theta) cos( phi )
	uniform[y] = Mag * sin(theta) cos( phi )		uniform[y] = Mag * sin(theta) cos( phi )
	uniform		uniform[z] = Mag * sin( phi )
	= Mag * sin( phi )~~[/b]~~

	Some people define phi as the angle deviation from straight up instead of an elevation from the horizon, in that case interchange cos(phi) and sin(phi).		Some people define phi as the angle deviation from straight up instead of an elevation from the horizon, in that case interchange cos(phi) and sin(phi).

Fidcal: /* Using Func_Forcefields */

2009-04-08T12:54:35Z

Using Func_Forcefields

← Older revision		Revision as of 12:54, 8 April 2009
Line 5:		Line 5:
	The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.		The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.

	First of all, a func_forcefield is a brush. Stuff inside that brush is affected, stuff outside is not. You can resize and reshape it however you want. It will not work correctly if you texture the brush with common/nodraw, but you can use common/caulk.		First of all, a func_forcefield is a brush. Stuff inside that brush is affected, stuff outside is not. You can resize and reshape it however you want.

			It will not work correctly if you texture the brush with common/nodraw, but you can use common/caulk.

	Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".		Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".

Angua at 20:55, 29 April 2007

2007-04-29T20:55:47Z

← Older revision		Revision as of 20:55, 29 April 2007
Line 5:		Line 5:
	The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.		The basic documentation is there in the usage tab in the editor, if you place a func_forcefield and look at it. I'm just going to explain some of the more subtle stuff so that whoever creates this map can set it up.

	First of all, a func_forcefield is a brush. Stuff inside that brush is ~~effected~~, stuff outside is not. You can resize and reshape it however you want.		First of all, a func_forcefield is a brush. Stuff inside that brush is affected, stuff outside is not. You can resize and reshape it however you want. It will not work correctly if you texture the brush with common/nodraw, but you can use common/caulk.

	Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".		Force fields have spawnargs for whether they should apply their push as a force, an impulse, or a velocity. These are set with spawnargs applyForce, applyImpulse, and applyVelocity. A force field may only apply one of those. Set the one you want to "1".

Greebo: removed double category

2007-03-21T23:23:29Z

removed double category

← Older revision		Revision as of 23:23, 21 March 2007
Line 1:		Line 1:
	~~[[Category:Editing]]~~
	~~[[Category:Tutorial]]~~

	{{Original_Reference\|Ishtvan\|5502}}		{{Original_Reference\|Ishtvan\|5502}}

← Older revision		Revision as of 23:15, 14 December 2021
Line 82:		Line 82:
	= See also =		= See also =
	[[Force Fields]]		[[Force Fields]]

	[[Objects_Floating_in_Water]]		[[Objects_Floating_in_Water]]

	{{editing}}		{{editing}}
	{{water}}		{{water}}
			[[Category:AI]]