[Eldorado.Railroad]

?

[longiron]

Here's a non-technical suggestion. Test each of the subobjects independently in OR. It should point to which one or ones have the offending issue. From there you can dig into which matrix (es) are the root cause.

[James Ross]

 Eldorado.Railroad, on 17 November 2011 - 12:11 PM, said:

The log gives no indication in what matrix/subobject this is occuring. This would be really handy for modelers such as myself. This model is by no means "optimized" and there are 39 matrices in the file for various "creative" reasons.

I have several models that all have this same "error" when run in OR(v0.6.2) and I am at a loss to explain what this means or why it is appearing in the log. As mentioned before, the model runs as expected in the sim. These models are not compatible with MSTS Bin, in the sense of, there is no way that MSTS Bin will load them in their present form!

It's a warning and the shape is loaded fine, it's just not necessarilly going run as well as it could. The warning can occur for any of the primitives in a sub_object, which makes it tricky to easily identify (but I will try making the message more detailed), whenever sub_object.vertex_sets is missing a set to go with that primitive. I'd consider this a bug in the program that generated the shape file, but since the vertex_sets are only used to optimise the rendering by identifying which range of vertices are used for a primitive, OR handles this by just including the all of the sub_object's vertices and everything should still draw fine.

[James Ross]

 Eldorado.Railroad, on 17 November 2011 - 09:27 PM, said:

If I delete anyone of these "offending" prim_state_idx (with the corresponding indexed_trilist, vertex_idxs, normal_idxs, and flags) there will be one less "Shape file missing vertex_set" error in the OpenRailsLog.txt. So there is a definate one to one correspondence here. Of course that deleted prim_state_idx et all is not displayed as expected.

OR uses the prim_state_idx value prior to each primitive to look up an entry in prim_states, which then has a value which must match the first value of one of the vertex_set blocks. As I neither wrote this code nor have any documentation for the shape files to back up what it does, I have absolutely no idea myself if this is actually the correct thing to be doing or not. It does work for most shapes, though.

 Eldorado.Railroad, on 17 November 2011 - 09:27 PM, said:

What I cannot figure out is why OR singles these out as errors if they are being displayed correctly in the sim? Should this be an error in the first place? What value in the vertex_set is "making" the prim_state_idx (with the corresponding indexed_trilist, vertex_idxs, normal_idxs, and flags) "unhappy"? If I knew this I might be able to fix this "error" in the my shape file(s).

It's a display optimisiation that is being skipped because of the data not aligning as OR expects, so of course things will display fine. Just a bit slower. OR is issuing warnings, which are for things that appear to be wrong but which do not prevent things from working (exactly what we have here). And as I noted before, this is really a problem with the program that generated the shape file and not the model itself so I would not expect you to worry about fixing it.