Lead locomotive missing attachments in session, when I move to another train

janathan

Member
I have a weird glitch I'm trying to figure out. Often times, when starting a session, only the lead locomotive is missing all of its attachments (headlights, ditchlights, bogies, pantographs) and is just a hovering mess. (Like the second train in this video: https://www.youtube.com/watch?v=OXc--Cfujog)

Oddly enough, so far, I've only observed this issue with the AEM-7's I'm working on. Other trains I've made recently don't have this problem, even though I made them using similar methods. Odder still is that even if there are multiple AEM-7's in the consist, only the leading one loses its attachments.

This glitch happens:
Whenever the consist isn't currently selected
Whenever I switch from that consist to another
Whenever I leave the general area of the train

This glitch is reset by:
entering the cab of the effected locomotive, then exiting it.

If the above video is to be believed, trains coming from portals aren't effected by this glitch. It might just be the first train placed on the map that's effected?:confused:

So where is this glitch coming from? It doesn't happen to any other train I've made that I've tested. None of the effected trains are faulty, nor do they trigger any errors.
 
I'm not a modeler, or rather I haven't modeled anything since the late 1990s thru mid-2000s, but I suspect that there's some kind of load caused by that locomotive or a component on that locomotive that's causing things not to load up right away. I would check the components carefully for overly complex meshes, too high-res textures or other things that will cause those components not to load up properly.
 
I don't think it's a load issue. I've been running some experiments where I put a bunch of AEM-7's on the track and no matter what, it's only the first one in a consist that's missing its attachments. For example, I compared them to my fictional American Bullet Trains I'm working on (https://www.youtube.com/watch?v=oktMq-7QpGw) and despite taking up more space, the ABT doesn't have this problem ever. In a comparison test, I placed the ABT on a track, then put several AEM-7's on other tracks, one with only one leading locomotive, one with two, one with three and one with 20 locomotives leading. Then I went far enough away that the game would unload them, then came back. When I came back, the ABT loaded all its attachments properly, but the AEM-7 consist with one lead locomotive was missing its attachments. On the consist with two AEM-7's, only the lead locomotive was missing its attachments. On the one with three AEM-7's, only the lead locomotive was missing its attachments and on the one with twenty AEM-7's all locomotives had all their attachments loaded properly.

I then tried another test when I deleted the leading locomotive on the one with 20 AEM-7's, so that it had 19 AEM-7's. When I redid the test, all AEM-7's loaded their attachments properly.

I then tried removing the ABT in case it was demanding too much loading problem, then repeated the test. The train with one AEM-7, the locomotives was missing its attachments. On the train with two AEM-7's, the first one was missing its attachments. On the train with three AEM-7's, the first two were missing their attachments, but not the third one. And on the train with 20 leading AEM-7's, they all had all their attachments, so the ABT isn't the problem. Also, the fact that the first two AEM-7's in the train with three were missing their attachments this time, rather than just the leading tells me it's completely random what causes this.

Also the AEM-7's take up way less space than the ABT.
AEM-7: 93.1 MB, 195,273 polygons (lod0)
ABT locomotive: 212.5 MB, 86,908 polygons (lod0)
ABT coach: 197.3 MB, 82,428 polygons (lod0)
ABT Powered coach: 309.5 MB, 93,866 polygons (lod0)

During another test without the ABT present, the first AEM-7 on the consist with 20 AEM-7's was missing its attachments, once again proving that it's completely random.
 
It happens in both DCC mode and Cab mode. Also, I tried using the "edit trains" tool in driver to delete and replace them back on the track to see what would happen. When I went far enough for the game to unload them, then came back, some of the ones I had just placed down were missing their attachments, but others weren't, so it seems to be completely random.

I also tried replacing the leading AEM-7 with other trains I had made in the past, such as the Arrow III. When I came back, these locomotives still had their attachments, so for whatever reason, it only affects the AEM-7, but only if it's the first or first and second locomotive in the consist. So far being the third to twentieth locomotive in the consist has no affect on it.
 
We are led to believe the sky is the limit now making assets
our PC's are much faster for sure
It does not matter if you place 1 or 20 of the same, cause only 1 needs to be loaded
the (graphic) calculations done when more placed ofc. do matter.


There are still limits to content creation, specially when loading
These are hickups I found here when making/testing content:
-if a single asset/mesh is over 70k poly it gives a problem
-if the total texture size is too big (over 20mb) problems loading
-Too much lod switching, not good
-Using different textures on different lods, not good
-Attachments will not cull well via the .lm file (only 1)


A good test is, select your loc(asset) in main menu
if it does not show up in a split second, its not good content
main menu is just a small route and simulates actual use.


Often I get ridiculed if I point to this, doesn't bother me
I choose not to use overthetop content and can run very large maps with many trains
by being critical selective, its the combination of all items that is import.
hope you find the problem
greetings GM
 
I'm still trying to solve this mystery. I've tried giving the bogies a lod system, which I usually don't do for bogies, 'cuz I never needed to. That didn't solve anything, sadly. It's still the leading locomotive that refuses to load its attachments. This glitch doesn't make any sense. Why is it only this locomotive of all the ones I've made so far that's doing this?! I'm getting really frustrated because I was planning on releasing this as payware, but I can't sell a product that doesn't work. I've been working on this locomotive for months! This glitch is really annoying! I tried looking at the logs to see if any errors come up when trying to load the bogies and pantograph, but no errors show up that are directly related to any of my assets.

; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.


; <kuid:30501:1009> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1008> : Recursive attempt to compile this asset; skipping.



- <NULL> : Cabin control has mismatching Notches and Notch-Height arrays (had 11, 9)
! <NULL> : VE217: Material *br143int*2b50a4c*glas*m.reflect in mesh file br143int.im has no texture assigned to a required slot: texture0



! <NULL> : VE186: Material 'arc:fld:$(local)/hash-8A||kuid 396831 1691.tzarc|**black_m.notex' is shared between multiple chunks in this asset but the material parameters conflict.
; <NULL> : World.NativePlaySound> Asset '<kuid:396831:1691> "Amtrak Phase IVb Metroliner Cab Car"' does not have attachment point '' or is not currently loaded.
; <NULL> : World.NativePlaySound> Cannot find asset '<kuid:396831:1691> "Amtrak Phase IVb Metroliner Cab Car"' in scene.




- <NULL> : InterfaceSounds::OpenConfig()> bad command
 
Step by step, and don't give up !


30501 kuids are auran/n3v, they have to do with multiplay and are broken since the start of TRS19 (for now ignore)


Cabin control has mismatching Notches and Notch-Height arrays (had 11, 9)
check your Cabs config, example from 1 of my cabs:
throttle_lever {
kind lever
auto-create 1
mesh hendel2.im
att a.rem
limits 0,32
angles 3,2
notches 0,0.125,0.25,0.375,0.5,0.625,0.75,0.875,1 //9 notches
notchheight 1,2,2,2,2,2,2,2,1 //9 notch height
radius 0.15
tooltip-text "tractie"
mousespeed 0.5
att-parent default
}


VE217: Material *br143int*2b50a4c*glas*m.reflect in mesh file br143int.im has no texture assigned to a required slot: texture0
Add a texture , 1 diffuse and 1 reflect (FI env_glass.bmp)


black_m.notex
you used it more than 1x in your content but different parameters


World.NativePlaySound>
On init(start of session), Trainz cannot find the attachment point you specified,
this is not your fault it happens on many assets
What you can do is build in a Sleep(20) at the start of your thread

greetings GM

addendum:
Try open your asset in the viewer, (Content manager Open... Preview asset)
check the LOD Distance box on the right
change distances and see what happens
 
Last edited:
I tried "preview asset" and just like in the sessions, the bogies and pantographs disappeared when the locomotive was far enough to be unloaded.
 
Sure is weird janathan, specially as only 1 (the first placed) is affected.
have you tried in older versions? TANE or TRS19 before SP1?
btw if I edit a lot on an asset, I completely remove it from a session, then after edit i place it again
things could be in cache still
 
I haven't tried it on T:ANE because I no-longer have it installed. Plus I heard that T:ANE doesn't do PBR textures.
 
Really wierd this.
Can you make a new session, place those trains exact the same, then test the same way?
 
Few questions:
-Are you using an .lm file or have lods in the config?
-does your lowest lod have a.bog0, a.bog1, a.panto0 and a.panto1 points?
 
I'm using .fbx files and .lm.txt files only. I don't use .im files anymore because of a few minor issues I've had when importing. You see, back before I started making my own lighthouses, I imported meshes from SketchUp, but one in particular, the Bodie Island Lighthouse would never import right. It kept triggering an error saying, "invalid position data." Though it might've been SketchUp's fault. It's pretty bad at exporting. When I started making things in Blender 2.8, I switched completely to .fbx files.
 
Also, I forgot to mention. I recently checked and yes, the other lod meshes have a.bog0, a.bog1, a.pant0 and a.pant1 attachments.
 
Can you check the lm (el em) file for the loc, and experiment with the parameters with an arrow behind
here an example of 1 of mine:

version 1.0
offset = 0.01;
calcPoint = center;
multiplier = 1.0;
animationCutoff = 0.50; <--
renderCutoff = 0.01; <--
attachmentCutoff = 0.1; <--
mesh("0.05") {name="f7nll.IM";}
mesh("0.4") {name="f7nlm.IM";}
mesh("1.0") {name="f7nl.IM";}

not all parameters work as expected in TRS19, but some make a difference
 
Back
Top