[Jovet]

Csantucci, on 21 December 2016 - 10:04 AM, said:

pls. check whether following .exe patch to x3710 fixes your problem.

It sure does, Carlo.

[Csantucci]

I've uploaded in x.3712 a fix.

[Jovet]

Jovet, on 21 December 2016 - 08:40 AM, said:

I don't see any reason why BALANCEARM and ROD would be made visible by MSTS. That's surprising and confusing. Named parts (and associated matrices that are not matrix #0) should not be visible unless they're invoked by a SignalSubObj.

I don't know how the 3DC exporter and hierarchy/LOD system works, but the Gmax exporter lets me differentiate between a "shape sub object" and a part. A shape sub-object seems to be called a matrix internally in the .s file format. Every mesh object within Gmax is a part. The exporter lets me specify which parts are children of which, and which parts should be combined into the same matrix in the .s file. For my signal hierarchy above, ARM1 has one child called PIVOT1, and PIVOT1 has one child called BLADE1. All three are part of matrix #0 (or, sub-object #0 in Gmax). Every .s file has a matrix #0 (most only that) and it is always visible according to its LOD configuration. The part BLADE1P is a child of BLADE1, but it has a different matrix ID so it has to be specifically told to show up with a SignalSubObj. Compare all of this to the second semaphore arm—ARM2 has a child part of PIVOT2 which has a child part of BLADE2. All three of these parts are still separate but they share the same matrix ID (sub-object number) which is not zero... so they are all optional and also appear at the same time. If that helps.

Also note that I have created a few "order board" semaphore signal shapes which have moving rods and such, and they also work fine in OR like they do in MSTS.

Csantucci, on 21 December 2016 - 01:02 PM, said:

I've uploaded in x.3712 a fix.

Thank you, Carlo.

[rickloader]

Thank you Joseph for your detailed explanation. I`ve learned a lot.
I have tried to follow your hierarchy, using 3dc and x3710 but I can`t yet get the parts to display or animate. (can`t find x3712 in James` site)
I may try to replicate the signal using TSM, to see if 3dc is incompatible with OR, but I will have to relearn TSM as I haven`t used it for years!
I hope I am not causing James and Carlo extra work by my lack of knowledge.
rick

[Jovet]

rickloader, on 22 December 2016 - 05:14 PM, said:

Thank you Joseph for your detailed explanation. I`ve learned a lot.
I have tried to follow your hierarchy, using 3dc and x3710 but I can`t yet get the parts to display or animate. (can`t find x3712 in James` site)
I may try to replicate the signal using TSM, to see if 3dc is incompatible with OR, but I will have to relearn TSM as I haven`t used it for years!
I hope I am not causing James and Carlo extra work by my lack of knowledge.

I wouldn't bother with TSM at this point in time, 3DC should be able to do anything it can, and perhaps more. I'm sure we can get it figured out. X3712+ have shown up on James's site now, so that's another roadblock taken care of.

One other thing I'd like to point out is that there is a common "error" in animated signal shapes' SignalType configurations. The SemaphorePos value tells a SignalDrawState which animation pose (frame) to be in for that DrawState (aspect). This value should be zero-based, e.g. the first frame is frame #0. MSTS will silently assume the first frame is #1 if no SignalDrawState specifying #0 is utilized. Open Rails does not forgive this, though, so be sure you're assigning your SemaphorePos values correctly or the wrong frames may be used. (This is one of the few ways in which I believe OR correctly breaks existing MSTS signaling and should require existing-file correction, because the first frame should be specified as #0 anyways.)

[Jovet]

scottb613, on 23 April 2015 - 11:01 AM, said:

I thought I had read somewhere the animated part of a semaphore in MSTS could only be an alpha'd texture to support the rotation - if not it's a misconception I've had for years...

Nah.

scottb613, on 23 April 2015 - 11:01 AM, said:

So on your specific issue - it sounds like you have 3DC animation down - as you noted "main" is required to be the top most level of the hierarchy you are exporting - is there some reason you need it to be "signal" ?

The MSTS documentation states that signals should have a root part name of SIGNAL. But like other things the documentation states, I don't think it makes any real difference. I've seen signal shapes not so named seem to work just fine. But I've never fully tested/explored that. (I've always named mine SIGNAL.)

scottb613, on 23 April 2015 - 11:01 AM, said:

When the whole thing is invisible - can you see it in Shape Viewer and MSTS ?

When the whole thing is invisible, the absolute, very first thing to look at is to make sure the LOD is set to more than 0 meters!

[rickloader]

Update. I have rebuilt my signals in TSM. The ancillary parts (balance arms rods etc) created in TSM animate correctly in ORTS. I could not get ancillary parts created 3dc. to animate or display in ORTS.
I suspect the 3dc exporter is at fault. But I don`t have the expertise to say why.

I think it is worthwhile bringing this old thread up to date, in case anyone else has a similar problem.
Thanks to all who contributed.
rick