[JIRA] Updated: (SVC-5244) Expand the control keys available with llTakeControls and the control event

Reynard Baroque (JIRA) no-reply at lindenlab.cascadeo.com
Fri Jan 8 21:14:32 PST 2010


     [ http://jira.secondlife.com/browse/SVC-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Reynard Baroque updated SVC-5244:
---------------------------------

    Description: 
The *llTakeControls* function and *control* event need to provide access to a larger set of control inputs. From the Second Life Wiki entries for the [control event|http://wiki.secondlife.com/wiki/Control] and [llTakeControls|http://wiki.secondlife.com/wiki/LlTakeControls], we see that _level_ and _edge_ in the *control* event, and _controls_ in the *llTakeControls* function are 32-bit integer (8 hexadecimal digits) values. Since multiple simultaneous controls need to be detectable, this indicates a maximum of 32 possible control inputs can be detected. Similar issues have called for making the entire keyboard available ([SVC-1610 Allow LSL to access the entire keyboard|http://jira.secondlife.com/browse/SVC-1610]), to add the Home key ([SVC-344 Can the llTakeControls also work for the home key please.|http://jira.secondlife.com/browse/SVC-344]), to add the number keys ([SVC-1590 Enable LSL to take control of the top 1-0 keys in addition to the movement|http://jira.secondlife.com/browse/SVC-1590]) or to map more mouse buttons ([SVC-2566 Add CONTROL_ML_RBUTTON to llTakeControls|http://jira.secondlife.com/browse/SVC-2566]). While not identical, these four issues are all related in that they are indicating a need for a wider range of control signals to be available through the control functions and event.

Currently, the following control constants are provided and mapped to bits in the _level_, _edge_ and _controls_ integers:
{noformat}
CONTROL_FWD		0x00000001	move forward 		(up-arrow or W key)
CONTROL_BACK		0x00000002	move back control	(down-arrow or S key)
CONTROL_LEFT		0x00000004	move left control	(Shift + left-arrow or Shift + A key)
CONTROL_RIGHT		0x00000008	move right control	(Shift + right-arrow or Shift + D key)
CONTROL_UP		0x00000010	move up control		(PgUp or E key)
CONTROL_DOWN		0x00000020	move down control	(PgDn or C key)
CONTROL_ROT_LEFT	0x00000100	rotate left control	(left-arrow or A key)
CONTROL_ROT_RIGHT	0x00000200	rotate right control	(right-arrow or D key)
CONTROL_LBUTTON		0x10000000	left mouse button control
CONTROL_ML_LBUTTON	0x40000000	left mouse button control while in mouselook
{noformat}

To these, I would propose adding the following mappings:

{noformat}
CONTROL_TRIGGER_1	0x00000040	trigger button 1	(spacebar)
CONTROL_TRIGGER_2	0x00000080	trigger button 2	(Enter key)

CONTROL_PITCH_UP	0x00000400	pitch up control	(Home or Q key)
CONTROL_PITCH_DOWN	0x00000800	pitch down control	(End or Z key)

CONTROL_MBUTTON		0x01000000	middle mouse button control
CONTROL_ML_MBUTTON	0x02000000	middle mouse button control while in mouselook
CONTROL_WHEEL_UP	0x04000000	mouse wheel rolled up/forward
CONTROL_WHEEL_DOWN	0x08000000	mouse wheel rolled down/back
CONTROL_RBUTTON		0x20000000	right mouse button control
CONTROL_ML_RBUTTON	0x80000000	right mouse button control while in mouselook

CONTROL_CUSTOM_1	0x00100000	custom-mapped key
CONTROL_CUSTOM_2	0x00200000	custom-mapped key
CONTROL_CUSTOM_3	0x00400000	custom-mapped key
CONTROL_CUSTOM_4	0x00800000	custom-mapped key
{noformat}

Adding these mappings uses the 3 most-significant digits and the 3 least-significant digits of the available 8 hex digits, leaving the two middle digits for future expansion, possibly for joystick/gamepad controls.

The last four listed are named CONTROL_CUSTOM_n and are specified as custom-mapped keys. I would like to propose a new function to work hand-in-glove with *llTakeControls* and the *control* event, to allow scripters to map 4 keys or key combinations of their choice as control keys.

+Proposed syntax:+
*llMapControls( integer custom_map, integer modifiers, string key )*

custom_map would have a range of 1, 2, 3, or 4 and would match one-to-one with the CONTROL_CUSTOM_n flags
modifiers would be flags to specify left or right Shift, left or right Ctrl, left or right Alt:
{noformat}
KEYMOD_NONE	0x00
KEYMOD_LSHIFT	0x01
KEYMOD_RSHIFT	0x02
KEYMOD_LCTRL	0x04
KEYMOD_RCTRL	0x08
KEYMOD_LALT	0x10
KEYMOD_RALT	0x20
{noformat}
key is the character literal returned by pressing the unmodified key (i.e, lowercase letter, or a number or other un-Shifted, un-Ctrlled, un-Alted key)

Example of use:

{code:title=foo.lsl|borderStyle=solid}
...

	// maps the J key to custom control key 1, and specifies that we want only the unmodified key
	llMapControls( 1, KEYMOD_NONE, "j" );		

	// maps Shift + T (either shift) to custom control key 2		
	llMapControls( 2, KEYMOD_LSHIFT | KEYMOD_RSHIFT, "t" );		
...
	llTakeControls( CONTROL_FWD | 
			CONTROL_BACK |
			CONTROL_UP | 
			CONTROL_DOWN |
			CONTROL_CUSTOM_1 |			// will now respond to the J key
			CONTROL_CUSTOM_2 |			// will now respond to Shift - T key combination
			0, TRUE, TRUE )
...
{code}

+NOTES:+
1) The proposed function would need to ensure that a string length of 1 was enforced.

2) The proposed function call specifies a 1-character string to indicate the key being mapped, but I don't like that. Among other things, doing it that way makes it impossible to distinguish between the numbers on the main keyboard and the numbers on the numeric pad. Depending on whether Num Lock was on or not, you could either confuse the numbers mapped or you could confuse the arrow key mappings. I assume there is a way to uniquely identify each key on the keyboard; if so, it may be necessary to add constants to identify them so they can be identified in scripting.

3) The proposed llMapControls function should check the mappings to prevent mapping combinations which already exist, i.e., the arrow keys, PgUp, PgDn, etc; also if the scripter tries to assign the same key or key combination to two signals, i.e., Left-Shift-K to both custom control 1 and custom control 2. Left-Shift-K to custom control 1 and Right-Shift-K to custom control 2 would be a perfectly valid mapping, though. Note also that this could interfere with some of the viewer shortcut keys (i.e., Ctrl-A, Ctrl-C, Ctrl-V, Ctrl-X, etc.)


  was:
The *llTakeControls* function and *control* event need to provide access to a larger set of control inputs. From the Second Life Wiki entries for the [control event|http://wiki.secondlife.com/wiki/Control] and [llTakeControls|http://wiki.secondlife.com/wiki/LlTakeControls], we see that _level_ and _edge_ in the *control* event, and _controls_ in the *llTakeControls* function are 32-bit integer (8 hexadecimal digits) values. Since multiple simultaneous controls need to be detectable, this indicates a maximum of 32 possible control inputs can be detected. Similar issues have called for making the entire keyboard available ([SVC-1610 Allow LSL to access the entire keyboard|http://jira.secondlife.com/browse/SVC-1610]), to add the Home key ([SVC-344 Can the llTakeControls also work for the home key please.|http://jira.secondlife.com/browse/SVC-344]), to add the number keys ([SVC-1590 Enable LSL to take control of the top 1-0 keys in addition to the movement|http://jira.secondlife.com/browse/SVC-1590]) or to map more mouse buttons ([SVC-2566 Add CONTROL_ML_RBUTTON to llTakeControls|http://jira.secondlife.com/browse/SVC-2566]). While not identical, these four issues are all related in that they are indicating a need for a wider range of control signals to be available through the control functions and event.

Currently, the following control constants are provided and mapped to bits in the _level_, _edge_ and _controls_ integers:
{noformat}
CONTROL_FWD		0x00000001	move forward 		(up-arrow or W key)
CONTROL_BACK		0x00000002	move back control	(down-arrow or S key)
CONTROL_LEFT		0x00000004	move left control	(Shift + left-arrow or Shift + A key)
CONTROL_RIGHT		0x00000008	move right control	(Shift + right-arrow or Shift + D key)
CONTROL_UP		0x00000010	move up control		(PgUp or E key)
CONTROL_DOWN		0x00000020	move down control	(PgDn or C key)
CONTROL_ROT_LEFT	0x00000100	rotate left control	(left-arrow or A key)
CONTROL_ROT_RIGHT	0x00000200	rotate right control	(right-arrow or D key)
CONTROL_LBUTTON		0x10000000	left mouse button control
CONTROL_ML_LBUTTON	0x40000000	left mouse button control while in mouselook
{noformat}

To these, I would propose adding the following mappings:

{noformat}
CONTROL_TRIGGER_1	0x00000040	trigger button 1	(spacebar)
CONTROL_TRIGGER_2	0x00000080	trigger button 2	(Enter key)

CONTROL_PITCH_UP	0x00000400	pitch up control	(Home or Q key)
CONTROL_PITCH_DOWN	0x00000800	pitch down control	(End or Z key)

CONTROL_MBUTTON		0x01000000	middle mouse button control
CONTROL_ML_MBUTTON	0x02000000	middle mouse button control while in mouselook
CONTROL_WHEEL_UP	0x04000000	mouse wheel rolled up/forward
CONTROL_WHEEL_DOWN	0x08000000	mouse wheel rolled down/back
CONTROL_RBUTTON		0x20000000	right mouse button control
CONTROL_ML_RBUTTON	0x80000000	right mouse button control while in mouselook

CONTROL_CUSTOM_1	0x00100000	custom-mapped key
CONTROL_CUSTOM_2	0x00200000	custom-mapped key
CONTROL_CUSTOM_3	0x00400000	custom-mapped key
CONTROL_CUSTOM_4	0x00800000	custom-mapped key
{noformat}

Adding these mappings uses the 3 most-significant digits and the 3 least-significant digits of the available 8 hex digits, leaving the two middle digits for future expansion, possibly for joystick/gamepad controls.

The last four listed are named CONTROL_CUSTOM_n and are specified as custom-mapped keys. I would like to propose a new function to work hand-in-glove with *llTakeControls* and the *control* event, to allow scripters to map 4 keys or key combinations of their choice as control keys.

+Proposed syntax:+
*llMapControls( integer custom_map, integer modifiers, string key )*

custom_map would have a range of 1, 2, 3, or 4 and would match one-to-one with the CONTROL_CUSTOM_n flags
modifiers would be flags to specify left or right Shift, left or right Ctrl, left or right Alt:
{noformat}
KEYMOD_NONE	0x00
KEYMOD_LSHIFT	0x01
KEYMOD_RSHIFT	0x02
KEYMOD_LCTRL	0x04
KEYMOD_RCTRL	0x08
KEYMOD_LALT	0x10
KEYMOD_RALT	0x20
{noformat}
key is the character literal returned by pressing the unmodified key (i.e, lowercase letter, or a number or other un-Shifted, un-Ctrlled, un-Alted key)

Example of use:

{code:title=foo.lsl|borderStyle=solid}
...

	// maps the J key to custom control key 1, and specifies that we want only the unmodified key
	llMapControls( 1, KEYMOD_NONE, "j" );		

	// maps Shift + T (either shift) to custom control key 2		
	llMapControls( 2, KEYMOD_LSHIFT | KEYMOD_RSHIFT, "t" );		
...
	llTakeControls( CONTROL_FWD | 
			CONTROL_BACK |
			CONTROL_UP | 
			CONTROL_DOWN |
			CONTROL_CUSTOM_1 |			// will now respond to the J key
			CONTROL_CUSTOM_2 |			// will now respond to Shift - T key combination
			0, TRUE, TRUE )
...
{code}

+NOTES:+
1) The proposed function would need to ensure that a string length of 1 was enforced.
2) The proposed function call specifies a 1-character string to indicate the key being mapped, but I don't like that. Among other things, doing it that way makes it impossible to distinguish between the numbers on the main keyboard and the numbers on the numeric pad. Depending on whether Num Lock was on or not, you could either confuse the numbers mapped or you could confuse the arrow key mappings. I assume there is a way to uniquely identify each key on the keyboard; if so, it may be necessary to add constants to identify them so they can be identified in scripting.
3) The proposed llMapControls function should check the mappings to prevent mapping combinations which already exist, i.e., the arrow keys, PgUp, PgDn, etc; also if the scripter tries to assign the same key or key combination to two signals, i.e., Left-Shift-K to both custom control 1 and custom control 2. Left-Shift-K to custom control 1 and Right-Shift-K to custom control 2 would be a perfectly valid mapping, though. Note also that this could interfere with some of the viewer shortcut keys (i.e., Ctrl-A, Ctrl-C, Ctrl-V, Ctrl-X, etc.)



> Expand the control keys available with llTakeControls and the control event
> ---------------------------------------------------------------------------
>
>                 Key: SVC-5244
>                 URL: http://jira.secondlife.com/browse/SVC-5244
>             Project: 2. Second Life Service - SVC
>          Issue Type: New Feature
>          Components: Permissions, Scripts
>         Environment: Cool Viewer 1.22.11 (0) Apr 10 2009 18:17:04 (Cool Viewer)
> Release Notes
> You are at 133342.6, 253927.8, 500.8 in Phoenix Estates located at sim2114.agni.lindenlab.com (216.82.56.119:12035)
> Second Life Server 1.34.2.142087
> Release Notes
> CPU: Intel Core 2 Series Processor (1994 MHz)
> Memory: 3070 MB
> OS Version: Microsoft Windows Vista Service Pack 2 (Build 6002)
> Graphics Card Vendor: ATI Technologies Inc.
> Graphics Card: ATI Mobility Radeon HD 3650
> OpenGL Version: 2.1.7980 Release
> libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
> J2C Decoder Version: KDU
> Audio Driver Version: FMOD version 3.750000
> LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.29645 (Mozilla GRE version 1.8.1.13_0000000000)
> Packets Lost: 0/711 (0.0%)
>            Reporter: Reynard Baroque
>            Priority: Major
>
> The *llTakeControls* function and *control* event need to provide access to a larger set of control inputs. From the Second Life Wiki entries for the [control event|http://wiki.secondlife.com/wiki/Control] and [llTakeControls|http://wiki.secondlife.com/wiki/LlTakeControls], we see that _level_ and _edge_ in the *control* event, and _controls_ in the *llTakeControls* function are 32-bit integer (8 hexadecimal digits) values. Since multiple simultaneous controls need to be detectable, this indicates a maximum of 32 possible control inputs can be detected. Similar issues have called for making the entire keyboard available ([SVC-1610 Allow LSL to access the entire keyboard|http://jira.secondlife.com/browse/SVC-1610]), to add the Home key ([SVC-344 Can the llTakeControls also work for the home key please.|http://jira.secondlife.com/browse/SVC-344]), to add the number keys ([SVC-1590 Enable LSL to take control of the top 1-0 keys in addition to the movement|http://jira.secondlife.com/browse/SVC-1590]) or to map more mouse buttons ([SVC-2566 Add CONTROL_ML_RBUTTON to llTakeControls|http://jira.secondlife.com/browse/SVC-2566]). While not identical, these four issues are all related in that they are indicating a need for a wider range of control signals to be available through the control functions and event.
> Currently, the following control constants are provided and mapped to bits in the _level_, _edge_ and _controls_ integers:
> {noformat}
> CONTROL_FWD		0x00000001	move forward 		(up-arrow or W key)
> CONTROL_BACK		0x00000002	move back control	(down-arrow or S key)
> CONTROL_LEFT		0x00000004	move left control	(Shift + left-arrow or Shift + A key)
> CONTROL_RIGHT		0x00000008	move right control	(Shift + right-arrow or Shift + D key)
> CONTROL_UP		0x00000010	move up control		(PgUp or E key)
> CONTROL_DOWN		0x00000020	move down control	(PgDn or C key)
> CONTROL_ROT_LEFT	0x00000100	rotate left control	(left-arrow or A key)
> CONTROL_ROT_RIGHT	0x00000200	rotate right control	(right-arrow or D key)
> CONTROL_LBUTTON		0x10000000	left mouse button control
> CONTROL_ML_LBUTTON	0x40000000	left mouse button control while in mouselook
> {noformat}
> To these, I would propose adding the following mappings:
> {noformat}
> CONTROL_TRIGGER_1	0x00000040	trigger button 1	(spacebar)
> CONTROL_TRIGGER_2	0x00000080	trigger button 2	(Enter key)
> CONTROL_PITCH_UP	0x00000400	pitch up control	(Home or Q key)
> CONTROL_PITCH_DOWN	0x00000800	pitch down control	(End or Z key)
> CONTROL_MBUTTON		0x01000000	middle mouse button control
> CONTROL_ML_MBUTTON	0x02000000	middle mouse button control while in mouselook
> CONTROL_WHEEL_UP	0x04000000	mouse wheel rolled up/forward
> CONTROL_WHEEL_DOWN	0x08000000	mouse wheel rolled down/back
> CONTROL_RBUTTON		0x20000000	right mouse button control
> CONTROL_ML_RBUTTON	0x80000000	right mouse button control while in mouselook
> CONTROL_CUSTOM_1	0x00100000	custom-mapped key
> CONTROL_CUSTOM_2	0x00200000	custom-mapped key
> CONTROL_CUSTOM_3	0x00400000	custom-mapped key
> CONTROL_CUSTOM_4	0x00800000	custom-mapped key
> {noformat}
> Adding these mappings uses the 3 most-significant digits and the 3 least-significant digits of the available 8 hex digits, leaving the two middle digits for future expansion, possibly for joystick/gamepad controls.
> The last four listed are named CONTROL_CUSTOM_n and are specified as custom-mapped keys. I would like to propose a new function to work hand-in-glove with *llTakeControls* and the *control* event, to allow scripters to map 4 keys or key combinations of their choice as control keys.
> +Proposed syntax:+
> *llMapControls( integer custom_map, integer modifiers, string key )*
> custom_map would have a range of 1, 2, 3, or 4 and would match one-to-one with the CONTROL_CUSTOM_n flags
> modifiers would be flags to specify left or right Shift, left or right Ctrl, left or right Alt:
> {noformat}
> KEYMOD_NONE	0x00
> KEYMOD_LSHIFT	0x01
> KEYMOD_RSHIFT	0x02
> KEYMOD_LCTRL	0x04
> KEYMOD_RCTRL	0x08
> KEYMOD_LALT	0x10
> KEYMOD_RALT	0x20
> {noformat}
> key is the character literal returned by pressing the unmodified key (i.e, lowercase letter, or a number or other un-Shifted, un-Ctrlled, un-Alted key)
> Example of use:
> {code:title=foo.lsl|borderStyle=solid}
> ...
> 	// maps the J key to custom control key 1, and specifies that we want only the unmodified key
> 	llMapControls( 1, KEYMOD_NONE, "j" );		
> 	// maps Shift + T (either shift) to custom control key 2		
> 	llMapControls( 2, KEYMOD_LSHIFT | KEYMOD_RSHIFT, "t" );		
> ...
> 	llTakeControls( CONTROL_FWD | 
> 			CONTROL_BACK |
> 			CONTROL_UP | 
> 			CONTROL_DOWN |
> 			CONTROL_CUSTOM_1 |			// will now respond to the J key
> 			CONTROL_CUSTOM_2 |			// will now respond to Shift - T key combination
> 			0, TRUE, TRUE )
> ...
> {code}
> +NOTES:+
> 1) The proposed function would need to ensure that a string length of 1 was enforced.
> 2) The proposed function call specifies a 1-character string to indicate the key being mapped, but I don't like that. Among other things, doing it that way makes it impossible to distinguish between the numbers on the main keyboard and the numbers on the numeric pad. Depending on whether Num Lock was on or not, you could either confuse the numbers mapped or you could confuse the arrow key mappings. I assume there is a way to uniquely identify each key on the keyboard; if so, it may be necessary to add constants to identify them so they can be identified in scripting.
> 3) The proposed llMapControls function should check the mappings to prevent mapping combinations which already exist, i.e., the arrow keys, PgUp, PgDn, etc; also if the scripter tries to assign the same key or key combination to two signals, i.e., Left-Shift-K to both custom control 1 and custom control 2. Left-Shift-K to custom control 1 and Right-Shift-K to custom control 2 would be a perfectly valid mapping, though. Note also that this could interfere with some of the viewer shortcut keys (i.e., Ctrl-A, Ctrl-C, Ctrl-V, Ctrl-X, etc.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.secondlife.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


More information about the Jira-notify mailing list