CT Mat'64 update

[Spikee1975]

This is no version difference. This is purely a "mod" that is completely optional and not in any way required (as a separate EngineBlueprint would be).

[Rubku_NL]

Even so, it’s a modification of the original that’s being circulated; if you have Chris’s permission, that’s fine.
But otherwise, we won’t allow it – not even as a link to another site.
Given that we simply don’t want any version differences.

[ChrisTrains]

Hi Chris.

Seriously good job, thank you.

Small issue I got. Why are you making the player's head so rigid? With your cab camera values you've killed almost all natural headsway.

Now here's a suggestion.

First, try the default values which are imho just representing the effect of the forces on the human body best (0.1, 0.12, 0.06, 0.018, 0.015, 0.01). I've a suspicion these rigid values are often used to mitigate the jolting which is due to coupler parameters.

Now set the Mat'64's couplers' min, max, target, spring and damping all to zero. We really do not need these, they are crucial for freight cars to evenly let the forces travel through the train (else consist may split if long and heavy). But in Multiple Units I see no need to use these values - quite the opposite actually:

There can be an ugly effect when the spring and damping don't really cancel each other out and after driving for a while start to play ping pong - you'll experience permanent small jolting (found on the ICM too). You can even see it in the external camera, the effect stays even after coming to a stop and moving again. The second unit will not be "in sync" and appear to constantly push against the lead unit.

About the lights, I've reduced radius, theta and phi for the dimmed light as in their current state they're not really dimmed and illuminate the scenery way too strong in daylight. For the normal headlights I would suggest activating shadow casting, as they are fairly strong and without shadow casting will protrude walls and your cab if coming up from behind. (My rule of thumb is if a headlight radius is larger than 20m, it should cast shadows. Looks strange on a bridge if the water below is illuminated "through" the tracks.)

I'd go a step further and enable DayNight cycle for the light so it's only really illuminating the world between dusk and dawn, same as AP does it. Imho it feels off seeing headlight cones illumate the tracks in daylight. (Note this can not be done on locos which rely purely on the headlight flare overlay (baaaad design - these will then appear to be off as the actual lamp doesn't have a lit texture. Found in the lately very inconsistent virtualRailroads stock.)

Cheers,
Pete

Pete. Thanks for the feedback.
First the easy one : shadows on the lights. I've never done this because of the performance impact on the game. TSC is notoriously terrible at doing light shadowing and even with only three shadow-casting headlights, it can seriously plow the framerate for a lot of players. I have comments from people who see framerate drops when they turn on the cab light and that's just a single shadow-casting light.

All my headlights have always had illuminated textures, and flares (for the main and high beams, but not for the low) and projected light elements. I did experiment with the DayNight cycle a few years ago but I didn't really like the result. It was inconsistent at best with the illumination being pretty random. It seemed to be tied to the clock time, not the actual sun-cycle. So in the winter when it's dark at 16:30, the lights would not illuminate the world because the game seemed to hard-code that day/night switch to 06:00 and 18:00. So you could be driving for 90 minutes with no lights at all.

I could do different radius/theta/phi values for the dimmed lights. Honestly the reason I didn't was a combination of about 25% laziness and about 75% having so much other stuff in the project that I just completely forgot. That's absolutely something I can patch easily if you have some suggested values.

The coupler thing is long-standing issue with the game because I don't think it was ever really designed to properly do solid couplings (like the permanent couplers between the wagons of an EMU/DMU). In fact I don't think it was ever really designed to do multiple units at all.
Anyway - if you set the min, max and target distances ALL to zero, the game has a tendency to either vibrate the whole consist, or just explode it into the air the second the consist spawns into the game. I've long suspected there is a divide-by-zero error somewhere in the internal maths.
In the Mat'64 the values are set like this:
Min distance 0
Max distance 0.1
Target distance 0.05
Spring coefficient 0.0
Damping 0.0

The ICM has the max distance set to 0.025 and the target distance set to 0 and I suspect that zero target distance is what causes the jolting in that model as it's falling over a divide-by-zero error somewhere inside the game code. I really need to fix that with a model patch.

So you're 100% correct about the tighter cab camera sway values - a lot of it is to try to mitigate the jolting caused by the suspected coupler divide-by-zero error in the game. By the way - those errors compound the longer you drive. For example if I use the 'stock' cab sway values and you drive the HSL route from Amsterdam through Rotterdam past Breda down to Brussels, after a couple of hours of continuous driving, the coupler error jolt gets so bad that the trains become almost undriveable. And if you do a long enough scenario where - half way through you change cabs to the other end - the game just gives up completely and even stops drawing the scharfenberg couplers on the return leg. If you try to couple when the game gets into that state, it's an instant crash.

[Spikee1975]

Hi Chris.

From my own experience the headlight shadow casting has less impact than the (very inefficiently coded) lens flare rings. But depends on the PC specs of course. For me the pros outweigh the cons here - especially at stations with the wide angle of the spotlight it looks weird and very dated not having the objects cast shadows and light protruding everything. I first noted that I think on DTG's Kansas Topeka route which had headlights set to a mile radius, full RGB and no Shadow Casting. Your cab would light up without you knowing what's the deal only to find there's an AI train a mile behind you causing this...

The DayNight cycle corresponds to the Dawn and Dusk times set in the season's TimeOfDay blueprint. I do not know how it works under SilverLining - but then who's using that since AP overhauled the whole lighting and weather system...

I had removed any coupler slack in the ICM too which completely resolved the issue of jolting. They may be realistic but here's a compromise to make to suit the game's physics. It also feels much more better having the natural camera sway sitting high above the tracks where lateral movement is stronger than below.

Also made the 6400's couplers rigid as with heavy trains applying the brakes and releasing them could cause the loco to make a wild jump forward (which in turn is a problem of the freight wagons brake release timings being to short, all the spring values of each coupler in the consist add up and the damping can't catch that - only if everything is setup correctly the train will behave good.

As for the lights, I use the dim setting if available in daytime as you really shouldn't see any illumination, as no headlight is stronger than daylight.

I really hope you do not have a problem with user created tweaks - I understand and appreciate how strict the dutch community is - but as long as I don't make a patch that creates a version of a train like Rubku fears, everyone should stay free to release their improvements, there's people who care about camera sway or lights and people that don't. That's why it's optional and my patches are never a requirement for any scenario. They are just for people who want them.

You don't want to know how many DutchClassics or MyRailDreams window textures I've ran through paint.net just to remove the milky window tint which annoys me like hell... but I haven't released any of these (too much work uploading, making descriptions. I patch things on the fly to my guidelines within minutes after acquiring new stock). With your update, I thought here's a chance to tell you what can be improved.

EDIT:
Another note on couplers. Years ago, I fixed all DTG US couplers to get rid of the consist splits that noone had any solution for. These need a good amount of slack, the TS physics are actually pretty good. With that came the problem of the "jolting". The reason was that DTG shared their loco couplers with the stock couplers. Even if an AAR is the same, you want the locos not to have that slack especially as they are working as MUs. So the solution on my end was to make separate coupler blueprints for the locos, and edit each loco bp to use these rigid couplers. I saw that SwitchpointSimulation have made it the same way for their excellent freeware locos. That way you can keep the natural cab camera spring and damping (which wasn't just a roll of a dice by Kuju, they seem to be empirically gathered.)

[ChrisTrains]

I don't mind mods of course - people have modified my stuff going back forever. I do understand Rubku's reasoning though, for the Dutch community that uses DutchSims regularly, it could be confusing to some to see a patch not issue by me. I've no problem with you hosting it on the other site though. Please just make sure it keeps up with anything I do. For example if I patch to 4.0.1 for the headlights and couplers, make sure the thing you have on the other site then doesn't conflict with it.

If you send me the values you've tried for the dimmer headlights, I can definitely roll that into a 4.0.1 'official' patch.

I'd have to to spend some more time with the coupler values though - I'm not convinced that zero'ing all the values works in the long run.

As a general rule, I try not to deviate too far from my 'core' model design. So for example I wouldn't put the day/night cycle on the lights in one single train because then I'd likely need to go and patch all the others. So yes - headlights at daytime are perhaps just too visible but "at least" they're the same on all my models. So they're consistent. Some would argue 'consistently wrong'

If you're on discord, maybe better to take this there so we can discuss it without clogging up the forum Send me a PM on here with your discord username.

[Spikee1975]

You could download the mod and try for yourself.



They will still softly illuminate tunnels while being hardly visible in daylight.

I'll see you on discord.

[DutchDriver]

This is no version difference. This is purely a "mod" that is completely optional and not in any way required (as a separate EngineBlueprint would be).

Making a mod isn't forbidden of course. If you would like a mod like this to exist on here, then Chris would need to give approval and it should be posted as a download on this site. We don't want loose downloads as links on our site, as that makes it a whole lot more difficult to know where they all are. We have a very complete list where every download is placed and in the past we had a lot of problems with these kinds of things (mostly on another website, where part of our team was moderating as well).

Rubku didn't mean to say it's pointless or anything, just that we have a complete download section for these mods.

[Spikee1975]

Agreed on that, that's why I'm hosting my stuff on trainsimcommunity, which is as it says, the place for community mods. I consider DutchSims.nl to be the source of official content, hence why I released it on tsc for people who feel the same as me about these things. (Which I cannot classify as bugs though - it's purely optional QoL improvements here.)

[Telefunken]

To alleviate the situation with patches/mods vs original files, I always put the original DLC in an .ap file. When there aren't settings files or concatenated scripts of course, those will need to stay in their original folders parallel with the .ap file.

Preload files are best left in their own folder, since I usually create more consists or add routes with TS-Tools or LocoSwap.

This way, the original DLC stays secure in its .ap file, free from modded bins, mappers, audio proxy's, geo's or textures. Same named files outside the .ap file take preference over the 'packed' ones when the DLC gets parsed. Best to delete the DLC's .pak file after every edit to a modded file or you'll get an OOM error on first run.

And a player can tinker with a train at will, in the reassurance of always being able to revert to the default DLC by deleting his files. No re-installation needed.

With some careful planning and selective copying (read those .bat files line-by-line) repaints can reside in .ap files too, one just has to avoid duplicate identical paths which will crash the game.

Packed DLC is much easier and faster to backup than hundreds of individual folders compromising thousands of files.

My TSC PC has 3 installs, Europe, UK and USA/rest-of-the-world, totaling 2.17 TB. With NTFS's 'symbolic link feature' and this tool <Snip> asset folders can be shared between the installs without having to create copies.
Best split off the Preload files and put the rolling stock into a separate .ap first so your Europe QuickDrive selections doesn't show UK or USA locomotives.

[Spikee1975]

Careful though. No umlauts may be present in the filenames you're packing into .ap files. zlib.dll can't parse these to the game (and it's a common rule to keep technical filenames that are processed by games 7bit ASCII strictly). Also repaint installers may want to find a DLC in its original state for Geo copying either using "xcopy" or "7za.exe". Advanced german signals will not work (see DTG delivering an extra KarlsruheStrasbourgSignals folder for example.)

What I am doing is each route gets put into a MainContent.ap to save it from accidental changes. You can just delete the external folders to either undo the change or distribute just those files as a patch.

Of course, modern OSes like NTFS and TCP/IP prefer large files as they are much easier to handle as you say. (And against common myths, an .ap does not get loaded into memory, only its registry "blueprints.pak" gets cached and zlib handles the file access completely transparent for the game which doesn't know about .ap files.)

[Spikee1975]

My TSC PC has 3 installs, Europe, UK and USA/rest-of-the-world, totaling 2.17 TB. With NTFS's 'symbolic link feature' and this tool <Snip> asset folders can be shared between the installs without having to create copies.
Best split off the Preload files and put the rolling stock into a separate .ap first so your Europe QuickDrive selections doesn't show UK or USA locomotives.

Instead of posting direct links to software please try to link to its downloadpage as much as possible which can found behere. That way people have easier access to the description and readme of what there actually downloading.

Also i'd like to put out a firm warning that while using this feature to have multiple TSC installations can both be very usefull and powerfull, improper use of this rather unknown Windows feature can easilly cause issues with the operating system not working as intended.
Please be sure to only take this advice if you're know exactly what you're doing!

Daarnaast is een flinke waarschuwing gepast, symbolic links kunnen heel nuttig zijn maar ook grote problemen met je Windows installatie veroorzaken als je niet weet wat het is of hoe het precies werkt.
Overweeg dit advies/gebruik deze tool alleen als je precies weet waar je mee bezig bent!

Finally I want to make a reminder this topic is about the Mat64, if you want to discuss this further; please consider making a topic spefically about collection managment

[Telefunken]

Careful though. No umlauts may be present in the filenames you're packing into .ap files. zlib.dll can't parse these to the game (and it's a common rule to keep technical filenames that are processed by games 7bit ASCII strictly). Also repaint installers may want to find a DLC in its original state for Geo copying either using "xcopy" or "7za.exe".

What I am doing is each route gets put into a MainContent.ap to save it from accidental changes. You can just delete the external folders to either undo the change or distribute just those files as a patch.

Of course one has to be careful, and make regular backups of such large installs with a lot of 'history'. Diacritics common in German or French are a source of problems when your Windows uses a different NLS than the route's author.

Indeed, after checking it with TS-Tools I immediately pack a route into MainContent.ap, usually without the Scenarios folder, since any change to a scenario means the files will get pulled from the .ap files. TS-Tools cannot natively check .ap files without opening and de-serzing their contents.

Luckily, ChrisTrains new NS Mat64 comes pre-configured with QuickDrives for the major Dutch routes available at DutchSims here.

Oeps, mijn verontschuldiging voor het laten ''ontsporen" van deze rubriek.