Page 1 of 1
Maintaining Compatibility A scheme to help users
#1
Posted 04 January 2022 - 12:43 PM
On the thread about train cars climbing up the rails and derailing, new parameters are introduced to model this behavior. For old content which is unchanged, these parameters are missing and a best guess is made instead, which is not ideal.
But for developers who add new features, there is no way to know what content our users already have installed and our means of communicating with them are very limited (although see the proposal for Notifications). So how do we tell users of these splendid new features, encourage them to pester their content maker for upgrades or update their content themselves?
Our Open Rail log files contain messages in a standard format for Information, Warning, Error with the filepath and the line number. For example:
Information: Some NumPositions entries refer to non-existing frames, trying to renumber in C:\data\Demo Model 1\trains\trainset\MT_DD_CLASS_27_27207\Class26_rv.cvf:line 197
How about another message especially for compatibility issues? In this case, that would catch each wagon that lacked the derailment parameters, like this:
Information: Compatibility issue (see https://tinyurl/ORSTderailment for advice) at C:\data\Demo Model 1\trains\trainset\MT_DD_CLASS_27_27207\Class26.eng:line 18
Note the Web address which links to a page explaining in as much detail as necessary how to use the new feature.
The key element is bringing these messages to the user's attention, which Open Rails could do by parsing the log file as soon as the run ends and showing a message like this:
But for developers who add new features, there is no way to know what content our users already have installed and our means of communicating with them are very limited (although see the proposal for Notifications). So how do we tell users of these splendid new features, encourage them to pester their content maker for upgrades or update their content themselves?
Our Open Rail log files contain messages in a standard format for Information, Warning, Error with the filepath and the line number. For example:
Information: Some NumPositions entries refer to non-existing frames, trying to renumber in C:\data\Demo Model 1\trains\trainset\MT_DD_CLASS_27_27207\Class26_rv.cvf:line 197
How about another message especially for compatibility issues? In this case, that would catch each wagon that lacked the derailment parameters, like this:
Information: Compatibility issue (see https://tinyurl/ORSTderailment for advice) at C:\data\Demo Model 1\trains\trainset\MT_DD_CLASS_27_27207\Class26.eng:line 18
Note the Web address which links to a page explaining in as much detail as necessary how to use the new feature.
The key element is bringing these messages to the user's attention, which Open Rails could do by parsing the log file as soon as the run ends and showing a message like this:
#3
Posted 04 January 2022 - 02:03 PM
#4
Posted 04 January 2022 - 02:15 PM
I read and participated in most of those threads about the new derailment parameters...this is a welcome addition, Chris. I also saw a desire in most folks that these new parameters ( if applicable ) would apply to users of the advanced physics option.
Question -- would a user running simple physics see the warnings in the HUD and also in the log?
Question -- would a user running simple physics see the warnings in the HUD and also in the log?
#5
Posted 04 January 2022 - 03:44 PM
It may sound nice, but it could get a bit scary if, like me, you are running large timetables, such as mine which is now up to 7425 trains. Many trains will, of course, be using the same consists, but there still is a large variation and so a pretty large amount of different rolling stock is used. And, for starters, none of these will have these parameters set as all are at least a few years old. And I have not even started with freight trains yet, which will add even more different rolling stock.
So, the log file will be pretty much swamped with all these new messages. And when running steam engines, it's even worse for these also generate a fair avalanche of messages regarding defaulted parameters (unless this has now been removed).
In all, I fear that there will be so many messages that one really cannot see the wood anymore because of all the trees, and really important information may be completely lost in this flood of information. So the main question is - will there be parameters available to switch this off?
Regards,
Rob Roeterdink
So, the log file will be pretty much swamped with all these new messages. And when running steam engines, it's even worse for these also generate a fair avalanche of messages regarding defaulted parameters (unless this has now been removed).
In all, I fear that there will be so many messages that one really cannot see the wood anymore because of all the trees, and really important information may be completely lost in this flood of information. So the main question is - will there be parameters available to switch this off?
Regards,
Rob Roeterdink
#6
Posted 04 January 2022 - 06:45 PM
roeter, on 04 January 2022 - 03:44 PM, said:
It may sound nice, but it could get a bit scary if, like me, you are running large timetables, such as mine which is now up to 7425 trains. Many trains will, of course, be using the same consists, but there still is a large variation and so a pretty large amount of different rolling stock is used. And, for starters, none of these will have these parameters set as all are at least a few years old. And I have not even started with freight trains yet, which will add even more different rolling stock.
So, the log file will be pretty much swamped with all these new messages. And when running steam engines, it's even worse for these also generate a fair avalanche of messages regarding defaulted parameters (unless this has now been removed).
In all, I fear that there will be so many messages that one really cannot see the wood anymore because of all the trees, and really important information may be completely lost in this flood of information. So the main question is - will there be parameters available to switch this off?
Regards,
Rob Roeterdink
So, the log file will be pretty much swamped with all these new messages. And when running steam engines, it's even worse for these also generate a fair avalanche of messages regarding defaulted parameters (unless this has now been removed).
In all, I fear that there will be so many messages that one really cannot see the wood anymore because of all the trees, and really important information may be completely lost in this flood of information. So the main question is - will there be parameters available to switch this off?
Regards,
Rob Roeterdink
An on-off switch is a good idea. I usually dig pretty deep into my freight .wags but I don't do that work routinely, more like a couple of times per year. I probably would not value these reports in those gaps while being delighted with them at such time I'm already working the problem.
#7
Posted 05 January 2022 - 02:02 AM
Just a thought - perhaps the information can be split over multiple logfiles. The 'proper' logfile would then be restricted to messages directly related to the activity or timetable which one is running, let's say 'operational' messages. One or more other logfiles can then be used to provide 'background' information like defaulted or missing parameters.
Regards,
Rob Roeterdink
Regards,
Rob Roeterdink
#8
Posted 05 January 2022 - 10:29 AM
roeter, on 05 January 2022 - 02:02 AM, said:
Just a thought - perhaps the information can be split over multiple logfiles. The 'proper' logfile would then be restricted to messages directly related to the activity or timetable which one is running, let's say 'operational' messages. One or more other logfiles can then be used to provide 'background' information like defaulted or missing parameters.
Regards,
Rob Roeterdink
Regards,
Rob Roeterdink
That's probably a good solution to avoid the "swamping" issue.
#9
Posted 05 January 2022 - 01:52 PM
Wait a minute: the logfile analyse capability seems to be great feature for menu.exe.
But, what about manual reading of the log...
Yes: there are plenty of reports about missing ORTS dieselengine's block, wrong friction parameters, shape errors (luckily optioned to be on-off)
So, maybe issues, causing crashes along with system and performance statistics may be splitted from non-critical errors, tied with obsolete configuration files of content?
But, what about manual reading of the log...
Yes: there are plenty of reports about missing ORTS dieselengine's block, wrong friction parameters, shape errors (luckily optioned to be on-off)
So, maybe issues, causing crashes along with system and performance statistics may be splitted from non-critical errors, tied with obsolete configuration files of content?
Page 1 of 1