KIND MOSignal - Revision history

Glt0145: /* TBD */

2018-04-13T03:23:20Z

TBD

← Older revision		Revision as of 03:23, 13 April 2018
Line 92:		Line 92:
	Tile=st		Tile=st

	This style of referencing will also work with TS12. Each of the coronas must ~~hav~~ a solid background and not transparent.		This style of referencing will also work with TS12. Each of the coronas must have a solid background and not transparent.

	===Notes on the default signalling logic===		===Notes on the default signalling logic===

Glt0145: /* TBD */

2018-04-13T03:22:39Z

TBD

← Older revision		Revision as of 03:22, 13 April 2018
Line 69:		Line 69:
	So the above example would read		So the above example would read

	lights

			lights
	{		{
	0		0

Glt0145: /* TBD */

2018-04-13T03:20:17Z

TBD

← Older revision		Revision as of 03:20, 13 April 2018
Line 85:		Line 85:
	}		}
	An example of the corona_red.texture.txt file would be		An example of the corona_red.texture.txt file would be

	Primary=red_corona.tga		Primary=red_corona.tga

	Tile=st		Tile=st

Glt0145 at 03:18, 13 April 2018

2018-04-13T03:18:18Z

← Older revision		Revision as of 03:18, 13 April 2018
Line 65:		Line 65:
	}		}


			Note: To comply with TANE onwards creators need to reference the corona via a texture.txt file for example "corona_red.tga" in the config file would need to read "corana_red.texture"
			So the above example would read

			lights
			{
			0
			{
			corona "corona_green.texture"
			}
			1
			{
			corona "corona_yellow.texture"
			}
			2
			{
			corona "corona_red.texture"
			}
			}
			An example of the corona_red.texture.txt file would be
			Primary=red_corona.tga
			Tile=st

			This style of referencing will also work with TS12. Each of the coronas must hav a solid background and not transparent.

	===Notes on the default signalling logic===		===Notes on the default signalling logic===

Pcas1986: Added sort criterion

2014-02-14T05:03:07Z

Added sort criterion

← Older revision		Revision as of 05:03, 14 February 2014
Line 139:		Line 139:

	==Categories==		==Categories==
	[[Category:Asset KIND]]		[[Category:Asset KIND\|M]]
	[[Category:TBD]]		[[Category:TBD]]

Windwalkr at 12:08, 10 February 2013

2013-02-10T12:08:27Z

← Older revision		Revision as of 12:08, 10 February 2013
Line 13:		Line 13:


	==TBD===		==TBD==
	Config entries specific to signals are:		Config entries specific to signals are:

Windwalkr at 11:50, 10 February 2013

2013-02-10T11:50:13Z

← Older revision		Revision as of 11:50, 10 February 2013
Line 1:		Line 1:
	~~''Warning: This page is~~ a ~~work in progress~~ and ~~any details or metrics included here may be subject to change as TS2009 development continues~~.''		[[KIND MOSignal]] provides a rail signal asset of a specific type. These assets are placed on a track and interact with the Trainz signalling system.

	~~Classics 3 introduced an updated Signalling system, which is being extended further for TS2009.~~

			=KIND Hierarchy=
			==Parent Classes==
			* [[KIND TrainzBaseSpec]]
			==Child Classes==
			* ''none.''

			==Supported Tags==
			TBD.



			==TBD===
	Config entries specific to signals are:		Config entries specific to signals are:

Line 121:		Line 132:
	ApplyUpdatedState takes a soup in the same format (though it only cares about the state, not the reason), and from that, sets up the visual representation of the signal as required. This is very useful for animated signals (e.g. semaphores).		ApplyUpdatedState takes a soup in the same format (though it only cares about the state, not the reason), and from that, sets up the visual representation of the signal as required. This is very useful for animated signals (e.g. semaphores).

	~~HEALTH~~ WARNING: It is VERY easy to totally destroy the performance of Trainz using these functions. ~~In Classics 3, they are called twice a second for every signal in~~ the ~~map, so they need to be very fast~~ and efficient.		WARNING: It is VERY easy to totally destroy the performance of Trainz using these functions. Please be careful to perform only the necessary calculations and use efficient data structures and algorithms.

	~~FUTURE BUG~~ WARNING: ~~Do NOT rely on the half second interval between updates. TS2009~~ does not ~~call~~ signals every half a second. It calls them when it believes they might want to change based on what they queried via GSTrackSearch in their DetermineUpdatedState phase. This could result in intervals of minutes at a time without an update. (This does not, however, mean you can be any less efficient - signals may still be called up to twice a second).		WARNING: Trainz does not update signals on a regular basis such as every half a second. It calls them when it believes they might want to change based on what they queried via GSTrackSearch in their DetermineUpdatedState phase. This could result in intervals of minutes at a time without an update. (This does not, however, mean you can be any less efficient - signals may still be called up to twice a second).

	~~SECOND HEALTH~~ WARNING: Do NOT make a [[KIND Scenery-trackside]] object a subclass of 'Signal' in script. This will cause script errors. The correct TrainzScript class for a Scenery-Trackside object is 'Trackside'.		WARNING: Do NOT make a [[KIND Scenery-trackside]] object a subclass of 'Signal' in script. This will cause script errors. The correct TrainzScript class for a Scenery-Trackside object is 'Trackside'.

	==Categories==		==Categories==
	[[Category:Asset KIND]]		[[Category:Asset KIND]]
			[[Category:TBD]]

Windwalkr at 08:51, 18 October 2010

2010-10-18T08:51:44Z

← Older revision		Revision as of 08:51, 18 October 2010
Line 5:		Line 5:
	Config entries specific to signals are:		Config entries specific to signals are:

	~~[[TagName_Kind\|~~kind]] mosignal		kind mosignal
	~~[[TagName_Type\|~~type]] Trackside		type Trackside
	~~[[TagName_Function\|~~function]] TrackSignal		function TrackSignal
	~~[[TagName_Trainz-build\|~~trainz-build]] 2.8		trainz-build 2.8
	~~[[TagName_Distant\|~~distant]] 0		distant 0
	~~[[TagName_Home\|~~home]] 0		home 0
	~~[[TagName_Repeater\|~~repeater]] 0		repeater 0
	~~[[TagName_Always-controlled\|~~always-controlled]] 0		always-controlled 0
	~~[[TagName_Double-blocking\|~~double-blocking]] 0		double-blocking 0
	~~[[TagName_Overlap\|~~overlap]] 183		overlap 183
	~~[[TagName_Overlap-track-circuited\|~~overlap-track-circuited]] 1		overlap-track-circuited 1
	~~[[%22Signals%22_container\|~~signals]] {		signals
	1 {		{
			1
			{
	light 2		light 2
	speed 6.71		speed 6.71
	}		}
	4 {		4
			{
	light 1		light 1
	}		}
	7 {		7
			{
	light 1		light 1
	flash 1		flash 1
	flash-offset 0		flash-offset 0
	}		}
	8 {		8
			{
	light 0		light 0
	}		}
	}		}
	~~[[%22Lights%22_container\|~~lights]] {		lights
	0 {		{
			0
			{
	corona "corona_green.tga"		corona "corona_green.tga"
	}		}
	1 {		1
			{
	corona "corona_yellow.tga"		corona "corona_yellow.tga"
	}		}
	2 {		2
			{
	corona "corona_red.tga"		corona "corona_red.tga"
	}		}
Line 74:		Line 83:
	Remember to call inherited(); in your Init() method: (THIS IS IMPORTANT!)		Remember to call inherited(); in your Init() method: (THIS IS IMPORTANT!)

	void Init(void) {		void Init(void)
			{
	inherited();		inherited();

			// your code goes here ..

			}

	and then override the function 'DetermineUpdatedState' like this:		and then override the function 'DetermineUpdatedState' like this:

	Soup DetermineUpdatedState(void) {		Soup DetermineUpdatedState(void)
			{
	Soup sigSoup = inherited();		Soup sigSoup = inherited();

Line 88:		Line 103:
	to implement custom logic, and/or the function 'ApplyUpdatedState' like this:		to implement custom logic, and/or the function 'ApplyUpdatedState' like this:

	void ApplyUpdatedState(Soup sigSoup) {		void ApplyUpdatedState(Soup sigSoup)
			{
	inherited(sigSoup);		inherited(sigSoup);

Windwalkr: 1 revision

2010-02-03T13:59:13Z

1 revision

← Older revision	Revision as of 13:59, 3 February 2010
(No difference)

Bloodnok: /* Custom Logic */

2008-12-17T22:48:29Z

Custom Logic

New page

''Warning: This page is a work in progress and any details or metrics included here may be subject to change as TS2009 development continues.''

Classics 3 introduced an updated Signalling system, which is being extended further for TS2009.

Config entries specific to signals are:

[[TagName_Kind|kind]] mosignal
[[TagName_Type|type]] Trackside
[[TagName_Function|function]] TrackSignal
[[TagName_Trainz-build|trainz-build]] 2.8
[[TagName_Distant|distant]] 0
[[TagName_Home|home]] 0
[[TagName_Repeater|repeater]] 0
[[TagName_Always-controlled|always-controlled]] 0
[[TagName_Double-blocking|double-blocking]] 0
[[TagName_Overlap|overlap]] 183
[[TagName_Overlap-track-circuited|overlap-track-circuited]] 1
[[%22Signals%22_container|signals]] {
1 {
light 2
speed 6.71
}
4 {
light 1
}
7 {
light 1
flash 1
flash-offset 0
}
8 {
light 0
}
}
[[%22Lights%22_container|lights]] {
0 {
corona "corona_green.tga"
}
1 {
corona "corona_yellow.tga"
}
2 {
corona "corona_red.tga"
}
}

===Notes on the default signalling logic===

The signalling system now knows about, and uses, a lot more states than it did previously. This means you have to be a lot more careful of including the correct states in your signals than you did before.

If a signal is supposed to be permissive, include state '1' rather than state '0'. The Autopilot will now treat it as a permissive signal, and drive past it, queueing up behind the train in the next section.

A distant signal should not include state '0' or '1' at all.

A fixed distant can be made by specifying 'distant 1' and including only state '4'. All trains approaching (whether the line ahead is clear or not) will slow down when approaching it.

A repeater should not show state '0' - use state '1' for this instead, otherwise the Autopilot will stop at the repeater, and not at the signal it is repeating.

Some signalling systems (such as cab signalling systems or automatic train operation systems) use two danger indications in rear of a train, as they cannot prevent trains from passing the start of a block, only stop them once they have entered. To reproduce this behaviour, include both state '0' and state '1' in your signal, and use the double-blocking tag. This will give a (permissive) safety block, with an absolute stop indication at the end of it, which should produce the correct behaviour for both the human driver and the Autopilot.

If you want a particular state, but don't have a light to use for it, use "light -1". This is enough to make the state valid, but not use a light for that state.

If you don't specify any states at all, the signal is assumed to be a Pre-v1.3 style signal, which can display Stop, Caution and Proceed via the attachments a.red, a.orange, and a.green. This behaviour is deprecated - so please don't rely on it. It's main use at present appears to be buffer stops and fixed distant boards, which don't actually have the attachment points anyway. I suggest taking advantage of the 'light -1' behaviour to add specific relevant states to these kind of signals. (Fixed buffer stops should have state 0 only, fixed distants state 4 only, and the 'distant 1' tag).

===Custom Logic===

Signals can implement custom logic in script, should the improved default logic not be adequate for the signalling system being modelled. Make your signal script a subclass of 'Signal' like this:

include "signal.gs"

class MyCustomLogicSignal isclass Signal {

Remember to call inherited(); in your Init() method: (THIS IS IMPORTANT!)

void Init(void) {
inherited();

and then override the function 'DetermineUpdatedState' like this:

Soup DetermineUpdatedState(void) {
Soup sigSoup = inherited();

// your code goes here ...

}

to implement custom logic, and/or the function 'ApplyUpdatedState' like this:

void ApplyUpdatedState(Soup sigSoup) {
inherited(sigSoup);

// your code goes here ...

}

to implement custom state display.

Note: You do not need to override both functions. You can override only one if that is all you need to do. I expect a lot of people will want to override 'ApplyUpdatedState' but not need to override 'DetermineUpdatedState'.

The soup that DetermineUpdatedState needs to return contains two records - the integer tag "state" set to one of the signal display states, and the string tag "reason" set to the reason string to use. Default strings are available in Trainz - these are called up by name (starting with a dollar sign) - e.g. "$signal_nextblockbusy_lbl". If none of the default strings are appropriate, you can load a string from the asset's string table in the usual way and pass that in directly.

The soup that you get back from inherited(); will have the values that the default logic thinks you should use, so you can implement specific cases and allow the "default" values through if those cases are not hit.

ApplyUpdatedState takes a soup in the same format (though it only cares about the state, not the reason), and from that, sets up the visual representation of the signal as required. This is very useful for animated signals (e.g. semaphores).

HEALTH WARNING: It is VERY easy to totally destroy the performance of Trainz using these functions. In Classics 3, they are called twice a second for every signal in the map, so they need to be very fast and efficient.

FUTURE BUG WARNING: Do NOT rely on the half second interval between updates. TS2009 does not call signals every half a second. It calls them when it believes they might want to change based on what they queried via GSTrackSearch in their DetermineUpdatedState phase. This could result in intervals of minutes at a time without an update. (This does not, however, mean you can be any less efficient - signals may still be called up to twice a second).

SECOND HEALTH WARNING: Do NOT make a [[KIND Scenery-trackside]] object a subclass of 'Signal' in script. This will cause script errors. The correct TrainzScript class for a Scenery-Trackside object is 'Trackside'.

==Categories==
[[Category:Asset KIND]]