- 335
- MGR
Updated 11th February 2012
Progress!
Seems we've finally generated enough noise to bring this issue to PD's attention. In the recent GT5 V2.04 update the first line of the release notes states:
An initial test by GTP member cicua has demonstrated a full grid 16x car race at Suzuka (no weather) being run without the bug present. The test subject was using a FFB wheel but all voice chat was disabled for the race.
Early signs are promising. However more testing is needed - especially while using voice chat.
*****
Updated OP 20th January
Gran Turismo 5 suffers from a serious online bug which results in abnormally long lap times for those affected.
Symptoms
The bug manifests itself by way of the competitors vehicle having reduced grip, poor acceleration and poor braking. It is also associated with a noticeable drop in frame rate or stuttering. The amount of time lost will vary depending on several factors which influence the severity of the bug.
Contributing factors
Race Only
This bug does not appear to effect free-run mode. Competitors are able to make consistent lap times regardless of how many people are practising at any one time. These free-runs laps can be used to benchmark the severity of the bug when it occurs in racing.
Number of Competitors
There is no magic number here but based on sample data and feedback from other GTP Members the bug can appear with 11 or more competitors and becomes more severe as competitor numbers increase.
Controller method
The bug has consistently proved to affect FFB wheel users much more than Dual Shock users.
Headset use
The bug has also proved to be more prevalent with those using voice headsets.
Track choice
Some tracks demonstrate a tendency for the bug to appear with fewer competitors compared to other (smaller) tracks. For example youre much more likely to encounter problems on Grand Valley Speedway than Tsukuba.
Premium cars
This is based mostly on anecdotal evidence but the bug seems more common with many premium (highly detailed) model cars in use. Races using standard model cars (like shuffle races) seem to be slightly less affected.
Recognising the bug
Firstly, it is important to remember this bug does not appear to affect free-run mode. Lap times made in free-run mode seem to be consistent no matter how many users are within the gaming lobby and can potentially be used as the benchmark to determine when youre affected by the bug during races.
Seasoned drivers will (in free-run mode) be able to punch out lap after lap within a few tenths of each other. However once the race starts, should those (clean) lap times suffer by several seconds right from the start of the race then its highly likely the bug is adversely affecting the drivers pace.
However there is a method of checking post-race whether a particular driver has definitely been affected.
Replay time discrepancy
It has been established that replay data provides a window into which races are affected and by how much. To check suspect replays simply watch the replay and use a handheld stopwatch to time the recorded laps manually. The difference in time between the clock as shown on the replay and the stopwatch recorded time appears to be an accurate indicator of the amount of time lost due to the bug.
Example:
The first table shows the lap time differences between the game clock and stopwatch in a replay that was noticeably affected during the race by the bug. The data is from a driver using a Logitech G25 FFB wheel. The dual shock users in this race seemed to be unaffected.
The second table shows the lap time differences between the game clock and stopwatch in a replay that seemed (to the driver involved) to be unaffected. Each lap (with the exception of the first and to a lesser extent the second) is virtually the same time on the game clock and stopwatch. The one tenth could be accounted for in the accuracy of the stopwatch in question (in this case an Ipod Touch). It should also be noted this replay data was from the pole sitter whom led from the start and quickly pulled a reasonable lead. The slight time difference from the first lap could be attributed to the amount of heavy traffic (graphical data) being processed.
As a video demonstration of the time discrepancy please view this video provided by GTP member Filip_Ovik. As you can see the game clock shown in the video seems to be running much faster than the timecode on the youtube video:
Analysing contributing factors
Number of Competitors
As previously stated there is no magic number of competitors which will always activate this bug. Although I have seen the bug affect races with only 11 (standard model) cars on Grand Valley Speedway. Given how there are many factors which can influence the bug I wouldnt be surprise if the bug could affect races with fewer competitors.
The following replay data was supplied by the pole sitter of this particular race. The driver was using a Logitech G27 wheel but did not use any microphone/chat communication.
As you can see the bug was having a significant impact on his lap times with 12 competitors. Once that number dropped back to 11 (at the start of lap three) the bug was still present but only affecting lap times by just under half a second. It wasn't until the numbers dropped back to 10 (early in lap 5) that the bug was gone.
Below is some sample replay data of races held on the same day using the same lobby/group of competitors. All races were conducted on the evening of the 16th June 2011.
This data illustrates the relationship between the number of competitors and the severity of the bug. I have much more recent (and severe) examples but I wanted to demonstrate that this is not a new issue and I suspect has been going on much earlier than June 2011 possibly since the game launched.
Controller method & headset use
When competitor numbers reach the tipping point and the bug appears its the FFB wheel users and to a lesser extent those using headsets that are first affected and suffer the most time loss.
In a very recent one-make race with 14 competitors on the Nurburgring GP/F using premium model Mazda MX5s we suffered an incredible amount of time-loss right from the start. However this did allow me the opportunity to test using different peripherals and turning the headset on and off during the same race.
You can see from the table above that by switching from the Logitech G25 to the dual shock controller and by disabling the official Sony BT headset the driver is able to gain back a massive amount of time lost. Despite these measures the bug is still hampering lap times in this extreme case but to a far lesser extent.
Below is a video compiled by GTP member Speedy6543 from a race on Tokyo R246 reverse. It graphically demonstrates the difference in pace between the different cars depending on controller method.
Track choice
Tracks such as Tsukuba seem less susceptible to the bug while tracks such as Grand Valley Speedway have seen significant time loss with only 12 competitors using standard model cars. I will use this particular Grand Valley example in this next point.
Free-run vs. Racing
As previously stated this bug doesnt seem to affect free-run mode. However there is a key difference between free-run and racing that being the PS3 is not recording anything in free-run mode. It would also seem that the recording of replays not only contributes to the bug, but may contain clues as to how much time is being lost during the race.
For example;
Grand Valley Speedway - 12 competitors all using the Viper GTS 99 (Standard Model)
Qualifying lap (Free-run mode) - 2:11.8 (game clock)
Clean race lap - 2:17.6 (game clock)
Although the driver is able to set several laps within a few tenths of each other during free-run, come race time the lap is nearly 6 seconds slower. But heres where it gets interesting;
If you play back the recorded replay of this race and manually time the clean race lap the stopwatch gives a lap time of 2:11.7 only 1 tenth difference between the free-run lap and race lap. The replay of course will still show 2:17.6 on the game clock.
This is only one of many examples where the manually timed replay lap all but matches the time achieved in free-run mode. I suspect the time difference recorded in the race replay is directly related to the amount of time lost during an actual race.
Physics theory
The following is my own personal theory. It may not be 100% accurate but it does go a long way to accounting for all of the symptoms suffered and is based on the data collected.
Loss of power, braking and grip combined with a frame rate drop or stuttering is the symptom describe by racers experiencing the bug. To the driver it feels like the physics have changed. But I propose that the time discrepancies shown in the race replay and the strange physics are one in the same problem.
First, lets cover some basics. The game clock is accurate while racing. That means 1 minute on the game clock during a race is 1 minute in real life. It is only when a bug affected replay is played back that the game clock progresses faster than real life.
It has also been previously noted that the time discrepancy in the replay seems to directly correlate to the lap time achievable in free-run mode. ie If a clean free-run lap is 2:00, and the bug affected race lap is 2:10 then the stopwatch timed replay race lap will be 2:00.
Given the close links to the PS3s workload (# of competitors, replay recording, FFB effects, headset voice processing, highly detailed premium cars & high draw tracks) and the occurrence/severity of the bug I propose that in some circumstances the game (or PS3) is simply unable to process data for every frame quickly enough and is causing the game of those affected by the bug to suffer from (for lack of a better term) micro-pauses.
Earlier in this thread I posted some replay timing data from a bugged replay;
Qualifying lap (Free-run mode) - 2:11.8 (game clock)
Clean race lap - 2:17.6 (game clock)
Replay race lap 2:11.7 (stopwatch)
Around 6 seconds lost.
Working on the assumption that GT5 is running at 60fps (obviously it's not solid 60fps but the actual framerate is not really relevant) then the 'stuttering' effect could be from the bugged individuals game pausing frames 2 or 3 times per second while it catches up on its workload. Tiny pauses of this nature should be detectable to the naked eye and will of course be even more apparent should greater time loss be experienced.
The game timer clock continues to run and each recorded frame is time stamped. However during these 'pauses' the frames are not recorded by the replay data. This would account for the time difference between the game clock in a bugged replay and stopwatch time.
So while the bugged car is pausing 2 or 3 times per second (each pause less than two hundreds of a second) the unaffected car has moved on up the road just a little.
In the example above the race lap was 6 seconds (approximately 4.5%)
Now consider the car is travelling at 100km/h - but the game is 'micro-pausing' 2 or 3 times per second. Because of these added paused frames the driver perceives or 'feels' the car to be travelling slower than it actually is in the physics engine. Because the driver perceives the vehicle to be moving 4.5% slower (say 95.5km/h) than it actually is then they will brake at an appropriate point - based on their perceived (slower) vehicle speed.
However, the car is not travelling at 95.5km/h in the game engine. It's actually travelling at 100km/h and the braking point selected by the driver will almost certainly be too late. Not only that, but now that the driver has hit the brakes (and the game is still micro-pausing) the car is now taking 4.5% longer (in perceived time by the driver) to pull up for the corner.
Cornering will have the same 'slow' feeling. Due to these micro-pauses the car is perceived by the driver to be travelling slower than it should. And relative to the rest of the unaffected cars racing - it is travelling slower.
This theory would explain:
- The slow lap times
- The framerate stuttering
- The lost replay data
- The perceived loss of grip and power.
Other key points
This is not a Spec 2.0 bug.
It has been around well before Spec 2.0 as demonstrated from the data recorded in June 2011.
This is not an online vs. offline physics discussion.
Yes, they are different. No, offline lap times do not match online lap times. We know.
This thread is about the discussion of this specific bug.
Room settings are not a factor.
Boost on / off, Grip low / real, Tyre wear on/ off, normal or shuffle race, whatever.
It does not matter. The bug can affect racers regardless of the room settings.
Network connection speed is not a factor.
Doesnt matter how good your connection is. This particular bug does not discriminate against good or poor connections.
Lobby spectators are not a factor.
For example if you have 10 cars racing and 3 or 4 spectators the race will not suffer the bug. Normal network lag may increase as the amount of bandwidth required to service the additional client (spectator) consoles will increase but this will happen in any room or lobby.
Credits
I would like to thank everybody in this thread for their input and a special thanks to Famine and Jordan for highlighting the issue and posting on the front page of GT Planet (although I like my OP title better
).
I hope this finally brings to the fore the seriousness of this bug.
Once again, thank you to all contributors.
Cheers
MGR
Progress!
Seems we've finally generated enough noise to bring this issue to PD's attention. In the recent GT5 V2.04 update the first line of the release notes states:
An initial test by GTP member cicua has demonstrated a full grid 16x car race at Suzuka (no weather) being run without the bug present. The test subject was using a FFB wheel but all voice chat was disabled for the race.
Early signs are promising. However more testing is needed - especially while using voice chat.
*****
Updated OP 20th January
Gran Turismo 5 suffers from a serious online bug which results in abnormally long lap times for those affected.
Symptoms
The bug manifests itself by way of the competitors vehicle having reduced grip, poor acceleration and poor braking. It is also associated with a noticeable drop in frame rate or stuttering. The amount of time lost will vary depending on several factors which influence the severity of the bug.
Contributing factors
Race Only
This bug does not appear to effect free-run mode. Competitors are able to make consistent lap times regardless of how many people are practising at any one time. These free-runs laps can be used to benchmark the severity of the bug when it occurs in racing.
Number of Competitors
There is no magic number here but based on sample data and feedback from other GTP Members the bug can appear with 11 or more competitors and becomes more severe as competitor numbers increase.
Controller method
The bug has consistently proved to affect FFB wheel users much more than Dual Shock users.
Headset use
The bug has also proved to be more prevalent with those using voice headsets.
Track choice
Some tracks demonstrate a tendency for the bug to appear with fewer competitors compared to other (smaller) tracks. For example youre much more likely to encounter problems on Grand Valley Speedway than Tsukuba.
Premium cars
This is based mostly on anecdotal evidence but the bug seems more common with many premium (highly detailed) model cars in use. Races using standard model cars (like shuffle races) seem to be slightly less affected.
Recognising the bug
Firstly, it is important to remember this bug does not appear to affect free-run mode. Lap times made in free-run mode seem to be consistent no matter how many users are within the gaming lobby and can potentially be used as the benchmark to determine when youre affected by the bug during races.
Seasoned drivers will (in free-run mode) be able to punch out lap after lap within a few tenths of each other. However once the race starts, should those (clean) lap times suffer by several seconds right from the start of the race then its highly likely the bug is adversely affecting the drivers pace.
However there is a method of checking post-race whether a particular driver has definitely been affected.
Replay time discrepancy
It has been established that replay data provides a window into which races are affected and by how much. To check suspect replays simply watch the replay and use a handheld stopwatch to time the recorded laps manually. The difference in time between the clock as shown on the replay and the stopwatch recorded time appears to be an accurate indicator of the amount of time lost due to the bug.
Example:
The first table shows the lap time differences between the game clock and stopwatch in a replay that was noticeably affected during the race by the bug. The data is from a driver using a Logitech G25 FFB wheel. The dual shock users in this race seemed to be unaffected.
The second table shows the lap time differences between the game clock and stopwatch in a replay that seemed (to the driver involved) to be unaffected. Each lap (with the exception of the first and to a lesser extent the second) is virtually the same time on the game clock and stopwatch. The one tenth could be accounted for in the accuracy of the stopwatch in question (in this case an Ipod Touch). It should also be noted this replay data was from the pole sitter whom led from the start and quickly pulled a reasonable lead. The slight time difference from the first lap could be attributed to the amount of heavy traffic (graphical data) being processed.
As a video demonstration of the time discrepancy please view this video provided by GTP member Filip_Ovik. As you can see the game clock shown in the video seems to be running much faster than the timecode on the youtube video:
Analysing contributing factors
Number of Competitors
As previously stated there is no magic number of competitors which will always activate this bug. Although I have seen the bug affect races with only 11 (standard model) cars on Grand Valley Speedway. Given how there are many factors which can influence the bug I wouldnt be surprise if the bug could affect races with fewer competitors.
The following replay data was supplied by the pole sitter of this particular race. The driver was using a Logitech G27 wheel but did not use any microphone/chat communication.
As you can see the bug was having a significant impact on his lap times with 12 competitors. Once that number dropped back to 11 (at the start of lap three) the bug was still present but only affecting lap times by just under half a second. It wasn't until the numbers dropped back to 10 (early in lap 5) that the bug was gone.
Below is some sample replay data of races held on the same day using the same lobby/group of competitors. All races were conducted on the evening of the 16th June 2011.
This data illustrates the relationship between the number of competitors and the severity of the bug. I have much more recent (and severe) examples but I wanted to demonstrate that this is not a new issue and I suspect has been going on much earlier than June 2011 possibly since the game launched.
Controller method & headset use
When competitor numbers reach the tipping point and the bug appears its the FFB wheel users and to a lesser extent those using headsets that are first affected and suffer the most time loss.
In a very recent one-make race with 14 competitors on the Nurburgring GP/F using premium model Mazda MX5s we suffered an incredible amount of time-loss right from the start. However this did allow me the opportunity to test using different peripherals and turning the headset on and off during the same race.
You can see from the table above that by switching from the Logitech G25 to the dual shock controller and by disabling the official Sony BT headset the driver is able to gain back a massive amount of time lost. Despite these measures the bug is still hampering lap times in this extreme case but to a far lesser extent.
Below is a video compiled by GTP member Speedy6543 from a race on Tokyo R246 reverse. It graphically demonstrates the difference in pace between the different cars depending on controller method.
Track choice
Tracks such as Tsukuba seem less susceptible to the bug while tracks such as Grand Valley Speedway have seen significant time loss with only 12 competitors using standard model cars. I will use this particular Grand Valley example in this next point.
Free-run vs. Racing
As previously stated this bug doesnt seem to affect free-run mode. However there is a key difference between free-run and racing that being the PS3 is not recording anything in free-run mode. It would also seem that the recording of replays not only contributes to the bug, but may contain clues as to how much time is being lost during the race.
For example;
Grand Valley Speedway - 12 competitors all using the Viper GTS 99 (Standard Model)
Qualifying lap (Free-run mode) - 2:11.8 (game clock)
Clean race lap - 2:17.6 (game clock)
Although the driver is able to set several laps within a few tenths of each other during free-run, come race time the lap is nearly 6 seconds slower. But heres where it gets interesting;
If you play back the recorded replay of this race and manually time the clean race lap the stopwatch gives a lap time of 2:11.7 only 1 tenth difference between the free-run lap and race lap. The replay of course will still show 2:17.6 on the game clock.
This is only one of many examples where the manually timed replay lap all but matches the time achieved in free-run mode. I suspect the time difference recorded in the race replay is directly related to the amount of time lost during an actual race.
Physics theory
The following is my own personal theory. It may not be 100% accurate but it does go a long way to accounting for all of the symptoms suffered and is based on the data collected.
Loss of power, braking and grip combined with a frame rate drop or stuttering is the symptom describe by racers experiencing the bug. To the driver it feels like the physics have changed. But I propose that the time discrepancies shown in the race replay and the strange physics are one in the same problem.
First, lets cover some basics. The game clock is accurate while racing. That means 1 minute on the game clock during a race is 1 minute in real life. It is only when a bug affected replay is played back that the game clock progresses faster than real life.
It has also been previously noted that the time discrepancy in the replay seems to directly correlate to the lap time achievable in free-run mode. ie If a clean free-run lap is 2:00, and the bug affected race lap is 2:10 then the stopwatch timed replay race lap will be 2:00.
Given the close links to the PS3s workload (# of competitors, replay recording, FFB effects, headset voice processing, highly detailed premium cars & high draw tracks) and the occurrence/severity of the bug I propose that in some circumstances the game (or PS3) is simply unable to process data for every frame quickly enough and is causing the game of those affected by the bug to suffer from (for lack of a better term) micro-pauses.
Earlier in this thread I posted some replay timing data from a bugged replay;
Qualifying lap (Free-run mode) - 2:11.8 (game clock)
Clean race lap - 2:17.6 (game clock)
Replay race lap 2:11.7 (stopwatch)
Around 6 seconds lost.
Working on the assumption that GT5 is running at 60fps (obviously it's not solid 60fps but the actual framerate is not really relevant) then the 'stuttering' effect could be from the bugged individuals game pausing frames 2 or 3 times per second while it catches up on its workload. Tiny pauses of this nature should be detectable to the naked eye and will of course be even more apparent should greater time loss be experienced.
The game timer clock continues to run and each recorded frame is time stamped. However during these 'pauses' the frames are not recorded by the replay data. This would account for the time difference between the game clock in a bugged replay and stopwatch time.
So while the bugged car is pausing 2 or 3 times per second (each pause less than two hundreds of a second) the unaffected car has moved on up the road just a little.
In the example above the race lap was 6 seconds (approximately 4.5%)
Now consider the car is travelling at 100km/h - but the game is 'micro-pausing' 2 or 3 times per second. Because of these added paused frames the driver perceives or 'feels' the car to be travelling slower than it actually is in the physics engine. Because the driver perceives the vehicle to be moving 4.5% slower (say 95.5km/h) than it actually is then they will brake at an appropriate point - based on their perceived (slower) vehicle speed.
However, the car is not travelling at 95.5km/h in the game engine. It's actually travelling at 100km/h and the braking point selected by the driver will almost certainly be too late. Not only that, but now that the driver has hit the brakes (and the game is still micro-pausing) the car is now taking 4.5% longer (in perceived time by the driver) to pull up for the corner.
Cornering will have the same 'slow' feeling. Due to these micro-pauses the car is perceived by the driver to be travelling slower than it should. And relative to the rest of the unaffected cars racing - it is travelling slower.
This theory would explain:
- The slow lap times
- The framerate stuttering
- The lost replay data
- The perceived loss of grip and power.
Other key points
This is not a Spec 2.0 bug.
It has been around well before Spec 2.0 as demonstrated from the data recorded in June 2011.
This is not an online vs. offline physics discussion.
Yes, they are different. No, offline lap times do not match online lap times. We know.
This thread is about the discussion of this specific bug.
Room settings are not a factor.
Boost on / off, Grip low / real, Tyre wear on/ off, normal or shuffle race, whatever.
It does not matter. The bug can affect racers regardless of the room settings.
Network connection speed is not a factor.
Doesnt matter how good your connection is. This particular bug does not discriminate against good or poor connections.
Lobby spectators are not a factor.
For example if you have 10 cars racing and 3 or 4 spectators the race will not suffer the bug. Normal network lag may increase as the amount of bandwidth required to service the additional client (spectator) consoles will increase but this will happen in any room or lobby.
Credits
I would like to thank everybody in this thread for their input and a special thanks to Famine and Jordan for highlighting the issue and posting on the front page of GT Planet (although I like my OP title better
).I hope this finally brings to the fore the seriousness of this bug.
Once again, thank you to all contributors.
Cheers
MGR
Last edited:
.
