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

An exact specification of the way the description string in the switch stand should be read is needed.

Example problem: A train script might get the switch channel by reading the item in the string at index 5. 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 ~ and a private channel added at the end of the description string. The first train script would work, and the last train script would get the wrong channel and break with this advances switch script. To maintain maximal freedom for experimentation without risk of 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. For maximal flexibility it should be clear that in the future in each field information might be added. Therfore, indexes should be use to read the data from the description (See example script below)

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

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

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, future extensions will be 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 fields) at least the following parts are expected, delimeted by "."

0 Informal destination description string

Within the channel field at least the following part is expected, future extensions will be 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 part is expected, future extensions will be delimeted by "."
integer STATUS                      = 0;     // Text string of status

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

//Witin the descriptions at least the following part is expected, future extensions will be delimeted by "."
integer NAME_DESTINATION            = 0;      // Informal  description string of direction

//Example of a future extension
//When a block information system is used, for each connection in the switch the address of the next block controller in that direction could be added, 
//using the same format as for 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 guideline 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 additonal info will ever be present.

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