PDA

View Full Version : More "broken" bogies with T:ANE Hot Fix 2



JCitron
October 8th, 2015, 10:43 AM
See this from Norm Hart.

http://forums.auran.com/trainz/showthread.php?123203-Hotfix-2-Bug-List&p=1446812#post1446812 And there are many that follow...


It is my understanding that there are two types of faults that have arisen with HF2 and bogies/trucks.

1) Some bogies have anim - - - "anim.kin" in the mesh table of the config.txt

2) Some bogies were constructed with the wheels incorrectly placed in the original mesh

Both of these problems were not problems prior to HF2.

Can you find out from WindWalkr if N3V is intending to fix this problem in future SPs or HFs?

Thanks

Norm

ianwoodmore
October 8th, 2015, 02:25 PM
I don't have this problem as TARDIS automatically removes

anim anim.kin
animation-loop-speed 1.0

during repairs and has done so since 2006.

You are likely to get:

wheels running reversed
wheels running continuously even when stationery
and in TANE a new one the whole bogey goes around in a circle. looks like a galloping centipede.

JCitron
October 8th, 2015, 02:39 PM
That's good to know, but the problem is not everyone uses AssetX and TARDIS, which means there will be complaints... If this is truly obsolete, then T:ANE or any newer version of Trainz should ignore the line completely if it appears in the config.txt of assets that are already installed, or error the assets out in Content Manager when imported. This will of course need a more descriptive error message than we usually get that's not written in "Programmer". This would make these things a lot less intimidating and, to put it bluntly, less frustrating and frightening for those users without the knowledge on how to repair problems like this.

John

PEV
October 8th, 2015, 07:45 PM
As I said in Norms thread on this.. fault 2 in John's post is associated with INFL chunk based animations and has nought to do with what's in the config.txt.

Animations made with TACS will always work (SKEL chunk animation data) where as those from Blender via TrainzMeshImporter and later MAx versions will have INFL chunk animation data in the mesh and may fall over as described.

The problem arises from the original animation being made with dummy offset or rotation at frame 0. All previous versions of Trainz coped with this; but TANE HF2, in particular, has failed. The previewer also showed this problem.. For my own benefit I have reverse engineered the meshes of some of the offending bogeys and now I have them working properly.(with INFL chunk animations via the TMI)

If this issue cannot be corrected in TANE then we will need to either dispose of broken assets or repair them. Repairing without the original creators' files is a big job but possible with certain tools.

WindWalkr
October 8th, 2015, 08:14 PM
See this from Norm Hart.

http://forums.auran.com/trainz/showthread.php?123203-Hotfix-2-Bug-List&p=1446812#post1446812 And there are many that follow...


I loaded up one of pweiser's trains and didn't spot any problems. Let me know if there's a specific asset that you think needs review.

thx,

chris

JCitron
October 8th, 2015, 09:10 PM
I loaded up one of pweiser's trains and didn't spot any problems. Let me know if there's a specific asset that you think needs review.

thx,

chris

Here you go...

<kuid:520526:2266> NH Class 20 RDC-1 McGinnis

<kuid:520526:2301> 4W6S RDC Bogey Silver <---- and this bogie is a good example.

Thanks,

John

ianwoodmore
October 8th, 2015, 10:39 PM
See Wiki


critical-animation

Type: BoolDefault: 1 (TBD: surely this should be false (0))Compulsory: NoDesc: "critical-animation" indicates that this mesh's animation generates events which are critical to the script system's behavior. If your asset is not scripted, does not use scripted animation events, or only uses the events for display purposes and will not break if the occasional event is missed, this tag should be set to false (0). Leaving this flag set to true (1) is a significant performance penalty.

These bogeys are not scripted so 'critical-animation' should not be there and we already know we don't need 'anim'.

My recommendation is to remove both

anim "anim.kin"
critical-animation 0


from all of pweiser bogeys.


I've not tried these at TB 4.2 because of the >500 poly issue that prevents you observing them.
Any coach that uses these bogeys after removing those tags look pretty good in Preview to me at TB 3.7. I'm not expert in bogey placement. Can someone confirm please. Can't check in build 78602 Surveyor at moment. Oh for the return of the CM Pick List. Then we could transfer to Surveyor Pick List and place it.

BUT anyway, Preview is incorrectly displaying the bogeys separately when they have been upversioned to TB 3.7.

WindWalkr
October 9th, 2015, 12:46 AM
Thanks guys. I've added a workaround for this issue to our loaders. Check it out in the next test build and let me know.

chris

JCitron
October 9th, 2015, 11:29 AM
Thank you Chris for addressing this.

Here's an example from Norm Hart I received in my PM box of the 2nd item in case you didn't catch this one too.

"2) Some bogies were constructed with the wheels incorrectly placed in the original mesh"

<kuid2:86105:50059:1> 36inch 4foot 6inch 3 Axle Truck

John

PEV
October 11th, 2015, 05:08 PM
"2) Some bogies were constructed with the wheels incorrectly placed in the original mesh"

<kuid2:86105:50059:1> 36inch 4foot 6inch 3 Axle Truck

These are examples of what I was saying above where the wheels are put in the right position by displacing the dummies at frame 0 of the animation.

It seems as if there was a tutorial some where that advocated this method in the early days of the game. It's quite common..

VinnyBarb
October 11th, 2015, 06:03 PM
These are examples of what I was saying above where the wheels are put in the right position by displacing the dummies at frame 0 of the animation.

It seems as if there was a tutorial some where that advocated this method in the early days of the game. It's quite common..

Can you explain what you mean by "displacing the dummies at frame 0 of the animation"? What I normally do is to animate an axle set with wheels, meaning the dummy in the centre of the axle to rotate 30 frames. If I have to make a 2 or 3 axle bogey, I clone that first animated axle/wheel set after unlinking this first from the main dummy, clone as often as needed including dummy with its appropriate new name and shift both or all three in the right position and relink these.

Does this mean, if I "displace a dummy" and shift it somewhere else after first unlinking and then relinking it, is this now faulty? As I can not wrap my head around what you mean by "displacing the dummies at frame 0 of the animation" as I have build ALL my bogies since TRS04 the above way. Where they all worked up to and in TS12 as they should. I have not installed TANE's HF2 yet as this is still buggy, hence I am asking. The tutorial of the early animation of bogies is in the TRS04 CCG plus I used this in conjunction with the now defunct WorldOfTrainz bogey tutorial when I animated my first bogey.

Thank you for any answers

VinnyBarb

PEV
October 11th, 2015, 09:29 PM
Your method sounds OK. As far as I can see Phil_c's tutorial ticks all the right boxes. I still use it occasionally..I made a copy of it before he closed the WOT site.

It's the case, sometimes, that the wheels and axle are located (along with the dummy) at 0,0,0 and are moved to the appropriate position by dragging the dummy with its linked wheels and axle as part of the animating process.. Hence you will have displacement (and/or rotation) of that dummy at frame 0.. Sounds dumb but that is the only possible explanation, as far as I can see, for the problem.

I have fixed these, as stated previously, by reverse engineering the mesh and animation in GMax. Having no displacement and rotation of all dummies at frame zero fixes the problem.

You all know that I tinker with home brewed tools to do all this stuff so getting little things like this sorted is no problem for me.. I know reverse engineering is not allowed so nothing I do of this sort can be re-published. But it prooves a point for modelling method....

VinnyBarb
October 11th, 2015, 11:55 PM
Thank you Peter, what would we do without you and your tools/utilities :wave:.

Now I can sleep easier when building my next set of bogies but then again, there is a big patch coming up and one never knows, what might be broken there :p.

Thank you again.

VinnyBarb

WindWalkr
October 12th, 2015, 02:08 AM
"2) Some bogies were constructed with the wheels incorrectly placed in the original mesh"

<kuid2:86105:50059:1> 36inch 4foot 6inch 3 Axle Truck


Okay, this one's a little different. The issue here is that the skeleton in the mesh and the animation file don't actually match up properly. My guess would be that one file was exported, some further modifications were made (including editing the bone names) and then the other file was exported.)

In this scenario, TS12 and T:ANE were providing different default handling for the bones that weren't defined in the animation. I will adjust the T:ANE handling of this case to give a similar result to the TS12 case.

chris

pcas1986
October 12th, 2015, 04:55 AM
...
It's the case, sometimes, that the wheels and axle are located (along with the dummy) at 0,0,0 and are moved to the appropriate position by dragging the dummy with its linked wheels and axle as part of the animating process.. Hence you will have displacement (and/or rotation) of that dummy at frame 0.. Sounds dumb but that is the only possible explanation, as far as I can see, for the problem...

Are you saying it's a dumb method or as part of your explanation?

My method is the same as VB's and I'm sure I got the methodology from Paul Hobbs' tutes. After cloning and displacing the dummy (lattice in Blender speak), I reset the cloned dummy origin and usually temporarily unlink the child mesh to make sure the mesh doesn't move. During my early days of animation I used to have rogue meshes scattered all over.:hehe:

PEV
October 12th, 2015, 05:01 AM
Ah.. Thanks Chris..

I did not check that aspect in this case.. It's usually obvious to me when this happens but I missed it this time. I've made that error with some of my own assets..

Do you wish to repair/replace the asset?... if so, my rebuilt version works OK. I can upload it if you set it for repair... (next week.. I'm away from home at present)

WindWalkr
October 12th, 2015, 06:07 AM
Do you wish to repair/replace the asset?

No real need. As above, we'll change the behaviour in this case to match TS12. Aside from fixing compatibility with objects such as this, it's the better approach in general.

chris

PEV
October 12th, 2015, 04:48 PM
Yes indeed.

Thanks again Chris.

WindWalkr
October 14th, 2015, 08:43 AM
When you get a chance, could you please confirm that things are working as expected in the most recent internal test builds?

chris