James Ross, on 19 March 2017 - 08:00 AM, said:
I disapprove of the use of STF/SIMIS format for brand new data files, particularly as JSON has seemingly been agreed since late 2011 (!).
The problem with JSON is that no 'support' is provided yet within the program structure (e.g. method library for error handling etc.), all of which is readily available for STF.
Also I do not have any knowledge of or experience with JSON myself - I've never used it in either my professional or personal work.
Admittedly, when I created this function I had no intention of ever committing it - it was just intended as a 'personal' addition, just a bit of eye candy for fun. So it did it 'quick and dirty' using STF. But as I was now working on a more public update for signals and timetables I thought I might as well include it as others may perhaps also like it. But I do not have the time at the moment to sort out what it should look like in JSON, so if that is required, I will have to drop it.
I would like to suggest a compromise : I will include the processing of the information (i.e. the processing of the class as such), but not the reading of the file. Later on I may find the time to work out what it should look like in JSON, or perhaps someone else with that knowledge can pick up that part.
Quote
Otherwise, the structure and data in the file feels okay, but I think it might benefit from having fog be a different element type (e.g. FogSetting) to clearly distinguish it from WeatherSetting with clear/rain/snow, since the two groups run independently, if I understood correctly.
It was not intended to define fog and precipitation at the same time, but I must admit I do not know what will happen if you define rain or snow before defining that the fog should lift. I will have to look into that.
Quote
One small note: if the code doesn't already do this, I'd recommend sorting the blocks by time, so the order in the file doesn't matter.
Good suggestion, haven't done it yet (as I said, it was all very basic).
Quote
I'd recommend we add a new ORTSWeatherFile option to activity files. I was expecting something similar to be added to timetable files, but I don't see any mention of it. Is this currently just a user-selectable option in the menu?
The idea was that it would be possible to run the same timetable in different weather conditions, so it is indeed just an entry in the menu and no part of any timetable as such. If no file is selected, the present basic weather is used.
By the way, having an additional option in the activity still leaves the problem of two separate mechanisms to influence the weather (the activity events and the weather file), something will have to be decided on how that should be handled.
Quote
Kosmos was just a specific means of setting up the MSTS environment file, but those do cover more things than this weather file (they cover water as well as sky) but they do it in a very precise way (exact list of textures for water and sky, movement, etc.). When we finally add non-MSTS water, we should make sure it responds to the weather settings and that's probably it.
OK - clear.
Quote
Hmm, the particles themselves should and appear in the code to be given wind direction, but the setting up of the "Wind" field looks to be sub-optimal and simply based on the precipitation level.
Wind was the one item which was both difficult to define and to set up - it is much more variable than the other elements. For instance, in showery weather, those showers often bring strong gusts of winds (the famous 'squally showers'), which may actually come from different directions as the prevailing wind as such.
I did a number of experiments but whatever the wind definition was, it seemed to make little difference to the way the precipitation particles were behaving. So, it was difficult to define and difficult to set up and did not have any noticeable effect - and so I just dropped it.
Regards,
Rob Roeterdink