[jonas]

Jovet, on 24 December 2023 - 01:40 AM, said:

...

If you should want to examine the shape I made for testing, here it is.

Thank you Joseph for your detailed work on this topic so far and even for creating your extra shape - especially on a day like today!

You encouraged me to read the "Conversion of Shapes and Textures 1.01.doc" again and I have translated part of it for myself. Thanks for the offer to send me the file, but I had easily found it on my computer. In principle I still knew the contents, it had been some time since I had read it, but now it is well refreshed.

I also work with Gmax sometimes, especially when 3dsmax messes up when exporting animations to 3ds format, which can be very annoying with steam locomotive rods, for example. So I also know that Gmax works enviably "cleaner" when it comes to creating s-files.They seem to be more clearly structured and work for MSTS/OR without much rework. However, I am very accustomed to the handling of 3dsmax and also to the possibility of making detailed manipulations, e.g. via material designations. Something that often seems like an advantage to me, but has become a problem here.

On this occasion of the thread here, I tried to understand the structure of the s-file in relation to the ESD_SubObj ( ) parameter in more detail. The categories "matrices", "hierarchy", "sub_objects" and "primitives" were my approach. For the most part, it is still a mystery to me how exactly this works in relation to the ESD_SubObj ( ) parameter, because of course I can clearly see that the US2lamp1.s or your shape work well, but what is so "wrongly sorted" in my reception building that some sub_objects are always hidden that are not desired still remains hidden from me.

I don't want to bore anyone here with these details, which perhaps only concern me. I'll stay on the ball a little longer and if I have any further insights, I'll be happy to post them here.

Until then, Merry Christmas to everyone!
Jonas

[Jovet]

Quote

There is a strict naming convention for shapes:MaterialName[sub object id][_user defined].

Myself never having put shapes together as you are doing, I can only guess how exactly this "strict naming convention" works in practice. Are you currently assigning a "sub object id" of 1 to the lighted part?
As far as the shape files, I can't claim to be an expert, even after all these years, but it's been my understanding that the sub_objects() groups under each LOD distance_levels() group represent each part in the shape. The first sub_object() is part #0 which is the main shape (or the root of the hierarchy). Additional sub_object() groups continue as needed for each part. The matricies() group earlier in the file enumerates the later sub_object() groups, gives them their part names, pivot point coordinates, etc. Looking over my example shape from my last post in Archibald, many of the shape file's fields are given interesting or helpful titles as to their purpose, but not all of them are.

Merry Christmas back at you! Even if it's a day late.

[jonas]

Jovet, on 26 December 2023 - 07:05 AM, said:

Quote

There is a strict naming convention for shapes:MaterialName[sub object id][_user defined].

Myself never having put shapes together as you are doing, I can only guess how exactly this "strict naming convention" works in practice. Are you currently assigning a "sub object id" of 1 to the lighted part?

Thanks to your advice, Joseph, I did exactly that. And after many hours, I have now gained some insights. In addition to your quoted part, the following is then written in the "Conversion of Shapes and Textures 1.01.doc":

"•Sub object id is an optional number between 0 and 31 so that other sub objects can be assigned, ..."

I didn't understand this exactly for years, because for me it should have read better:
"•Sub object id is an optional number between 0 and 31 using it one can define sub objects IDs, ..."

Finally, I then understood/discovered for the first time that a SubObjID exists in every sub_object_header, which uniquely indexes the sub_object:

SIMISA@@@@@@@@@@JINX0s1t______

shape (
	...

	lod_controls ( 1
				...
					sub_objects ( 3
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 0               <-- SubObjID = 0
							)
							...
						)
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 2               <-- SubObjID = 2
							)
							...
						)
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 1               <-- SubObjID = 1
							...
							)
						)
					)
				)
			)
		)
	)<div>)

The last digit at the end of the "subobject_light_cfgs" lines is always the SubObjID.
(Admittedly, the connection between this number in the last "subobject_light_cfgs"-lines at each blockends and the "sub_object_header" wasn't easy to realize for me)

---

Now back to the actual topic, the ESD_subobj () entry in the sd file:

In MSTS, the sub_object for which this SubObjID = 1 is always hidden during the day!
(In the example shapefile above, the lowest sub_object would be hidden during the day because it has SubObjID = 1)

OR, on the other hand, indexes by itselfe the sub_objects according to their appearance from top to bottom in the shape file and ignores the SubObjID!
(In the example shapefile above, the middle sub_object with SubObjID = 2 (!) would be hidden during the day)

I looked up the OR code and identified the variable i in the corresponding for-loop-i++ as the "wrong" indexer (Shapes.cs, approx. line 2121).

The SubObject that appears second in the shape file is often the one with the SubObjID = 1, but even not always.

All the effects here and here are now easy for me to explain.

[Genma Saotome]

jonas, on 27 December 2023 - 08:31 AM, said:

In MSTS, the sub_object for which this SubObjID = 1 is always hidden during the day!
(In the example shapefile above, the lowest sub_object would be hidden during the day because it has SubObjID = 1)

That explains this shape:

Quote

SIMISA@@@@@@@@@@JINX0t1t______

shape ( Vampire.s

ESD_SubObj ( 1 )
ESD_Detail_Level ( 5 )
ESD_Alternative_Texture ( 0 )

)

jk.

I see many ESD_SubObj ( 1 ) values assigned to automobile shapes in both the Raton, WP3, and Tehacchippi routes, some i n carspawners, most static.

[jonas]

Genma Saotome, on 27 December 2023 - 12:49 PM, said:

...
I see many ESD_SubObj ( 1 ) values assigned to automobile shapes in both the Raton, WP3, and Tehacchippi routes, some i n carspawners, most static.

Hi Dave,

For MSTS it does not matter how you write it, it is always the sub_object with the SubObjID = 1 that disappears during the day.

I've tested:

ESD_SubObj ( )
ESD_SubObj ( 0 )
ESD_SubObj ( 1 )
ESD_SubObj ( 2 )
ESD_SubObj ( 3 )
ESD_SubObj ( Rabbit )
and even ESD_SubObj without any brackets works...but always only for sub_object with SubObjID = 1.

For me, this means that the letter sequence ESD_SubObj alone is already effective. Only when I entered ESD_SubOb (e.g. without the j) does it become ineffective in MSTS.

Here are the only MSTS sd files in which ESD_SubObj occurs at all:
carlisle.sd
c_van.sd
JP1SagumionoSt.sd
JP1ShinjukuSt.sd
JP1streetlight1.sd
Jp1Truck1.sd
OEHauptInnsbruckSt.sd
OEKematonSt.sd
OELamppost.sd
OEOzthalSt.sd
OEStamsSt.sd
US2BeltonSt.sd
us2cutbank.sd
US2lamp1.sd
US2Shelby.sd
US2SpottedRobeSt.sd
US2WhitefishSt.sd
US2YardLts.sd

There are some dubious ones, such as carlisle.s, a truck shape which only has 1 sub_object with the SubObjID = 0 anyway.
But at least the lamps like JP1streetlight1.s, OELamppost.s and US2lamp1.s seem to have the same good working structure and always a sub_object with SubObjID = 1, which represents the light.

I have not explicitly tested whether OR differentiates between ESD_SubObj ( ), ESD_SubObj ( 1 ) or ESD_SubObj ( 2 ), but I think it is unlikely. The code always tests for "1", regardless of which ESD_SubObj entry was read, whereby in OR it is not the SubObjID = 1 that is meant, but the rank in the order of the sub_objects.
Excerpt from the If query in the code: "... (i == 1 && HasNightSubObj ..." (Shapes.cs, approx. line 2127)

[Kapitaen13]

Our expert Hehl has posted an answer for Jonas at TSSF, as he can't write here.

ESD_SubObj()

[jonas]

Kapitaen13, on 27 December 2023 - 10:48 PM, said:

Our expert Hehl has posted an answer for Jonas at TSSF, as he can't write here.

ESD_SubObj()

Under this link ESD_SubObj() at TSSF is written in german:

Quote

Mit den Id Nummern der Sub_objects hat das nichts zu tun, diese sind m. W. belanglos. Es kommt einfach auf die Reihenfolge der Sub_objects an.

English: "This has nothing to do with the Id numbers of the sub_objects, these are irrelevant in my opinion. It simply depends on the order of the sub_objects."

Unfortunately, this is not true for MSTS, only true for OR. In MSTS it is crucial that the SubObjID is equal to "1", regardless of where the sub_object is located in the s-file.

You can easily test this for MSTS by setting the SubObjID to a value other than "1".
(The SubObjID is the last digit in the subobject_light_cfgs-lines of a shape)

For me my initial suspicion has been confirmed that OR does not correctly reproduce the original functionality of MSTS when it comes to ESD_SubObj ( ).

[jonas]

I currently would summarize the ESD_SubObj ( ) topic as follows:

For the use of the ESD_SubObj ( ) parameter in the sd-file for daytime hiding of a sub_object in the s-file, you should note ...

- ... that in OR the sub_object to be hidden must be listed in the second position in the s-file.

- ... that in MSTS the sub_object to be hidden must have the SubObjID = 1.
(The SubObjID can be found in the s-file in the sub_object_header blocks as the last digit in the subobject_light_cfgs lines).

As currently "tip and best practice" for both simulators MSTS/OR simultaneously:
Set the Sub_object to second position in the s-file and it's SubObjID = 1.

[Csantucci]

Thanks, Jacob, that was a precise and useful conclusion.