I think we need another semaphore (Philiskene? Anyone?)

frogpipe

Yesterdayz Trainz Member
(I am not counting non-DLS content)

In TS12 we have 2 United States type animated semaphores, there are other's but they have troubles or are not animated.

Signal US&S type B Block/Distant Semaphore TS2010,<kuid2:69871:2064:1>
Signal US&S type B Home/Distant Semaphore TS2010,<kuid2:69871:2065:1>

Both are in essence, Signal USA 04,<kuid:-1:100880> but as a semaphore rather then a searchlight.

I'd like to have at least one other available, and 02 type which would show divergence.

My research shows that US&S Style B semaphores were in numerous configurations, but for this I am thinking what we'd want is a 2 Blade, 3 Position. Where both are "Home" (square ended red) blades. The top one showing "Stop, Caution, and Proceed" for the left branch and the lower one showing "Stop, Caution, Proceed" for the right branch.

Ultimately, there would be TWO, one for right divergence and one for left divergence.

I would tackle this myself, but the aforementioned semaphores are all one mesh with a *.kin animation - so one would need access to the source files for this.

I thought I would find one mesh for the pole and others for each blade, but that wasn't the case....

Is this nuts? Was there some other method used when a Mainline split into two directions in the days of semaphore signals? My research has shown little information, but what little I found seems to indicate that my idea is indeed what was done (or two mechanisms were mounted side by side on a bracket).
 
Regarding the 3-position blade--

Content creator experts please correct me if I'm wrong about this, but apparently an animation file can only have two endpoints (i.e. the animated object can go from position A to position B or vice versa). This means that a 3-position animated semaphore is not possible with the current engine, hence the many (very good) U.S. semaphores that "click" from one position to another without intermediate animation.

The lower quadrant semaphores (such as the US&S type B Block/Distant Semaphore) only had two positions per blade (horizontal or slanted downwards) so don't suffer from this limitation.

And don't get me wrong--I'd LOVE to be proven wrong on this...

--Lamont
 
Dunno much about the engine (TS12) but as for the Style B, it did come as a 3 position. http://www.semaphores.com/USSSB.PDF which is a reformat of a 1925 manual clearly shows this, as does another PDF I have which is a catalog from 1909.

Single Blade, 2 Position
Single Blade, 3 Position
Dual Blade, 2 Position
Dual Blade, 3 Position

Are all listed as options (for a whopping $300-$400 dollars, LOL)

I think that's why the 2 Position ones had 3 spectacles - tho I would also mention that the DLS one's are incorrect in this regard. The manual again shows the in the case of the 2 blade, 2 position unit the blades were Red-Red-Green over Yellow-Yellow-Green, NOT Red-Yellow-Green over Red-Yellow-Green. But that's a minor detail.
 
Notes on Semaphores

Based strictly on my own experience building US semaphores in TS2009...

First, it is perfectly possible for an animation to have more than two positions - in fact, one with a range of 30 frames can have more than 30 different positions (since you specify the desired endpoint as a floating number). The game will interpolate for you. This assumes use of a script, of course, which is not required for searchlight signals.

Second, it is also possible to have a semaphore signal with multiple aspects, with no animation at all. You just need multiple meshes in the asset, and display the current one via script. This lacks the interesting motion of the fully animated version, but is simpler to script (IMHO) and gets the job done just as well from any distance.

Examples: <KUID:520526:1492>, which is a USA 02L semaphore, two arms each with three positions. It is scripted with each possible aspect having a distinct meaning. Only complaint I've ever had about it is that the original version was too far from the line. This is a New Haven semaphore, so it's left-handed. <KUID2:61556:2410142:1> is one of seniorchief's wide range of semaphores, in this case right-handed and a much better model than mine.

Discussion: IMHO many of the scripts written for animated semaphores get too complicated by trying to generalize with libraries, heirarchical scripts, matrices and so forth. The snap-action (non-animated, using variant meshes) script could be fairly easily made to work with animated meshes if you're willing to just tell it where to go (fire and forget, as it were) instead of trying to find out when it's through moving. Just change the light color with a reasonable delay when you send the arm on its way to its next position, I say - if another change is required while it's still in motion, just tell it its new destination and let it go.
 
Perhaps something here would help your research?

http://books.google.com/books?id=6wt...age&q=&f=false

Automatic Block Signals and signal circuits. Circa 1908

Full View, PDF downloadable,.

Lots of drawings of Signal equipment.

Semaphores and support equipment.


http://books.google.com/books?id=Tm0...age&q=&f=false

The Railroad signal dictionary. circa 1908

Full Version, PDF available.

Lots of pics and drawings.


http://books.google.com/books?id=1oU...age&q=&f=false

Railroad Signaling:Automatic. Circa 1922

Full version, PDF available.

Pics and drawings.


http://books.google.com/books?id=Z7k...age&q=&f=false

Railroad Signaling. Circa 192. Mcgraw-Hill

Full version, PDF available.

Pics and drawings.



The railway signal dictionary
http://books.google.com/books?id=vpJ...page&q&f=false
 
Last edited:
Um, the whole point was that I am not prepared to go head first into the scripting (they CAN be made to rotate via a script, I've seen it - B&M US&S Style B Semaphore or something like that, does not appear to use a *.kin file) nor modeling them.

Could I? Probably, but it would be a steep learning curve for a guy who is amazed when he get's an industry script or numberit config right... :D

So far I've managed to model some buildings, but nothing as intricate as a style B semaphore.

In addition to all that, for ME animation is a must, otherwise it might was well be a searchlight signal. I understand the desire for snapscripted signals, and I do not think evil of those who like them, but for ME they are inadequate.
 
Need built-in

Um, the whole point was that I am not prepared to go head first into the scripting (they CAN be made to rotate via a script, I've seen it - B&M US&S Style B Semaphore or something like that, does not appear to use a *.kin file) nor modeling them.

Could I? Probably, but it would be a steep learning curve for a guy who is amazed when he get's an industry script or numberit config right... :D

So far I've managed to model some buildings, but nothing as intricate as a style B semaphore.

In addition to all that, for ME animation is a must, otherwise it might was well be a searchlight signal. I understand the desire for snapscripted signals, and I do not think evil of those who like them, but for ME they are inadequate.

Sounds like what you're asking for is a built-in Trainz functionality which handles semaphore signals something like pantographs: name things correctly and if certain named meshes and an anim.kin are in the asset, it does its thing without a script. That's a good suggestion for future versions. Alternatively, someone could develop a completely vanilla script which would work that way: here the problem again becomes over-generalization, hence over-complexity in the generic script as well as having to deal with Trainzscript's tendency to crash uninformatively when some (but not all) required items are not exactly what it expects. By analogy with a pantograph, you might have a faux pantograph asset which is actually the moving semaphore arm and its animation file, with all names exactly the same for all examples. Interesting idea.
 
Back
Top