Odd wobbling with MILW "Little Joe" electrics.

[lateagain]

No vibration is controlled by the stock model. Vibration is controlled by OR code.

Logic dictates it has to be?

There are several of the Milwaukee electrics that do not work well in OR, so far reasons are unknown,....

I have noticed issues with some electrics physics files? ....and yes they are MSTS models.

......but they are all multipart models.

But weren't the REAL Milwaukee electrics "multipart" too? I'm guessing that the tracks they operated on never got to be as poor as the video above though so realistically a minimal "vibration" would be a maximum for them as far as that aspect is concerned?

It's one of the features that OR brings to the new Sim and as such I personally like it. I do think it needs some development though?

[geepster775]

The fact that the model needed to be segmented into multiple pieces to work around MSTS limitations is as much of a culprit here. Its not all on the OR code, my friend. OR code vibrates the model just fine when you have a one piece model. One piece models are kinda the new standard; no longer any requirement to break them into pieces.

I will concede one point, in that it probably is quicker to solve the problem by altering OR code to meet yet another "MSTS workaround" than expecting a next generation model, at least a freeware version that so many economically challenged folks around here seem to carry such a torch for all the time. But since when is that the best approach in a long term strategy perspective.

Yes, the list is long and distinguished. I'm talking about the number of contributors of oddball models who 'plateaued' at the height of MSTS and tend to lose interest in anything but. Talented people who, once MSTS begins to struggle with maintaining its footing, suddenly develop other interests.

And so begins another monumental struggle, a war of words, between the gate crashers and the impoverished hoarders. SSDD.

[lateagain]

The fact that the model needed to be segmented into multiple pieces to work around MSTS limitations is as much of a culprit here. Its not all on the OR code, my friend. OR code vibrates the model just fine when you have a one piece model.

My point was that REAL locomotives are not one piece units. Furthermore parts within parts move independently (wheels, suspension etc. within trucks, trucks separately from body etc.) So agreed it works as you specified but as the sim is in development why stop there? One of the things folk on this forum have been moaning about for 16 years now is why didn't Kuju develop this, finish that or implement function X,Y or Z that they obviously started?

One piece models are kinda the new standard; no longer any requirement to break them into pieces.

I will concede one point, in that it probably is quicker to solve the problem by altering OR code to meet yet another "MSTS workaround" than expecting a next generation model, at least a freeware version that so many economically challenged folks around here seem to carry such a torch for all the time. But since when is that the best approach in a long term strategy perspective.

If you'll forgive me for saying so, you're commenting on two things here in one statement? Agreed fixing the code would be quicker. However the issue of whether OR specific, as in built for exclusively with no concession to backward MSTS compatibility, models are freeware or payware is frankly irrelevant whilst there are none? Many of us here buy MSTS Payware. They must do because the producers are still churning it out! In the UK the last MSTS payware provider finally "left the building" and apart from a skeleton "shop site" all but turned off the light. So freeware or payware is IMO irrelevant.

Yes, the list is long and distinguished. I'm talking about the number of contributors of oddball models who 'plateaued' at the height of MSTS and tend to lose interest in anything but. Talented people who, once MSTS begins to struggle with maintaining its footing, suddenly develop other interests.

??? Folk usually move on? Nothing strange about that. Peoples lives and circumstances change. Surely there can't be anyone who resents that? Surely we're grateful for what they contributed? The Milwaukee Electrics are a great set of models and without them the Milwaukee route would really be missing something.

And so begins another monumental struggle, a war of words, between the gate crashers and the impoverished hoarders. SSDD.

Well no one forces anyone to read posts here? ...any more than they're forced to read Stephen Kings Dreamcatcher. BTW this side of the pond it's "different shovel"

[pwillard]

This post is very cringe-worthy to me.

On one hand we have a NEW simulator that exists since day one to take advantage of the plethora of MSTS content but strives, of course, to make the experience better and up-to-date. On the other, we have content that was created that MEETS ancient MSTS content building guidelines (and because it RUNS in legacy MSTS) but now behaves oddly on Open Rails due to an introduced feature.

The problem is, of course, that ONE person sees this as a true behavioral bug and the ANOTHER sees it as a complaint (disapproval) about a wonderfully performing simulator and takes offense by basically saying "How dare you say its a bug!".

The actual solution needs to be "middle ground". I think we all accept that OR is a work in progress, much unlike our abandoned 90's era SIM, and getting feedback about unexpected performance of multi-part engines is valid and it "should" be reported. I also feel that OR is a much better showcase for MSTS models and we don't want to deal with little nit picky things you can easily can turn off ending up preventing better (more important) fixes and features from being added.

The real problem though, is that OR content creation guidelines STILL basically come from MSTS and only a small list of "fixes" that are not backward compatible exist at this point. The OR team has NOT decided to "chuck the baby out with the bath water" yet and create entirely updated, new, better, improved creation guidelines that leave even S files a thing of the past... so, if we have models that don't work right... for valid reasons... this should be taking into account and decided on as either "to be fixed" or "will not be fixed". The only way it gets in the pipeline to be discussed by coders is when a bug report gets created that says "hey... this isn't right". Saying its not a bug and getting defensive just isn't the right response in this forum.

Totally MY opinion... ;-P

[tbundy1982]

Just an observation on the EF-4 electrics: Individual MSTS/OR shapes are broken into parts. The relevant parts here are the two or more bogies with associated animated wheels, and everything that sits on top of that, including freight animations. The Open Rails vibration feature keeps the bogies and wheels aligned with the rails while "vibrating" everything above that.

In order to articulate the Little Joes, they are made of 3 cars that couple together to form the full locomotive. In order for the outside bogie "cars" to articulate at the right spot, the main body shape had to use some smoke and mirrors to trick MSTS. In the .eng file for the middle "body", the declared "size" is only 2.1m; the body itself is probably 15m or more.

Open Rails must base the lateral vibration movements on the length declared in the Size line, as the Size line is what MSTS uses to determine coupler pulling faces. If you could only see the middle 2.1m of the body, it's vibration would be normal looking. In practice, its the fact that the ends are extended far from the coupling face that is problematic. The only way I could envision fixing this is for Open Rails to calculate the physical length and width of the shape file in their vibration technique. This might cause problems with other models, or use too many resources.

Tyler

[Sidewinder]

I agree ORTS is a work in progress. I for one would just prefer to see the dev time spent on forward progress, not backwards progress. There always will be abandonware content where the creator did one revision and left the scene. Just how much time should be spent on compatibility issues with that class of content? Reporting it is fine. I Just wouldn't expect much remedial action. Especially when the problem can be worked around by simply turning the new feature off with a keystroke in the few instances when a person uses that asset.

I would say there is a difference between the general goal of meeting MSTS content guidelines, which ORTS does just fine, and meeting the peculiarities of some abandoned, never-repeated, multi-piece asset. The former is generally accepted, the latter should be treated on a case-by-case cost/benefit basis when they appear, with fixes never guaranteed.

I do believe the days of creating new assets to fit both worlds should be over. New products should not be based upon the design compromises of the past, as required for dual use. Polls and user statistics no longer support that approach. And that is something that can be implemented by asset creators on their own, independent of the ORTS team's views on feature cutoff decisions.

[lateagain]

The real problem though, is that OR content creation guidelines STILL basically come from MSTS and only a small list of "fixes" that are not backward compatible exist at this point. The OR team has NOT decided to "chuck the baby out with the bath water" yet and create entirely updated, new, better, improved creation guidelines that leave even S files a thing of the past... so, if we have models that don't work right... for valid reasons... this should be taking into account and decided on as either "to be fixed" or "will not be fixed". The only way it gets in the pipeline to be discussed by coders is when a bug report gets created that says "hey... this isn't right". Saying its not a bug and getting defensive just isn't the right response in this forum.

Totally MY opinion... ;-P

Exactly!

It also raises another point Pete. When RS started there came the realisation that all the modelling skills that contributors to MSTS had learned were redundant? Further more they chose (perhaps to increase possible levels of "eye candy"?) a set of pro tools to create them. The rest is history. Very little freeware (not unreasonable as anyone dabbling has to recoup the costs of expensive software?) and frankly a much smaller library of stock and content?

Now one would hope that to realise the additional potential of OR we don't see another type of creative software that's expensive and hard to learn? .

One of MSTS's strengths was that anyone who wanted to try something creative could do so with reasonably cheap tools.

It took MSTS 10 years or so to get a reasonable level of decent content. OR content is NOT going to appear overnight. If you want more folk involved in OR you have to make sure that what they can use works. That may be "Statin the Bleedin' Obvious" to most but it seems to need stating for some still

PS

Thanks for the theory Tyler. I see now where the problem is. Thinking aloud though if the reason the pitch is exaggerated because of the "artificial" length? ...then surely creating some milder pitch modes would dampen the effect on the additional length?

[Sidewinder]

Tyler, can you compare the Milwaukee electrics with the Streamlines heavy duty flatcar, the one with the windmill nacelle load? That also is a 3-unit model, where the wheels comprise the 2 outer units. The only difference is the wheel modules do not extend as far inward to nearly meet each other like they are on the Milwaukee electrics.

[seagoon]

It wasn't my intent with the original post to create a shit-storm, fellers!!
If you go back and read it you will see that I (a) raised a point and (b) asked for a possible fix....which was provided in the next post.
Everything else since my thanks for that response is superfluous.

[baldwin]

If you turn 'Car Vibration' off, does the problem go away? The 'Joe is a three part model, where the running gear is two long pieces that track nicely, but the carbody is defined as a short piece in between. Imagine a see-saw, the further you get from the fulcrum the more exaggerated the motion becomes. The short distance between the two running gear pieces acts as a fulcrum, and the ends of the carbody, where the cab is, reacts like a see-saw!

Spot on observation. It is indeed the very short length of the carbody that is the root cause of the problem. I have changed the lengths of the running units and the carbody on one set to get everything in the right place, and the exaggerated wobble is gone, trucks and body all sway if vibration is on, but it is no use except as a light engine because the shortening of the running gear size mucks up the coupling distances.

[geepster775]

That sounds similar to the shaky EOT syndrome. Which likely will remain an issue until we get an EOT mounting/dismounting function and get away from needing an ultra-short EOT wagon in our Trainset folder.

[lateagain]

It wasn't my intent with the original post to create a shit-storm, fellers!!
If you go back and read it you will see that I (a) raised a point and (b) asked for a possible fix....which was provided in the next post.
Everything else since my thanks for that response is superfluous.

No worries, No shit storm. It just prompted further, and as it turns out, constructive discussion.

As Pete said we should grasp every bit of feedback as an opportunity to further development.

[R. Steele]

There is considerable modeling talent hereabouts, why not get together and redesign a model that will work in OR.
Are there hurdles I'm not aware of to doing that? I read in the readme's for the original model that Lucas Lusser, Tim Muir, and Frank Musick were all involved with the model creation. I know that Tim is in the hospital (GET WELL SOON), Lucas according to current threads is okay but involved with other things, don't know about Mr. Musick.

Anyway this may help with the rumored Sh%$t Storm
BikeToylet.jpeg
It could be ridden to any other threads where this storm is happening...

Me I'm going to get a tan at the beach
sombreo.jpeg



Just saw this post (#6 in thread at ET >> http://www.elvastower.com/forums/ind...05#entry214305 ) from Carlo Santucci, maybe it is a simple adjustment of existing code in OR, that may quell things a bit.

"I believe there is in the code a test that disables vibration for cars shorter than 1 meter because of problems like this one. Apparently this threshold should be increased a bit..."

[seagoon]

Me I'm going to get a tan at the beach...

LOL!
That would be most appropriate for me right now, Gerry.......middle of a (very hot) summer, living in the best coastal town in Australia and currently surrounded by hundreds of partially-clad holiday makers!

[NW 2156]

Why not just adjust and redo the eng and wag files? I believe using the include function in ORTS would allow for a special set of physics.

I don't really see why redoing the scripting in the eng and wags and then adjusting the bounding boxes and couplers would not work?

The physics for current and KW need work for ORTS anyways.

Geoff, What UK MSTS site are you talking about?

Robert