a more serious bug

[Fidd]

Wolfpack time progression - and a bug

I've long noticed that if one synchronises an electronic watch or timer with the clock inside the uboat, the two will gradually diverge. For years I've not understood why or how this arises. And not thought about it much since I moved to the engine room. Using Septimaniens Engineer Tool, where at game start you synchronise the app to "WP" time, I've encountered this problem again. Talking it over with Septimanien, he made a VERY interesting observation, that the discrepancy - which is sometimes a few seconds over a game - but can be several minutes - was caused by the use of the stop-watch within the game. I tested this by using the in game stop-watch a lot - and sure enough the WP time on both the u-boat clock, and on his app, diverged from the system time.

So, you might start a game at 00:10:30 hrs, and synchronise the two, it could end up with a 5 or 10 minute discrepancy between the rate at which the uboats clock advanced it's time, and that of a RL wrist-watch or clock.

This is something that REALLY needs fixing, as time is so critical to teamwork between different u-boat crews. I've got into the habit of resynching WP time to game time every time we dive, in order that the battery reports output are correct. That's an easy thing to do, but when TOI's are being done, if such corrections are not made, and supporting time-pieces are in use - such as timer of wrist-watch, then it can cause terrific issues.

If the reason for use of the stop-watch causing divergencies can be nailed down and corrected that would be very good. I'll try and film this in the coming days. If anyone sees other causes, or can confirm it is the in game stop-watch(es) that are causing this effect, please reply here.

[Flubbo]

There are many players already aware of this and the effect is referred to "time dilation" by those I know, who know of this. This could be a feature as such effect occurs in a multitude of games as a way for servers to keep up with all the calculations occurring. Games such as Stormworks or EVE Online have this.

The time dilation in wolfpack can be both faster and slower than PC system time, If this is a bug or not, it's hard to say from my point of view.

If the cause of this time dilatation is due to the use of having in-game stopwatches actively counting in game or not should be explored. I only brushed it off as server calculating time slower as a result on high load.

Regardless the time dilation is not only representing itself on the time display itself. It actually will represent the actual time that the game session is running on regardless if there is a delay or a speed up. This can be seen by checking TTI before launch of torps and them watch when the impact happens. As far as I have observed torpedo simulation is accurate in sync with the in-game time and in-game stopwatches and you would only really notice a discrepancy with a IRL clock and im game time.

So as long as you do not use out of game clock/timers/watches/counters then you will never really notice the time dilation.

[Fidd]

Thanks for the further information. I've long been aware of the effect, but only lately had proof of it as it were; what was new to me was the observation that stop-watch use for one of the causes of it. It seems to me that it is a bug, because time is fundamental to everything we do in multi-boat games and it's very common for players to employ external clocks and timers.

If it's unavoidable or unfixable for other reasons, then we need better provision of the tools related to the dilating time data. For example count-down timers, and perhaps a wrist-watch view where the time can be read that is slaved to the ships clock, so that players no longer feel the need to use external timers etc.

Alternatively, the game needs to use system time for every player, simply correcting that system time with the nominal in game time to generate the time on clocks etc. That would make the time information visible in game on the clocks correct for all, and self-correcting all the time? If I understand this correctly.

[Flubbo]

Originally Posted by Fidd

and perhaps a wrist-watch view where the time can be read that is slaved to the ships clock

Press M, works everywhere on the boat.

Originally Posted by Fidd

Alternatively, the game needs to use system time for every player, simply correcting that system time with the nominal in game time to generate the time on clocks etc. That would make the time information visible in game on the clocks correct for all, and self-correcting all the time? If I understand this correctly.

This is not likely a time presentation problem but a time simulation problem. Stopwatches, and TTI are still following the in-game clock so, this has to do with simulation speed. Just syncing in-game time to system time will not solve this. The game might need a adaptive time dilatation system that works faster to catch up on lost time and slower to compensate for heavier load. Now this bug is something that probably only really exist in the beta due to the de-sync problems we have due to the excess data where one source of this is the enigma-form sending too much data to clients but there is still desync in the beta-beta which also could contribute to the dilated time.

[Fidd]

Originally Posted by Flubbo

Press M, works everywhere on the boat.



This is not likely a time presentation problem but a time simulation problem. Stopwatches, and TTI are still following the in-game clock so, this has to do with simulation speed. Just syncing in-game time to system time will not solve this. The game might need a adaptive time dilatation system that works faster to catch up on lost time and slower to compensate for heavier load. Now this bug is something that probably only really exist in the beta due to the de-sync problems we have due to the excess data where one source of this is the enigma-form sending too much data to clients but there is still desync in the beta-beta which also could contribute to the dilated time.

Interesting. I had not understood that time dilation was being "used" to cope with desynchs, if indeed that it the case. My point was that "time" and the rate of its' progression are so fundamental to the game, that the current variable rate is unacceptable. From what I've seen WP time is not self-correcting, but continuously divergent, so I frankly have my doubts that your interpretation is correct. That said, I've not studied the progression with that in mind. But, by resynching WP time and RL time every 25 mins or less seems to indicate that it is divergent rather than corrective. In other words, the difference between the two only increases over time.

We'll have to wait for the end of the beta to know what's what here, but my instinct is that wp time and rl time need their relative values and rates resynched at a much greater frequency than is currently the case, if it resynching at all currently, which I doubt.