Message Simulator dates: option to use running clock but base it on first message

[garysheppardjr]

Add an option for the time override that would work like this: instead of just using the current time, as the new time override feature does, start with the time in the first geomessage, and then use the system time to increment that time.

For example, let's say you start the simulation at 2015-02-20 23:07:35, and the first geomessage in the file has a time of 2012-07-04 18:32:00. Let's also say the throughput is set to one message per broadcast and the frequency is set to one broadcast per second. The first geomessage will go out with a time of 2012-07-04 18:32:00, because that is the time in the first geomessage. One second later, at 2015-02-20 23:07:36, the next geomessage will go out with a time of 2012-07-04 18:32:01, because one second has elapsed. The next geomessage will have a time of 2012-07-04 18:32:02, then 2012-07-04 18:32:03, and so on unless the frequency changes.

There are some decisions to be made on how this works, including but not limited to the following:

• Which field determines the starting time? There could be multiple time fields in the first geomessage. And I don't think we're currently parsing out dates in the simulator--we're just reading the string and then sending the string--so that will be new.
• What happens when the throughput is set to multiple messages per broadcast?
• What happens when the simulation is paused and then restarted? Does the running clock keep running during the pause, or does it pause? For example, if a message is sent out with a time of 2012-07-04 18:32:42 and then the simulation is paused for five seconds, which time does the next message have: 2012-07-04 18:32:42 (running clock pauses), 2012-07-04 18:32:47 (running clock continues running), or something else?

These questions and possibly others mean that this issue is complex enough to be considered a separate issue from #4.

[conklinbd]

I think I understand the nature of the enhancement but I am unsure why we need to do it. What are we trying to handle with this case? The GeoEvent Simulator has some interesting ways of dealing with time that we might want to look at but this case isn't specifically covered.

[garysheppardjr]

This was @csmoore's idea, so maybe he can elaborate.

[csmoore]

Oh boy, it was actually a request of Dave Mitchell (I just entered the issue) - so I'm afraid I can't shed any light on either (other than the issue is at least as old as when he worked on the project)

[conklinbd]

Wow...that is funny! Dave continues to have impact. Since we can't really define the purpose for the request I vote we close it.

@joebayles and @jrweakland can have a vote.

[csmoore]

I believe the Qt version behaves the way this issue describes. But having 2 versions (Qt/C++ and Java) with different behavior is the other issue I suppose.

[garysheppardjr]

I don't think the Qt simulator does this. By default, it uses the time in the geomessage. Or, if you check any time override fields, it overrides those fields' values with the current time when the geomessage is sent out over UDP.

I am totally fine if we close this issue, whether I get a vote or not. :-)

[jrweakland]

I vote to close the issue.

[joebayles]

Time Override has one benefit that I can think of, and I think that is for planning purposes like Command Post Exercises, Rock Drills, etc. These are all developed with a very specific timeline in mind, and I think mimicking that as close as possible is the ideal method, instead of forcing people to make the jump mentally. Granted, this wouldn't be useful so much in Vehicle Commander vs. other offerings.

It also seems from the above conversation that this may already be possible. If so, it's a moot point and we should close the issue.

If not, the cost/benefit analysis for that functionality is not mine to conduct. I'm not saying that it is or isn't worth it, just something to think about from the devil's advocate. :smiling_imp:

[conklinbd]

This specific enhancement would not help us with that use case. This really just adds values to some base, not a replay of a specific timeline. The replay of a specific timeline is what geoevent supports already so I don't think we need it in this simulator either.

Based on that discussion and the additional votes from Jim and Gary I am closing.