Local variable - Revision history

Proleric1: /* Variable 2DAs */

2011-03-25T09:20:24Z

‎Variable 2DAs

Craig Graff at 04:33, 4 February 2010

2010-02-04T04:33:55Z

Craig Graff at 04:26, 4 February 2010

2010-02-04T04:26:33Z

BryanDerksen at 16:07, 4 September 2009

2009-09-04T16:07:01Z

BryanDerksen: SetLocalLocation is in the "avoid" category

2009-09-01T15:21:42Z

SetLocalLocation is in the "avoid" category

BryanDerksen: category

2009-08-31T23:29:37Z

BryanDerksen: post an important bit of information that was just emailed to me

2009-08-31T15:28:25Z

post an important bit of information that was just emailed to me

New page

There are a number of SetLocal* functions in the game engine. The five that are of use to you (that Programming fully supports) are:

*[[SetLocalInt]]
*[[SetLocalFloat]]
*[[SetLocalObject]]
*[[SetLocalString]]
*[[SetLocalResource]]

These functions work and have been through the fire of QA for many months. They are solid and work well.

There are a number of other functions that happen to exist such as:
*[[SetLocalPlayer]]
*[[SetLocalEffect]]
*[[SetLocalEvent]]
*[[SetLocalCommand]]
*[[SetLocalItemProperty]]

These functions do *NOT* work the way that the first five do. The major issue with this second set of functions is that they are not saved/loaded via the save system. So, if a community member or designer wants to save information like this for use later, and someone saves/loads the game, that information is lost forever. Thus, using them outside of situations where you can guarantee no save/load occurs (i.e. during combat) is pretty much guaranteed to fail for some enduser. Furthermore, if you use these variable types in the var_ 2DAs, it will fail gloriously.

Don’t use these functions. They will in all likelihood be removed in a future patch.

← Older revision		Revision as of 09:20, 25 March 2011
Line 39:		Line 39:

	Dragon Age doesn't support the dynamic in-game allocation of new local variables.		Dragon Age doesn't support the dynamic in-game allocation of new local variables.
		+
		+	== Scope of local variables ==
		+
		+	If a resource isn't currently loaded, you can't reference its local variables.
		+
		+	Module variables are always available. So are [[plot]] flags.
		+
		+	Variables for an area, and objects within it, are only available for the current area list.
		+
		+	So, those variables should only be used for information that will never be needed in other areas.

	==Alternatives ==		==Alternatives ==

@@ Line 1: / Line 1: @@
 Local variables are persistent variables that are associated with in-game objects. They are not the same as the temporary variables you can create in a script; local variables retain their values even when no scripts are using them, and are shared across any scripts that choose to access them.
 Local variables are set using the SetLocal* functions and read using the GetLocal* functions. There are a number of SetLocal* functions in the game engine.  The five that are of use to you (that Programming fully supports) are:
@@ Line 11: / Line 12: @@
 These functions work and have been through the fire of QA for many months.  They are solid and work well.
 There are a number of other functions that happen to exist such as:
 *[[SetLocalPlayer]]
@@ Line 38: / Line 40: @@
 Dragon Age doesn't support the dynamic in-game allocation of new local variables.
 An alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.
 [[Category:Variable functions|*]]

← Older revision		Revision as of 04:26, 4 February 2010
Line 37:		Line 37:

	Dragon Age doesn't support the dynamic in-game allocation of new local variables.		Dragon Age doesn't support the dynamic in-game allocation of new local variables.
		+
		+	An alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.

	[[Category:Variable functions\|*]]		[[Category:Variable functions\|*]]

@@ Line 1: / Line 1: @@
-There are a number of SetLocal* functions in the game engine.  The five that are of use to you (that Programming fully supports) are:
+Local variables are persistent variables that are associated with in-game objects. They are not the same as the temporary variables you can create in a script; local variables retain their values even when no scripts are using them, and are shared across any scripts that choose to access them.
 *[[SetLocalInt]]
@@ Line 20: / Line 22: @@
 Don’t use these functions.  They will in all likelihood be removed in a future patch.
 [[Category:Variable functions|*]]

← Older revision		Revision as of 23:29, 31 August 2009
Line 19:		Line 19:

	Don’t use these functions. They will in all likelihood be removed in a future patch.		Don’t use these functions. They will in all likelihood be removed in a future patch.
		+
		+	[[Category:Variable functions\|*]]

@@ Line 15: / Line 15: @@
 *[[SetLocalCommand]]
 *[[SetLocalItemProperty]]
 These functions do *NOT* work the way that the first five do.  The major issue with this second set of functions is that they are not saved/loaded via the save system.  So, if a community member or designer wants to save information like this for use later, and someone saves/loads the game, that information is lost forever.  Thus, using them outside of situations where you can guarantee no save/load occurs (i.e. during combat) is pretty much guaranteed to fail for some enduser.  Furthermore, if you use these variable types in the var_ 2DAs, it will fail gloriously.