Mostly posting for Spikee but it might be good intel to whoever wants to look into it. I have a suspicion it's my thread 3 about it, but anyway. Can't attach to conversations so here it is. The only way for you to really see the difference is by downloading and comparing the pics. I'll also add them as thumbnails so you can try here. All captures use the BR Green Class 47. My observation is that over time, some kind of tension builds which forces the player head away from its initial position. If you stay in the cab, the shift is not visible unless it also affects sway, however if you cycle between cameras, you'll notice the shift upon entering the cab. The first pic is the final capture of yesterday's run of about 90 minutes. The second pic is the first capture of today's trial run. You can notice the missing left window, the clipped top, and the meters being lower. But the Headlamp just at the left end of the HUD shows how much we were forward. A little later from the same scenario, at Stevenage. I didn't have the HUD on, however you can see the difference of the left window at least, or flip-flop to see the direction of movement. You can see I'm stationary from the Amps, vacuum brake pressure and speed. Here are the pics as thumbnails.
So let's continue here. If you change cameras and go back to the cab while in motion, the cab camera will be at its initial position and then follow the forces defined by the Spring and Damping values in the cab camera file. That's ok. Even a slight shake when entering the cab is normal and due to how the algorithm works. It needs a few frames to recalculate the position after camera change. The lower the spring values, the slower the movement is. The camera should return to its initial position when you're stationary again. I have not seen this error using locos with the default spring/damping cab camera parameters of 0.1, 0.12, 0.06, 0.018, 0.015, 0.01. The BR Green 47 cab camera is located in Kuju\RailSimulator\RailVehicles\Diesel\Class47\Default\CabView It uses the Kuju parameters. Unfortunately, you have not given the name of the scenario which is vital for reproducing your run. Questions: - Have you modified it or are using a mod? The camera not returning points to erraneous Spring values without Damping. - To reproduce, always name a scenario for testing. I would suggest creating a simple Freeroam on the Academy "8". For testing custom values, I have found Ruhr Sieg to be perfect, because it is a stress test due to missing easements and superelevation. For the last three days, I'm searching for the "perfect" values, eliminating coupler bumping amplification due to the camera parameters. Personally, I've found I like it to be much more stable. I'm currently using these values. You'll notice slight cab rumble from the suspension still, which is fine. 1 1 1 0.3 0.3 0.3 These also eliminate the coupler slack bumping, or when dynamic brakes kick in on US locos.
It is entirely universal. It just takes time to develop. Old style end to end runs. For best results, drive 90+ minutes. Both scenarios are mine, on SC I pulled a Class 158 set and on the ECML (workshop, BR, simonmd) it's a rake of DT Mk1s. Attached them. The camera also returns to the same position at a given moment. So if I flip-flop 1-2 then it will do the same over and over. In a way it is similar to the arcane issue of tilting heavy cars - when you start a scenario they are upright, but if you wait (say, it's a free roam and you return in an hour), they randomly tilt to the side. They do react to curves, bends and superelevation, but once in a straight section, they return to the as-coupled tilt position. Makes no sense but it exists. And that's clearly not georotation as each car tilts randomly. (The randomness looks realistic.)
90 minutes? Don't have time now As for the tilting cars, I've posted that the Kuju US doublestacks don't have bogie stiffness and damping defined. Also, the bogie axles have little smaller gauge specified. They are not sitting on the rails correctly. Remember this is old RailSimulator content, and the first US stuff ever made for RS (by 3DTrainStuff of Run8 fame). Though that accumulation of camera movement over 90 minutes is hardly noticeable, but could be a core issue due to rounding errors of the constant spring vs damping calculations. Probably not important, but I'll check what happens using my own cab sway parameters. (Still working on my Donner Pass overhaul pack ) Anway, off we go. Initial position captured (different than yours as I have fixed the camera position, which is too far right and too low by default, of course ) Gosh the camera sway is unbearable on these tracks... Will apply mine, but first continue this run.
Ok, yes I can confirm this. I haven't noticed in seven years of playing.... there's an offset already shortly before Appleby. I think it's rounding errors that are summing up. Is it worth changing this piece of code (always the risk of breaking stuff)? I will now test using more rigid parameters, so the actual cab sway is not amplified, but is as you see it in external view.
Thanks, it feels good to know it is not an arcane issue on my end It's not extremely problematic, fixing it really depends on what's causing it. I would think that time or history doesn't play a role in this calculation, spring and damping should be fixed parameters given a loco, and the force is a dynamic parameter (itself a function of gravity, curvature, track tilt, grade, etc). I took the example of the tilting wagons for the same reason, when the force is zero these functions should return zero, and I see no reason why they wouldn't. The explanation itself could be truly interesting. It's so silly that some kind of magic idea must be behind it.
You could let TS run overnight on Academy 8 with an AFB loco and see if you're outside the cab the next morning Just a thought. I remember on the Quake3Arena engine, you could increase your jumping distance by using a specific maxFPS value. The jumping code was related to the gametics and yielded a different result at a specific framerate - but only at one specific rate! I could go on about Wallrunning in Doom... increased speed when facing a north-south wall at a specific angle and running along it Now onto my own cabcam settings check, same run.
Some news. The effect is apparent even 10 minutes into the SC scenario. The shift in camera position is related to grades, no matter what the sway parameters are. As you climb the grade, your head is tilting forward to stay upright (or the cab is tilting backward to you in relation). It seems, you're not recovering from that shift. That's a point to start looking for in the code. If it only happens uphill, then the bug should be easy to locate. And considering sway: The actual cab sway depends on the bogie parameters, visible in external view. What the camera sway does is try to simulate how your body mass and damped seat amplify or soften the (virtual) cab sway. This is what I want to be easy customizable, other than editing camera files. TSW has a motion sway intensity slider, and Run8. TSC needs that too. But this camera shifting issue is not related to the camera motion sway directly, but to the tilting on grades as I see it now. I'll run downhill now and see if it pushes you / the cab in the opposite direction. Edit: The movement shift that happens when you switch between 1-2-1 camera when stationary and after having climbed the grade is interesting. It should not be there when you're standing. It looks to me as if a variable that stores your momentum is not being cleared - getting closer. This is now very obvious to me. You will keep that momentum even when stationary. I will see if I can substract something from that variable by moving backward. One thing I have noticed, testing only on Settle Carlisle atm, that this route doesn't have smooth grade changes. 0, 1:100, then 1:200. At each of the grade changes you see the camera move a little, not returning to its old position. Now I'll check on a modern route.
The worst one for this is the 4F steam loco original DLC. I eventually sorted the problem but one would see a noticable "sag" in the head up position until it was pointing at the floor. It would only take a maybe 10 minutes to happen. I forget what I did but I have a feeling it was also playing around with the view "bounce" factors as above.
If I remember that correctly, it's because the 4F camera position is outside the cab (too far in the back) which screws the physics. That's a different issue. Move Z a little forward and this is fixed.
It showed this crazy tilting, right? Yeah, moved forward a little till I'm on the footplate and this was sorted.
triznya.andras Next things I found. It did not happen doing the same on Tehachapi. I was running up the hills from Mojave, a light GEVO, and stopped at Cameron. Went to external camera, then back to driver's. There was no shifting movement. -> The abrupt grade changes on older routes are related to this issue. It's when you run over these ugly bumps your momentum gets "overloaded", don't know how to explain it. Think of it as an integer overflow. Instead of zero the position aims to go to -128 (or 127). Just for imagination. See if you can reproduce the effect yourself playing a more recent route.
Morning! I'll be hunting for perfect camera values still. As these are not units but dimensionless coefficients, we cannot rely on tables or calculations. It's about changing and testing. So I take an easy approach by multiplying the values. The higher the spring, the shorter the oscillation, and the higher its according damping coeff, the sooner the energy's gone and the oscillation stops. I don't want te be as inert as in the default cam that has you camera following a straight line in a curve and thus moving a lot left or right. Let's shorten the distance by raising the spring coeff. And to have you return to initial position sooner, let's also multiply this axis' damping coeff. The Kuju values are interesting, because each value is different. The highest spring value was used on the Y axis (up/down), because gravity has a big impact here, which it has has not in the horizontal movement axis X and Z. Still it has less damping than the X axis, probably to suggest a good soft springy seat. So I have to define what I want (and it's mostly like in TSW, much less amplitude in relative movement to the cab). So first, I'll raise the spring values without touching the damping, then see how much damping is required to quickly stop the movement.
Blasphemy. Me driving anything less than ten years old? How... I have Tehachapi, can do that. Also drove the new PDL a lot. I thought about it further, the interesting part is going to camera 2 and back - it intentionally shifts. Also, with time the bounces are greater. It is as if trying to simulate that the springs are weakening. Like with the ICE 1, bounce enough and you fly out of the cab. When entering back to camera 1, ideally it should stay if there are no forces. So there must be something. I've been consciously observing my head movement a few times on a tram or bus. Even just sitting right here in front of the PC, I keep moving. The brain automatically filters it, following our focus and acknowledging the bumps with our bodies. I kinda like the vertical, too, it gives information about where the grades are starting.
Yep, you don't even need to make comparison screenshots. If stationary and you press 2-1 and observe camera forward movement, you know you triggered the bug. Like I said, not found it on well-constructed routes without sudden rough grade changes. But will hand this over to Steve. It'll just need a momentum resetting line of code (split consists will also need this as you know how they begin to move at the speed when the consist split happened, and you try to recouple) when coming to a stop - or good debugging when that value overshoots. Settle Carlisle northbound was the perfect route for testing, as you'll have the first slight shift when going to 1:100, and you see the bigger shift when the 1:200 grade starts without transition. It slightly lifts you out of your seat but doesn't fully return, no matter what cab camera sway values are used. (Funnily I only managed to play your carriage return scenario once, all subsequent tests ended in derailments due to that idea of coupling a buckeye up to hook and chain - use "Allow all couplings" at your own risk. At least use a CoupleToBack instruction so the consist becomes active before the coupling happens which leads to derailment. So I chose a 37 and 4 MK1s Railtour . Or equip a 47 with a buckeye.) The vR BR 218 also shows movement, but that is due to the adjustable seat height code which gets active. When you change from external to internal view, the cabcam coordinates are applied (TSC code) and then the transition to your chosen seat height takes place very quickly (vR script).
Just curious, did you change the couplers? (158 or 47) You may recall my fluff screenshot recently with a few meters between the coaches. They can also merge somewhat. Thanks for the idea about the coupling instruction. I didn't specifically notice but this is where your sway changes can help. Didn't you invert the grades? There are multiple shifts up to Ribblehead, so it's a fairly fast test route, then, indeed. I assume running light is the same. If you need a vouch to be part of my imagined TSC community contribution team... send Steve my way :-D Github terms, you could create pull requests for Steam content, and suggest approvals.
So, I think I found the perfect values. You don't need to go to extremes, and it seems to avoid rapid oscillations it's best to keep the Kuju ratios of Spring/Damping. I've slowly raised X and Y by multiplying them but keeping the ratio, and then applied the X to the Z value. You're not being pressed into the seat like on a rocket start now, which should also eliminate coupler bump. (Testing now) All other values I checked from vR or RSSLO had unwanted side effects ("trembling") on uneven tracks. Current favourites: Spring X -- 0.5 Spring Y -- 0.72 Spring Z -- 0.5 Damping X - 0.09 Damping Y - 0.09 Damping Z - 0.09 Tested on Ruhr Sieg "ICE Speed" scenario. Feels great, and no rapid oscillation. US dynamic brake and coupler bumping eliminated (reduced to a minimum). Will do some more testing on US and european content. Will then put them in my DonnerPass physics, lights and scenario fix update on trainsimcommunity. I will only keep the old values for Steam engines where I want that swaying (and the Pacer probably ) Of course, for players who like the feeling of being thrown around in the cab, these values are not good
Andras, no coupler changes. Only US stock and the tankers used in the Class 70 WCMLNorth "Keep On Running".
Works like a charm, now the Class 86 on WCML North is much more enjoyable. And using these parameters on heavy US locos is a real game changer. They feel much more powerful and heavy, and those forward bumpings when notching up made the loco feel too lightweight before. Btw, if you edit Assets\keithmross\WCMLNorth\RailVehicles\Audio\Electric\Class86\Cab\Cab Occlusion.bin and set the LFRatio value to 0.35, the annoying fan sound gets muffled nicely.
Well, I tried to run a Tehachapi QD from 01 (yard) to 10 (Caliente) and halfway loading, the game just disappeared. No crash report, temp dump, nothing. Here is the QD it generated. I'm losing my trust that the content I purchased earlier remains playable over the years.
It's working here, no problem. I suspect you have both ES44AC ROW and US livery packs active. That will crash the game on blueprints.pak generation. It is mentioned in the Support FAQ, so make sure it looks like this. I'm sure that's your issue. You must only have one active.
Thank you. It worked. I had some shift in the cab, unfortunately no proof because just as I was trying to stop on the final waypoint - without much effect - there was an AI collision. There were lots of grade changes on this section and of even more power flip-flop. I had lots of scenery issues though, from flickering distant scenery, big miselevated blocks to a floating signal in a siding. I must double check my settings and cache but Sherman and Soldier are way superior to what I experienced. Might be an issue with the season, or simply a design decision to cope with 40 fps. Trees were flickering crazy as well. There are two spruces near Kern Junction which disappear when approached. This is not the topic so no pics, but have to say it. I also had a funny operational error on the summary: All.
15 FPS in 3D Snow, 40 fps on Sherman and Soldier? You might consider upgrading your hardware mate All runs in capped 75 FPS on my system.
What did you change on the WCML Class 86 - this Occlusion LFRatio? I must do that on the Class 370 - not not sure what to change - does not seem to be a Cab Occlusion.bin file
Yes, the LFRatio which cuts high frequencies. Class 370 (DTG) Cab Occlusion: Assets\DTG\Class370Pack01\Audio\RailVehicles\Electric\Class 91\Cab\Class 91 Cab Occlusion.xml You might need to set "OcclusionDirectRatio back to "1" here, which is a multiplier and should be left to 1 according to this brilliant FAQ: https://www.christrains.com/nl/ts_faq_audioocclusion.html
After a lot of testing, I've stepped away again from my super hard suspension values, to find a good balance with light headsway movement. I found the key is to first raise the damping parameters - they affect how far the g-forces moves you away from your position. Then adjust the spring, which is the speed at which you're pushed back into position when the force on you lessens. Currently using these: 0.1 0.12 0.11 0.06 0.06 0.06
Looks like quite a significant change compared to the earlier ones Isn't it a little "content for content"? So if you design it for the likes of Settle-Carlisle or Donner, you want reduced reaction on the sharp changes, compared to smoother routes. Similarly, the speed of the ICE 1 After all, people on our local tram lines do fly around the car, when it's going through a switch, for example, or certain curves. Particularly the (old?) Siemens Combino where each car is a truck. But the CAF (every odd car is a truck and each even between is hanging) can move around quite a bit, too.
Yes, it's almost default again but with higher damping. And Motion Sway is subjective and depends on your body tension, how you're seated. I've not experienced the Kuju sway driving my car with much faster acceleration and speeds. So the higher damping achieves that. Of course, when standing it should be different (TSW has different values for sitting and standing), but TSC has no standing mode. The good thing about these values is they do fit all. Even the Allegra, or the Taurus, that needs higher damping due to the quick acceleration which has ugly bumping side effects with default values. And you still feel when your couplers are stretched and you pick up the whole train weight on US locos, but it won't throw you forward as before.
triznya.andras This problem is know, found it in the rail-sim.de wiki. Here's the auto translated version of the article from 2017: If you have already traveled a long distance in a vehicle, the visibility in the driver's cab becomes more and more wobbly. Some users refer to the shaking as the “JellyCam effect”. The shaking is so bad that you can hardly look at the screen. It usually occurs particularly when accelerating, braking and cornering. The view seems to be getting closer and closer to the window. If you look at the outside view and then back into the driver's cab, you notice that the view quickly moves from further back to further forward. The only solution here is to save the task once, exit and continue. Then the wobbling goes away for a few kilometers. But unfortunately it comes back. The shaking, understandably, makes you a little nauseous. Maik Goltz, a developer at virtualRailroads, took a closer look at the problem. Using the search function you can find some of his articles that explain the problem or the reason he suspects in more detail (search term “Jelly Cam effect”). But unfortunately the developer DTG is once again taking a stand. This probably won't be fixed. Maik Goltz gave a solution: If you don't leave the cab, the shaking doesn't occur or is delayed. But who manages to stay in the cab all the time? In scenarios in which you want to drive a push-pull train, you should finish the task at the terminus, create a new one in the editor and place the train at the terminus. Then the wobble is basically “reset”. It occurs approximately between 80 and 160 km. For the vR Dosto control car it's more likely from 80 km onwards, with locomotives more likely from >160 km. Since hardly any route is >160 km long, this shouldn't be a problem with locomotives or railcars (like Stadler Flirt). However, if you turn your head and want to go back, the shaking starts. https://rail-sim.de/forum/lexicon/entry/118-die-kamera-im-führerstand-wackelt-sehr-stark/
I remember when the BR 103 from vR was released it suffered from Jelly Cam but I think Maik Goltz found a solution? It was a bit since I saw the thread and it might even have been on UKTS. Peter
Though the shaking is only apparent to me on old routes without superelevation like Settle-Carlise or WCML North.
Run the Swallow HST from Peterborough to Kings Cross, then back. It's a mostly flat route, with some 1:200. Camera movement aside, on the way back it was a lot more jittery. Mostly due to how curves are polygons. I still think that the cause is some force that causes the head position to move forward, and due to already being forward, it reacts differently to additional forces. TSC physics have many quirks. I wish to see this fixed as this is not just a minor quirk (like swinging and sliding in place) of a force-reaction implementation, but something that builds, just like the consist tilt (reported recently by rwaday).
I think the fix would be just adding ONE line of code.... driving the APT becomes horrific after some time, I tried to stay in the cab it was ok but once I changed to external cam and back the camera was wobbling all around the place and the rest of the run was terrible. Don't like to use savegames.
I notice the APT Cab Cam is at an angle to the left when you return but it does seem to smooth out. I did a QD from Munchen to Augsburg with the APT which was fairly smooth - was that down to the track?
