Hi, @ChrisTrains, in case you don't know thia archive. Here you have the fact sheets about different RS-1 from Stadler:
https://web.archive.org/web/20…ahn-gmbh-eib-deutschland/
Regards
Bernd
Ah thanks! I knew the old Stadler site had all this info but the new one is so hard to navigate. Thanks for the link.
@ChrisTrainsWere there still a version with Scharfenberg coupling coming? Because the ODEG and the DB Zugbus dont have a Scharbenberg coupling
If I can get a license from EB (Erfurter Bahn) then yes.
No - Agilis, EB and STB are all no luck so far 
@ChrisTrains I will be in the area of RAB next week. If I´ve got the time I´ll make some pictures of the inside.
That would be excellent - thank you !!!
Hmm. Well - I need some photos of the inside of the ODEG and Zugbus (RAB) versions. Then I can figure out what their floorplan looks like.
While I wait, this is where I am today:
I can make the windows more clear.
Question : is the inside of all the RS1 the same basic layout as this? ie. position of seats and toilet? Specifically, ODEG and RAB ?
Also, I really could use some video or photos of the inside of the ODEG and RAB versions, specifically. If anyone has some links or info, I would appreciate it.
Texture layout mostly complete. Starting on detail work - then actual paint ! 
If the route is built correctly the PZB should work (as long as the route is sending the correct PZB trackcodes that I can read with OnConsistMessage)
You don't really need to delete them if you're not using them - unless you're short on disk space. They'll never get loaded. At least - not with the cab fix 
Ok I'll make sure that gets in the next update
This is why I'm considering adding "CT" to the beginning of the names. So in scenarios, the engines would show up as (for example) : "CT Stadler Flirt 3 Suwex" instead of "Stadler Flirt 3 Suwex".
For the cabview using the wrong textures @ES64F4 - try this : https://www.dropbox.com/s/lfe6…ex%20cabview.GeoPcDx?dl=0
It should now ONLY be using the Suwex textures instead of Suwex, NS (and RNET - oops!)
It would be nice too, if you don't use everytime the same folder for all products (ChrisTrains/RailSimulator).
Why you don't do it like this: ChrisTrains/Flirt3 or ChrisTrains/NS6400 and so on?
I don't get it. Why do you put everything in the same folder and generate problems like we had in the past with too big Kuju/RailSimulator folders?
I use all the same folder for convenience. When making a scenario you can check one provider and have everything show up. This might have been a poor choice early on but I can't change it now as it would break all the consists and scenarios that have been written in the last 5 years (changing the path to the models would break all the links). Also - just checking the folder in the scenario editor doesn't consume memory. The only time memory gets used is when one of the items is actually loaded in the game.
If I had been thinking, in 2012 when I started doing this again, I would also have prefixed all my models with "CT" to make them easy to find when making scenarios.....
Technically I probably can still do this change because just changing the name doesn't affect the paths.
Well to be fair my textures are "only" 2048x2048 to get as much as possible in. But the Flirt has so many different wagon versions that I had to use more than one texture to capture all 5 wagons
Oh Ok I understand now. Yes - the wiper is part of the "main" texture. For the cabview it's using the same model as the outside view which is why the texture comes from the outside model. The mistake is that the suwex cabview is still using the wiper from the NS model. I can fix that in a future update.
On the original question, I'm not sure why you're seeing the wiper using the texture from the "NS" version. This is a list of the textures in the "AB" Suwex wagon:
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\bogie_jacobs"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\bogie_motor"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\dummy"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\flirt3_windowframes"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\flirt3_windows"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\flirt3_windows2"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\lighthalos_suwex_nm"
---- TextureFile: "Stadler Flirt 3\Wagons\Textures\new_wheel"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\AB_nm"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\AB_norm_nm"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\cabinterior"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\decal_commonnumbers"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\decal_door_panel_lines"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\decal_pass_logos"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\decal_pass_logos2"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\decal_suwex"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\dummy"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\flirt3_windows_suwex"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\glass_inside"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\groundshadow"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\roofmesh"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\ventilator"
---- TextureFile: "Stadler Flirt 3\Wagons\Version Suwex\Textures\wagon_interiors"
On the compression: that's weird. The "_nm" suffix is supposed to prevent any compressed version of the texture from being created. I'm not sure why the "_nmc" versions are showing up at all. Changing the "_nm" names to "_nmc" should make no difference because the compression happens when the textures are built by the blueprint editor.
But - as the compressed textures ARE being made, isn't there a much simpler solution to all of this? Change the game setting to force it to use the compressed texture: Settings->Graphics->Advanced->Scenery Quality. It has 4 steps. This is what it looks like steps 1 (top) to 4 (bottom). The lowest level reduces the texture dimensions but the top 3 all perform different amounts of lossy compression:
There are many things to consider here. The first one is texture compression. The compression system that DTG uses is terrible. They use RGB565 which means the texture is compressed from 8 bits red,green and blue, down to 5 bits red, 6 bits green, 5 bits blue. This reduces the amount of bits used to store each part of the texture. For a "mixed" texture like grass or rocks, this isn't noticeable. But for textures where "pure" colours are used, like the red stripes in the Suwex version, or the blue stripes in the Dutch trains, the colour compression results in blocky square artifacts both inside the stripes and along the edges. This is unacceptable for almost everyone. I used to do my textures so they could be compressed, but the universal feedback I received in 2012 and 2013 was "this looks terrible". So now I suffix my textures with "_nm" which prevents them from being colour-compressed. That's a deliberate move on my part.
The second issue is shared textures. You'll find on most of my trains that parts of the train that are shared with other trains also share the textures. Normally this is things like bogies, wheels, electrical parts etc. Sometimes - as you've seen - things like the wipers get through. That IS something I can look at changing.
On, the memory issue. There is a lot of misinformation on how models are loaded into memory in this game. There is a perception that activating a particular author's set of assets when making a scenario, forces them all to be loaded into memory. This is not the case. If you build a scenario and activate "christrains" but don't use any of my stuff in the scenario, none of it it loaded. The same is true for multiple colour schemes. Unless a texture is shared (like the wiper that you pointed out), the other versions are not loaded unless they are used in the scenario.
There is also some misunderstanding about how texture memory is packed on PC graphics cards. A lot of people say "why don't you use more smaller textures for the parts like wipers and pantographs?". I could but I try to minimize the number of different textures used in any model. This is because of something called "state change". PC Graphics cards are very bad when it comes to swapping shaders in memory. For example if I can draw the entire train in one single large texture, the game will run faster than if I break it into 30 smaller textures. The reason is that each time the graphics cards encounters a change of texture, it has to "state change" and unload the shader that it WAS using, load the NEW shader and start drawing again. Each change costs a measurable amount of time. 10,000 triangles in a train with one texture will draw quicker than 5,000 triangles in a train that uses 30 textures.
So there are reasons why I make the choices i make. I can slow the game down and make the textures look really bad, but I choose to try to keep the framerate as good as I can whilst making the trains look as nice as possible.
The attached picture shows an example zoomed-in section an uncompressed texture (on the left) and what 565 compression does to it in the game. You can see also the slight 'blue' in the white colour has become more 'yellow' because of the colour-shift caused by going from 8-8-8 to 5-6-5. You might
@ChrisTrains the RS1 can drive with 2 or 3 Units?
I think I have seen photos with to two units. In the game of course you can put as many together as you want
For this metal piece around the coupler, there will be a random function so it will be on with some trains, and off with others
Yep. And ODEG are "excited" to be involved and see their train in the game
