Train-Sim.Com
MSTS Activity Design

Relativity passenger run

Notice to all visitors and members of the Train-Sim.Com message forums:
If you plan on using a signature banner in your posts, we would like to remind you that there is a maximum size for banners. That maximum is 450 pixels wide by 120 pixels high, and not to exceed 25k. Your compliance is appreciated. FORUM RULES Problems? There are two common reasons for problems with logging in and posting messages. The first is that you are running a firewall that prevents your messages from being sent to the server. The other is that you have cookies disabled; the DCForum software requires cookies to work properly.

Previous Topic | Next Topic

Printer-friendly copy Email this topic to a friend

Reading Topic #1727

Member since May-20-03 · 21 posts

Hi everybody.
Have any of you seen a difference between clock and time running TS activities?
Last weekend I've been running an activity made in modified Marias to be able to run passenger activities, an put an eye over the indicated time of arrival and departure in stations, and see that the clock in the <F10> window show me different time than the indication of arrival at station.
The de-phase (is this the way to say that?) was about 30 secs., but increasing every station as the activity runs.
What could it be due to?

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RE: Relativity passenger run..., Bing, Jun-17-03, 11:46 AM, (1) RE: Relativity passenger run..., ferrovirtual, Jun-18-03, 08:04 AM, (2) RE: Relativity passenger run..., Bing, Jun-18-03, 11:40 AM, (3) RE: Relativity passenger run..., ferrovirtual, Jun-18-03, 02:46 PM, (4) RE: Relativity passenger run..., anakha, Jun-19-03, 08:55 AM, (5) RE: Relativity passenger run..., Bing, Jun-19-03, 11:00 AM, (6) RE: Relativity passenger run..., ferrovirtual, Jun-23-03, 10:10 AM, (7) RE: Relativity passenger run..., Patfitz, Jun-25-03, 07:36 AM, (8) RE: Relativity passenger run..., ferrovirtual, Jun-25-03, 09:13 AM, (9) RE: Relativity passenger run..., Patfitz, Jun-26-03, 12:10 PM, (10) RE: Relativity passenger run..., ferrovirtual, Jun-26-03, 12:42 PM, (11) RE: Relativity passenger run..., Patfitz, Jun-26-03, 04:52 PM, (12)

Conferences | Topics | Previous Topic | Next Topic

Charter Member · 972 posts

RE: Relativity passenger run...

MSTS keeps lousy time. They should use my grandfather's railroad watch, which was guaranteed to be accurate witin one or two seconds per month. Incorrect clock running time is one thing; might indicate you are short on resources, I notcied one second = one second when I upgraded my sytem, which had not been true with the older computer.The other, and I don't have any idea how to fix this, is when you arrive at a station platform and hit Enter first time, the correct clock time is shown in F-10. When it's time to depart, MSTS adds several seconds to when you actually moved forward. You can't start ahead of the station master's release, or the countdown shown at the bottom of F-10 - if you do you are guilty of leaving passengers on the platform (they couldn't get on the train in four minutes?)So you have to wait. I have NEVER been able to depart at the exact time I moved the loco forward, TS always adds a number of seconds, meaning I was "late" leaving the station. Anywhere from 3 or 4 up to 10 or 15 seconds is glopped on the clock time when I triggered the depart state. Whoever thought up this one had done more than his normal quota of funny cigarettes. Should this have been nailed during beta testing? YoU bet it should have. What else is new with Kuju?Bing

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since May-20-03 · 21 posts

RE: Relativity passenger run...

Really hope that new release of this drug will be more accurate about passengers and more permisive on little movements of consists stopped at stations, as other adjustments in editors.
The reality shows me that sometimes (in Argentina, at least) trains can do very small movements once stopped at stations while passengers get up and down, but they don't care about this and still remain getting up and down.
Is this so difficult to get in TS?
Thank you for replying.
Greetings from Buenos Aires (Argentina)

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Charter Member · 972 posts

RE: Relativity passenger run...

Computer events are not like real life. The computer can't think, it can't do anything you don't tell it to do, the trouble is we often don't know what we DID tell it to do. Arrival and departure in a computer world have to be simplified. 0 = NO, 1 = YES, or the reverse sometimes, depending upon the "logic" involved. Accidental movement of the train in MSTS when it is at the platform triggers 1 = YES, the train has moved, You have no choice in the matter. I understand that, or at least I am used to it. What I don't understand is the arbitrary additioln of three to fifteen seconds on my departure time, it makes no sense at all. There might be something in the AE that controls this, I haven't got to that yet.Bing

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since May-20-03 · 21 posts

RE: Relativity passenger run...

Dear Bing: I don't think that Kuju-M$ programmers are using COBOL or GWBasic to get the simple logig of 0 or 1 departure conditions, so a threshold in speed as they already did with position, don't seems to be very difficult to use. I've tried to express one little idea about a little and simple correction that Kuju-M$ could bring us in next Release 2.
But, let me put my feet on the ground (or on the plattform/on the yard, as you like): I don't think that this is an error that makes the sim less funny (for me, at least) and must tell you that I DO ENJOY with editors and the sim itself.
I only hope that Release 2 would bring us a little more easy and logical fun.
BTW, another item that I do belive is more conflicting and anti-logic is the AI dispatcher use of signals and priorities of trains, parameter that can't be directly set by the activity designer.
Thank you for your reply and I send all my greetings from Argentina to you all.

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since Apr-12-03 · 13 posts

RE: Relativity passenger run...

Hi,I had this exact problem recently on a number of different routes. The counting clock in F10 would show the time as 9.00am for example at the exact moment I pulled into a station and hit the unload button and then station arrival time would be entered as 9.01am.What I thought might be happening is that MSTS stuttering when driving the route might be causing the game to miscount the time that it displays in F10. For me it definately seemed to be worse the more stuttering I experienced when running the activity.Something that has helped me recently was to do a defrag on my HD. Since I did that, my mismatched time problem has been a lot less evident

Robbie.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Charter Member · 972 posts

RE: Relativity passenger run...

1) I have no stuttering, I fixed that, see the thread in MSTS2 section.2) I defrag daily, often two or three times a day. Runnng MSTS I don't see where I have a choice.These two items aren't casuing the problem on my system. Not the ARRIVE time which is faulty, it is the DEPART time. I don't like adding one or two seconds to arrive / depart times, but I can live with it.What really bunches up my shorts is when I am poised to go into action like a blaze of light to get the depart EXACTLY right. I hit the buttons exactly right. Right on the schnozz, precisely at the depart time shown. MSTS adds up to fifteen seconds. Happens a lot if I am running a local passenbger service with lots of platform stops. Nor is there a pattern I have recognized, TS just adds as many seconds as it pleases, whenever it wants to do so.
Bummer.Bing

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since May-20-03 · 21 posts

RE: Relativity passenger run...

The best way to say what i've tried is to attach a screenshot, but i'll try to explain the situation instead.
Arriving at first station, the clock in F10 window shows 10:00:00, but as train completely stops, arrival time shows 9:59:15, so my train has been faster than light and that's why i've named this message as i did.
About departure time, i think that it could be due to any threshold of speed or position, from what TS begins to consider the departure.
Greetings.

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Charter Member · 12 posts

RE: Relativity passenger run...

It sounds like the arrival/departure logging function is pulling the time from a source other than where the f10 real-time clock is drawing from, and creating the discrepancy you mentioned. Also, the departure time takes into consideration the pax load/unload time. This is calculated from a) the number of pax you have listed at the station (right-click platform and select "properties") and b) how close your train is positioned in relation to the platform when you press ENTER to begin the load/unload process. For example, I can spot my main coach right at the platform and load 40 pax in 1:19, but if I overshoot by 50 feet or so, that time is increased to 2:00 or more.Another thing that can cause problems is partial stops -- where you stop the train as planned but there's still momenteum, which makes your speedometer jump quickly from 0.0 mph to 0.1 mph and back to 0.0 mph again (in a fraction of a second). This resets the f10 unload screen and your arrival time (and is quite a pain).For example, if you stop the train at 9:59:59 and it does the jump thing and "re-stops" at 10:00:01, then your arrival time on the f10 screen is 10:00:01, even though you intended to stop at 9:59:59 and didn't even see the jump. In the log, this will show your arrival/departure time as 9:59:59, and the 10:00:01 time won't be listed, as MSTS thinks this is just a mid-trip stop somewhere. If you pressed ENTER to load/unload before the jump happened, then it will cancel the load/unload function (for that stop) and show in the log that you departed before the loading was complete.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since May-20-03 · 21 posts

RE: Relativity passenger run...

Hi, Patfitz.
It's exactly as you say.
Only one more thing to add: seemed to me or it's real that time from arrival to departure at same stations is not the same in different runnings of the same activity?
I.E: planned arrival time at Baltimore running "Short passenger run" yesterday was 10:00:00, and planned departure time is 10:00:25.
Today, i'm running the same activity, again from the beginning, and new values are: 10:00:00 to 10:00:35
I think that this is accurate, because not every times there are the same number of passengers each day at the same time in a station.
BTW: does anyone know why the "plattform" object allows you to set "Right side", "Left side" or both?
I've seen plattforms wrongly set, but working as well as well set, so what's the difference for?
Thank you all for your smart comments

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Charter Member · 12 posts

RE: Relativity passenger run...

In the scenario when the departure time changed to :35 from :25, was the change in real-time (i.e., it took 10 seconds longer for the "unload passenger" function to work), or was the change reflected in the timetable without your having changed it?In the case of the former, where it took longer, that would most likely be the result of your train being positioned differently in relation to the platform than on the prior run. There is a hidden "trigger" (for lack of a better term) at each platform, which tells the program that you're "right on it," thereby keeping the load/unload time (when you press ENTER) to the very minimum. The farther you are away from that point, the longer the function will take. That's the first thing that comes to mind. As for the number of passengers, that affects it too; but there should be the same number each day (in MSTS) unless you go into Activity Editor, right-click the platform, select "properties," and manually change the number of passengers.As for the latter (departure time automatically changed and reflected in the timetable), I don't know of any "feature" that does this. If such a feature were in place, it would forecast each stop's load/unload time based on the load/unload time from the day before. Like I said, I haven't actually seen such a feature...but it could be hidden (as most MSTS things are)."Right Side" and "Left Side" have to do with the side of the platform that you'll be loading/unloading from. If you check both, then I believe you will have the option in Activity Editor of setting a different number of passengers on each side. I'm not positive, though. Route Editor and objects is even more disgusting than Activity Editor (if you can imagine that), so I try and stay as far away as possible from route creation and object manipulation.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Member since May-20-03 · 21 posts

RE: Relativity passenger run...

Is the second alternative: the difference of 10 sec. is shown in the F10 window with no change done for me, only running activity twice.
If there is a hidden feature that could let you set these times, it would be the great solution for so many problems shown in this Forum, about arrival/departure times.
BTW, must confess you that I've been modifying original and added on routes with DRE (damn Route Editor)... next step: CANONIZATION, then HEAVEN is surely done for me.

Jorge Damonte
All new is virtual
Steam is the only reality

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Charter Member · 12 posts

RE: Relativity passenger run...

Does it show in the "scheduled" or "actual" column in the F10 window? If shown in "actual," then it would mean you left the station at a different time than the day before; OR, perhaps you encountered a permature start (computer/brake generated) or unplanned drop in speed to zero as soon as you throttled up. There's also the possibility that your train was positioned differently and caused the load/unload time to change slightly -- which ultimately affects your departure time.If it shows in the "scheduled" column, then I don't know what would cause the change, as I think the schedule remains static once entered. One possibility might be the timetable's recalculation. Maybe you recalculated when you shouldn't have, or didn't recalc when you should have?? As for when you "should" recalc, I have no idea -- I'm just exploring possible answers to the timetable discrepancy.But I guess the net of it is that in real life, 10 seconds isn't a biggie. I know on the "City of New Orleans," we are sometimes several minutes late departing, and just have to make up the time, keeping the next station's arrival time in mind. One night we were late rolling into one stop by 30 minutes, but still managed to get to the NEXT stop -- 100 miles away -- 20 minutes early! It 'can' be done. But in another case, we were running on time 250 feet from the platform, but we nevertheless arrived at the platform 6 hours late. I'll tell you more about that when I have more time. Now back to the real world (MSTS)....There IS a little-known way to "hard code" your arrival and departure times into the timetable. Double-click the arrival time and enter it. Do this again -- immediately -- but enter the DEPARTURE time instead. Finally, do it once more, but enter the ARRIVAL time again. Viola.... the arrival and departure times you manually entered are now hard-coded into your timetable.

Alert | IP


[ Home | MSTS Forum | MSTS FAQ | File Library ] Copyright © 2002 by Nels Anderson. All Rights Reserved.

Restored from the Train-Sim.Com archive, captured June 29, 2003. About this archive.