If I'm not completely wrong, I never developed the script of the KT4 (published by BLV-1986) for a possible back-to-back coupling.
So it's intentional behavior, and if it worked at some point it was most likely a bug that I fixed at some point.
If I'm not completely wrong, I never developed the script of the KT4 (published by BLV-1986) for a possible back-to-back coupling.
So it's intentional behavior, and if it worked at some point it was most likely a bug that I fixed at some point.
Ich habe ein bisschen weiter getestet und glaube, ich habe eine mögliche Ursache gefunden. Das Problem tritt immer dann auf, wenn in den Gleiseigenschaften ein Oberflächen-Spline für die Bettung ausgewählt wurde.
Das Ganze tritt auch bei Verwendung von Standard Content auf. Das gezeigte Beispiel macht zwar überhaupt keinen Sinn, aber der Karteneditor mag diese Kombination offensichtlich garnicht, da die Berechnung eines 50m Gleises auf einer neuen leeren Karte durchschnittlich 3-5 Minuten dauert (ohne einen Oberflächen-Spline als Bettung dauert es nur 10-20 Sekunden).
I've tested a bit more and believe I've found a possible cause. The problem always occurs when a surface spline has been selected for the bedding in the rail properties.
The whole thing also occurs when using standard content. The example shown makes no sense at all, but the map editor obviously does not like this combination, since it takes an average of 3-5 minutes to calculate a 50m track on a new empty map (without a surface spline for bedding it only takes 10-20 seconds).
Yes i use spline
If you want to continue using the PH37a rail and ties, please also replace the splines with polygons (it should be at least -0.195 below the top of the rail).
I just tested it and was able to reproduce a very similar behavior in the map editor when creating a two lane test track with splines on a blank map. Therefore, it's very likely that the error is caused by the use of the surface splines.
Now that I know about the problem, I'll take a closer look at it. Apart from that, I would recommend using polygons anyway, as these are usually much more versatile than a spline.
The ties are not basic content. Do you also use a gravel spline from my package (e.g. KT_Bettung-02...) or polygons?
The model itself is fine, in different modeling editors.
This is where the 3D programs "lie to you".
As you've already noticed, the problem is that the normals of several polygons point in the wrong direction. This doesn't matter so much in Blender (or many other 3D programs), because usually the back of a polygon is also displayed with a material / texture.
But most game engines don't have this strange behaviour. Therefore I recommend to enable "Backface Culling" to see the mesh as it appears in Lotus.
To solve the problem in Blender, you can try 2 things.
In edit mode you can run "Recalculate Outside" (CTRL + N) while all polygons of the object are selected (A) and hope that Blender will fix everything (unfortunately this function often fails with very complex objects).
Or you have to select all affected polygons (Backface Culling helps here too) and rotate them manually with the "Flip Normals" command in the same menu.
Just deselect the option "High resolution center tile"
just clear this line, so that it is empty
For later, all possible parameters for Lotus can be found in the lexicon. https://www.lotus-simulator.de…y/23-starting-parameters/
The old file is automatically overwritten by the game. You don't have to delete anything
Ok, now that's clear. Did you remove -VRon from the startup parameters? If you still have problems, a new logfile would be helpful
Unfortunately, I forgot to mention that private messages are only available if your account is at least 5 days old (I think it was 5 days, but I'm not totally sure).
Maybe Janine can make an exception for you, if you like.
You can try to use another starting parameter, such as -windowedfullscreen and see if there are any changes.
You can also tell us your hardware configuration (especially graphics card) and send a log file too. This could help us understand this case better.
The only thing that came to my mind now is to do the following:
Open your working directory from the map editor and navigate to the folder of your map and then to the "Export" folder.
There you can sort the files according to their file size.
For my testmap it looks like this
The name of the largest .mtl file is now important because the first two numbers show you which tile it is.
The first number is the position of the tile at the latitude, the second value is the position at the longitude.
These values can be read in the map editor in the lower status bar.
I'd come up with two things you might want to check out.
First one is the type of material, but you will surely have it right.
Second is the "Intensity of normal texture" maybe the value is still "0"?
I hope this will help you, if not please post a screenshot of your material properties.
Edit: Even another idea. There is also a setting on the Graphics tab. This option may not be enabled.
Can you upload the log files while this error occurs?
Anyway, have you already tried to repair the game data? Maybe something went wrong during the update.
Please check if the content is still subscribed in Steam Workshop and start the simulator once before starting the map editor.
Edit: Again a little too slow, I have to stop doing more than two things the same time
Not at the moment, but maybe there will be one in the future.
Also there is one more thing: A Lexicon article mentoined that it is recommended to use smaller textures for the LOD modell. But then there will be 2 different textures stored in the VRAM, won't be? (Original and the smaller LOD texture)
Therefore I would recommend to use mipmap in dds textures