Difference between revisions of "Talk:Second Life Railroad/SLRR Switch"

From Second Life Wiki
Jump to navigation Jump to search
m
Line 24: Line 24:
:* Thanks Guys.  I will redact my statment under the Signal diagram and build tham as Everest advises.  Sylvan
:* 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 scripter writing a train script might get the switch channel by reading the fifth item in the string. This is OK. However, another train scripter 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 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.
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 does does not forbid that extra information is added. This means that indexes  must be use to read the data from the description.
Currently 6 fields are defined, delimited by "~" Their indexes are:
:'''0''' unique identifier of the switcg1 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 field 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 connection-info, 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 will follow as soon as i figure out how to format it.
[[User:Vaughn Deluca|Vaughn Deluca]] 00:45, 6 January 2011 (UTC)

Revision as of 17:45, 5 January 2011


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 scripter writing a train script might get the switch channel by reading the fifth item in the string. This is OK. However, another train scripter 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 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. 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 does does not forbid that extra information is added. This means that indexes must be use to read the data from the description.


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

0 unique identifier of the switcg1 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 field 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 connection-info, 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 will follow as soon as i figure out how to format it.

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