III & VC Save File Glitch Detection and Repair

May 24, 2015

The purpose of this topic is to document Glitches in GTA III and GTA: Vice City

that are part of the save file. It is intended for people who can hex edit a save file

or create tools that can detect or repair save file glitches.

Useful links with save file structure documentation, forum discussions and save editors:

Saves (GTA 3) - GTAModding.com

GTA III Save File Documentation - GTAForums.com

GTA III Save File Editor - GTAGarage.com

Saves (GTA VC) - GTAModding.com

Vice City Save File Format - GTAForums.com

VC Savegame Editor - GTAGarage.com

OrionSR's similar topic about GTA: San Andreas

Grand Theft Auto III Save File Glitches

1. Unique Stunt Jump Camera Freezing Glitch

Class: Class III - Inevitable

Status: WORKAROUND ONLY

Description: The glitch occurs immediately after achieving game time of 37:17 (2237 mins, 134 220 000 msecs) if the game runs at 60 fps and 74:34 (4474 mins, 268 440 000 msecs) in the case of 30 fps (double amount of the first number). The problem takes place after entering any USJ ramp and triggering USJ cinematic camera view. First of all, game clock seen on HUD completely stops. Then, after your vehicle hits the ground, regardless of whether USJ was completed or not, cinematic camera doesn't revert back to normal view making further gameplay impossible.

Genesis: Seems to be connected with game timers mailfunction. Deeper investigation needed!

Protection: None applicable. The glitch is inevitable regardless of player actions.

Solution: Only а workaround method is known at the time. To revert USJ camera back you need to minimize game window to desktop using Alt+Tab and then maximize it back several times. Repeat 3-4 times to fix the camera view. No real permanent solution is developed yet!

2. Game Speedup Glitch

Class: Class III - Inevitable

Status: UNSOLVED

Description: This is the second phase of glitch #1. The glitch occurs immediately after achieving game time of 74:34 (4474 mins, 268 440 000 msecs) if the game runs at 60 fps and possibly 149:08 (8948 mins, 536 880 000 msecs) in the case of 30 fps (double amount of the first number; hypothetically, not tested yet). The problem lies in game clock scale. Normally, 60 seconds of real time equal 58 seconds in-game (58 game minutes). After achieving abovementioned game time clock scale doubles and 60 seconds of real time begin to equal 116 seconds in-game (116 game minutes). This causes strong effect on gameplay as generic processes such as leaves falling, smashed car hoods separating, pickups rotating, weapons firing or traffic vehicles driving flow two times faster than normal.

Genesis: Like #1, seems to be connected with game timers mailfunction. Deeper investigation needed!

Protection: None applicable. The glitch is inevitable regardless of player actions.

Solution: No methods or even workarounds are known yet!

3. Purple Nines Disappearance Glitch

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: If a player has completed D-Ice's story missions once and then replays the game repeatedly on another save file, the Purple Nines gang which is supposed to vanish after D-Ice's missions tends to be absent from the beginning of a new game. This makes D-Ice's missions "Uzi Money" & "Rumble" impossible to complete subsequently as necessary Purple Nines gansters don't spawn anymore.

Genesis: Beleived to be connected with some influence of completed saves on script.

Protection: Neither I nor any of my fellow GTA players haven't experienced this glitch ever despite having multiple save files with different completion percents at the time, so I don't know for sure. Basic recommendations are backing up your save files and playing new game after GTA III's installation from scratch.

Solution: If the glitch takes place in your game, use GTA III Save File Editor to fix it.

4. Uncancelable Cheats Сonsequences

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: Not a typical glitch, but still worth mentioning. The "pedestrian hatred" (NOBODYLIKESME) and "pedestrian riot" (ITSALLGOINGMAAAD) cheats have irreversible effects. If a player allows the game to be saved when any of these cheats are active then the effects of mentioned cheats will be impossible to switch off.

Genesis: Basically, these cheats were designed without possibility to be switched off.

Protection: Obviously, do not save when these cheats are on.

Solution: If you've managed to disregard this easy protection measure, you'll have to use GTA III Save File Editor to switch off these cheats.

5. Negative Money Amount Issue

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: Again not a glitch, but a kind of game limit worth mentioning. If you've earned $2 147 483 647 and then acquire even $1 more, your money amount will negate to -$2 147 483 648. Because you'll have a "debt" you won't be able to buy anything or use services that require money. All your further earnings will contribute in decreasing your "debt" heading to $0.

Genesis: The game stores Claude's money amount in an integer 4 byte variable. Since R* hasn't implemented any limits, money values can change in the range of [-2 147 483 648, ... , 0, ... , 2 147 483 647]. The process of exceeding this limit is called "integer overflow" and has a cyclical nature.

Protection: Because GTA III follows 2D era's pattern to reward a player with money for destruction actions like explosions during gameplay, it is easy to have money overflow if you've previously earned an amount close to the limit. So the advice is to keep you money balance around $2 146 900 000 so that no game reward (maximum is $500 000 profit after "The Exchange" mission) could cause your money to overflow.

Solution: If you've somehow got a "debt", you can use GTA III Save File Editor to set a normal amount of money.

6. Mission Blending Problems

Class: Class I - Bypassable by certain gameplay method

Status: NO SOLUTON APPLICABLE

Description: Not a single glitch but the whole complicated system of different exploits and their consequences. Can break save files, so worth mentioning nevertheless. Never appears during normal gameplay. Used by speedrunners to complete several missions simultaneously and unique/rare vehicle (URV) collectors to acquire target vehicle from a mission. Generally, mission blending is a game exploit letting you to start two same or different missions at a time. Requires activating preliminary recorded replay of starting a rampage (rampage replay, RR) or performing "Taxi Mission in Memory" bug (TMM, letting you to enter "Taxi Driver" sub-mission using any vehicle). The consequences can include saving mission blips on a radar, impossibility to start some missions preventing 100% game completion or simple game crash depending on a specific blending method.

Genesis: Occurs due to multiple scripts conflicting with one another.

Protection: If you are performing mission blending you must have been gone far from a casual player level so consider doing everything at your own risk. Always backup your save files at every stage of the game to distinguish possible problems that may appear suddenly.

Solution: There is a huge variety of different blending strategies so there can be no specific solution. Just follow protection measures and hope that everything would be all right. Good luck.

Grand Theft Auto: Vice City Save File Glitches

1. Unique Stunt Jump Camera Speedup Glitch

Class: Class III - Inevitable

Status: UNSOLVED

Description: GTA VC introduces one more glitch related to game timers, which happens right before familiar timer glitches. The glitch occurs immediately after achieving game time of 18:39 (1119 mins, 67 140 000 msecs) if the game runs at 60 fps and 37:17 (2237 mins, 134 220 000 msecs) in the case of 30 fps (double amount of the first number). The problem takes place after entering any USJ ramp and triggering USJ cinematic camera view. The issue lies in some slow motion mailfunction. It's hard to describe, but let's look at the specific example. Use Rhino to try a USJ seen on a screenshot above in Escobar Intl. Airport. Begin accelerating at the very beginning of the airport runway, turn the tank's tower back and start shooting backwards for gaining more speed. After you take off the ramp, continue shooting Rhino's cannon and count the number of shots you can fire before hitting the ground. Regarless of game's fps, it'll always be roughly 5 shots before achieving "glitch time" and 8-9 shots between "glitch time" and the beginning of second glitch phase descriped in #2. Increased amount of shots also lead to Rhino flying further than normally. This fact clearly shows that game timers begin to work oddly here. Strangely enough, this phase is absolutely absent in GTA III.

Genesis: Seems to be connected with game timers mailfunction. Deeper investigation needed!

Protection: None applicable. The glitch is inevitable regardless of player actions.

Solution: No methods or even workarounds are known yet!

2. Unique Stunt Jump Camera Freezing Glitch

Class: Class III - Inevitable

Status: WORKAROUND ONLY

Description: See GTA III's glitch #1. This is the second phase of glitch #1. The glitch occurs immediately after achieving game time of 37:17 (2237 mins, 134 220 000 msecs) if the game runs at 60 fps and 74:34 (4474 mins, 268 440 000 msecs) in the case of 30 fps (double amount of the first number). The problem takes place after entering any USJ ramp and triggering USJ cinematic camera view. First of all, game clock seen on HUD completely stops. Then, after your vehicle hits the ground, regardless of whether USJ was completed or not, cinematic camera doesn't revert back to normal view making further gameplay impossible.

Genesis: Like #1, seems to be connected with game timers mailfunction. Deeper investigation needed!

Protection: None applicable. The glitch is inevitable regardless of player actions.

Solution: Only а workaround method is known at the time. To revert USJ camera back you need to minimize game window to desktop using Alt+Tab and then maximize it back several times. Repeat 3-4 times to fix the camera view. New workaround method for VC is using a replay function. Unlike GTA III, switching VC's replay on and off adds one second to game clock. Repeat this 7-9 times to fix the issue, apparently overtaking stopped game clock and forcing it to move on. But still - no real permanent solution is developed yet!

3. Game Speedup Glitch

Class: Class III - Inevitable

Status: UNSOLVED

Description: See GTA III's glitch #2. This is the third phase of glitch #1. The glitch occurs immediately after achieving game time of 74:34 (4474 mins, 268 440 000 msecs) if the game runs at 60 fps and possibly 149:08 (8948 mins, 536 880 000 msecs) in the case of 30 fps (double amount of the first number; hypothetically, not tested yet). The problem lies in game clock scale. Normally, 60 seconds of real time equal 58 seconds in-game (58 game minutes). After achieving abovementioned game time clock scale doubles and 60 seconds of real time begin to equal 116 seconds in-game (116 game minutes). This causes strong effect on gameplay as generic processes such as leaves falling, smashed car hoods separating, pickups rotating, weapons firing or traffic vehicles driving flow two times faster than normal.

Genesis: Like #1 & #2, seems to be connected with game timers mailfunction. Deeper investigation needed!

Protection: None applicable. The glitch is inevitable regardless of player actions.

Solution: No methods or even workarounds are known yet!

4. Off-Road Races' Statistics Inconsistency Glitch

Class: Class III - Inevitable

Status: WORKAROUND ONLY

Description: There are two off-road racing sub-missions: "Test Track" (TT) & "Trial by Dirt" (TD). There is some stats inconsistency linked to these races. TT itself works fine: when you complete it for the first time corresponding entry appears in game stats. If you improve your result further the entry updates to show your current record. The problem lies in TD mission. Its stats entry at best will be equal to TT result and at worst it won't appear in stats at all even after the mission is completed any number of times. So, getting real TD result shown in stats is impossible.

Genesis: Imperfection and possible conflict of racing sub-missions' scripts. Needs some research!

Protection: None applicable. The glitch is inevitable regardless of any completion methods.

Solution: The best what can be done here is getting better scenario. Firstly, complete TT mission, e.g. your result will be 3:00 mins. Then complete TD with any result and you'll get an entry stating 3:00 for it. Do not complete TD before TT or TD stat entry will be gone forever for this save file! You may try to impove your results onwards, moreover, you'll have to if you want to acquire UC Black Rancher and UC Black Sanchez URV's. If you update TT result, e.g. to 2:30 mins, you'll get its entry with 2:30 and TD entry will remain at 3:00. If you update TD result afterwards, no matter how much it'll be, you'll get its entry with the same result as previous TD's, namely 2:30. But no complete fix exists today!

5. Dirtring Stat Disappearance Glitch

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: There is an exploit shown in

which lets the player complete Dirtring race with extremely low record times up to 0:00. But if a 0:00 record would be achieved, the stats entry for Dirtring will vanish forever from the save file.

Genesis: The game becomes stuck in contradiction. On the on side, 0:00 is the best possible record and therefore it can't be beaten. Ot he other side, 0:00 is nothing and shouln't be displayed at all.

Protection: If you would like to use this exploit you should collect all checkpoints with your own Sanchez except one that is closest to your mission Sanchez. After that, leave your own bike, push mission bike directly onto the last checkpoint and seat on it. You'll get a fine 0:01 record which will be shown perfectly in your stats.

Solution: No solution is known, but it's not so necessary. You better follow easy protection measures,

6. Havana Outfit Inaccessibility Glitch

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: The Cuban gang outfit is unlocked after the mission "Two Bit Hit". But after completing some other missions it becomes impossible to pick up because it teleports behind an invisible wall.

Genesis: All of the game missions that include changing Tommy's clothes relocate clothing pickups around the game map. Some of them, namely "Cop Land", "No Escape?" and "The Job" move the Havana Outfit pickup to unreachable area.

Protection: 3 abovementioned missions should be completed before completing "Two Bit Hit".

Solution: If you can't pickup Havana Outfit normally anymore, you can either exploit a bug shown in

to reach a pickup behind the invisible wall or use this fix which reverts the pickup to its normal place.

7. Hyman Stadium Events Change Glitch

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: There is a trick shown in

to complete the Hotring race easily. But this method has some consequences. Normally, the stadium events change every game day. If you spend enough time using this, e.g. the full race, the events won't change during the day when you save your game, only during game days that went without save.

Genesis: Likely because of Hotring script imperfection which makes the mission glitch when there are no opponents left.

Protection: Of course, you can ignore this way of completing Hotring and forget about best record times, but you'd better look straight to solution.

Solution: Easy as can be. Travel to Vice City Beach and then back to Vice City Mainland and the glitch will disappear.

8. Uncancelable Cheats Сonsequences

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: See GTA III's glitch #4. Not a typical glitch, but still worth mentioning. The "pedestrian hatred" (NOBODYLIKESME) and "pedestrian riot" (FIGHTFIGHTFIGHT) cheats have irreversible effects. If a player allows the game to be saved when any of these cheats are active then the effects of mentioned cheats will be impossible to switch off.

Genesis: Basically, these cheats were designed without possibility to be switched off.

Protection: Obviously, do not save when these cheats are on.

Solution: There is no known solution right now, but the protection measures are easy enough not to screw up your save file.

9. Zeroing Money Amount Issue

Class: Class I - Bypassable by certain gameplay method

Status: RESOLVED

Description: See GTA III's glitch #5. Again not a glitch, but a kind of game limit worth mentioning. GTA VC introduces a limit of $999 999 999 money amount, unlike GTA III. But still if you get a reward which together with your current money balance will exceed good old number of $2 147 483 647 you'll find out that you money amount quickly drops down to $0.

Genesis: The game still stores Tommy's money amount in an integer 4 byte variable. Now we can't have negative "debt" balance nor exceed our money over $999 999 999, but $2 147 483 647 is still secretly present as a restrictive number. So we can still get our fabulous "integer overflow" and screw up all the cash.

Protection: It's not easy to earn so big one-time rewards, but it's possible. Refrain from completing "Cone Crazy" more than 23 times, exceeding "Vigilante" mission level far over 390, outreaching "Taxi Driver" past some astronomical amount of fares and beating "Test Track" & "Trial by Dirt" races' records more than about 20 billion times.

Solution: If you somehow ended up without a single cent, use VC Savegame Editor to become rich again.

10. Mission Blending Problems

Class: Class I - Bypassable by certain gameplay method

Status: NO SOLUTON APPLICABLE

Description: See GTA III's glitch #6. Not a single glitch but the whole complicated system of different exploits and their consequences. Can break save files, so worth mentioning nevertheless. Never appears during normal gameplay. Used by speedrunners to complete several missions simultaneously and unique/rare vehicle (URV) collectors to acquire target vehicle from a mission. Generally, mission blending is a game exploit letting you to start two same or different missions at a time. Requires activating preliminary recorded replay of starting a rampage (rampage replay, RR), bying some property (asset replay, AR) or precise timing of some post-mission phone calls while starting another mission. The consequences can include saving mission blips on a radar, impossibility to start some missions or buy some property preventing 100% game completion, screwing up game stats or simple game crash depending on a specific blending method.

Genesis: Occurs due to multiple scripts conflicting with one another.

Protection: If you are performing mission blending you must have been gone far from a casual player level so consider doing everything at your own risk. Always backup your save files at every stage of the game to distinguish possible problems that may appear suddenly.

Solution: There is a huge variety of different blending strategies so there can be no specific solution. Just follow protection measures and hope that everything would be all right. Good luck.

P.S. You may notice absence of Class II glitches, which are "Forcing not to use some features".

It's okay since there are no of them in III & VC. For example, Class II glitch is avoiding to save

at Madd Dogg's mantion in SA to prevent basketball balls disappearance from game map.

P.P.S. All the glitches and issues described here are tested to take place in 1.0 and 1.1

PC retail versions of GTA III and GTA: VC respectively. I don't have such information

about PC digital download release on Steam, console versions and recent mobile ports.

Any additional information or help in resolving glitches will be highly appreciated!

Spasibo to 4emp2008 for his help in prepairing this topic!

Edited May 24, 2015 by AlSar

May 24, 2015

The beginning of subject discussion in GTA III Save File Editor topic:

AlSar's post:

AlSar, on 18 May 2015 - 01:15 AM, said:

thehambone

Hello and thank your very much for you work! It's never too late for such a useful tool.

I have one question partially concerning this topic. I think you can help me, because you're a person

who knows a lot about 3rd era GTA savefiles and their structure. But let's move closer to the point.

I prefer playing GTA at 60 FPS framerate. It can be achieved by turning frame limiter off while

using global V-Sync setting in video card driver control panel or using CLEO frame limiter script.

But the method doesn't matter here. Thing that matters is an effect of such gameplay.

When you reach roughly 2239 minutes of playing time (sligtly more than 37 hours) in GTA III and

about 84 hours in GTA: VC regardless of framerate a bug occurs. This bug takes effect only at 60 FPS.

The problem lies in breakdown of unique stunt jumps' camera. When you jump off the ramp, as usual,

the cinematic mode enables. But when you touch the ground back, cinematic camera remains enabled!

Moreover, game's clock freezes. Of course, it makes following gameplay absolutely impossible.

I figured out that this is directly linked only to the time spent in-game. The bug appears on every version

of III and VC and on every savefile made to abovementioned amounts of time respectively. I suppose this

happens because of some game timers mailfunction. So I looked for GTA III's save editor and found your work.

I tried to change values of "Global Timer" (GT onwards) and "Weather Timer" (WT onwards) respectively

to amount equivalent to 2000 minutes. I've got the following results:

— changing both GT and WT to equal numbers -> cinematic camera totally disappears

— changing GT only -> the same, no more cinematic view at all

— changing WT only -> no effect, cinematic camera is broken and doesn't switch off

So my question is: is it possible to fix that lousy bug using this save editor, any other tools,

maybe HEX editing? Any means of any difficulty will be okay. I prepare ultimate game start saves

(aka master-saves) and collect URV's (aka special vehicles) so I really need huge amount of gameplay

and it's absolutely impossible for me to fit full game completion in 37 hours.

Looking forward to any answers.

Yours, AlSar.

Militia's reply:

Militia, on 18 May 2015 - 01:56 AM, said:

Yes, it's possible. I can't give you details, but this stuff is 100% possible. I know others, even on PS2, and not PC, who had Traffic Glitches and problems in their SA Save File. They were able to hex edit the stuff to fix it by editing the Global Timers and what not. If it can be done on something more challenging as a PS2 Version, PC Version should be a walk in the park to get it fixed. It's not in my league, so I can't help you. But OrionSR and maybe even thehambone himself can help, but all this Modding stuff is out of my league and never tried doing any of it...

AlSar's 1st reply:

AlSar, on 18 May 2015 - 02:02 AM, said:

Militia

Thanks for giving more hope =) I know about traffic and taxi glitches in SA, there are fixes for that in good savefile editors.

You know, I don't use modding myself, but this can be considered fixing, adaptation or something like that.

The purpose is not to bring new features, but to restore normal gameplay features to original game.

OrionSR's 1st reply:

OrionSR, on 18 May 2015 - 02:40 AM, said:

We may want to spin this problem off to it's own topic. I doubt this tool is currently up to the task. After we have completed our research perhaps thehambone will want to integrate a fix into this tool but in the meantime the investigation and testing process is liable to clutter this conversation unnecessarily.

Your strategy of resetting the game clock by tweaking the variables in the save file is very similar to the Traffic Bug fix in San Andreas. This is a very complicated repair, something I have never attempted manually with a hex editor. In SA there are many hundreds of values that need to be adjusted for everything to work properly again. From memory:

Global and Weather timer
Wake up timers for active threads
Activity timers for pickups, car generators, and police trigger zones.
Similar timers in III or VC that I'm unfamiliar with
Global variables associated with game time

The global variables are the trickiest to track down. I suspect that this is where the problem is for the unique jump cameras in III and VC since these functions are part of the script (the USJs are integrated in SA, and aren't effected by timers). Any repairs to global variables may be inappropriate for saves created with modified scripts.

I suggest starting by resetting the global and weather timers to a very low value, and then manually adjusting the wakeup timers for threads to get the save back to somewhat normal functioning. In SA, everything that is controlled by the scripts, including the MAIN thread, will be stuck in a WAIT loop (I think wait 250 sets the wake timer of that thread to the global timer plus 250 milliseconds).

Look for problems with pickups, cargens, and police triggers; use pickups and cargens, activate the police triggers, cause peds to drop stuff, then look for what happens if you don't reset their variables. This is intended as a learning process, but also verification that what I know from SA applies to III and VC.

Read through the USJ section of the scripts and see if you can find how it uses the game clock; look first for global variables that record the game time, but... I am not very familiar with the scripts of III and VC. I'm not really sure what to look for. The idea is to see if your strategy will work on a handful of jumps before worrying about the bugs introduced by your fix.

GTASnP has recently upgraded to handle glitch repairs for SA, including the traffic fix. If we can document the process properly there's a reasonably good chance we can talk him into adding a repair on his list of services.

thehambone's reply:

thehambone, on 18 May 2015 - 04:46 AM, said:

I've always heard of issues occurring if you're running your game above 30fps with these older GTAs. This is quite an interesting bug. The fact that the game is running at twice the normal number of frames probably causes the timers to climb super high much earlier than they would under normal conditions.
I would follow the steps that OrionSR suggested, that is, tweaking timer values. I can assist you with this task if you'd like.

OrionSR's 2nd reply:

OrionSR, on 18 May 2015 - 09:41 AM, said:

A quick review of the USJ script did not turn up any variables that rely on in-game timers. I suspect that editing the GT, WT, and thread wake up timers, will provide a good test save to see if this fix might help.

I am puzzled that the game is struggling. I don't see anything in the script that would suggest a problem. I'm wondering if expanding the radius of the jumps might allow the game to discover that the player is within the correct coordinates. Modified scripts is not a good solution but might provide a few clues to where the problem lies. As long as you are experimenting with a modified main, consider adding text messages to each stage of the jump as a strategy for isolating the problem. (Added: This would probably need to be a new save test as any changes to active threads usually results in an immediate crash.)

Another strategy that might be a less destructive solution is to modify your cleo frame limiter script to detect when a unique jump is in progress and limit the frame rate to 30 FPS until the jump is complete. A quick search through the III scripts shows that the game speed is always 1.0 unless a USJ is in progress, then it is set to 0.25. You might be able to tease a jump in progress global variable out of the control variables used in the USJ thread but nothing obvious jumped out at me. In VC the gamespeed is always 1.0 except it is set to 0.3 during USJs and some parts of the Stunt Boat Challenge - I can't remember the details of this mission.

My thought is, limit the frame rate when the game speed is less than 0.33 and use the same script for both games. This strategy is based on a crude understanding of early patches for problems with dancing and lowrider challenges in the PC version of SA. If game speed is not well documented in memory then it should be easy to isolate by seeding a unique float into the time scale value in the save file.

From the GTA III Save Wiki

0x006C float time scale (opcode 051D)

I strongly suspect that the opcode listed above should be 015D: set_gamespeed 0.25, but this should probably be verified before making the correction. However, there is no opcode listed for 051D so I'm pretty confident that this is a typographical error.

I'm not sure what to suggest for the V-sync strategy.

________________________ Added Notes ________________________

Keep an eye on the globals shown below in III. Other uses of 00BF are always to $65 and $66. These two should always be read just before use. What you need to watch for are occasions where these values are recorded elsewhere. A quick search did not find anything obvious. Edit: I don't think this is an issue. IIRC, it was 01BD that is directly tied to the global timer and is the most concern for resetting the clock.

00BF: $2451 = current_time_hours, $2452 = current_time_minutes

It looks like the police trigger zones are not integrated into the engine on III or VC. Are they disabled on a save with the global and weather timers reset but the threads left asleep? Police Trigger: Usually, police shooting out of nowhere in response to the player entering a certain area with a wanted level. It's always the same number of cars in the same spot, which is different from the random spawns that escalate to Swat, FIB, and Army.

Are there other issues associated with very large global timer values in III or VC? Perhaps a timer reset strategy would have other uses. Seeding larger GT and WT values doesn't usually have the adverse effects on wake timers and timestamps that a lower value does. Seeding a unique value into the GT of a save and re-saving might make it easier to identify unknown timers. Search for the upper word in the global timer dword as the lower bits will vary.

Resetting the global and weather timers to a low value is a useful strategy for disabling all threads. I have used this strategy to isolate save problems to data file compatibility (you can basically load damn near any screwed up save), and then reset the wake timers one at a time to find a problem thread. You can kill active missions saved by little brothers using a save anywhere mod and then undo the timers to have a working save (maybe delete some blips or mission objects). If missing objects are causing a crash you can at least go to the area and look for the object.

I don't know why the repair tools tweak the local timers of active threads. My best guess is that pdescobar thought there might be problems and included this tweak in his early repair tool and everyone else followed suit without checking if it really matters. I know pdescobar to have had an over-engineer philosophy. But if you are doing manual edits you might be able to get away with skipping the local timers.

I'm going to be really busy with work for the new few weeks and I probably won't be able to contribute anything of substance. Good luck. I'm piling on the notes somewhat out of context while I've got the time.

010 Editor - It's not really all that expensive. If you are really into save editing it is an extremely powerful tool you should consider. I've barely started to learn how to use the extensive feature set. The primary reason I got the 010 Editor was to take advantage of the gta save templates produced by Seemann. These templates can break down the structure of the saves and display the information in a much more useful form. Look for links at the end of each save wiki.

$CURRENT_TIME_IN_MS = This value may be used to prevent the player from being interrupted by phone calls too quickly after a mission has ended. If it isn't reset the calls will be disabled but this can easily be fixed by triggering any mission. I may be wrong on the specific variable. I'm too tired to follow through but I know this value is hidden in SA and suspect it is included in VC and III. You should probably look for other instances of 01BD associated with global variables. Added: In SA there may be problems with eating fast food if the timers are reset within 3 hours (iirc) after eating.

AlSar's 2nd reply:

AlSar, on 22 May 2015 - 9:18 PM, said:

OrionSR

thehambone

Thank you very much for your attention. Sorry for answering so late, but this massive amount of unknown

technical information in foreign language makes notable difficulties for me to understand. I've had to read it,

manually translate into Russian and read again over and over.

As OrionSR suggested, we'd better fork this discussion to a new topic. It would serve as a place

to find and solve savefile bugs in GTA III and VC, respectively, like OrionSR's famous topic about SA.

I already plan to describe several known bugs there.

thehambone, your help in studiing these issues will be highly appreciated, because I don't have necessary

amount of knowledge at all. So you'll be a welcome guest in my new topic.

I'll create it soon and give a link here, as I'll formulate and prepare my post.

UPDATE

The topic is created, everybody are welcome HERE.

Edited May 24, 2015 by 4emp2008

May 24, 2015

OrionSR

thehambone

Continuing our discussion here, I must clear that I don't have much experience in GTA modding, only basic knowledge about Renderware engine of III, VC and SA. I've worked with IMG modding back to 2006-2008, some TXD and GXT editing, DATA folder tweaking and something like that. I've never worked with scripting, save editing and this stuff. The only programming languages I know are Pascal (barely Delphi) and Basic (barely VBA) and GTA scripts don't look like them absolutely. So I don't have required knowledge to deal with this task myself. 4emp2008 has similar situation here. I realize that I have to learn GTA scripting from scratch, but unfortunately, I don't have enough free time now beause I'm working on my diploma work as I'm going to graduate from the university soon.

Speaking about the subject, 4emp2008 and I tried to make maximum amount of checks and to give as many details as possible for specialists to understand where all these problems lie. So now we can only hope that skillful people can help us and many other 3rd era GTA players to play theit favourite games in the manner they've meant to be played.

2All

The main idea of this topic is to develop a fix for III & VC's timer problems. According to OP, they are:

GTA III

1. Unique Stunt Jump Camera Freezing Glitch

2. Game Speedup Glitch

GTA VC

1. Unique Stunt Jump Camera Speedup Glitch

2. Unique Stunt Jump Camera Freezing Glitch

3. Game Speedup Glitch

Here are some save files to test abovemetioned timer issues.

GTA III. Before and after 1st "glitch time" - 37:17
Before After

GTA VC. Before and after 1st "glitch time" - 18:39
Before After

GTA VC. Before and after 2nd "glitch time" - 37:17
Before After

GTA VC. Before and after 3rd "glitch time" - 74:34
Before After

Hope that will provide some help in research.

Other glitches documented here are common knowledge of Russian GTA Community and are described purely for completeness and reference. The final goal of this topic is to become a complete list of bugs and their fixes in III & VC save files like OrionSR's famous topic about SA.

Edited May 24, 2015 by AlSar

May 24, 2015

I have some time off tomorrow and the day after and I would like to attempt a few edits to test resetting the timers on III like we did in SA. Please suggest a III save for this test. Something with both camera freeze and speed up glitches would be a good starting point.

Plan:

Reset global and weather timers to 0
Reset all thread wake timers to 0
Recalculate checksum-32 at end of file

From now onward, assume that the checksum is always fixed anytime a save is edited.

This plan ignores problems with the timers of pickups and car generators. We can work out those details after we know that the plan should work. I see three good options for making a complete repair. 1) I think that the 010 editor might be able to make a complete repair. This option won't transfer to people without the 010 editor. 2) Samutz at GTASnP already has experience with this repair on SA and may be able to adapt the procedure for III and VC. 3) thehambone may want to include this fix in his III editor, but I'm not sure how quickly this tool can be adapted.

Do these glitches occur if you set the GT and WT of a new save to a value that should cause the glitch? Yes

Are any of these issues addressed by the SilentPatch for III or VC? Maybe

Please use GTASnP for save file transfers.

Test Save 1 and 2 are modified version of the After saves for III posted above by AlSar. Please test if the problems are fixed. Test save 3 doesn't really serve a purpose at this time.

Test Save 1 - GT, WT, and Wake Timers set to 0

Test Save 2 - save as above but local timers also reset to 0

Test Save 3 - New game with GT and WT increase to 600,000,000 using ham's III editor.

Purple Nines Glitch - "playing new game after GTA III's installation from scratch"

If this glitch works the way carryover glitches work in SA then it should not be necessary to uninstall GTA III from Windows and to reinstall from scratch. The key factor is to avoid loading old saves before starting a new game. PS2 versions usually load the most recent save automatically so the glitches tend to get a reputations for persistence. On PC, quit the current session, start the game and selet Start New Game from the menu options. PS2 players should pull all memory cards that contain saves.

How does the Staunton Island to Shoreside Vale bridge work in III? I remember that in LCS that once the bridge was started, either by loading a late-game save or triggering the See the Sights side-mission, it tended to keep working but I don't remember if I had to trigger it once per session or if the setting persisted in the save.

Observations: I'm a bit lost in III, it's been a very long time since I have played. I loaded test save 3 from above and did not notice anything unusual at 600M milliseconds. Increasing the GT and WT to between 800M and 1100M eventually lead to freezing issues during the fade-in after loading the save - an issue I noticed in the SilentPatch topic. Turning the frame limit off lead to freezing issues on test save 3.

I have observed the USJ camera glitch at 600M from test save 3 on a standard game (plus cleo) when the frame limiter is on.

I can load test save 3 if the frame limiter is on, but not when it is off. If I disable the frame limiter after loading the same the game clock freezes, pickups don't rotate, vehicles don't move, and my coordinate script for cleo does not update. The wheels on the vehicles continue to spin in place, and some newspapers rotate on the ground. I did notice the vehicle suddenly jump ahead a short distance.

Resent observations of SA's timer issue indicate that system performance contributes heavily to the severity of the glitches. Have you tested your observations on different systems - are the tests repeatable?

Edited May 25, 2015 by OrionSR

May 24, 2015

Here are some save files to test abovemetioned timer issues.

GTA III. Before and after 1st "glitch time" - 37:17

Before After

GTA VC. Before and after 1st "glitch time" - 18:39

Before After

GTA VC. Before and after 2nd "glitch time" - 37:17

Before After

GTA VC. Before and after 3rd "glitch time" - 74:34

Before After

Hope that will provide some help in research.

Perfect, thank you!

3) thehambone may want to include this fix in his III editor, but I'm not sure how quickly this tool can be adapted.

Yeah, I can definitely add these glitch fixes into my editor. It shouldn't take too long. I'm currently re-working the I/O functionality to make it more adaptable to other games (in case I decide to make other editors), as well as adding iOS/Android support. I can always release an update with the added glitch-fix features before releasing the aforementioned update, however.

How does the Staunton Island to Shoreside Vale bridge work in III? I remember that in LCS that once the bridge was started, either by loading a late-game save or triggering the See the Sights side-mission, it tended to keep working but I don't remember if I had to trigger it once per session or if the setting persisted in the save.

Not too sure what you mean by this. Do you mean the lifting motion? AFAIK, the bridge doesn't budge until after you complete A Drop in the Ocean for Donald Love. Going to Shoreside early doesn't trigger the bridge to move.

I can get to work on these saves today and tomorrow (Monday), as I am off work.

Edited May 24, 2015 by thehambone

May 24, 2015

Test Save 4 - New Game with GT and WT set to 1073600000 will freeze in 2 minutes and 21 seconds at game time 16:20 with frame limiter on.

I can cut it a bit closer. 1073737373 will freeze after about 4 seconds mid-fade and leaves an imprint of the previous image on a playable game screen. If I cut it much closer it will freeze too soon to see anything. The test save should provide plenty of time to make observations before the freeze. The game is somewhat playable when after the freeze. The player can move around, drive, and fight with peds that are still walking around. I notice a camera freeze I think was associated with exiting a vehicle.

Test Save 5 - New game with GT and WT set to 536800000 will display jittery traffic after about 1 minute and 9 seconds at 15:28 with frame limiter on. The game clock will freeze at 15:27 if the frame limiter is off.

During my experiments to determine ranges for the glitches on a standard game I noticed the same "jittery traffic" issue observed with too much game time in SA and attempted narrow in on when this occurs. I am quite impressed by the accuracy of your measurements and predictions. These appear to be very distinct changes at a specific time. In SA I always thought this was a gradual glitch that got worse over time. Perhaps I should retest that hypothesis.

Jittery traffic can easily be observed by driving parallel to another vehicle along a road without turns or traffic lights. Or park or stand next to a road and look directly across without looking up and down the road (vehicles can spawn and unspawn nearer and more quickly).

034B: staunton_complete

Executing the code above within a cleo script immediately started the draw cycle of the bridge between Staunton and Shoreside Vale. I am unsure of what else might be effected by this code or where the setting is stored, although I suspect it can be found in the save file. My best guess would be in the stats block (yep, offset 0x00CC). This is a bit off topic since carryover doesn't appear to be a factor. Perhaps we should continue this discussion in your III save doc topic.

Test Save 6 - GT and WT set to 268300000. Game clock will freeze in 2 minutes 15 seconds at 16:32 if a USJ is in progress if the frame limiter is on, and goes into the game speedup glitch if the frame limiter is off (not tested during a USJ). I reloaded the save and used a cleo save script to save at 16:32. The global timer on that save is set to 268435392.

I think this is about as precise as I can get. The strategy was to continuously update the current time in milliseconds to the screen and have it freeze when the cleo script hung along with everything else. This particular value, 268435456, 0x10000000, turned up most often.

// FXT: GTIME Global Timer = ~1~ milliseconds{$CLEO}0000:while true    wait 1    01BD: [email protected] = current_time_in_ms     01E5: text_1number_highpriority 'GTIME' [email protected] 1 ms 1  end

Test Save 7 - GT and WT set to 13415772. With frame limiter off the clock will freeze during a USJ in 59 seconds. Target time was 12:00 but it usually came up a bit short at 11:59 with a GT of 134217728, 0x08000000.

I suppose I could go back and take readings for the glitches at higher global timer values but you already found the doubling factor so at this point I'm pretty sure we are looking at 536870912 (0x20000000) and 1073741824 (0x40000000).

Summary: OFF and ON indicate the frame limiter setting on a standard game.

Hexadecimal  Milliseconds  Hours      USJ Freeze  Speedup/Jitter  Clock Freeze0x08000000      134217728   37.2827   OFF		0x10000000      268435456   74.5654   ON          OFF (speedup)	0x20000000      536870912  149.1308               ON  (jitter)    OFF0x40000000     1073741824  298.2616                               ON

Additional Comments:

Vehicles that freeze with the game clock with become unstuck if they are bumped by the player or another moving vehicle. It appears that vehicles that spawn off-screen don't become frozen until they become visible - maybe. The game isn't completely stuck. Sometimes the stuck vehicles will jump a short distance; during this time the GT increases a small amount, and my cleo scripts can update. The time spurts appear to be random, but I did notice that the act of taking a screenshot will cause a small increase in time.

Edited May 25, 2015 by OrionSR

May 25, 2015

I did some tests with the GTA III save and can confirm that with the frame limiter option being turned off the game behaviour is very odd. The camera is moving the way slower (not only the USJ camera, but during usual vehicle movement it's also slower). Also I saw how multiple vehicles (about ten or close to this number) were spawned at one time at one point, what a mess. Probably it is the "jittery traffic" glitch described by OrionSR. But I'm a bit curious what a reason for such behaviour. You guys may know better, what should I check in the exe at first?

Executing the code above within a cleo script immediately started the draw cycle of the bridge between Staunton and Shoreside Vale. I am unsure of what else might be effected by this code

034B: staunton_complete affects the bridge and tunnel traffic between Staunton and Shoreside islands, news headlines and no criminal rating limit (otherwise it can't be higher than 4552). Nothing special at all. Also the game plays an audio announcement on the radio about the bridge operating again once the opcode is executed.

Purple Nine Glitch was explained here.

Edited May 25, 2015 by Seemann

May 25, 2015

Purple Nines Glitch - "playing new game after GTA III's installation from scratch"

If this glitch works the way carryover glitches work in SA then it should not be necessary to uninstall GTA III from Windows and to reinstall from scratch. The key factor is to avoid loading old saves before starting a new game. PS2 versions usually load the most recent save automatically so the glitches tend to get a reputations for persistence. On PC, quit the current session, start the game and selet Start New Game from the menu options. PS2 players should pull all memory cards that contain saves.

Indeed, this is the reason. Those variables are not being reset on game reinit, so they carry over from the previous session. SilentPatch corrects this by making those vars reset, but yeah, broken saves can only be fixed by editing.

May 25, 2015

what should I check in the exe at first?

I'm sorry. No one seems to have any idea what's going on. This investigation has provided a lot more clues, and is giving much more concrete examples than we ever had in SA.

All timer issues are tied directly to the global timer. (old news in SA, confirmed in III, observed in VC)
All edits to the timers of weather, threads, and timestamps are to repair glitches introduced by changing the global timer. (old news)
Glitches escalate at significant hex values. (How could that be tied to the expected issues with floating point values?)
Frame limiter has a direct effect on the level of the glitch.
Jittery traffic and clock speedup may be different forms of the same glitch.
Game speed appears to escalate the glitch significantly. (III USJs = 0.25, VC = 0.3)
- I want to test game speed independently of the USJs
- If 0.33 escalates the glitch by a factor of two, maybe other factors are possible
- Maybe the glitch can be deescalated by high game speeds
Taking a screenshot causes the clock to sputter. (Alt-PrtScn - a Windows function)
- Maybe rather than fix the problem we can uncork it on the other end (video capture?)

Is the 010 Editor's script feature up to the task of quickly resetting all the of timers? I don't see any point in putting a lot of effort into a proprietary strategy but if it's an easy process it would be nice to run a complete test before submitting the repair for implementation in save editors or GTASnP.

Does anyone have a really old III save I can use for testing?

Added:

Limited testing with game speed adjustment implemented with cleo scripts.

Note that a speed of 0.24 has the same influence as 0.125. There appears to be a direct correlation with factors of two.

//Clock Freeze With Frame Limiter OnHexadecimal  Milliseconds   Hours   Game Speed 0x08000000     134217728   37.28   0.125 0x10000000     268435456   74.56   0.25	 0x20000000     536870912  149.13   0.5 0x40000000    1073741824  298.26   1.0//Clock Freeze With Frame Limiter OffHexadecimal  Milliseconds   Hours   Game Speed 0x08000000     134217728   37.28   0.25 0x10000000     268435456   74.56   0.5	 0x20000000     536870912  149.13   1.0 0x40000000    1073741824  298.26   2.0

Edited May 25, 2015 by OrionSR

May 25, 2015

Is the 010 Editor's script feature up to the task of quickly resetting all the of timers?

A quick answer is yes, can't see any reason why not.

I'm diggin into the exe playing with your Test Save 6, and game issues are easily reproducible when the frame limiter is off. Traffic vehicles does not move and game time ticks rarely. Everything is looking smooth when the FL is on, though.

Note that a speed of 0.24 has the same influence as 0.125. There appears to be a direct correlation with factors of two.

There appears to be a limit for floating-point values for scripts in GTA III. Oddly GTA III uses only 2 bytes for them, and the remainder value is rounded (by dividing by 16). So, you cant compile a value of 0.24, you will get 0.1875

Unsorted facts:

The MADWEATHER cheat effect is that the game adds one minute per frame, not per second (=> much faster time).

The global timer can be increased maximum by 60 ms per frame. Normally the game performs rendering much faster, but there can be lags on slow machines. The timer is increased by 0 ms while in menu.

008E2CB4 : CTimer::ms_fTimeStep is the time multiplier used everywhere around the code. I don't get its exact meaning, but it seems to be a very vital value. From my POV it's a frame delta time - the time interval passed between the current and the previous frames. It's always equal to ~1,66 when the FL is on, and ~0,2 when it's off.

This value is saved in a savefile (@Block 0: 0x0070). However it's always = 0 as you're saving from the main menu where time does not advance (see above).

Edited May 25, 2015 by Seemann

May 25, 2015

Firstly, I'd like to thank everybody for paying so active attention to my topic.

Not being an expert in all this stuff, I don't have much to add, but I can still say something.

Please suggest a III save for this test.

Does anyone have a really old III save I can use for testing?

I asked all our community and have found the oldest save we have. Here it is.

A pretty old GTAman's 100% with Dodo flight world record as of 2010 - 100 000 secs.

It has 57:07 of overall time spent in-game, which is 205 649 680 msecs.

Unfortunately, we don't have even a 74:34 save, of course nothing even more.

Please use GTASnP for save file transfers.

I used cloud service here, because GTASnP has limited storage time, and MediaFire offers eternal storage.

Usually I use some Russian cloud services as YandexDisk or Mail.Ru Cloud, but I registered a MediaFire account

now especially for English-speaking audience not to be confused with Russian interface of local cloud services.

I think the exploration could take quite a time and by its end the main saves may be already removed from GTASnP.

Speaking about other test saves I'm going to share (if I can help in something), I'll use GTASnP, of course.

saves for III posted above by AlSar

Perfect, thank you!

We tried to make as much research as we can by observing in-game effects and making some conclusions.

But I should say that you should thank 4emp2008 here, because all of these are his own saves.

Purple Nines Glitch

If this glitch works the way carryover glitches work in SA

Purple Nine Glitch was explained here.

Indeed, this is the reason.

Thank you for additional info about Purple Nines Glitch but it's not a problem now.

I just briefly described it for the sake of OP's fullness. Please, focus on timer problems.

How does the Staunton Island to Shoreside Vale bridge work in III?

A lifting section is blocked until completing Love's "A Drop In The Ocean". More info here.

But if you want to go to Shoreside at the beginning of a game, use Porter Tunnel. No need to unlock

Shoreside Bridge using script modding. Staunton-Shoreside section of tunnel is open. There is only

a wall blocking access from Portland's side. Later a wall blocks access to Shoreside, after Staunton is opened.

For easiest transportation methods you can watch

.

I can load test save 3 if the frame limiter is on, but not when it is off

If I disable the frame limiter after loading the same the game clock freezes

4emp2008 told me he remembered about such stuff. It's the 3rd phase of timer issues, to my mind.

He is familiar with this, he confronted the bug in VC. This time is impossible to achieve in any gameplay.

Even all master-save, URV and record-making stuff won't take such a heap of time.

I'll surely add this bug to OP and describe it later.

Have you tested your observations on different systems - are the tests repeatable?

The tests were made on 3 machines - 4emp's PC (weak), 4emp's laptop (below average)

and my PC (fairly good). I can give you detailed hardware specs if you want, but

all machines exceed both III and VC's minimum and recommended requirements, of course.

All the tests had similar results and discovered times described in the OP.

Yeah, I can definitely add these glitch fixes into my editor.

That would be absolutely great. And even more greater than great if online fixing would be available at GTASnP.

in case I decide to make other editors

Maybe you'll think about cooperating with VC & SA save file editor's developers to make a universal tool?

Such a tool which can edit all the 3rd era saves and fix bugs. Mobile support would be a fine feature too.

I noticed the same "jittery traffic" issue

I described exactly this effect as III's #2 glitch and VC's #3 glitch.

I am quite impressed by the accuracy of your measurements and predictions

Thank you. Pure empirical experiments and engineering logic.

I've even built a function graph, it's simple linear dependance.

These appear to be very distinct changes at a specific time.

I used the term "discrete" describing these effects.

In SA I always thought this was a gradual glitch that got worse over time. Perhaps I should retest that hypothesis.

For now I'm pretty sure that it is III's #2 and VC's #3 glitch. Consider testing at 74:34 for 60 fps and 149:08 for 30 fps.

Early phases seem not to appear in SA because of its new USJ mechanism not relaying on game timers.

I'm pretty sure we are looking at 536870912 (0x20000000) and 1073741824 (0x40000000).

Oh, great! I couldn't understand a logic in my measurements. They were not 2^x nor smooth decimal numbers

of whole integer type (like millions, billions and so on). You discovered that they're "smooth" in hex!

with the frame limiter option being turned off the game behaviour is very odd.

Frame limiter has a direct effect on the level of the glitch.

Everything is looking smooth when the FL is on, though.

I bet the frame limiter itself doesn't matter. It's FPS amount that matters here.

Playing at 60 FPS may be unfamiliar to somebody but it's absolutely normal

before glitches start appearing. Namely 37:17 in III and 18:39 in VC.

I discovered 60 FPS GTA gameplay back in 2008 and smoother graphics is a great benefit.

It's simply unpleasant for me now to observe 30 FPS gameplay, it looks like lagging.

And speaking about these glitches, 60 fps makes them appear roughly 2 times faster than 30.

I think making the game run at 120 fps will cause screwing up 4 times faster.

Similarly, if you make a limit of 15 fps you'll apparently get 2 times slower problems.

multiple vehicles (about ten or close to this number) were spawned at one time at one point

Did It happen after leaving Staunton safehouse? It's a common bug there.

But I'm a bit curious what a reason for such behaviour.

Speaking about me, all my thoughts are already described in detail in III's #1-2 and VC's #1-3 sections of the OP.

is giving much more concrete examples than we ever had in SA.

I tried my best to provide all the information I could.

Jittery traffic and clock speedup may be different forms of the same glitch.

I strongly beleive all these effects to be phases of a single timer glitch system.

Game speed appears to escalate the glitch significantly.

I think it's a dependance in inverse ratio here.

USJ is 4 times slower than normal game, glitch happens 4 times faster there in III.

If USJ speed is 0.3 in VC then VC's ratio should be 3.33, not 4.

If 0.33 escalates the glitch by a factor of two, maybe other factors are possible

It seems that a factor of 2 is a kind of a constant here.

Note that a speed of 0.24 has the same influence as 0.125.

Discrete changes, proved one more time.

The MADWEATHER cheat effect is that the game adds one minute per frame

I had similar thoughts. The game cheats linked to game speed, namely TIMEFLIESWHENYOU

(4x speed) and BOOOOORING (0.25x speed, 5 O's) and already mentioned MADWEATHER in III.

VC analogs are ONSPEED (4x speed), BOOOOOORING (0.25x speed, 6 O's) and LIFEISPASSINGMEBY.

UPDATE

From my POV it's a frame delta time - the time interval passed between the current and

the previous frames. It's always equal to ~1,66 when the FL is on, and ~0,2 when it's off.

This value is saved in a savefile (@Block 0: 0x0070). However it's always = 0 as you're

saving from the main menu where time does not advance (see above).

You mean that FL doesn't simply change FPS level? Then it's likely that I've made a mistake

stating that it is nothing to do about FL and everything is affected only by FPS.

I use CLEO Frame Limiter by ThirteenAG for playing. It makes available setting FL to on

and still getting 60 fps. Here is the link. In previous discussion in thehambone's topic

OrionSR suggested modifying this script to limit frames to 30 during USJ's.

I'll contact ThirteenAG about this question. In can work as a temporary solution.

I can load test save 3 if the frame limiter is on, but not when it is off
If I disable the frame limiter after loading the same the game clock freezes

4emp2008 reports that this is the same situation he has encountered in VC.

Moreover, the save file refuses to load with FL off, but FL on with CLEO

(thus still getting 60 fps) made it work. FL status matters, proved one more time.

Edited May 25, 2015 by AlSar

May 25, 2015

Okay..., so the III USJ game speed setting of 0.25 may have originally been 0.3 as in VC but this was lost during compilation. With that in mind, let me restate my hypothesis.

Unconfirmed: Any game speed setting that is equal to or greater than 0.5 and less than 1.0 will have the same influence on these timer glitches. A similar pattern is expected for the ranges of >= 0.25 and < 0.5, etc. My observations appear to support this hypothesis but they are incomplete and lacked specific information.

Max 60ms per frame: Does that mean we don't need to achieve 120 FPS to check for another level of the glitch?

0 ms in Menu: But yet a low game speed will still slow the menu animation.

What are the potential effects of not resetting the local timers of active threads?

May 26, 2015

the III USJ game speed setting of 0.25 may have originally been 0.3 as in VC but this was lost during compilation

Speaking only about gameplay feelings, slow-motion factor in III and VC looks the same for me.

we don't need to achieve 120 FPS to check for another level of the glitch

Frankly, I don't know how to achieve 120 fps in GTA III. VC's FL setting to OFF makes the game run at

maximum amount of fps that a PC can render, then you can limit your frames to 120 using V-Sync setup

in video card driver settings. In SA disabling FL will result in 60 fps but there is a FPS De-Limiter CLEO script

which removes this cap and you may act the same way as in VC. III's FL switching off results in rough 60 fps.

And I don't know any ways to override it.

P.S. 4emp2008 tenders his apologizes for not participating in our discussion.

But he's bad with English, so I have to represent his opinion as well.

Edited May 26, 2015 by AlSar

May 26, 2015

If USJ speed is 0.3 in VC then VC's ratio should be 3.33, not 4.

Please note that some of my early references to game speed during jumps were incorrect, but have been quoted so now I'm reluctant to update the info. The USJ game speeds decompiled by Sanny are 0.25 for III and 0.3 for VC. Please ignore any other values. I expect 0.3 to fall within the glitch range of >= 2.5 and < 5.0. I predict that "ratios" must be factors or multiples of 2. This should be confirmed.

There is a large difference between the feel of game play at game speeds set with cleo to 0.24 (Seemann warns that this will compile to 0.1875) or 0.125, yet the clock still hangs at the same millisecond.

I asked all our community and have found the oldest save we have. Here it is.

A pretty old GTAman's 100% with Dodo flight world record as of 2010 - 100 000 secs.

It has 57:07 of overall time spent in-game, which is 205 649 680 msecs.

Unfortunately, we don't have even a 74:34 save, of course nothing even more.

If I try to repair this save as it is, would it provide more information than what is available in test saves 1 or 2?

How confident would your community feel if this Old Dodo save was artificially inflated to 74 hours, played with for a while, and then repaired when things got really bad? Or if you would prefer a purely natural glitch, it shouldn't be too difficult to tack on another 17 hours of game time idling in a safe location. Ether way, before things get too glitchy, I would like for someone on your team to create specific glitches so you'll know what to look for and where to look for it.

Use lots of parked car generators. Move away from the area and try not to return.
Use some but not all respawning pickups like weapons, health, armor, and bribes. Move away from the area and do not return.
Cause pedestrians or the environment to drop money or weapons. If it spins like a pickup then it is a pickup. Move away before they despawn.
Trigger any side activities or ambient events that might be tied to a timer. Try everything, but don't worry about finishing or winning.

The order of tasks in not important. Please come up with a good plan to leave potential problems where you can find them. My first attempt at a repair should leave problems with pickups not spawning or unspawning as they should and used car generators that refuse to spawn. Experience identifying known glitches should help with the evaluation of a complete repair.

Old Dodo - (Sweet! Nice touch, Samutz) This save is the oldest save you posted above with the global timer increased to 267715456, 12 minutes before the speedup glitch kicks in for frame limiter off and USJs freeze the game clock with frame limiter on. This should allow plenty of time to introduce potential glitches. The game time was adjusted so the glitches should kick in at midnight. The save name was modified to denote this as a special test save.

I won't have time for more experiments for a while. I'm going to try to wrap things up with III by bringing Samutz at GTASnP up to speed on the latest developments.

I'm not sure how I can contribute to the investigation of VC. I no longer have a working copy of the game.

No need to unlock Shoreside Bridge using script modding.

You don't understand. I must know these things, how to control them, and where this information is recorded in the save file. Also, I will take any steps I feel necessary when crafting saves for testing - these will be declared. I intend to manipulate all of the barriers and unlockables eventually. No hurry for now though. I'm wondering if there are any other effects of the Commercial Complete opcode, or known effects of the Industrial and Suburban Completion opocdes, but these questions are a bit off-topic.

If we ask nicely there's a reasonably good chance that Samutz will provide permanent hosting for any saves that we need to keep available. Most of the test saves I've posted are really easy to recreate using ham's editor. so hardly worthy of retention.

Please run some tests of Test Save 2. This is 4emp2008's III After save with GT, WT, and thread wakeup and local timers reset to 0 (over 160 manual edits - someone should at least look at it). With this fix the game should no longer freeze during a USJ if the frame limiter is disabled. I expect problems with pickups and cargens but I'm not sure where to look for something used or dropped recently.

Edited May 26, 2015 by OrionSR

May 26, 2015

Hey guys, some things came up today so I didn't have too much time to look into this issue. I did gather a few findings, although nothing that hasn't already been posted in this topic, unfortunately. I'll keep trying though!

Like OrionSR mentioned in a previous post, I noticed that Print-Screen advances the stuck GT a few ticks. I actually managed to mess up my camera by pressing it a few times (screens below). It definitely appears that this GT bug really has a large impact on gameplay, as it causes everything to freeze up. I've noticed that it's impossible to exit a car one the GT locks up.

I've attempted to tweak with the timescale and time step fields in the save files but the changes that I make don't seem to have any effect once the game is loaded. Similarly, saving the game with the timescale set to anything but 1.0 will write that value to the save file, but the game will always load back up with a normal timescale. This may be a discussion better suited for the save doc topic, but I figured I'd mention it here.

I suppose the next thing I should do is look into the script timers and see if I can tweak those to reverse/prevent the affects of the GT bug.

Buggy camera screens:

I'm driving the Bobcat in this image.

Edited May 26, 2015 by thehambone

May 26, 2015

P.S. 4emp2008 tenders his apologizes for not participating in our discussion.

But he's bad with English, so I have to represent his opinion as well.

I am also here, but not participating in the discussion. I know English, but I do NOT know this stuff you guys are talking about. But it always interests me to read up on it. So I am here, just in the background!

Good work guys...You are genius'!

May 26, 2015

The USJ game speeds decompiled by Sanny are 0.25 for III and 0.3 for VC. Please ignore any other values.

Ok, but I already took right these numbers into consideration.

I predict that "ratios" must be factors or multiples of 2. This should be confirmed.

Apparently all of these is caused by rounding deflections.

There is a large difference between the feel of game play

Maybe, but I was saying that only about USJ feel in unmodded III & VC.

If I try to repair this save as it is, would it provide more information than what is available in test saves 1 or 2?

Hmm, I don't know for sure. You asked about the oldest save, so I tried to find the oldest avalable to me.

How confident would your community feel if this Old Dodo save was artificially inflated to 74 hours

GTAman (aka V-Nine), who is the author of the save, gives his permission to do anything you need to do with his save file.

Or if you would prefer a purely natural glitch

For now, that doesn't really matter. We want to contribute as much as we can considering our limited knowledge.

The final goal is the update of thehambone's editor, which would allow to make fixes of "natural" saves.

Until that moment, it's absolutely OK to make any artificial changes needed for the sake of research and

for achieving the final goal mentioned above.

I would like for someone on your team to create specific glitches

This should allow plenty of time to introduce potential glitches.

The save name was modified to denote this as a special test save.

OK, you want somebody to use that "Old Dodo" modified save to cause some pickup trouble

and other mentioned things? No problem, I think 4emp2008 will easily deal with the task.

He'll prepare a new save based on this one and upload it to GTASnP.

I'm not sure how I can contribute to the investigation of VC. I no longer have a working copy of the game.

I think I can help with this. Details in PM.

You don't understand. I must know these things

I will take any steps I feel necessary when crafting saves for testing

Sorry, my fault. I thought that you had trouble getting to Shoreside at the beginning of the game.

Samutz will provide permanent hosting for any saves that we need to keep available

It seems like for now no uploaded saved need to be kept permanent.

Those ones I uploaded at the beginning of the topic may be useful more than for a month but still not forever.

Please run some tests of Test Save 2.

over 160 manual edits - someone should at least look at it

Wow, this is some great work you did! We'll try to perform the same activities both on Test Save 2 and Old Dodo save.

It definitely appears that this GT bug really has a large impact on gameplay

I'd rather call this impact crucial. The main problem is that it's totally inevitable.

I am also here, but not participating in the discussion.

You're totally welcome anyway! BTW, I looked at your URV collections, very nice!

There is something to improve, of course, but they're fairly decent on the whole.

Edited May 26, 2015 by AlSar

May 26, 2015

I gave the jittery traffic a look and it definitely looks like a precisiou issue. Might be stuck too deep in the game logic to be fixable

Edited May 26, 2015 by Silent

May 26, 2015

That crazy Traffic exists on ALL my PS2 Save Files, including BC PS3. III, VC, SA, LCS, and VCS I see this. However, it happens even at the beginning of the game on a new, fresh save file for all of the games mentioned. Although, the one in particular that I notice which is the worst is SA on Mobile, since I am approaching 81+ Hours of gameplay. Whereas on my PS2 Save, it's only 55 Hours and 28 Minutes of gameplay and I don't see it often, but it exists still. PS2/3 Controls are easier for me than Mobile so the Total Playing Time Stat is a lot lower. Now, for III, VC, LCS, and VCS, my Stats are very low. 20-30 Hours basically for 100%, etc. But the Traffic stuff exists there, too. The cars appear in the grass in VC for me and when I come close, they drive into the road, but are in your lane and crash into you. They also do 180 degree turns right before your eyes, in the opposite lane. They drive backward and spin around. Sometimes it appears they are "flying" for a brief moment, too. It's not as bad, though, as I mentioned compared to my Mobile SA Save at 81 Hours of gameplay.

Even the peds are crazy in my Mobile SA Save and flash on the screens in and out and disappear and reappear. Idk what is going on!

Edited May 26, 2015 by Militia

May 26, 2015

Might be stuck too deep in the game logic to be fixable

It's still fixable in SA, is III and VC so different from SA?

That crazy Traffic exists on ALL my PS2 Save Files, including BC PS3.

It seems you've already reached pre-final phase. And what about USJ's in your save files?

If you test them, there might be some clues for PS2 versions research.

Edited May 26, 2015 by AlSar

May 26, 2015

What is a "pre-final phase?" The Stunt Jumps are "normal." How they always have been for me. I don't experience what you guys are saying on my PS2/3 Saves with the USJ's, only the crazy Traffic Bugs...

May 26, 2015

What is a "pre-final phase?"

Check OP, namely #1-2 glitches of III and #1-3 glitches of VC.

I mean that the next phase is total traffic (and game timer) freeze.

The Stunt Jumps are "normal." How they always have been for me.

It might be that PS2/3 version is free of USJ bugs. Maybe only traffic glitches can occur.

As console framerate is 30 fps, screwing up times for you should be 149:08 for both games.

I strongly doubt you've acheived it in your save files. Maybe PS2/3 has other logic here.

Edited May 26, 2015 by AlSar

May 26, 2015

Orion asked me to look in to adding timer reset modifications to GTASnP for testing purposes. I have implemented them for both III and VC (PC), marked as BETA/experimental. They can also be easily applied to Android/iOS in the future if needed.

Currently the modification resets:

Global timer
Reset to 0
Weather timer
Reset to 0
Script timers
Subtracting original global timer value from script timer values with a minimum result of 0
- Timer A
- Timer B
- Wake Timer
Pickup timers (III only currently)
Subtracting original global timer value from script timer values with a minimum result of 0
Cargen timers (III only currently)
Subtracting original global timer value from script timer values with a minimum result of 0

This is based on how the timer reset / traffic glitch fix currently works on SA.
SA also resets these, but I don't have any docs on their location (if they even exist) in III and VC: pickup timers, cargen timers, police trigger timers, and extra global vars

Edited May 26, 2015 by Samutz

May 26, 2015

I have noticed some incosistencies regarding one step variable in the function processing traffic... loss of precision is indeed very likely. It's NOT in the place I expected it to be, though

May 26, 2015

We'll try to perform the same activities both on Test Save 2 and Old Dodo save.

Test Save 2 has been partially repaired (only GT, WT, and wake and local timers of threads are reset), but known pickup and gargen issues were not created before the repair so they may be difficult to identify. Goals of test save 2 are;

Clock should not freeze during USJ when frame limiter is off
Try to find dropped pickups that don't unspawn, and standard pickups that won't respawn, and standard cargens that won't respawn
All threads should be active (missions, USJ, R3, etc), test is passed if most work since it's a manual repair. (I will try to identify specific actions of threads)
Please check phones and cranes. I am not familiar with these structures or their timers.

The main goal of the Old Dodo save is to prepare glitches to be checked after the fix.

USJ with FL off should freeze the clock (only glitch at this level)
12 in-game hours until the next glitch level, then
- USJ with FL on should freeze clock
- Clock will speed up with FL off

@Samutz

In III, the pickup timer is identified as "regeneration time" and cargen timer should be "timestamp (time last stolen?)". There are no police triggers in III. (I will try to confirm.)

VC timestamps are not documented in the wiki. Timestamps are usually easy to identify visually, I'll see what I can find in the saves posted above.

@AlSar - Silent usually works within the engine. Sometimes he can fix the problem; all I can do is repair the damage. It is starting to sound like a proper fix may not be practical, but I am still confident that we can repair the save.

I thought of a potential problem with a fix for ThirteenAG's FL script; if the clock freezes the cleo script won't be able to make changes. He will need to detect a jump before the game speed is adjusted.

Edited May 26, 2015 by OrionSR

May 26, 2015

@Samutz

In III, the pickup timer is identified as "regeneration time" and cargen timer should be "timestamp (time last stolen?)". There are no police triggers in III. (I will try to confirm.)

VC timestamps are not documented in the wiki. Timestamps are usually easy to identify visually, I'll see what I can find in the saves posted above.

Ok, I thought that might be them, but wasn't sure. I updated the function on the site.

May 26, 2015

One possible practical fix would be dating back the timers in a save at either load or save time to lower values, so they don't overflow (unless you play for 70h within one session, it's not the game that needs help ).

Edited May 26, 2015 by Silent

May 26, 2015

I have visually confirmed those offsets. Now I'm looking for anything else that might pose a problem in III. A check for issues with globals will have to wait until we get the structural details worked out. I didn't see anything obvious on my early scans.

GTA III, Block 2: Garages. I'm not sure what this is, but anything time related should be checked.

0x0024 	dword 	time when 'GA_21' was last shown

Ah. "You cannot store any more cars in this garage." I'm guessing that if we don't reset this the message won't display correctly. That's something that could probably be tested on test save 2. Um... did we miss this in the SA fix? (yes)

Update: Normally this message is displayed if the player approaches a full garage while driving. If this timer is not reset along with the GT then the message will not be displayed unless the player opens the door on foot and then tries to enter a vehicle. This will force the normal display cycle of the message about every 20 seconds - this is an in-game strategy for resetting this timer.

Nothing else obvious popped up in the III wiki, but there are still an awful lot of unknowns.

Dating back the timers, huh? Can we find them all? That's what makes me nervous about a save repair strategy. I guess the main advantage to the save repair strategy is that is can be applied more easily to other systems. I'm curious how these errors play out on PS2 and Android. Are they repeatable for Steam?

Uh oh. I can't find an 010 template for VC. Progress on the timers is going to be a bit slow.

_______________________________

Added:

From the III High Jump (HJ) that controls the display and awards from insane jumps.

01BD: $750 = current_time_in_ms

I'm not sure what to make of these timers. For the most part opcode 01BD is always read as needed, so resetting them shouldn't be necessary. Most of these were ignored in the SA fix for years before someone finally ran into problems when resetting the timers within 3 hours of eating at a fast food joint. I think the best strategy is to document the use of 01BD in active threads and for players to check those threads for problems.

I was going to attempt to identify the active threads but now that Samutz is on the job I'm less worried about missing something in a manual edit. Instead I'll try to sample some that are easy to identify so player/testers can tell the difference between something that is controlled by the scripts and the environment controlled by the engine.

Threads in III to check for problems with 01BD: current_time_in_ms

:HJ - $750, $751 (High Jump)

:I_AMMU/:C_AMMU - $96, $97 (Ammu-Nation)

:HEALTH/WANTED - $1136, $1137 (info messages)

:RC1-4/:T4X4/:MAYHEM - $1171, $1172 (um... races and stuff)

:COPCAR - $1422, $1424 (Vigilante)

And then we are definitely getting into missions.

Suspicious Values in III - Looking for hidden timers, I don't suggest changing anything yet.

Block 1: Player Peds

0x74, 0x558 - no idea, but values are similar to the GT, might be a coincidence or unimportant.

Both appear to be within the CPed structure of PlayerPed, one before and another after the weapon slot arrays

Block 6: Cranes

Crane record offset 0x74 dword, timestamp - from my notes on cranes, I'm not sure how this value is used.

Edited May 27, 2015 by OrionSR

May 26, 2015

Steam, yes. Other platforms, no idea. And indeed, that would require finding ALL timers. Might be hardest in the case of saved vehicles, peds and props.

May 26, 2015

Whoops. Somehow I double posted instead of updating. I'll just use this post for VC updates.

0x0024 	dword 	time when 'GA_21' was last shown

In VC, this undocumented offset in the Garage block at 0x0028 looks very much like a timestamp.

VC Pickup Timers at offset 0x1C from beginning of record.

VC Cargen Timers at offset 0x20 from beginning of record.

VC Police Trigger (Set Pieces, block 20) Timers at offset 0x04 from beginning of record.

Added: What is the status of Cranes in Vice City?

I am unable to identify anything that looks like a time stamp in the crane structures of VC. My thought is perhaps VC doesn't have active crusher or export cranes so this field remains empty. I don't think we ever came to any conclusions about the nature of other cranes in III. Does VC have anything the least bit crane-like? I seem to remember speculation about attempting to activate a crusher or export crane in VC just to see if the legacy code still works. This might help identify a time stamp. I'm concerned about attempting to fix modified games, but this applies more to verifying standard scripts before attempting to tweak any global variables. This is more of a structural repair that should apply to all games. But then again, I'm still not sure how this time stamp effects III. Maybe it doesn't matter at all.

Edited May 27, 2015 by OrionSR

III & VC Save File Glitch Detection and Repair

Recommended Posts

AlSar

Link to comment

Share on other sites

4emp2008

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

thehambone

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

Seemann

Link to comment

Share on other sites

Silent

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

Seemann

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

thehambone

Link to comment

Share on other sites

Lethal Vaccine

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

Silent

Link to comment

Share on other sites

Lethal Vaccine

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

Lethal Vaccine

Link to comment

Share on other sites

AlSar

Link to comment

Share on other sites

Samutz

Link to comment

Share on other sites

Silent

Link to comment

Share on other sites

OrionSR

Link to comment

Share on other sites

Samutz

Link to comment

Share on other sites