[eugenR]

In the X2797 I have seen new errors in the logfile, producer by the control of the shapes
since X2802 this errors are now printed as warnings.

The Shapes pointed out in the logfile never had made problems, not in the MSTS and also not in OR until yet.
I had produced this files with gmax before some years.
Can you tell me what was going wrong by the production of this shapes with gmax ?

I have change the file name in *.txt, because I couldn't attach *.s File

Attached File(s)

•  OpenRailsLog.txt (44.26K)
  Number of downloads: 135
•  CHNHauptsignal2.txt (426.95K)
  Number of downloads: 134
•  CHNBahnhofende.txt (27.01K)
  Number of downloads: 160

[Jeffrey Kraus-Yao]

Erased.

[Genma Saotome]

In the .s file, around lines 10-12, look for a line that says "named_shader ( diffuse )". If found there is an untextured face present. Open Rails will always substitute a gray texture when detected and continue to run.

[copperpen]

That is why with many older shapes you see a blank.ace included. This is used to texture the untextured polygons in MSTS.

[eugenR]

 Genma Saotome, on 01 February 2015 - 02:24 PM, said:

In the .s file, around lines 10-12, look for a line that says "named_shader ( diffuse )". If found there is an untextured face present. Open Rails will always substitute a gray texture when detected and continue to run.

In Gmax I can't find a not textured face on the surface of the object. But I had produced this object in Gmax by attaching two parts. Perhaps this method has produced somewhere a hidden face. When I remove the whole texture and remade it, the problem will be solved.

But this Error produce so many Warnings in the Log-file, and I can't repair all the shapes in all routes where the routebuilders has used them!!!
Can you reduce please in the Log-file this type of Warning on one per shape. I think so many Warnings are not really helpful.

[roeter]

 eugenR, on 02 February 2015 - 03:25 AM, said:

Can you reduce please in the Log-file this type of Warning on one per shape. I think so many Warnings are not really helpful.

I fully agree with this.
Warnings are intended to improve either the program, or the objects etc. used by the player.
These warnings, however, are useless to most users. Even if they understand what it means, there is no way the problems can be solved.
It is not a program issue, and the average user will not be able to alter the shapes, as they do not have the original files nor in most cases the required tooling.
Moreover, it does not actually effect the display for most of the items, so there even is no real need to change anything either.
To repeat these myriads of warnings each and every time the program is started serves no useful purpose whatsoever.
That these warnings can be generated such that whoever is interested in this and wants to know if any shape is invalid - fine.
But PLEASE MAKE THESE OPTIONAL!!!!

There is no need to bother all of us with these warnings all of the time.

Regards,
Rob Roeterdink

[Yellow text changed to red for better viewing: Bazza Mod.]

[R H Steele]

:D From the West Colton OR log lines 166 to 980 were all this warning: Warning: Missing UV index in vertex 154 in sub-object 0 in distance level 2 in shape f:\2tsf\socaz\trains\trainset\dwatsfcoal\atsf81273.s (all referring to different shaped of course)

I have no clue what that means (UltraViolet rays are burning the Route, UV index is too high, makes sense in Southern CA) nor how to fix it.
Perhaps a one line warning like this: Warning: Missing UV index in vertexes See Warning Log Such &Such

But looking at both sides, perhaps these warnings provide information to the developers, if so, they could be kept but offerred up in another way.

[JohnnyS]

 R H Steele, on 03 February 2015 - 12:33 AM, said:

I have no clue what that means

UV mapping

[eugenR]

 R H Steele, on 03 February 2015 - 12:33 AM, said:

Perhaps a one line warning like this: Warning: Missing UV index in vertexes See Warning Log Such &Such

I hope Jeffrey Kraus-Yao is hearing our plead !!!!!!!!!!

[vince]

I leave untextured faces on my SketchUp model ON PURPOSE!! According to Shape Viewer & Shape Manager a textured face is counted as a poly so anything I can do why in heavens name are we attempting here to increase them? :party:

Here I am attempting to REDUCE polys to increase performance by leaving faces untextured and now code is introduced to call attention to poly REDUCTION? :D This is crazy!

The models I created work just fine and with a poly reduction by leaving interior and faces not seen untextured. I see absolutly NO USE for calling attention to this just because it doesn't fit with someones idea that the interior of a building should be textured.

PLEASE remove this so called "error condition"

ANY way I can reduce polys in a model I use if possible and the model displays correctly.

I've always wondered WHY would someone texture the bottom side of a building, say a house textured? It serves NO purpose, adds two polys, AND requires that really stupid BLANK.ace file with it's attendant draw call in the sim. :jumpy: Get real . . . please?

sincerely,

vince