Making an Arrival Clock

[Sari6t]

I have a cool shuttle that runs around on its own between two parts of the sim. People love it but asked me for an Arrival/Departure sign.

I found a simple count down clock that auto restarts once it reaches the end. So easy right, time the route , input the time and done. 

So, that's not working , lol . Although the route is automatic and unchanging, the timing varies still a great deal. So I have started thinking about a better way to do this but I was wondering before I get too fancy, is Sim time accurate. Meaning , can it fluctuate or is it likely the shuttle lags a bit here and there changing it's lap times making it a real life transport simulator lol.?  

 

[Rolig Loon]

Why not just place sensors along the route that trigger when your shuttle passes by?  All you'd need to do then is send a short update message to your display board that says,"Next shuttle arriving in about XX minutes."

[Sari6t]

Thanks Rolig, that is what I was going to do in the first place but was hoping to not have to write more scripts that might impact Sim script spare time, its a combat sim so need all the head room I can manage.

[Love Zhaoying]

1 hour ago, Rolig Loon said:

Why not just place sensors along the route that trigger when your shuttle passes by?  All you'd need to do then is send a short update message to your display board that says,"Next shuttle arriving in about XX minutes."

I was thinking: Have the shuttle send the sign a message (on a channel using llRegionSay(), or llRegionSayTo() if the train knows the clock's ID) when it starts the journey.  If the trip time is "always about the same", then it should be pretty accurate. This way, you would not need additional sensors and scripts along the way.

[Rolig Loon]

21 minutes ago, Sari6t said:

Thanks Rolig, that is what I was going to do in the first place but was hoping to not have to write more scripts that might impact Sim script spare time, its a combat sim so need all the head room I can manage.

I doubt that you'll see much of hit at all from three or four simple sensor-relay scripts.  If you're worried, though, you can always put a single script in the shuttle (or incorporate a wee bit if new code in the shuttle's script, to report its position every 30 seconds or so.  Send that info back to the display board and update its arrival estimate.

[Qie Niangao]

FWIW -- and I'm not claiming this is optimal or anything -- I've used a single script in a display board that tracks a shuttle's progress by OBJECT_POS from llGetObjectDetails on a slow timer. When the known shuttle UUID disappears from the sim, the script falls into a special sensor mode that hunts for a similarly named replacement on the course.

Practically, though, I'd think the most important thing to minimize any lag effect from this whole system is to use a shuttle based on Key-Framed Motion, with as little mid-course script activity as possible.

I've run shuttles that are pure KFM and delete their own script once loaded, and relied on the external tracking script to detect course deviations that sometimes happen to KFM at sim restart, etc. Usually, though, we expect more than simple motion -- effects such as sound, wheels turning, particles, etc. -- so usually my KFM shuttles nonetheless end up with at least one script along for the ride.

[Sari6t]

Hmmm,

Well thanks for all the ideas. I will try a few and what one works best. 

As for my original question, can I assume then that the sim stays locked as far as timing goes and its the shuttle and other factors causing the timing fluctuations?

 

[Xiija]

Something to mebbe play with?

http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation

Quote

Time dilation is a method the server uses to cope with simulator lag. Physics and script generated lag can result in time dilation. Time dilation slows script time & execution. When time dilation is zero script execution halts.

 

Edited June 22, 2017 by Xiija

[Sari6t]

Yes of course, time dilation....totally forgot about that.,....cheers

[Rolig Loon]

45 minutes ago, Sari6t said:

Hmmm,

Well thanks for all the ideas. I will try a few and what one works best. 

As for my original question, can I assume then that the sim stays locked as far as timing goes and its the shuttle and other factors causing the timing fluctuations?

 

I'm not sure that I understand what you are asking. What do you expect to be "locked," and what difference do you expect it to make?

[Sari6t]

I need to understand why there was such a discrepancy in timings for the route . +- 18 seconds on a 13 minute round trip, over the course of a day the clock is so out its useless. 

I found a person who made a train station sensor with updating board in the MP, for a couple dollars it may be better than making it all. 

 

[Rolig Loon]

It's impossible to say without seeing what the script is doing, but I suspect that the answer is fairly simple. There are many different ways to track time in SL.  If you use llGetTimeStamp, your output is real time relative to UTC, accurate to a millisecond.  llGetUnixTime, similarly, yields real time relative to the Unix origin date.  Neither is affected by server behavior, so they are excellent choices for stopwatches or the sort of thing you are doing.  Similarly, llGetTime is also unaffected by time dilation.  It marks the time since the most recent script restart.  If your script marks the passage of time by counting ticks in its own timer event, though, you'll get wild results because the script may pause for a few milliseconds hare and there as the servers need to divert attention to higher priority tasks.  If I were you, I'd monitor llGetUnixTime to see the real elapsed time for your task.

[Berksey]

So where exactly is this combat sim and do you allow flying bunny children with hyperauto weapons and multicast sorcery? I have airplane legs if they're absolutely mandatory.

[Sari6t]

I used a stop watch on my phone a few times lol

[Nova Convair]

The shuttle can find out the travel time for each section on its own. Get the time on launch and after landing and store the travel time for this section. The time for the halt is a constant I assume so just calculate and send out the estimated times for every halt via llRegionSay on every launch. After one round trip the system is calibrated and shows correct times and it's maintenance free and self correcting.

No need for fancy things like llRegionSayTo since one message every few minutes is not worth any optimizations. Send out the data package in a single message like: <halt#>|<arrival time>|<halt#>|<arrival time>|<halt#>|<arrival time>|... and every halt just grabs the time it needs. That times can just shown or  the remaining minutes/seconds can even be counted down by timer once a second or minute. Time dilation will cause a little discrepancy but the next message from the shuttle will sync everything again.

[Sari6t]

7 hours ago, Nova Convair said:

The shuttle can find out the travel time for each section on its own. Get the time on launch and after landing and store the travel time for this section. The time for the halt is a constant I assume so just calculate and send out the estimated times for every halt via llRegionSay on every launch. After one round trip the system is calibrated and shows correct times and it's maintenance free and self correcting.

No need for fancy things like llRegionSayTo since one message every few minutes is not worth any optimizations. Send out the data package in a single message like: <halt#>|<arrival time>|<halt#>|<arrival time>|<halt#>|<arrival time>|... and every halt just grabs the time it needs. That times can just shown or  the remaining minutes/seconds can even be counted down by timer once a second or minute. Time dilation will cause a little discrepancy but the next message from the shuttle will sync everything again.

Love this idea but its way past me on being able to even start. The logic is clear enough but syntax....nuuuu lol. I can imagine using something like a dataserver and some way of knowing when it stopped and started and then llGetPosition ,,,,,a timer() and a Listener for the arrival board with lRegionSay sending the updates and a few pounds of coffee and Advil at my side  lol. 

Thanks for the idea though. In time I will give it a try . 

 

Thanks though.

 

[Love Zhaoying]

On 6/22/2017 at 4:15 PM, Sari6t said:

I need to understand why there was such a discrepancy in timings for the route . +- 18 seconds on a 13 minute round trip, over the course of a day the clock is so out its useless. 

I found a person who made a train station sensor with updating board in the MP, for a couple dollars it may be better than making it all. 

 

Fluctuations in the space-time continuum.