Talk:Saves (GTA SA)

Initial Comments

Note that the initial version is pretty confusing. Only the first block has been written in any detail and the rest are CyQ's shorthand notes from 2 years ago. It'll get better, at least those parts I have any understanding of will. ;) pdescobar 16:01, 1 Sep 2007 (CDT)

ah, nice to see you again contributing to the GTA modding! I will add some save format info that I know later. Seemann 13:36, 2 Sep 2007 (CDT)

Thanks, Seemann; it's good to be back. And thanks for the additions/corrections you've already added. pdescobar 17:34, 3 Sep 2007 (CDT)

Unique Stunt Jump coordinates

How confident are you in the format of the Jump block? Orion_SR has been doing some testing with me and his contention is that the coordinates in that block are not the point/radius format seen in the SCM opcode but instead take the format "startXmin, startYmin, startZmin, startXmax, startYmax, startZmax, landXmin, landYmin, landZmin, landXmax, landYmax, landZmax, camX, camY, camZ" and I think the min/max format looks more likely after some quick examinations. pdescobar 19:00, 4 Sep 2007 (CDT)

Yes, you're right. Although to be more specific, they aren't the min/max points, it's a diagonal of the cube (there are 2 cubes: start and land); where the first XYZ is a lower cube angle, and the second is a upper angle. If a vehicle coords while in air are in the start cube the UJ begins. If it's landed in the land cube, the UJ is successful, otherwise it's not. Please, write this in the article. Seemann 23:43, 4 Sep 2007 (CDT)

Updated. Note that I reinserted the word unique so now the block is called "Unique Stunt Jumps" as this is the term most commonly used from my experience. pdescobar 00:46, 5 Sep 2007 (CDT)

Structures alignment

Fields of every structure are aligned on 4 (dword), this means if there's a field with size 1 or 2 bytes in the end of structure, there are also additional unused bytes to align the memory addresses. So, what I'm talking about: the last two bytes in the USJ structure are not unknown, it's just a gap. They are two additional bytes to make the total size of the stucture dividable by 4. We should not add them in the description, as it causes confusion. Thus, the total size of the USJ block is 0x44, the last field there is 0x41 - isFound. 0x42, 0x43 must be removed. It would be better to return "0x44 end". Alignment also could be used in the middle of the structure: 0xC8 byte[4] in the Thread dump, actually it should be "0xC8 byte unknown", "0xC9 byte unknown, and 0xCA, 0xCB is the gap. Btw, the thread structure is fully described here. Seemann 03:19, 5 Sep 2007 (CDT)

I'd prefer that something like "gap" or "padding" or "unused" was used to inform people of that situation instead of simply leaving those extra bytes out of the description. It's more specific and keeps people from thinking that there is an omission or incorrect type size listed. pdescobar 11:32, 5 Sep 2007 (CDT)

Maybe (align) word would be more convenient there?

0x41  byte        Boolean: is USJ found
0x42  byte[2]     (align)

looking good :) Seemann 03:45, 6 Sep 2007 (CDT)

(Align) works fine for me. :) I also added an explanatory note in the beginning of the data block section based on your above comment. pdescobar 16:34, 7 Sep 2007 (CDT)

Keep it up!

pdescobar & OrionSR: Good work, guys! I wish I have more free time to add some info. Btw, what about re-formatting of old tables to the style I used in the Block #27 (using templates)? Seemann 09:45, 6 Dec 2007 (UTC)

And thanks to you too. Every time we add something, it seems you come along and fill in the blanks. :) I've considered the table format (Orion asked about that too) but the simple formatting I've been using is easier for me to update and it's also much easier to copy & paste into a code block on a forum since the spacing doesn't change. Maybe once this is a bit more stable and is not being changed so much we can make it pretty with the tables. pdescobar 19:35, 7 Dec 2007 (UTC)

External Script Triggers (Block 1)

In addition to data from opcodes 0928/0929 these structures look like they also store data from 07D3 and 0884. I don't have a real good feel for the details yet, which is why I'm throwing it into a discussion. Here's the current Stucture Definition:

ExternalScriptTrigger
  0x00   word                     Index in the script.img 
  0x02   byte                     Attach type (actor or object)
  0x03   byte                     Type? -- only for ObjectTrigger
  0x04   dword                    Status?
  0x08   float                    Radius -- vary only for ObjectTrigger (ActorTrigger uses a pre-defined radius of 5.0)
  0x0C   word                     modelID
  0x0E   word                     priority
  0x10   dword                    (unknown)
  0x14                            end

And here is an example of 07d3 and 0884 from the original mission script:

07D3: 'HOUSE' = init_external_script_named_handle 23 (BURG_BRAINS) 
0884: 'DANCER' = init_external_script_named_handle 52 (DANCER) 

In the case of 07d3 the Attach type parameter (offset 0x02) seems to be 3 and for 0884 the Attach type seems to be 5; like actor triggers, the radius seems to default to 5.0 for both of these too. Those identifying strings (e.g. 'HOUSE') are stored in the 8 bytes after the radius. I'm guessing that the purpose of the 4 bytes at offset x10 is simply space to hold the rest of the string in these situations and they're probably unused for the structures related to 0928 & 0929. So for these cases, instead of modelID,priority,unknown, the data at offset 0x0c are simply a max 8-byte string (including null terminator). I'm not sure exactly how to describe that identifying string though, or how to update the structure definition in a minimally-confusing way. pdescobar 08:47, 29 Jan 2008 (UTC)

Yeah, I noticed that some time ago. IIRC, there're 35 structures with (modelID,priority,unknown) stuff and 35 - with a 8 byte string in the original savefile. I tried to find how the game detects what kind of structure is there: by using the Attach field value, or by index (let the first 35 structures be of type #1 and the next 35 with type #2), but failed. It looks like I need to search again. For a while I'm not sure if I know how to describe correctly that too. Seemann 12:46, 29 Jan 2008 (UTC)

Missing Byte

Where is 224th byte in 'Memory dump structure' (BLOCK 1)?

Look, the whole structure is 224 bytes in length. It means there are bytes from #0 to #223 (224 in total) counting from 0. So, a byte at zero offset is the first byte, at offset 10 - is 11th byte; at offset 223 (0xDF) - 224th byte. The current description is absolutely correct. Seemann 13:38, 3 Jul 2008 (BST)

I don't believe this. Look at Stack pointer. It is a word at 0x38 and next dword(first local variable) is 4 bytes away from it( at 0x3C). Shouldn't it be at 0x3A? Also 0x0 to 0xE0 are total 225 bytes. The extra byte added by me made it 226 bytes. If you correct stack pointer thing then you get 224 bytes.

(I may be wrong, if stack pointer is dword.)--hmvartak 17:00, 3 Jul 2008 (BST)

The stack pointer is a WORD and next two bytes after it is a padding (Align), but just not mentioned. And there's no any byte at 0xE0, last byte is 0xDF. 0xE0 is the end of this struct, not a byte field. Seemann 02:34, 4 Jul 2008 (BST)