[edwardk]

PT is evidently payware. Are there any semaphores with the same problem that can be downloaded?


Edward K.

[Mike B]

I don't have a German route to check at the moment, but possibly similar issues occur with the semaphores on the Glorieta Pass and Raton Pass routes from trainsim.com. Semaphore signals show correct light colors, but the blades don't move. I do have the "HOR-GEO Electric" route from railserve, but not currently installed; may check that one out to see if it has blades and whether they work.

The Glorieta and Raton blades work correctly in MSTS, but not in OR.

[roeter]

Semaphore arms not moving or shown in the wrong position is an 'old' problem which has been around for a long time and has been discussed frequently.
The most common cause is that the animation counter in the shape file does not start with 0. MSTS can handle this, OR can not.
Another possible cause is mismatch between the animation counters in the shape file and the numbers used in the sigcfg file for the semaphore positions. MSTS simply takes the lowest number as referenced and links it to the first animation etc. OR tries to use the actual animation linked to that number.
It's difficult to change given the way the data has been defined. And it has nothing to do with the signalling as such - it is merely a display problem.
Sometimes changing the semaphore position numbers in the sigcfg file can sort the problem.

Regards,
Rob Roeterdink

[Rogue]

I just corrected a PT sigcfg-file and that really was the reason for the incorrect semaphores.

But that probably doesn't solve the problems mentioned on the first side...the missing gantries and shapes.
Does someone has any ideas so far ?

[eugenR]

Rogue, on 27 July 2014 - 02:14 AM, said:

But I can't see any obvious pattern when a faulty signal is shown and when not.
And the problem exists in most Pro Train AddOns (my picture is from PT10 Deluxe).

see bug report:
https://bugs.launchp...or/+bug/1398081

[roeter]

There are two separate, and completely unrelated, problems with various German signals.

The first problem is missing parts in the static part of the signal, i.e. masts, platforms etc.
This is the problem referenced by Eugen in the bug report mentioned above.

I had a look at this, and it seems to be related to the hierarchy of the structure. That's something I know nothing about - so I would like to request someone with extensive knowledge of shape files to have a look at this.
It does explain, however, why it does effect only specific signals - it just depends on how the signal was build. Some signals may look the same 'from the outside', but may have different internal hierarchy structures which can cause problems.

The second problem, which I noticed myself on a distant signal on the "Mosel strecke", is incorrect animation of some of the moving signal parts - in case of that distant, the shield moved but the lamps did not.
That problem is caused by the fact that the moving part consists of multiple matrices, but OR only supports single matrix moving parts.
That problem has now been corrected, and version 2675 now can handle signals with moving parts which consist of multiple matrices.

Regards,
Rob Roeterdink

[eugenR]

roeter, on 02 December 2014 - 03:54 AM, said:

It does explain, however, why it does effect only specific signals - it just depends on how the signal was build. Some signals may look the same 'from the outside', but may have different internal hierarchy structures which can cause problems.

Right Rob, there must be a special built of the shape:
If I enter in the sigcfg.dat in every SignalSubobj of the Signal the line:
SignalFlags ( DEFAULT OPTIONAL )
I can delete every of the three parts of the shape SIGNAL, HEAD1, HEAD2 (but not all together, then MSTS crash)

[eugenR]

If I place the same Signal-shape as static-shape on the route, also OR display the complete shape
see the second signal-shape without lights in the Picture.

Attached thumbnail(s)

• 

[eugenR]

Also the animated part, numbers in the triangle box (Picture thread #18), is blinking

[eugenR]

In the shape the block lod_controls begin with:
lod_controls ( 1
lod_control (
distance_levels_header ( 0 )
distance_levels ( 1
distance_level (
distance_level_header (
dlevel_selection ( 1000 )
hierarchy ( 10 -1 0 0 2 2 2 2 2 2 2 )
)
sub_objects ( 3
sub_object (
sub_object_header ( 00000400 -1 -1 000001d2 000001c4
geometry_info ( 24 6 0 72 0 0 6 0 0 0
geometry_nodes ( 6
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
geometry_node ( 1 0 0 0 0
cullable_prims ( 1 4 12 )
)
)

geometry_node_map ( 10 -1 -1 -1 0 -1 1 2 3 4 5 )

the first sub object (.... is the block of the animated HEAD2, the numbers in the Triangle.
the second block is the signal-pole "SIGNAL" which OR can not display (but is correct displayed in MSTS)

If I change the places of this two blocks in the shape, first the block of the signal-pole "SIGNAL"
and then the block "HEAD2":

The Signal-pole "SIGNAL" is now correct displayed, but OR can now the animated "HEAD2" not display, in MSTS also with this modified shape the signal is correct displayed.