Another signalling problem from me...

[trains2]

Right, a new problem this time, unrelated from before.

I have been creating some new signals using TSM. I have made sure that the part properties bit has the 'light_' notation indicating that the part is to have lights on it. All exports fine, and the sigcfg and sigscr entries are all fine.

When I come to placing the signal in the RE however, and then running in MSTS, none of the lights appear. It shows up on the Track Monitor, but always as red, despite the scritping being exactly the same as another signal I am comparing with. I have tried moving the positions of the lights about several times, but still no show. The SigLight.ace file is also present and correct, so it cannot be that.

When comparing it to another signal, and indeed the signals in LSE, I can see no major differences that may cause this, so what on earth am I doing wrong?

If need be I can send the shape/texture/script files over to anyone who would like to see what I might be doing wrong, pm me in that case.

Regards

Rich

[laurie_heath]

Just one tought on this:

There is an entry under SignalSubObj ( usually (but not always) "HEAD1"
This is the name of the part in your signal shape relative to which the lights are placed.

If this is different to the name of the signal head part in your shape then the lights will not show.

[johny]

I assume you are constructing multiple-aspect signals using TSM, you do not need to use the light notation as signal lights and their positions and size, etc, are set in the sigcfg.dat file. You need to make the signal animated, the rotation for the head only needs to be set to zero, otherwise TSM gives you one matrix, 'Signal', whereas you require at least 'Signal' and 'Head1'. I usually make the head a very small two-sided object (4 polys) and hide it at the correct height within the signal. The reason for using animation is exactly the same as for creating LODs with Polymaster, otherwise, when you "Create TS Object File", TSM joins all your subobjects together. You can then remove the Animations from the shape file by editing in WordPad, once the signal is working.

John

[trains2]

Just one tought on this:

There is an entry under SignalSubObj ( usually (but not always) "HEAD1"
This is the name of the part in your signal shape relative to which the lights are placed.

If this is different to the name of the signal head part in your shape then the lights will not show.

Genius! Something as simple as that, thank you very much Laurie, and thanks John for the input.

Rich

[trains2]

I think I'll keep this as my signalling problem/info thread.

Moved onto Route Feathers at the weekend, and have managed to get single feathers to work fine (ignore the alpha trouble)




But have now moved onto Double route feathers, which poses a bit more a problem.

SigType for Left Hand feather followed by Right Hand feather, these both relay back to the Double feather as well as Single:

Code: Select all

SignalType ( "Feather1LH"

		SignalFnType ( DISTANCE )
		SignalLightTex ( "ltex" )

		SignalLights ( 6
			SignalLight ( 0 "White Light"
				Position ( 0 0 0 )
				Radius ( 0.001  )
			)
			SignalLight ( 1 "White Light"
				Position ( 0.017 4.36 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 2 "White Light"
				Position ( 0.115 4.46 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 3 "White Light"
				Position ( 0.220 4.56 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 4 "White Light"
				Position ( 0.317 4.66 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 5 "White Light"
				Position ( 0.415 4.76 0.002 )
				Radius ( 0.4 )
			)
		)
		SignalDrawStates ( 2
			SignalDrawState ( 0
				"Blank"
				DrawLights ( 1
					DrawLight ( 0 )
				)
			)
			SignalDrawState ( 1
				"Show"
				DrawLights ( 5
					DrawLight ( 1 )
					DrawLight ( 2 )
					DrawLight ( 3 )
					DrawLight ( 4 )
					DrawLight ( 5 )
				)
			)
		)
		SignalAspects ( 0
		)
	)

	SignalType ( "Feather1RH"

		SignalFnType ( DISTANCE )
		SignalLightTex ( "ltex" )

		SignalLights ( 6
			SignalLight ( 0 "White Light"
				Position ( 0 0 0 )
				Radius ( 0.001  )
			)
			SignalLight ( 1 "White Light"
				Position ( -0.017 4.36 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 2 "White Light"
				Position ( -0.115 4.46 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 3 "White Light"
				Position ( -0.220 4.56 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 4 "White Light"
				Position ( -0.317 4.66 0.002 )
				Radius ( 0.4 )
			)
			SignalLight ( 5 "White Light"
				Position ( -0.415 4.76 0.002 )
				Radius ( 0.4 )
			)
		)
		SignalDrawStates ( 2
			SignalDrawState ( 0
				"Blank"
				DrawLights ( 1
					DrawLight ( 0 )
				)
			)
			SignalDrawState ( 1
				"Show"
				DrawLights ( 5
					DrawLight ( 1 )
					DrawLight ( 2 )
					DrawLight ( 3 )
					DrawLight ( 4 )
					DrawLight ( 5 )
				)
			)
		)
		SignalAspects ( 0
		)
	)

Shapes for the Double feather only:

Code: Select all

SignalShape (
		"sigfeather_1LH_1RH.s"
		"1 LH 1 RH Signal Feather"
		SignalSubObjs ( 2
			SignalSubObj ( 0
				"FEATHERLH1"
				"Signal Feather LH1"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( JN_LINK )
				SigSubSType ( "Feather1LH" )
			)
			SignalSubObj ( 1
				"FEATHERRH1"
				"Signal Feather RH1"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK )
				SigSubSType ( "Feather1RH" )
			)
		)
	)

Interestingly, I can get the first feather head of the double to work, 'FEATHERLH1', but no the second one, 'FEATHERRH1', so I'm 1/2 way there.

I have built the double feather head by just combining the left and right feathers in TSM, so the naming is correct. But I cannot work out why the lights show for Left Hand but not Right Hand, even though the Right Hand on its own shows up fine.

Regards

Rich

[johny]

Don't want to put a dampener on things, but you are really going over old ground.

Tony Formoso has a kit of feathers and suchlike which are simply added to existing signals. Others, including myself, have built colour-light signals complete with integral feathers. Rob Thorburn, Alan Thompson and Edmund Kinder all built MAS kits with feathers in the early days of MSTS, sadly only one is currently available for download, Edmund Kinder's Early BR Colour Light Signals.

About the only two things that can't be done satisfactorily are approach control and, in the realm of semaphores, calling on and limit of shunt signalling, which is why we all hope for better things with TMTS and KRS.

Having said that, don't let me put you off, I keep on finding different ways of doing things, but they are generally within the existing scripting.

John

[trains2]

John, I am aware of the already available ones, but they are for a payware add-on, so I cannot use any freeware things, everything has to be done from scratch, except for the odd bit of scritpting that can be used as a template.

I cannot use the files for the other feathers because mine ar built in a different way. Whereas Tonys (I think) use the idea of having a base piece, and then adding the feathers to suit needs of the junction, I am creating seperate pieces for each feather combination, e.g. 1 left 1 right, 3 left 1 right etc. Although it adds more shapes, you can make the shapes much more accurate, with Tonys version, the centre light is ommited shared by all feathers is unable to be made or the 3L and 3R feathers would fowl the actual signal head.

[johny]

That puts a different complexion on things, which is why, for example, I used white lights for the matrix signs at Woking on the BATS Southern Region, whereas others have used texture files.

I wish you well.

John

[timbooth]

I think your problem is because you have made the right feather optional - I'm not sure if that feather can/will be linked. The SigSubJnLinkIf parameter should be used with optional heads.

Really, you'd be better off appending the feathers to the aspect signal shape - then setting those as both optional links, because at the moment the left one must always be present and linked. With two optional heads, you have a choice of left, right, and left+right feathers.

Also, using Distance as the signal type is not advisable since the feathers will operate/appear as a distant signal type - which could ruin signalling in the area. The INFO signal type ought to be used, so they don't interfere with anything.

The only problem with the INFO signal type is that it must be proceeded by at least one NORMAL signal type - otherwise it locks up MSTS. If you ever want to place an INFO signal where there is no preceeding NORMAL type, then the solution is to place a dummy/hidden NORMAL signal at the start of each track path before the INFO signal - facing towards the INFO signal.

[trains2]

I think your problem is because you have made the right feather optional - I'm not sure if that feather can/will be linked. The SigSubJnLinkIf parameter should be used with optional heads.

Really, you'd be better off appending the feathers to the aspect signal shape - then setting those as both optional links, because at the moment the left one must always be present and linked. With two optional heads, you have a choice of left, right, and left+right feathers.

Also, using Distance as the signal type is not advisable since the feathers will operate/appear as a distant signal type - which could ruin signalling in the area. The INFO signal type ought to be used, so they don't interfere with anything.

The only problem with the INFO signal type is that it must be proceeded by at least one NORMAL signal type - otherwise it locks up MSTS. If you ever want to place an INFO signal where there is no preceeding NORMAL type, then the solution is to place a dummy/hidden NORMAL signal at the start of each track path before the INFO signal - facing towards the INFO signal.

Thanks Tim,

Firstly, the second one was a JN_LINK as well, but that didn't work, so I tried OPTIONAL JN_LINK, didn't work either. I'll try your way of making them both OPTIONAL JN_LINK, see what happens.

Secondly, this is based on the UK RI feathers pack available of UKTS, and that uses DISTANCE as a signal type, and I have never experianced any problems with it when using on freeware routes.

UK Indicator Signals Kit V2.1 (Update) [108863 bytes] - INDSIG21.ZIP File ID: 8739 Date: 01 Apr 2004 - 696 Downloads

Rich

[timbooth]

The other thing to do is make sure the right feather is linked to the right-hand junction. I've occassionally found RE has not kept the link assignment when saving.

[timbooth]

Although the DISTANCE signal type may work in most situations, if there was a preceeding script that looked for the next distant signal then it would see the feather signal as the next distant rather than the next actual distant signal (if the route was set). With INFO type, not only can you avoid any possible interaction, but you can write scripts to look for INFO type signals if you want to repeat them or alter a proceeding signal.

The SHUNTING type is another type thats probably not used much - this type appears to act the same as INFO, but I suspect the reason for the specific type is so that you can write scripts to look for SHUNTING signals specifically, overlooking any INFO type signals inbetween. This gives you two layers of non-interactive signal types.

[trains2]

The OPTIONAL JN_LINK thing didn't work, will have to try something else.

I have never experianced a 'jumpy' link where is hasn't saved correctly, but is there a way of checking? I would've thought it would be ok as you can't exit the RE unless all Junction links are set up.I have just changed the oder of the shapes around, as so:

Code: Select all

SignalShape (
		"sigfeather_1LH_1RH.s"
		"1 LH 1 RH Signal Feather"
		SignalSubObjs ( 2
			SignalSubObj ( 0
				"FEATHERRH1"
				"Signal Feather RH1"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK )
				SigSubSType ( "Feather1RH" )
			)			
			SignalSubObj ( 1
				"FEATHERLH1"
				"Signal Feather LH1"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( JN_LINK )
				SigSubSType ( "Feather1LH" )
			)
		)
	)

Now the right hand one lights but the left doesn't, even though that is now the OPTIONAL JN_LINK which is lightig, whereas before it was JN_LINK that would light. So it's more about the order of things that scripting.

Rich

--edit--

Just edited all feathers to INFO, no effect at all, but shall keep it that way as it seems to be better scripting wise.

[timbooth]

With optionally linked signals, RE probably won't complain if the link isn't set for an optional head.

Just try and reapply the link, it will show the current state so you know if it needs changing/applying.

Also, try deleting and replacing the signal shape - just as the tdb links to the sigcfg file, so do world file entries. The signal entry stores references to linked paths for each head, so if you alter the head order/setup the world file signal entry won't match.

You should not really have a problem setting up more than one feathers.

I've only set up semaphores, but the principles are the same - here's my config for a GWR backing signal with a mechanical route indicator (3 routes).

Code: Select all

SignalShape (
		"dnsr_signal_backing_ri3.s"
		"Backing signal with Route Indicator (3x)"
		SignalSubObjs ( 4
			SignalSubObj ( 0
				"HEAD1"
				"Stop Arm"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( DEFAULT )
				SigSubSType ( "dnsrBacking" )
			)
			SignalSubObj ( 1
				"HEAD2"
				"Route Indicator 1"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK )
				SigSubSType ( "dnsrRI" )
			)
			SignalSubObj ( 2
				"HEAD3"
				"Route Indicator 2"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK )
				SigSubSType ( "dnsrRI" )
			)
			SignalSubObj ( 3
				"HEAD4"
				"Route Indicator 3"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK )
				SigSubSType ( "dnsrRI" )
			)
		 )
	)

This isn't a finished signal, as the links shouldn't be optional but it helped when testing not to have to set all three 3 routes to prevent RE complaining.

[trains2]

I think I've found the problem, its the Hierarchy.

Comparing it to the MT signals:



So the shape has somehow combined into one, even though in TSM I separated the shapes, so the left feather is FEATHERLH1 and the right is FEATHERRH1.

How do you get it to be two separate shapes within the project? I thought you jsut had to have them separate from each other and name them differently, obviously not.

Rich