PDA

View Full Version : high time compression is not good



Teddy Bar
01-29-2006, 03:29 AM
We have always known that high time compression was an issue with SHIII.

With aircraft the issue issue shows up in two completely opposite situations. The first is when you are suddenly being bombed by plane the split second the time compression goes to 1x and the other might be where for example you are crossing the Bay of Biscay day in and day out and never seeing an aircraft while your mates complain bitterly that they are getting hammered.

Stiebler, the man behind making the NYGM RUB Campaign Mod possible, has explained it a way that is poetic...

Stiebler has explained why high time compression is not good.

Concerning time compression (TC):
SH3 calculates the position of every unit (or unit block, such as a convoy) at every time unit (whatever the internal time tick may be). If you run at 1xTC then no unit, including your U-boat, has travelled very far when the update comes. At 128xTX, everything has moved 128 times further before updates occur. At 1024xTC everything has moved quite a distance before the update occur. So a ship or aircraft may jump suddenly into the middle of your field of view when it wasn't visible before. Alternatively, it may hop completely over the U-boat without either side ever seeing the other. I think use of TC above 512 is unwise, except to accelerate travel to remote patrol areas.

It is possible to use interpolation routines to check whether two units have hopped over each other without spotting one another. I've done it myself for a customer, but it is complicated and Ubisoft, probably wisely, has decided not to add the extra computational burden.

Teddy Bar
01-29-2006, 03:29 AM
We have always known that high time compression was an issue with SHIII.

With aircraft the issue issue shows up in two completely opposite situations. The first is when you are suddenly being bombed by plane the split second the time compression goes to 1x and the other might be where for example you are crossing the Bay of Biscay day in and day out and never seeing an aircraft while your mates complain bitterly that they are getting hammered.

Stiebler, the man behind making the NYGM RUB Campaign Mod possible, has explained it a way that is poetic...

Stiebler has explained why high time compression is not good.

Concerning time compression (TC):
SH3 calculates the position of every unit (or unit block, such as a convoy) at every time unit (whatever the internal time tick may be). If you run at 1xTC then no unit, including your U-boat, has travelled very far when the update comes. At 128xTX, everything has moved 128 times further before updates occur. At 1024xTC everything has moved quite a distance before the update occur. So a ship or aircraft may jump suddenly into the middle of your field of view when it wasn't visible before. Alternatively, it may hop completely over the U-boat without either side ever seeing the other. I think use of TC above 512 is unwise, except to accelerate travel to remote patrol areas.

It is possible to use interpolation routines to check whether two units have hopped over each other without spotting one another. I've done it myself for a customer, but it is complicated and Ubisoft, probably wisely, has decided not to add the extra computational burden.

wessenhammer
01-29-2006, 07:49 AM
I've also notice that with 514 and 1024 compression you can travel further underwater using less energy than at lower comp levels especially if you remove the hydro operator from station and avoid the reduction to 8x comp. generally 90k using only 50-60 of battery and approx 60% avail air supply.

Teddy Bar
01-30-2006, 10:19 PM
Dan of the Dev Team replied at the SimHQ forums...

Not true, TB. Our programmers are smarter than that, otherwise you'd be missing fast ships/convoys when running at 4096x or such. Mihai Enescu just explained to me how the system works, and the problem lies not in how often sensors and travel is run, but in the efficacity of the visual sensors during the night.

When at night, and with high speed planes, the window of detection for both the aircraft and the uboot is very small. Our bets are things would happen the same even with time compression set to 1x.

To reiterate, it shouldn't make any difference whether you're running at 1x or 100000x, for practical detection purposes.

The maximum time allowed between two calculations of the game situation - in game time - is 1 second. Of course, when running real time, this time period (delta t) is much shorter.

The probability of detection is scaled accordingly with this Delta T.

The REAL issue here is the detection time of the visual sensor on the submarine, which is 15 seconds for ideal conditions - and this is scaled up when conditions or efficiency degrade.

This basically means it can take up to 15 seconds to detect a unit in ideal conditions - full deck watch, good light et all. When visibility decays, the max time increases, and a fast, small plane can get to you undetected.

TB, I'll write to you on this issue.

jasonsagert
01-30-2006, 10:50 PM
Dan of the Dev teams's explanation accounts for the plane coming out of nowhere but fails to explain why at high time compressions (512 or 1024) you can experience the "no airplane" bug. I've experienced this and I can tell you it's pretty strange to be able to cruise around the Bay of Biscay in 1944 for three days in perfect weather at a time compression of 1024 and not see any airplanes. I can't offer an explanation, but there is clearly something strange happening with the time compression/detection--particularly with airplanes.

Cheers,

J

vanjast
01-31-2006, 01:46 AM
I think the Devs 'bombed' this part completely..

Try this.
While on the bridge your max time is 32x and limited as there are a lot of calculations to do while in visual mode.
But while at 1024x all those calculations are now not needed, and all you have to do in the software is treat a covvoy, lone ship, sub, plane as a single object with only detection and speed/course parameters.
With this minimal amount of info to calculate you can perform, taking a guess, at least a 100 calcs per object per sec. This should effectively reduce the time scale for detection down to 1024/100 = 10.2400000001x. http://forums.ubi.com/groupee_common/emoticons/icon_biggrin.gif
What has the Dev team done to blow this idea.

Tut tut http://forums.ubi.com/images/smilies/51.gif