Talk:Second Life Railroad/SLRR Switch

On this page you can voice your comments and your own idea about the SLRR Switch concept

--Stryker J 21:15, 28 December 2009 (UTC)

---

CORRECTION: While desirable, the ability to switch from one track to another on the SLRR is NOT essential. Our locomotives are made of 0s and 1s, not 100 tons of iron, they can be easily moved from one track to another. Also, switches such as the one described here have been available from private SL residents for years. Jer Straaf

CORRECTION TO THE CORRECTION

>>...While desirable, the ability to switch from one track to another on the SLRR is NOT essential...<<

You're right. it isn't essential, but tedious to move the trains by editing them. It is killing a lot of the experience Everest Piek 21:36, 29 August 2010 (UTC)

problem about being noob proof

In RL, the switches are signalled as they are built, means, there are always a straight track and a branching track. the arrow is always showing to the branching track, thats not necessarily a branching Line. For that, having the signals once this way, once the other way, might be confusing to noobs. I would plead for having them in a universal way set as the switches are built, as they are signalled in RL. Everest Piek 21:43, 29 August 2010 (UTC)

• There is a little bit of education to be done. I agree with the principle of making sure the switches are all setup the same way. In order to make the switches more Noob friendly the dwarflights are also installed. --Stryker J 09:32, 30 August 2010 (UTC)

• Thanks Guys. I will redact my statment under the Signal diagram and build tham as Everest advises. Sylvan

A more exact specification of the description string in the switch stand is needed.

Example problem: A train script might get the switch channel by reading the fifth item in the string. This is OK. However, another train script reads the last field of the description string to get the channel. This would also work, and is within the current specification.

While both scripts follow the standard, the last script limits compatibility. An advanced switch script, may for instance have a private channel added at the end of the description string. The first train script would work, and the last train script would break with this advances script. To maintain maximal freedom for experimentation without breaking existing scripts, the standard needs to be specific about the posibility that extra information might be present in the string.

The key point is that the standard for the description string currently specifies the minimal info that a script can expect, but it is unclear if the standard forbids that extra information is added (and it should not). For maximal flexibility indexes should be use to read the data from the description, and the possibility that fields can be extended must made explicit.

Proposed text to be put up in the page:

Currently 6 fields are defined, delimited by "~" Their indexes are:

0 unique identifier of the switch current status of the switch

1 current status of the switch

2 heading connection-info

3 main connection-info

4 branch connection-info

5 channel for local control of the switch

Currently defined indexes and descriptions for the subfields within these fields:

- Within the identifier of the switch, at least the following parts are expected, delimited by "."

0 region name

1 x coordinate of switch root prim

2 y coordinate of switch root prim

3 z coordinate of switch root prim

- Within the status field at least the following part is expected, extensions are delimeted by "."

0 text string describing switch status

Currently the only defined values for this part are "Main" and "Branch"

- Within each connection-info fields (heading, main and branch) at least the following parts are expected, delimeted by "."

0 Informal destination description string

Future expansions of the standard may add the address of the next block controller in the connection-info field, using the same format as the switch identifier:

1 region name

2 x coordinate of block controller root prim

3 y coordinate of blcok controller root prim

4 z coordinate of blcok controller root prim

Within the channel field at least the following part is expected, extensions are delimeted by "."

0 channel for local control

A script header for this specification might look like this:

// Constants to be used to retrieve fields and subfields of the description string 
// of SLRR standard switches. Currently 6 fields are defined, delimited by "~"

integer SLRR_SWITCH_DESC_ID          = 0;    // unique identifier of the switch
integer SLRR_SWITCH_DESC_STATUS      = 1;    // current status of the switch
integer SLRR_SWITCH_DESC_HEADING     = 2;    // heading connection info 
integer SLRR_SWITCH_DESC_MAIN        = 3;    // main connection info
integer SLRR_SWITCH_DESC_BRANCH      = 4;    // branch connection info
integer SLRR_SWITCH_DESC_CHANNEL     = 5;    // channel for local control of the switch

//Within the ID field at least the following parts are expected, delimeted by "."  
integer ADDRESS_REGION               = 0;    // region name
integer ADDRESS_X                    = 1;    // x coordinate of switch root prim
integer ADDRESS_Y                    = 2;    // y coordinate of switch root prim
integer ADDRESS_Z                    = 3;    // z coordinate of switch root prim

// Within the status field at least the following parts are expected, delimeted by "."
integer STATUS                      = 0;     // Text string of status

// Currently only the follow values for STATUS have been defined
string NAME_MERGE                   = "Merge";
string NAME_MAIN                    = "Main";

//Witin the BLOCK descriptions at least the following parts are expected, delimeted by "."
integer NAME_DESTINATION            = 0;      // Informal destination descrtiption string

//Future expansions of the standard could insert the address of the next block controller
//into the 3 BLOCK descriptions, using the same structure as the switch ID:
integer BLOCK_REGION                = 1;     // region name
integer BLOCK_X                     = 2;     // x coordinate of blockcontroller root prim
integer BLOCK_Y                     = 3;     // y coordinate of blockcontroller prim
integer BLOCK_Z                     = 4;     // z coordinate of blockcontroller prim

//Witin the channel description field at least the following parts are expected, delimeted by "."
integer LOCAL_CHANNEL       = 0;      // channel for local control of the switch

Note that none of this is mandatory for a scripter. If sombody want to write quick and dirty code that works now, that is fine. However, the point is that such a script can not be expected to keep working in the future. Scripts following this specification are guaranteed to work, even if additional info is added to the description string. This priciple is more general than the switch standard, and for all description strings a script should retrieve the info using indexes rather than asuming that no addional info will ever be present.

If no objections are raised here, i will update the page along these lines in a week or two from now.

Vaughn Deluca 00:45, 6 January 2011 (UTC)