Unusual RigidBody Errors

[douglee]

Hi All,
Is this relevant?

Tony Smedley reported a (uid:200163) in this thread:-

http://forums.uktrainsim.com/viewtopic. ... 6#p1379379

Which seemed to refer, in the end, to MSTS trying to place an item somewhere it was not expected. Not, where it would not fit.

I believe, (though others do not) that Train Store can get confused, and using Classic Train Store.
Simulation Tab.
Select Routes.
Click 'Unstore Selected Routes'
'GO'
Then select Routes.
Click 'Store Selected Routes'
'GO'

Seems to have an effect like, maybe, Resetting Train Store.

This may work slightly differently to 'Unstore Everything'

Whatever there is no harm in doing it. Above all do not manually move items between Train Store and MSTS or vice-versa.

I hope this is of some help

Good luck
Doug

[dforrest]

I believe I have made a breakthrough here!

There IS something completely unrelated to stock positioning which will give a RigidBody error.

I accidentally made an error in an .eng file (I had an extra character before "InertiaTensor") and trying to run the loco, even in explore mode, gave a RigidBody error with ID 200000. Remove the error amd the loco runs with no error.

David

[steam4me]

IThere IS something completely unrelated to stock positioning which will give a RigidBody error.

The 20000 number is a valid number in your case.

When team-ALCO was developing the "Spirit Of Progress" set, we ran into RigidBody errors (amongst others) - the last 2 numbers indicated the position of the vehicle in the consist, so 200000 would be the loco, 200005 would be the sixth vehicle in the consist. The problem turned out to be a shape with very small polys that upset MSTS. Rebuilding the shape and feeding it to Polymaster cured the problem. It's an exceptionally stable set, given the details in the typical SoP consist.

The RigidBody issue mentioned above has numbers (233, 163) which are far higher than one would expect in a consist, hence the difficulty in trouble-shooting.

[dforrest]

IThere IS something completely unrelated to stock positioning which will give a RigidBody error.

The 20000 number is a valid number in your case.

When team-ALCO was developing the "Spirit Of Progress" set, we ran into RigidBody errors (amongst others) - the last 2 numbers indicated the position of the vehicle in the consist, so 200000 would be the loco, 200005 would be the sixth vehicle in the consist. The problem turned out to be a shape with very small polys that upset MSTS. Rebuilding the shape and feeding it to Polymaster cured the problem. It's an exceptionally stable set, given the details in the typical SoP consist.

The RigidBody issue mentioned above has numbers (233, 163) which are far higher than one would expect in a consist, hence the difficulty in trouble-shooting.

Thanks Yuri. I have suspected for some time that there is another reason for RigidBody errors, other than badly positioned stock. This has now confirmed this.

Now to try and figure out what the higher numbers refer to. One possibility could be that the player consist takes the first numbers with other consist, in some order, following this.

David

[douglee]

Hi David & Yuri,
This is pure guess work but as no one knows it might be relevant.
Could the numbering be the consecutive numbering of stock items in the Activity. IE. A player Consist of 11 items 4 loose consists of 11 items could mean a problem with the last stock item, in the last consist placed would be 200050.

If I have made that clear.

Good luck
Doug

[dforrest]

Hi David & Yuri,
This is pure guess work but as no one knows it might be relevant.
Could the numbering be the consecutive numbering of stock items in the Activity. IE. A player Consist of 11 items 4 loose consists of 11 items could mean a problem with the last stock item, in the last consist placed would be 200050.

If I have made that clear.

Good luck
Doug

Doug, I believe you are suggesting the same as me. However, the last item of the last consist in your example would (probably) give the error 200054 (five consistd of eleven items = 55, with the first numbered 0). Loose consists would also have to be considered in the order. Player-AI-loose or player-loose-AI? Experimentation is necessary.

David

[douglee]

Hi Dave,

Doug, I believe you are suggesting the same as me. However, the last item of the last consist in your example would (probably) give the error 200054 (five consistd of eleven items = 55, with the first numbered 0). Loose consists would also have to be considered in the order. Player-AI-loose or player-loose-AI? Experimentation is necessary.

David

More than likely just thinking aloud really.
As for the maths, show me a list of numbers and my brain shuts down, seriously I still have to work out times tables. I can not do numbers quickly.

I would think the 'order' would be, when the consists were added to the Activity. There is no standard there one would think player would be the first added but even that is not an absolute.

I suppose to experiment would mean a known working activity and introduce an error at a known place. Then would the 'type' of error matter. It is not going to be a quick job.
Best of luck.

Good luck
Doug