I'm also noticing that some routes use the first part of the ground snow slider for snow atop mountains, and only after 15-20% it starts applying snow to player area (Semmeringbahn i.e.)... Which could also be utilized once some mapping are customizable per route... i.e. the peaks coordinates could be added to the app, and the snow atop them would be used for the 20%, which would result in having snow cover atop of peaks, based on real condition... You could have a nice spring run, while the peaks still have a little bit a snow... But these are kind of 'cherry on top' features
Antelope valley line is finished and ready for upload which I'll do after work. There may be an update for Arosaline as I am going to use Ooen Street Naps to see if there's any points of interests I missed using the other sources.
Question, I've noticed that locations have an icon next to them. Is there a list somewhere what all these icons mean? In the screenshot below for example there's an icon of a wagon next to the name, which I assume is a siding or a yard? I'm editing a video of a drive on Cajon Pass, where I intend to use them as chapter points, but it would be helpful if I knew what some of these mean. So this one would be Ono sidings?
As I haven’t seen it mentioned thought I’d drop a link in here to https://www.openrailwaymap.org which should be of help for railway locations
These are the kind of location that the app currently has - Station, Bridge, River, Viaduct, Tunnel, Yard, Hill, Summit, Junction, Other, Border, LevelCrossing, Road, Underpass... each one has an icon associated with it. What they are actually used for is on the annotations author. But yards I generally use for yards, siding, depots... basically, train stopping point which is not a passenger station :-D Aand, new version time Speed Based Snow Cover Progression - Similarly to fog, the rate of change for snow is now based on speed. While stationary the change is limited by the snowing / thawing rate. At speed, the default allowed max change is 2.5cm per 1km. This can be changed in settings. Extra visual snow when snowing - This is a little experimental.. basically I would like to capture how different 2cm of reported snow might look like when it snowed recently, as opposed as when it is few days old snow that's thawing away. Recent snow should be more uniform coverage of the world. While I cannot affect that, what I have done is that if there is recent snowfall, the app will increase the slider, based on how much it snowed in the last 4 hours.. and how much recent snowfall increases the slider is 50% by default, and can be changed in settings. That means i.e. if there are 4cm of ground snow, with 2cm of recent snowfall, the app will visualize as if there was 5cm of ground snow (4 + 2 * 50%). Set the value to 0 to disable the feature. Train Positions - For weather queries, and annotation triggering, the app now uses the train lead car position, not the camera position. So camera movement should no longer trigger a location to be shown. Locations can still be defined by camera location. Annotation Window mode - It is possible to set the annotation window to 'regular' window mode. This way the annotation window will be a non-transparent normal windows window, which can be positioned and resized. When placed on another screen it should not interfere with apps like Lossless Scaling.
Quick question if I may…been using this mod for a week or so but I am not sure if I should set the in game weather to ‘dynamic’ or ‘custom’ or does it not matter? Anyways, Im loving the mod thus far. Keep up the good work!
I mentioned this before, but I’ve been looking more into how snow accumulation behaves differently depending on the route, and to be honest, I’m still not entirely sure how it all works under the hood. It definitely seems like newer routes (especially the ones from TSW 4/5 and 6) handle snow a lot better. The buildup looks deeper and more realistic, even though I still wish we could get higher snow depth around scenery and buildings. (Dovetail, the mic is on you for this ) Older routes, like those from the TSW 2 era, don’t seem to accumulate as much snow even when both the ground and piled snow sliders are maxed out. So I started wondering if it’d be possible for the program to detect which route you’re on and adjust the snow accumulation values to match. If that isn’t doable, maybe a simple snow mapping drop-down menu could work instead. You could have one set of mapping settings for newer routes that use the updated system and another for older ones that don’t build up as much. That’d make switching between routes a lot smoother. For my own setup, I’ve spent some time watching how high snow builds up along the tracks and around nearby scenery when everything’s maxed out. Newer Routes: It seems like about 3 in (7.6 cm), maybe 4 in (10.2 cm), looks to be about right on the tracks and ballast. Looking at sidewalks and parking lots, the snow usually comes up to fully cover the bottom of the tire and part of the car rim, which visually seems like around 5-6 in (12.7-15.2 cm). Older Routes: When going from zero on the snow slider all the way up to maximum, it only seems to produce about 0.25 in (0.6 cm) of snow on the ground (both on tracks and ballast). Virtually a light dusting. (C’mon DTG, smh.) The piled snow slider doesn’t appear to have any noticeable effect, and the depth on roads and in parking lots near cars is the same as around the trackside areas. I understand the game isn’t going to match real-world conditions where several feet (around 30 cm or more) have fallen, since it simply doesn’t simulate that kind of depth. But below those upper limits, what you’re seeing still feels pretty accurate! Where this would really make a difference is on the lower end of the scale. On those older TSW 2 routes, if there’s only 1-2 in (2.5-5 cm) of snow, it can often look like nothing has accumulated at all, especially if you’re using settings meant for newer routes. Having two selectable snow profiles (one for newer routes and one for older ones) would help make snow levels look more believable without players needing to constantly tweak their settings. You’d still have full control over your custom values, but the program could automatically apply the right value set depending on which route you’re playing and which box you’ve checked. Maybe there’s an even better way to handle this, but I think this would be a great place to start.
It does not matter i find that the app overwrite both custom and dynamic. If your running scenarios set it to manual before you start the scenario
Yeah. still thinking how to solve it (or give the user the ability to solve it), without the need to fiddle with the settings all the time. Most likely there will be different settings, now I'm figuring out if it can be automatically selected by the app... which might work most of the time... This could also allow you to i.e. have less steep settings for mountain routes where it snows often vs lowland routes where 10cm of snow might be the most the area sees... and the user might want more aggressive curve, so the full slider range is user. But this will not work fully for areas like London, where routes from the whole history of TSW share the sme origin.
No rush at all! I'm sure that whatever is implemented will be great. Appreciate your hard work as always! PS: I’ve been putting together a community spreadsheet (inspired by JustWentSouth's "Awesome Tsw Service Mode Runs" thread & suggested by a few, both here and on YT) made for tracking interesting historic weather runs. The sheet has a few dropdowns and fields to help keep everything neat and consistent like: • Region(s), with preset options for all current TSW regions (including the option to select multiple territories for overlaps) • Route, Service Name/ID, and Train/Loco • Historic Weather Date & Start Time (24-hour format) • Difficulty, with an extra “Mystery” option for anyone who wants to keep the weather a surprise • An optional “Submitted By” field for those who’d like to include their name! Before I posted the link, I wanted to check in with you on this. I understand that this is your project, and I don’t want to add anything that could distract from or take focus away from your updates. If you’re okay with it, I’d like to start a new community thread that’s focused just on sharing weather runs, with clear links back to your tool and this thread. But if this is something you'd prefer to not be done, I completely understand. Again, thank you for all the effort you’ve put into this!
As a quick note, I have realized that when travelling as a passenger, the speed at the bottom always remains at 0kph (even though the coordinates are beeing updated constantly) Without actually knowing it myself, I have obviously been waiting for this feature Thank you for this one! I did not use the overlay in its old form, so much, as it was interfering with your view in game. Now I can place it underneath my EBuLa on my second screen and actually get usueful information from it. This made me thinking... on some EBuLa screens in Germany the driver can actually get informations about how fast he should drive, in order to not get too close to slower trains in the sectors ahead of his own train, in order to save energy by not having to use the brakes. (This system is called ZLS [Zuglaufsteuerung], loosly translated = [train control system] and looks something like this irl): The system is more complex then just this, however, just to simplify the approach, when I was reading through the API documentation, it seems now possible to get informations of the AI trains around you. Would it be possible to maybe just specify what train is driving up ahead and dispaly it on the overlay? Very often one can already make a judgement what the max speed of this train would be (by knowing the train number) and adjust the current driving style accordingly. Maybe it would even be possible to display more informations, like speed etc. I know, yet another idea, but maybe something that you and others would find intersting as well
This would be great, and I definitely fully support this. Anything that will increase the enjoyment of TSW is more than welcomed It would also help me when finetuning functionality how have references to interesting weather patterns. And, down the line, it might be cool to integrate this within the app, as 'weather scenarios', as an addition to 'historic' and 'live' weather. You would define Location + Datetime as the source for the weather. You could name it, import and export it... And it would allow the use of the scenario on any route, and on any service... The weather would progress based on how long you're in the world... So you could relive i.e. the Boston snowstorm on Southeastern High Speed... and you wouldn't be limited with what areas are actually covered by TSW... any interesting weather, anywhere on the world? Relive it in your TSW service Speed is not filled in the TSW data while you're not driving a train, as a driver. The problem is that I don't know anything about the rail network.. so the train positions might be there, but I don't know if we're on the same track. It is also why I feel doing a proper Ebula is not yet possible, and would require lots of manually entered data.
Yes, already thought that it is not as simple. Off topic, but as you were mentioning it, it may be of interest; In regards to the EBuLa, I am using a paid tool (online-EBuLa), which is now also linked to TSW, thanks to the API. The developer found a way to extract time table data by using the Editor and is therfore able to supply new time tables for a new route within a couple of days, It even has all consist data, down to brake percentage calculations. I am a big fan (but before anyone asks, I am a normal paying custome myself).
Doesn't matter. The app overrides the in-game weather (unless you want it: set the app to Manual (before launching the route)
Tried searching your handle and the route name no luck. Also tried weather and saw 2 other annotation files.
Gosh there's a new update to this tool every time I start up TSW, excellent work! That's interesting, I wonder how detailed the data is? If we have train coordinates, length, direction and speed, it might be possible to trigger a toot of the horn as an AI train approaches the rear end of another train. In the UK this is done to warn any trespassers or track workers that another train is coming in the opposite direction. It's the same in France but I don't know about DE, NL, CH or US regulations. Maybe a lot of work for little benefit, however. JB
The thread and link to the spreadsheet are up, along with the weather acceleration speed category added! Looking forward to playing some of the runs you guys submit! PC - Tsw Historic Weather Explorer & Community Log (winzarten App) | Dovetail Games Forums
Just found a new annotation for the Antelope line on Train Sim Community, Information on the writer is on the screen grab. Antelop Valley Line Annotations - Train Sim Community
Antelope Valley Line is now on the train sim community for download https://www.trainsimcommunity.com/m...ilities/i7028-antelop-valley-line-annotations
There looks to be an issue when the stored window location is left of the current minimal desktop area. In those cases the app can open outside of visible area. I will try to get it fixed. If it is this, then you could alt+tab to the app and then use the win + shif + left / right arrow key to move the window to another monitor. Hopefuly it will become visible.
Technical question in regards to visibility. On a recent run I have noticed that the visibility on the live weather was shown only with dash, however, on the TSW weather there was a value of 0,0009, which did not change for the rest of the run: I did check with open meteo and the visibility value was given with 36.000m for that current location. Is this working as intended? I have never seen this kind of behaviour before...
It was on KWG, expert timetable IC2177. Was your question related to my question, though?! I don’t see the connection…
It is good to provide as much information, as possible, as that helps to narrow the code which might causing the error, especially in cases like this, where the functionality is generally working, only in this particular case it got obviously broken. In this case I can see that the service is an afternoon service, but the app is querying 10pm data, so it's most likely in live weather mode. What is then weird, is that it is clamped to exactly 10pm, to the exact second.. Which suggests that something is wrong with the interpolation in live weather data, or something in the area... because, why is it is not using interpolated data? Well, because in live weather there looks to be an oversight, as I'm just querying the current day., 1 past day.. but no future days. So if you're running at the end of a day, the app has nothing to interpolate the data with, and it gets clamped, and some values are not filled. Will be fixed.
Yes, indeed, usually run with live weather, regardless of the time of the service. Thanks for the explanation of the issue, however, would that not mean that all weather parameters would be similar frozen, like the visibility? Just asking, as all of the other parameters were updating as usual… Also, as mentioned, I did go into open meteo (using the in app link) and there it gave me parameters also for visibility (as said above, around 36km). I have only noticed it because the 0,0009 value actually had a visible effect on my head lights and as I now have the overlay permanently on my other monitor it did not give me a visibility read out, which made me suspicious. As said, I have not seen this before, at least I don’t think so (I may not have realised in the past).
Visibility is not filled when using non-interpolated data (it's just a quick and dirty fallback, so the application doesn't crash). Other values are changing, because those are filled, and those are changing. While the time is frozen, your location is not.. so they are changing based on the location you're currently in. The data was present in open meteo, but generally, as data points are spaced one hour, I interpolate the data to get the weather for the exact time. At the end of day, the start of hour data point might be the last in the retreived data, thus I lack the next point, and no interpolation is done, and a fallback is created... It will most likely only happen if you play between 23:00 and midnight. The 0.0009 comes from the last update that had visibility. When visibility is not filled, it will not be converted to fog value, and TSW will not be updated.
It should be fixed now. As should be this: and the app now tracks which locations come from imported files, and hides them by default. Also during export it asks which points it should export - only those that the user created, or also the previously imported files. All previous exported files are still valid and can be imported without issues.. also people who already imported some files don't need to do anything.. unless it would be beneficial for the to have those points properly marked (i.e. you're working on annotations for a route that has the same origin as a route you have imported data for), in those case, just reimported the file, select 'merge' option, and the points should be correctly marked.
and the app now tracks which locations come from imported files, and hides them by default. Also during export it asks which points it should export - only those that the user created, or also the previously imported files. View attachment 205736 Nice! I love this little update
Hi, I updated the app to version 3.6.4 and now the window opens out of the desktop area. I never had this issue before.
I'm disabling the position storing for now, obviously it needs more time in the owen, and it currently causes more issues than it's solving.
Winzarten Apologies if this has already been discussed (I searched and couldn't find anyone mentioning it) Whenever I load historic weather into a route now, the error below appears. Any ideas? Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
I just realized that when you click “View Online” under Live Weather, there’s an hourly snowfall accumulation chart as well, not just the liquid precipitation. I think it would be a neat update if, whenever the weather code is showing snow, the app could switch from displaying liquid precipitation to snowfall in the overlay instead. That would give a much clearer sense of how much snow is actually falling, since the rate can vary depending on temperature, humidity, and other factors. purple: hourly liquid accumulation orange: hourly snowfall accumulation I’ve also noticed something interesting since one of the more recent updates that made the weather update based on train position instead of camera position... When a service ends and I fast-travel to another location, the weather no longer updates. Even if I spawn a train or start a new service, it stays stuck until I force close and reopen the program. Also, just a thought. I remember you mentioning that having a smooth transition from rain to snow or snow to rain isn’t really possible, but I was wondering if a small workaround could help. If the weather code changes from one precipitation type to the other, would it be possible to have a short transition period, maybe fifteen or thirty seconds, where the weather shifts to cloudy before switching over? So if it’s snowing heavily and the next update is heavy rain, maybe the precipitation slider could slowly drop to zero first, then the temperature in the world rises enough for rain, and after that the precipitation slider climbs back up to where it needs to be. That might take away some of that sudden cutoff that makes the switch feel jarring. I think it could be an interesting way to soften that transition, though I’m not sure how others would feel about it. I’ve been doing a lot of runs with weather changes lately and they’re really fun, but the jumps during the day are definitely noticeable. At night it feels much smoother, especially when it’s foggy.
Next time it happens, please save a log file Also note the route and service. These issues usually have very specific conditions, and can be harder to track down without these info. The fast travel update looks to be tied to the change of using train location, instead of camera, when possible. When you spawn on foot, it works. It is possible it gets broken the moment you step into a train, because TSW never clears the train location from its data, even if you step out of train.. I need to check. Also, keep in mind that the instant update happens only if the jump is over 10km in distance The transition, I need a new concept for that. some kind of animation, that would be used instead of values from the converted data.
It was on Morristown and the error appeared for a ALP-45DP service either 6619 or 877 & NJT cab car service 660. Unfortunately, I didn't save log files but I will endeavour to do so next time I see it.
I managed to find it. LIRR Commuter route. Train 1721. https://drive.google.com/file/d/1Pqd796Mj3uZ0kmM5IEzE3CDeYV2eENR1/view?usp=sharing
No worries, and thanks a lot for the log... I think I know what's going on, I will try to get it fixed
Oh, interesting. I route hopped from one route end to the other (Boston south station to Worcester) which is for sure more than 10KM
Weird, I have been testing it today, both straight from spawning 'on foot', to teleporting after the session, and it looks to be detecting the jumps correctly... Weird..
