Talk:Second Life Railroad/SLRR standards - Revision history

Kyrah Abattoir at 00:04, 9 April 2014

2014-04-09T00:04:14Z

← Older revision		Revision as of 17:04, 8 April 2014
Line 114:		Line 114:
	Is there still some maintenance done on the SLRR tracks? i noticed several issues on the public, semi public and private sections, namely phantom center rails, center rails that are too low to provide proper physical contact, and center rails that are turned backward. I've started working on physical locomotives and i have to say that a lot of the sim crossing areas are problematic (track switches or sharp turns/grade changes right before/after a crossing usually derail physical trains)		Is there still some maintenance done on the SLRR tracks? i noticed several issues on the public, semi public and private sections, namely phantom center rails, center rails that are too low to provide proper physical contact, and center rails that are turned backward. I've started working on physical locomotives and i have to say that a lot of the sim crossing areas are problematic (track switches or sharp turns/grade changes right before/after a crossing usually derail physical trains)


			One way to deal with red signals would be to accompany them ( and this should be in switches set against you too ) with a block signal, such as the line end signal. if you can't pass, end of line signal appears basically.
	[[User:Kyrah Abattoir\|Kyrah Abattoir]] 17:01, 8 April 2014 (PDT)		[[User:Kyrah Abattoir\|Kyrah Abattoir]] 17:01, 8 April 2014 (PDT)

Kyrah Abattoir at 00:01, 9 April 2014

2014-04-09T00:01:58Z

← Older revision		Revision as of 17:01, 8 April 2014
Line 111:		Line 111:
	:I would gladly help coordinate a command-and-control system for SLRR but unfortunately it is nearly impossible without a complete overhaul of the network and prohibition of current vehicles without compatibility fixes. Ultimately, it would basically necessitate an entirely new system, and would probably be best as a commercial, privatized one to ensure standards enforcement. The current state of SLRR is much like the Linux situation - there are many different versions which run off of the same specifications, but updating those specifications would be extremely difficult and would take many years to reach significant acceptance.		:I would gladly help coordinate a command-and-control system for SLRR but unfortunately it is nearly impossible without a complete overhaul of the network and prohibition of current vehicles without compatibility fixes. Ultimately, it would basically necessitate an entirely new system, and would probably be best as a commercial, privatized one to ensure standards enforcement. The current state of SLRR is much like the Linux situation - there are many different versions which run off of the same specifications, but updating those specifications would be extremely difficult and would take many years to reach significant acceptance.
	:[[User:Nelson Jenkins\|Nelson Jenkins]] 17:22, 28 October 2012 (PDT)		:[[User:Nelson Jenkins\|Nelson Jenkins]] 17:22, 28 October 2012 (PDT)

			Is there still some maintenance done on the SLRR tracks? i noticed several issues on the public, semi public and private sections, namely phantom center rails, center rails that are too low to provide proper physical contact, and center rails that are turned backward. I've started working on physical locomotives and i have to say that a lot of the sim crossing areas are problematic (track switches or sharp turns/grade changes right before/after a crossing usually derail physical trains)

			[[User:Kyrah Abattoir\|Kyrah Abattoir]] 17:01, 8 April 2014 (PDT)

Nelson Jenkins at 00:22, 29 October 2012

2012-10-29T00:22:09Z

← Older revision		Revision as of 17:22, 28 October 2012
Line 105:		Line 105:

	[[User:Vaughn Deluca\|Vaughn Deluca]] 12:35, 19 December 2011 (PST)		[[User:Vaughn Deluca\|Vaughn Deluca]] 12:35, 19 December 2011 (PST)

			:I should point out that a decentralized system will generally be less stable than a well-maintained centralized one, given the haphazard nature of inter-region communications using chat relays. HTTP communications are not possible without an off-grid server (barring a cheap workaround by exchanging URLs through chat, but this defeats the purpose). A system like this would only be much use in yards and other complex interlocks, which most of SLRR isn't. Ultimately the system is rendered useless by two inherent flaws with SLRR:
			:# Most of the system is a single-track mainline with very few sidings, most of which are incapable of handling more than one or two cars. Handling traffic in both directions would be difficult enough with a centralized system; without one it is nearly impossible.
			:# There isn't a system already in place. SLRR rolling stock generally either uses the script from the VRC freebie engine or an in-house system that will probably never be updated as the creator stopped playing many moons ago. If a system like this were to be implemented it would require compliance by all users and compatibility with all rolling stock to operate safely and effectively - as this is SL, this is not possible. Detecting incompatible cars and compensating for them is also prohibitively difficult, especially in a decentralized system.
			:I would gladly help coordinate a command-and-control system for SLRR but unfortunately it is nearly impossible without a complete overhaul of the network and prohibition of current vehicles without compatibility fixes. Ultimately, it would basically necessitate an entirely new system, and would probably be best as a commercial, privatized one to ensure standards enforcement. The current state of SLRR is much like the Linux situation - there are many different versions which run off of the same specifications, but updating those specifications would be extremely difficult and would take many years to reach significant acceptance.
			:[[User:Nelson Jenkins\|Nelson Jenkins]] 17:22, 28 October 2012 (PDT)

Vaughn Deluca: /* removed outdated discussion */

2012-05-31T13:40:25Z

removed outdated discussion

← Older revision		Revision as of 06:40, 31 May 2012
Line 16:		Line 16:
	--[[User:Stryker Jenkins\|Stryker J]] 14:53, 28 December 2009 (UTC)		--[[User:Stryker Jenkins\|Stryker J]] 14:53, 28 December 2009 (UTC)



	...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all residents, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.[[User:Yevad Doobie\|Yevad Doobie]] 22:21, 12 June 2011 (PDT)
	~~<br><br>~~
	:: If an actual human wants to disregard the information that is provided to allow a pleasant and realistic journey, than that human can just do so. I would like to stress once more, that the "control" that we talk about here is not control of the train operator. What is discussed is the control of signals and other information sources. The VRC works to design a standardized and open information exchange system, that <i>can</i> be used by a human operator or by automated trains, but can just as well be ignored if the human operator wishes to do so.<br><br>
	::The VRC is an open organisation that in no way claims rights over the SLRR nor prescribes or dictates anything to anybody. If you like to join you are welcome, if you don't want to be involved that is fine to. We will not restrict anybody in using the SLRR in the way they want but, we expect that same attitude from others. If you don't like to discuss ways to design a block control system, please don't do it, but stop cluttering the page with claims of restrictions of your rights that have no basis.

	~~::[[User:Vaughn Deluca\|Vaughn Deluca]] 05:11, 17 December 2011 (PST)~~
	<br>		<br>
	<br>		<br>

Vaughn Deluca: corrected old version order in address

2012-01-03T05:53:14Z

corrected old version order in address

Vaughn Deluca: /* control system discussion */

2011-12-30T05:34:17Z

control system discussion

Vaughn Deluca: /* control system discussion */

2011-12-21T21:18:24Z

control system discussion

← Older revision		Revision as of 14:18, 21 December 2011
Line 107:		Line 107:
	Note that to control a switch, a request will be send containing the new position. The switch will acknowlege by sending its new position. The switch will take care of adjusting its own element, like signals lights in a consistent manner.		Note that to control a switch, a request will be send containing the new position. The switch will acknowlege by sending its new position. The switch will take care of adjusting its own element, like signals lights in a consistent manner.
	Objects automatically determine their own address (Using configuration info from the description field or from a configuration notecard). Each object has a parent object, for forwarding messages that can't be handled by the object itself.		Objects automatically determine their own address (Using configuration info from the description field or from a configuration notecard). Each object has a parent object, for forwarding messages that can't be handled by the object itself.

			<i>Update December 21, 2011:</i><br>
			Here is an example how the system can be used: In a rail yard, the signal hut (or control tower) can contain a map with all signals in the yard. When a switches is flipped by running trains, the switch sends a status message message to its parent structure (the tower), and the tower forwards this to the map(s) it controls that displays the new status. A human user can touch buttons or pull levers in the tower, and those objects will send messages to the switch they are associated with. The switch responds by changing position and sending a message back to the tower with the new state of the switch. The above described functionality is currently up and running in Huckleberry, but the scripts still need a lot of work. All volunteers are welcome.


	[[User:Vaughn Deluca\|Vaughn Deluca]] 12:35, 19 December 2011 (PST)		[[User:Vaughn Deluca\|Vaughn Deluca]] 12:35, 19 December 2011 (PST)

Vaughn Deluca: /* control system discussion */

2011-12-19T20:35:02Z

control system discussion

← Older revision		Revision as of 13:35, 19 December 2011
Line 24:		Line 24:

	::[[User:Vaughn Deluca\|Vaughn Deluca]] 05:11, 17 December 2011 (PST)		::[[User:Vaughn Deluca\|Vaughn Deluca]] 05:11, 17 December 2011 (PST)
			<br>
			<br>

			;SCADAD controll system:

			The Virtual Railway Consortium (VRC) is developing an open specification for a generalised control system (SCADAD, Supervisory Control, Data Acquisition & Distribution) for public transport in SL-like virtual worlds. Here an overview of the SCADAD protocol is presented. All comments and suggestions for improvement are welcome. Interested scripters are invited to contact Moundsa Mayo or Vaughn Deluca.

			Currently two implementations are deployed inworld. Along the GSLR a (slightly older) version of the systems communication backbone is running over 7 sims, but no equipment is connected as yet. In the Huckelberry yard, communication between several switches and status maps are tested and the main development is taking place there. A new implementation is planned in Tuliptree.

			<b>--General design considerations and requirements</b>

			(1) The system must operate fully in-world, i.e. independent off external servers for communication.
			<br>
			(2) The system must be as much as possible distributed, i.e. the objects in the system should be able to function independent and autonomous (possibly at a reduced level of functionality). If one entity fails, the remaining entities use sensible defaults to keep up a reasonable level of functionality. This results in graceful degradation of the system when communication starts to fail.
			<br>
			(3)The system must be modular and as much as possible self-configuring to allow easy extension with new objects, and provide both efficient and user friendly operation.
			<br><br>
			<b>-- System overview</b>

			At the highest level the system can be viewed as a set of objects that exchange protocol messages.
			Examples are switches, stations, control towers and message relays. The protocol makes no assumptions about the inner workings of the object. Any object that follows the protocol will be able to communicate. This will allow railway line operators that have developed their own communication systems to use the VRC protocol in addition to their own system and interface it with their local protocols and existing builds simply by dropping some scripts in the object.

			The structure of the system is a "vertical" chain of command in which each object knows about nodes lower in the system, and knows the address of one parent object to which messages are forwarded that the object can not handle itself. The chain branches out at the bottom to structures like switches and automated rolling stock, and finally to elements of structures like signals and train detectors. In addition there are "horizontal" connections to allow inter-region communication.

			Request messages can be injected at each level. Routing of messages to neighboring regions is done by region controllers that (currently) communicate to pairs of repeaters whispering over region boundaries, but HTTP connections are equally possible. The region controller uses a local routing table to determine in what direction a message that is not addressed to its own region should be forwarded.


			These two main "dimensions" in the network (vertical within region, and horizontal between regions) are intersecting at the the region controllers (one per region) that function as routers for messages for objects not present in the region. In each region the region controller talks to one or more downstream control towers, typically managed by parcel owners. The lower parts of the system (switches, stations etc) are also owned and operated by the parcel owner. The region controllers together build a communication "backbone", a shared public network operated by the members of the VRC or equivalent organisation, at a best effort basis. Traveling rolling stock may contact the region controller to request information about the local infrastructure (switches, stations, etc., and in most cases will receive the address of a local tower for further communication.

			The chosen design of addressable objects has the advantages that it can be fully in-world (requirement 1), that there is no central point of control, so the system will degrade gracefully (requirement 2) and individual units can be relatively easy added or changed (requirement 3). The drawback is more complexity of the system as a whole, compared to a system where each entity communicates directly with a central hub like an out-of-world server. The biggest advantage is however that the system fits well to the relative fluid nature of SL were parcel owners come and go. The general approach can be compared to the internet, that is not "owned" by anybody and allows every interested party to connect and exchange information using a standard protocol.

			<b>-- Message template</b>

			All messages that are passed to the different objects in the network have the same format: a set of 16 main fields that together define the message. All 16 fields are always present in each message.
			The fields can be individually read from the message using an index into the message.
			The destination region of the message is for instance stored in the string at position 3.

			<pre>
			// =====================================================================
			// VRC SCADAD message template v4
			// =====================================================================
			// Message template fields
			//
			// integer MSG_INFO = 0; index of message info
			// integer MSG_SEQUENCE = 1; index of sequence number
			// integer MSG_DEST = 2; index of global destination
			// string MSG_DEST_REGIONNAME = 3; index of destination region
			// integer MSG_DEST_STRUC_LOC = 4; index of destination structure location
			// integer MSG_DEST_STRUCTURE = 5; index of destination structure class
			// integer MSG_DEST_ELEMENT = 6; index of sub-structure class
			// integer MSG_SENDER = 7; index of global sender
			// string MSG_SENDER_REGIONNAME = 8; index of sender region
			// integer MSG_SENDER_STRUC_LOC = 9; index of sender location
			// integer MSG_SENDER_STRUCTURE = 10; index of sender structure class
			// integer MSG_SENDER_ELEMENT = 11; index of sender sub-structure class
			// integer MSG_COMMAND = 12; index of command word
			// integer MSG_CONTENT_INT = 13; index of payload integer
			// float MSG_CONTENT_FLOAT = 14; index of payload float
			// string MSG_CONTENT_STRING = 15; index of payload string
			// string MSG_CONTENT_KEY = 16; index of payload key
			</pre>
			Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.


			<b>-- Address logic</b>

			Communicating objects need a way to address each other. In the SCADAD system each node can send out requests and respond to requests. The destination and origin of a message are specified by building the unique address of the destination from information in the message. See examplem below: words in capitals are predefined constants, CONN_BRANCH indicates for instance the branch side from a Y switch.
			<pre>
			Field Content Example values
			----------------------------------------------------------------------
			MSG_DEST World, Organisation, Service SL, VRC, VRC_TEST
			MSG_DEST_REGIONNAME RegionName Huckleberry
			MSG_DEST_STRUCTURE ObjectType STRUC_SWITCH
			MSG_DEST_STRUC_LOC x, y, z 132,6,85
			MSG_DEST_ELEMENT Element, ElementID ELEM_SIGNAL, CONN_BRANCH
			</pre>

			The full and unique name of this object (one of the signals of a switch) could be:
			SL.VRC.VRC_TEST.Huckleberry.Switch.132,6,85.Signal.Branch.
			In most cases the first 3 fields of the address (world, organisation, service) will be implied (i.e. used as default), and the last two will be only used by the switch itself. Therefore, to communicate with the switch described above the partial address Huckleberry.Switch.132,6,85 will be all that is needed for local communiciation.

			Note that to control a switch, a request will be send containing the new position. The switch will acknowlege by sending its new position. The switch will take care of adjusting its own element, like signals lights in a consistent manner.
			Objects automatically determine their own address (Using configuration info from the description field or from a configuration notecard). Each object has a parent object, for forwarding messages that can't be handled by the object itself.

			[[User:Vaughn Deluca\|Vaughn Deluca]] 12:35, 19 December 2011 (PST)

Vaughn Deluca: /* control system discussion */

2011-12-17T13:11:55Z

control system discussion

← Older revision		Revision as of 06:11, 17 December 2011
Line 19:		Line 19:

	...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all residents, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.[[User:Yevad Doobie\|Yevad Doobie]] 22:21, 12 June 2011 (PDT)		...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all residents, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.[[User:Yevad Doobie\|Yevad Doobie]] 22:21, 12 June 2011 (PDT)
			<br><br>
			:: If an actual human wants to disregard the information that is provided to allow a pleasant and realistic journey, than that human can just do so. I would like to stress once more, that the "control" that we talk about here is not control of the train operator. What is discussed is the control of signals and other information sources. The VRC works to design a standardized and open information exchange system, that <i>can</i> be used by a human operator or by automated trains, but can just as well be ignored if the human operator wishes to do so.<br><br>
			::The VRC is an open organisation that in no way claims rights over the SLRR nor prescribes or dictates anything to anybody. If you like to join you are welcome, if you don't want to be involved that is fine to. We will not restrict anybody in using the SLRR in the way they want but, we expect that same attitude from others. If you don't like to discuss ways to design a block control system, please don't do it, but stop cluttering the page with claims of restrictions of your rights that have no basis.

			::[[User:Vaughn Deluca\|Vaughn Deluca]] 05:11, 17 December 2011 (PST)

Yevad Doobie at 05:44, 13 June 2011

2011-06-13T05:44:16Z

← Older revision		Revision as of 22:44, 12 June 2011
Line 18:		Line 18:


	...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all ~~members~~, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.[[User:Yevad Doobie\|Yevad Doobie]] 22:21, 12 June 2011 (PDT)		...and what if an actual human wants to use the line rather than "controlled" rolling stock? And, why is a VRC meeting being used to dictate such things, the so-called "Community meeting". I do not recall an announcement on the Second Life blog, forums or anywhere else for a community meeting. The community is more than the VRC, which remains a private group. The SLRR is a resource for all residents, not a private group. I see this arrogant disregard for residents outside of the VCR continues, which doesn't surprise me.[[User:Yevad Doobie\|Yevad Doobie]] 22:21, 12 June 2011 (PDT)

← Older revision		Revision as of 22:53, 2 January 2012
Line 69:		Line 69:
	// integer MSG_INFO = 0; index of message info		// integer MSG_INFO = 0; index of message info
	// integer MSG_SEQUENCE = 1; index of sequence number		// integer MSG_SEQUENCE = 1; index of sequence number
	// integer MSG_DEST = 2; index of global destination		// integer MSG_DEST = 2; index of global part destination
	// integer MSG_DEST_REGIONNAME = 3; index of destination region		// integer MSG_DEST_REGIONNAME = 3; index of destination region
	// integer MSG_DEST_STRUCTURE = 4; index of destination structure class		// integer MSG_DEST_STRUCTURE = 4; index of destination structure class
	// integer MSG_DEST_STRUC_LOC = 4; index of destination structure location		// integer MSG_DEST_STRUC_LOC = 5; index of destination structure location
	// integer MSG_DEST_ELEMENT = 6; index of sub-structure class		// integer MSG_DEST_ELEMENT = 6; index of sub-structure class
	// integer MSG_SENDER = 7; index of global sender		// integer MSG_SENDER = 7; index of global part sender
	// integer MSG_SENDER_REGIONNAME = 8; index of sender region		// integer MSG_SENDER_REGIONNAME = 8; index of sender region
	// integer ~~MSG_SENDER_STRUC_LOC~~ = 9; index of sender ~~location~~		// integer MSG_SENDER_STRUCTURE = 9; index of sender structure class
	// integer ~~MSG_SENDER_STRUCTURE~~ = 10; index of sender ~~structure class~~		// integer MSG_SENDER_STRUC_LOC = 10; index of sender location
	// integer MSG_SENDER_ELEMENT = 11; index of sender sub-structure class		// integer MSG_SENDER_ELEMENT = 11; index of sender sub-structure class
	// integer MSG_COMMAND = 12; index of command word		// integer MSG_COMMAND = 12; index of command word
	// integer MSG_CONTENT_INT = 13; index of payload integer		// integer MSG_CONTENT_INT = 13; index of payload integer
	// integer MSG_CONTENT_FLOAT = 14; index of payload float		// integer MSG_CONTENT_FLOAT = 14; index of payload float
	// integer MSG_CONTENT_STRING = 15; index of payload string		// integer MSG_CONTENT_STRING = 15; index of payload string
	//integer MSG_CONTENT_KEY = 16; index of payload key		//integer MSG_CONTENT_KEY = 16; index of payload key
	</pre>		</pre>
	Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.		Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.

← Older revision		Revision as of 22:34, 29 December 2011
Line 70:		Line 70:
	// integer MSG_SEQUENCE = 1; index of sequence number		// integer MSG_SEQUENCE = 1; index of sequence number
	// integer MSG_DEST = 2; index of global destination		// integer MSG_DEST = 2; index of global destination
	// ~~string~~ MSG_DEST_REGIONNAME = 3; index of destination region		// integer MSG_DEST_REGIONNAME = 3; index of destination region
			// integer MSG_DEST_STRUCTURE = 4; index of destination structure class
	// integer MSG_DEST_STRUC_LOC = 4; index of destination structure location		// integer MSG_DEST_STRUC_LOC = 4; index of destination structure location
	~~// integer MSG_DEST_STRUCTURE = 5; index of destination structure class~~
	// integer MSG_DEST_ELEMENT = 6; index of sub-structure class		// integer MSG_DEST_ELEMENT = 6; index of sub-structure class
	// integer MSG_SENDER = 7; index of global sender		// integer MSG_SENDER = 7; index of global sender
	// ~~string~~ MSG_SENDER_REGIONNAME = 8; index of sender region		// integer MSG_SENDER_REGIONNAME = 8; index of sender region
	// integer MSG_SENDER_STRUC_LOC = 9; index of sender location		// integer MSG_SENDER_STRUC_LOC = 9; index of sender location
	// integer MSG_SENDER_STRUCTURE = 10; index of sender structure class		// integer MSG_SENDER_STRUCTURE = 10; index of sender structure class
Line 81:		Line 81:
	// integer MSG_COMMAND = 12; index of command word		// integer MSG_COMMAND = 12; index of command word
	// integer MSG_CONTENT_INT = 13; index of payload integer		// integer MSG_CONTENT_INT = 13; index of payload integer
	// ~~float~~ MSG_CONTENT_FLOAT = 14; index of payload float		// integer MSG_CONTENT_FLOAT = 14; index of payload float
	// ~~string~~ MSG_CONTENT_STRING = 15; index of payload string		// integer MSG_CONTENT_STRING = 15; index of payload string
	// ~~string~~ MSG_CONTENT_KEY = 16; index of payload key		//integer MSG_CONTENT_KEY = 16; index of payload key
	</pre>		</pre>
	Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.		Most of the 16 main fields in the template are divided into subfields to make more efficient use of space. The message destination field (MSG_DEST) at position 2 for instance has subfields for "world", "organisation" and "service" constants.