[eugenR]

TSRE5 show the Signalshapes in the Editor independent of the selected options.
It show the default and the default-optional parts of the shape as it is given in sigcfg.dat
MSTS-RE show the shapes with the options as they are selected
The Signalkopf Ausfahrsignal (Distantsignal) and Hilfssignal are not selected, but anyway displayed.
 defaultoption.jpg (326.01K)
Number of downloads: 4

Would it be possible to show the signalshape as they are stored in the Worldfile:
Signal (
UiD ( 96 )
FileName ( CHLEinfahrsignalklein.s )
Position ( -279.146 1.23392 33.11 )
QDirection ( 0 0 0 1 )
VDbId ( 0 )
StaticDetailLevel ( 0 )
SignalSubObj ( 00002501 )
SignalUnits ( 3
SignalUnit ( 0
TrItemId ( 0 0 )
)
SignalUnit ( 8
TrItemId ( 0 1 )
)
SignalUnit ( 10
TrItemId ( 0 2 )
)
)
)

In this number 2501 is for every Part of the signal a bit
counting in the order as they are given in the sigcfg.dat and they are presented in the picture above,
the last bit stand for the part on the top of the Window above
(1 = select, 0= unselect)
2 5 0 1
0010 0101 0000 0001

Thank you for your great Work with this new editor
EugenR

[Goku]

Signals shapes always look the same in editor, because TSRE rendering supports only static .s file shapes. No enabling/disabling parts, no animations.
But don't worry about it, TSRE properly sets SignalSubObj flags in TDB.

Better shape display is something to do in the future.

--

It's nice that you are looking at TSRE signals. It would be nice if someone confirm that they are working ok in TSRE.

[eugenR]

Goku, on 12 December 2016 - 04:29 AM, said:

But don't worry about it, TSRE properly sets SignalSubObj flags in TDB.

Yes, I have seen, the data are saved correct.

eugenR

[Goku]

Now supported in new version.

[eugenR]

Goku, on 02 June 2017 - 11:39 AM, said:

Now supported in new version.

Hi Goku, Thank You for your work!

I have tested the shape-display. It seams something is not correct?
This Signal is showing without Main and Distance-Signal-Head:
 Signal.jpg (457.63K)
Number of downloads: 6
This signalheads are in the sigcfg.dat the HEADs 0 and 4
In the worldfile I has found:
Signal (
UiD ( 436 )
FileName ( CHLEinfahrsignal.s )
Position ( -880.702 1.10084 -386.94 )
QDirection ( 0 0 0 1 )
VDbId ( 4294967295 )
SignalSubObj ( 00000c51 )
SignalUnits ( 4
SignalUnit ( 0
TrItemId ( 0 183 )
00000c51 means from the Signal are used the SignalSubType ll00 0l0l 000l to read from right to left: SubType 0,4,6,10,11

If I select for test purpose the subtype 1 and 2 this will display the signal heads with SignalSubType 0 and 4 in the Sigcfg.dat
show here:
 Signal Option not correct.jpg (454.15K)
Number of downloads: 5

Regards
EugenR

[Goku]

Don't know how it should work.
My solution works only if signalsubobjs in sigcfg and shape matrices in .s file are in the same order.

[eugenR]

Goku, on 02 June 2017 - 03:00 PM, said:

Don't know how it should work.
My solution works only if signalsubobjs in sigcfg and shape matrices in .s file are in the same order.

I think this condition is not correct?
MSTS and OR are finding the Shapepart to display as follow:
Worldfile:
SignalSubObj ( 00000c51 ) define the used SignalSubObj of the sigcfg.dat, here 0,4,6,10,11

First Part Sigcfg.dat of this signal with the SignalSupobj 0 and 4:
"CHLEinfahrsignal.s"
"CHL Einfahrsignal"
SignalSubObjs ( 15
SignalSubObj ( 0
"HEAD1"
"Signalkopf Einfahrt frei"
SigSubType ( SIGNAL_HEAD )
SigSubJnLinkIf ( 5 5 6 7 8 9)
SigSubSType ( "ChLEinfahrsignal" )
)
SignalSubObj ( 1
"AUSWAHL2"
"1.Route 40, beide 90 km/h"
SigSubType (USER2 )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 2
"AUSWAHL3"
"1.Route 60, beide 90 km/h"
SigSubType (USER3 )
SignalFlags ( OPTIONAL )
)
SignalSubObj ( 3
"AUSWAHL4"
"weitere Fahrstrassen"
SigSubType (USER4 )
SignalFlags ( OPTIONAL )
)

SignalSubObj ( 4
"HEAD2"
"Signalkopf Ausfahrvorsignal"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( DEFAULT )
SigSubSType ( "ChLVorsignal" )
)

SignalSubObj ( 5
"HEAD5"
"Einfahrt frei"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( OPTIONAL JN_LINK )
SigSubSType ( "ChLEinffrei" )
)
MSTS and OR are reading the red written names in the sigcfg.dat if the SignalSubObj is of the type SigSubType ( SIGNAL_HEAD ) to find the right part in the matrices of the (attached) shape, there exist no order rule!
I hope You can find the problem.
Regards
EugenR.

Attached File(s)

•  CHLEinfahrsignal.zip (44.93K)
  Number of downloads: 4

[roeter]

eugenR, on 03 June 2017 - 12:25 AM, said:

MSTS and OR are reading the red written names in the sigcfg.dat if the SignalSubObj is of the type SigSubType ( SIGNAL_HEAD ) to find the right part in the matrices of the (attached) shape, there exist no order rule!
EugenR.

That is correct - the name of the SignalSubObj should be used as reference, not the sequence.
Also please note that SignalSubObj of type 'DECOR' need not actually exist in the shapefile at all - both MSTS RE and OR disregard such parts if they don't exist, but the selection flag is processed as normal. That allows such items to be defined in the signal definition and to be used as 'options' without the need to adept the shapefile.

Regards,
Rob Roeterdink

[Goku]

Then, how about shape matrices that are not in sigcfg file. Are these hidden by default, or always visible?

[eugenR]

Goku, on 04 June 2017 - 06:29 AM, said:

Then, how about shape matrices that are not in sigcfg file. Are these hidden by default, or always visible?

Me example in Post #7 is showing the following matrices:
matrices ( 5
matrix SIGNAL ( 1 0 0 0 1 0 0 0 1 0 0 0 )
matrix HEAD2 ( 1 0 0 0 1 0 0 0 1 0 3 -0.0200002 )
matrix HEAD1 ( 1 0 0 0 1 0 0 0 1 0 4 -0.0200002 )
matrix HILFSSIGNAL ( 1 0 0 0 1 0 0 0 1 0 0 0 )
matrix BESETZTSIGNAL ( 1 0 0 0 1 0 0 0 1 0 0 0 )
)

Every Signalhead witch should be switchable visible/hidden depending of the sigcfg.dat, in the shape-file they must be in separate Subobjects. The Subobject 0 is always displayed.

The example in Post #7 CHLEinfahrsignal.s has 3 SubObjects.
The Matrices "SIGNAL,HEAD1,HEAD2" belong to the Subobject 0 and are therefore always displayed.
(see Shape CHLEinfahrsignal.s in post #7, SubObjects) geometry_node_map ( 5 0 1 2 -1 -1 )

The Matrices HILFSSIGNAL belong to the Subobject 1
geometry_node_map ( 5 -1 -1 -1 0 -1 )
switchable by sigcfg.dat.

And the Matric BESETZTSIGNAL belong to the Subobject 2
geometry_node_map ( 5 -1 -1 -1 -1 0 )
switchable by sigcfg.dat.

Here the interesting part of sigcfg.dat:
SignalSubObj ( 10
"KENNUNG1"
"Kennung"
SigSubType ( SIGNAL_HEAD )
SigSubSType ( "CHLKennungNormal" )
)
SignalSubObj ( 11
"Hilfssignal"
"Hilfssignal"
SigSubType ( DECOR )
SignalFlags ( DEFAULT OPTIONAL )
)
SignalSubObj ( 12
"Besetztsignal"
"Besetztsignal"
SigSubType ( DECOR )
SignalFlags ( OPTIONAL )
)
As explicated in Post #7 in the Worldfile is defined, witch SignalSubObj are used for this Signal:
SignalSubObj ( 00000c51 )
00000c51 means from the Signal are used the SignalSubType ll00 0l0l 000l to read from right to left: SubType 0,4,6,10,11

SignalSubObj 0 and 4 (see Post #7)this can't switched of by Sigcfg.dat/Worldfile, because they are in the Shape in the SubObject 0 witch is always displayed

SignalSubObj 6 is an Option and has in sigcfg.dat the Name HEAD6. This name doesn't exist in the Matrices, nothing to display

SignalSubObj 10 has the Name "Kennung" , This Name doesn't exist in the Matrices, nothing to display.

SignalSubObj 11 has the Name "Hilfssignal", exist in the Matrices and is the Subobject 1, this is to display

SignalSubObj 12 doesn't exist in Worldfile, the Matric "Besetztsignal" witch is Subobject 2 is not to display.

I hope this example is showing the principle correct an complete.

Regards
EugenR

[Goku]

No. You didn't answered my question.
Then, how about shape matrices (subobjects) that are not in sigcfg file. Are these always hidden, or always visible?

[eugenR]

Goku, on 05 June 2017 - 09:14 AM, said:

No. You didn't answered my question.
Then, how about shape matrices (subobjects) that are not in sigcfg file. Are these always hidden, or always visible?

Sorry, so I will try to give you the Rules what parts of the shape are in witch condition to display:
For explication I have attached an other Shape (test.s) it has 8 Matrices and 5 Sub_Objects

1) matrices and Subobjects are different things, look for Sub_objects in the shape, a sub_Object can contain one or more Matrices.

2) The Sub_Object 0 is always to display, with all his matrices, here the Matrice 0 (SIGNAL) and 5 (HINTERPFOSTEN).
geometry_node_map ( 8 0 -1 -1 -1 -1 1 -1 -1 )

3) all other sub_Objects ( 1...4 ) are not to display,
Exeption: The Name of the Matrice with "0" in the geometry_node_map of a SubObject is found in a used SignalSubObj of sigcfg.dat. If the SignalSubObj is used you will find in the Worldfile.

Example in the attached shape:
Subobject 1
geometry_node_map ( 8 -1 -1 -1 0 1 -1 -1 -1
0 = HEAD1, 1 = Schirm1
Wenn HEAD1 is found in Sigcfg.dat and used (see Worldfile) this two Matrice are to display.
If only a SignalSubObj with the Name Schirm1 is used and not HEAD1, nothing of this Subobject is to display

Attached File(s)

•  test.zip (39.72K)
  Number of downloads: 5

[Goku]

I think it's too complicated. I have more questions than before.* I don't want to waste my time for making my own example .s files and checking how it works.
So if someone will explain me in details how subobject visibility works in .s files, it will be implemented. Otherwise, not.

* How geometry node values works, if one subobject can have many matrices, then visibility of subobj is "or" or "and" of matrices.

[Jovet]

Goku, on 05 June 2017 - 03:16 PM, said:

I think it's too complicated. I have more questions than before.* I don't want to waste my time for making my own example .s files and checking how it works.
So if someone will explain me in details how subobject visibility works in .s files, it will be implemented. Otherwise, not.

I could be wrong about all of this, but it's my understanding that an MSTS shape file can have 64 sub-objects (0-63) and more than one matrix can be assigned to any of these.

Based on that: for a signal, the main sub-object, sub-object #0, is always visible. All other sub-objects are hidden unless specifically called for by an active SignalSubObj entry. When a SignalSubObj specifies a named matrix to show, all matrices with the same sub-object ID should be shown.

TSRE and Open Rails should accept any legal matrix name for any SignalSubObj entry, and ignore any situation where a shape file doesn't actually posses the named matrix. Open Rails should generate a warning message in this situation, if shape warnings are enabled. TSRE might do the same, but should only generate an error for each matrix name on each SignalShape once per session.

[roeter]

Jovet, on 06 June 2017 - 02:14 PM, said:

I could be wrong about all of this, but it's my understanding that an MSTS shape file can have 64 sub-objects (0-63) and more than one matrix can be assigned to any of these.

The signal definition only supports 32 SignalSubObj definitions (only 32 bits available to indicate SignalSubObj selection in the signal definition in the World file : SignalSubObj ( 00008003 ) (hexadecimal flag : 8 x 4 = 32 bits)).

Regards,
Rob Roeterdink