Looks like OR 0.7 doesn't like articulated electric locos ...

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • GoGoran
    Senior Member
    • Jun 2010
    • 880

    #1

    Looks like OR 0.7 doesn't like articulated electric locos ...

    Hello,

    I just tried to run on OR with a model of the German BR 194, a very popular type of articulated electric locomotive. There are quite a lot of similar locomotive types in Europe as well, the most famous being the Swiss "Crocodile" ...

    The MSTS model is contructed in the usual way for such a machine: two "truck waggons" (*.wag), each with three axles and a small hood, and the main locomotive body (*.eng), which does not have any wheels and resides on the two "truck waggons."

    This is the way it looks like in MSTS:



    And this is what I get with OR 0.7:



    The main body of the locomotive is invisible !

    And when I switch to the cabview, which is located on the main body as well, I get grey windows all around, I cannot see out of the windows ! But the same cabview works perfectly in MSTS !

    This is a major issue for all European OR users, and I hope it will be fixed soon.



    PS: The model used in this test is the HM_DB_194 by Heiko Mueller.

    It is freeware, so you can download it here for the testing and debugging of OR:

    http://www.thetrain.de/configuration...13001168704654

    Just click on the link, the download should start automatically.
    sigpic
  • mestevet
    2000 Post Veteran
    • Feb 2007
    • 2225
    • Chadds Ford, PA

    #2
    Issues with other articulated electric locomotives have been reported with this version of OR.

    Tim Muir reported having problems with his Milwaukee Road electric boxcabs over at Elvas Tower (you may need to be a member to view this):

    http://www.elvastower.com/forums/ind...x-cabs-and-or/

    The odd thing is that I loaded Tim's electrics in OR and had none of the problems he was seeing (can't explain).

    I'm not sure if the problems with the BR 194 are the same as the ones Tim was experiencing, but it's clear that not all the bugs have been worked out yet!

    Steve

    Comment

    • GoGoran
      Senior Member
      • Jun 2010
      • 880

      #3
      Originally posted by mestevet
      Issues with other articulated electric locomotives have been reported with this version of OR.

      Tim Muir reported having problems with his Milwaukee Road electric boxcabs over at Elvas Tower (you may need to be a member to view this):

      http://www.elvastower.com/forums/ind...x-cabs-and-or/

      The odd thing is that I loaded Tim's electrics in OR and had none of the problems he was seeing (can't explain).

      I'm not sure if the problems with the BR 194 are the same as the ones Tim was experiencing, but it's clear that not all the bugs have been worked out yet!

      Steve
      Did you try the BR 194 I linked to above yet ?

      After posting the above, I did some testing to find out what the problem was:

      I changed the value for the engine length in the *.eng file (it was set to 0.01m there), but the only result was that the two truck waggons ended up further apart.

      Then I set the main shape up as a FreightAnim on a flat car - and it displayed just perfectly there. I went on to exchange the loco's main shape with another shape, and that worked, too.

      So the problem had nothing to do with the *.eng file or the main shape. It had to be something more specific.

      So I converted the shape to 3ds format with the Shape Converter, and had a look at it in gmax:

      The first thing I noticed were two odd, isolated lines below the shape's mesh, on track level. These two lines were specified as Bogies 1, 2 and Wheels 11 thru 23 ! I subsequently deleted the "wheels" and "bogies" from the shape, and reconverted it to MSTS *.s format. Renamed the pantograph entries, compressed it with ShapeFileManager and had a go at it in OR: And suddenly, it worked !

      Conclusion: MSTS accepts everything as "bogies" and "wheels" - even if it's just a line and serves as multiple wheels and bogie at the same time (MSTS creators inserted those probably because they thpught MSTS required a loco to have bogies and wheels - I dunno whether that is the case, OR does not require it at any rate). OR does not - I guess for OR to be content with a wheel or bogie, it must be animated and unique. If the OR developpers changed that, OR would work fine with those locos, too !




      PS: The model of the BR 194 also has very complicated pantographs, with animated parts named as P1_ANI_11 thru P1_ANI_22 and P2_ANI_11 thru P2_ANI_22. I deleted these parts first, since I had never seen such a panto before, but it made no difference - the shape would not work in OR. So I am sure the pantos were not at fault there, and the culprits were the two lines described above. I'm just writing this as an extra information, that there are such pantographs - I'm not sure what OR does with them or whether they have been implemented yet. I guess it's some MSTS-Bin related code, right ?
      Last edited by GoGoran; 01-12-2012, 13:24.
      sigpic

      Comment

      • Simon12345
        Senior Member
        • Sep 2006
        • 369
        • MP 2068

        #4
        I noticed that every engine in the consist needs a pointer to a real and existing cab view in the .eng file, otherwise it will not be visible in OR.
        I had about the same problem with the EL-2B engine, changing the pointer in every .eng file to the .eng file in the cabview folder made the whole engine visible.
        with kind regards,
        Simon
        ____________________________________
        "It never hurts to help!" - Eek! the Cat

        Comment

        • GoGoran
          Senior Member
          • Jun 2010
          • 880

          #5
          Originally posted by Simon12345
          I noticed that every engine in the consist needs a pointer to a real and existing cab view in the .eng file, otherwise it will not be visible in OR.
          I had about the same problem with the EL-2B engine, changing the pointer in every .eng file to the .eng file in the cabview folder made the whole engine visible.
          The cabview has nothing to do with it. I already found the cause of the problem, see my post above.

          I now created a new shape file with gmax which retains all the panto parts mentioned above, incl. the P1_ANI_11 thru P1_ANI_22 and P2_ANI_11 thru P2_ANI_22.
          In this version, I ONLY deleted the two lines which the author of the model specified as "wheels" and "bogies", as described above.

          Result: Without the fake "wheels" and "bogies", it runs perfectly now in OR, the pantos are fully animated and function individually (P1, P2 separatedly raised or all together etc.). So we can rule out the pantographs as troublemakers - they work just fine.

          FINAL CONCLUSION: The root of the problem is definitely the practice of model builders to incorporate "fake" wheels and bogies into their models, as described above ... or the inability of OR (as of yet) to cope with those "fake" parts. I am sure that the OR developpers will now be able to fix this issue in a breeze, since it has been so clearly identified by me.

          Thank you for your attention.


          PS: In this screenshot of gmax, you can see the fake "wheels" and "bogies" below the main model (yes, the white lines!), at track level, and which I deleted to make it work:



          I guess many other articulated electrics are constructed in a similar way, causing the same or other odd errors in OR ...
          Last edited by GoGoran; 01-12-2012, 14:42.
          sigpic

          Comment

          • mestevet
            2000 Post Veteran
            • Feb 2007
            • 2225
            • Chadds Ford, PA

            #6
            I think that all you can truly say is that the root of the problem with that particular locomotive was the fake wheels and bogies.

            In the case of Tim Muir's Milwaukee Road electrics, there are no fake wheels and bogies. So, indeed, your solution may work for the BR 194 (and others that may have followed that practice), and certainly is worth the attention of the OR programmers.

            But I would stop short of saying that it is the root problem with articulation in every case.

            Steve

            Comment

            • GoGoran
              Senior Member
              • Jun 2010
              • 880

              #7
              Originally posted by mestevet
              I think that all you can truly say is that the root of the problem with that particular locomotive was the fake wheels and bogies.

              In the case of Tim Muir's Milwaukee Road electrics, there are no fake wheels and bogies. So, indeed, your solution may work for the BR 194 (and others that may have followed that practice), and certainly is worth the attention of the OR programmers.

              But I would stop short of saying that it is the root problem with articulation in every case.

              Steve
              I never claimed it was the solution to each and every problem OR has with articulated electrics, Steve. That would certainly not be true (and just plain idiotic).

              I quote myself:

              "I guess many other articulated electrics are constructed in a similar way, causing the same or other odd errors in OR ... "

              Goran.

              PS: I dunno just how "fake" those "wheels" and "bogies" were - they showed up as animated parts when I looked at the uncompressed shape in Notepad, and that was how I found out they were there in the first place. They are completely invisible in both sims and ShapeViewer. After deleting the parts in the 3ds shape, they were also gone from the *.s file text.
              Last edited by GoGoran; 01-12-2012, 17:17.
              sigpic

              Comment

              Working...