Documenting GTA-SA memory addresses

[X_ATP_X]

Hey, How can I read out a Car ID from the Memory?

 

I tried it in that way:

 

[email protected] = 0xB74494 0A8D: [email protected]  = read_memory [email protected] size 4 virtual_protect [email protected] += 340A8D: [email protected] = read_memory [email protected] size 2 virtual_protect 0045A: draw_text_1number 50.0 30.0 GXT 'number' number [email protected] 

I want to read the CarId of the first car in th Pool. But I get "134", and that is no CarID...

 

I took the adresses from here:

http://www.gtamodding.com/index.php?title=...s_%28SA%29#Cars

Edited July 15, 2009 by X_ATP_X

[asd23]

 

Now now people, share those addresses Some addy's from me about the radar-markers;

 

Structure: RadarMarker

Item size: 0x28 (40 bytes)

Pool start: 0xBA86F0

Pool size: 175 items

 

 

struct RadarMarker {   DWORD dwColourID;           // 0   DWORD* pEntity;             // 4   float fPosX;                // 8   float fPosY;                // 12   float fPosZ;                // 16   short wFlag;                // 20   short _wAlign;              // 22   float fUnknown;             // 24 (either 1.0 or 5.0)   DWORD dwIconSize;           // 28   DWORD *pEnterExit;          // 32   BYTE byteIcon;              // 36   BYTE byteFlags;             // 37   BYTE byteType;              // 38   BYTE _bAlign;               // 39};

 

 

0x583820   CMarker::Create

0x5839A0   CMarker::SetAboveEntity

0x583AB0   CMarker::SetColour

0x583F00   CMarker::SetEnterExit

0x583EB0   CMarker::SetFriendOrThreat

0x583D70   CMarker::SetIcon

0x583CC0   CMarker::SetIconSize

0x583D20   CMarker::SetType

 

This was most useful, however, those are just the blips on the map, but I need the actual markers that are in the level. Can anyone share info about the actual marker struct and also the start address of the pool?

Edited September 2, 2009 by asd23

[NTAuthority]

 

*(BYTE *)0x522423 = 0x90;*(BYTE *)0x522424 = 0x90;

 

 

From the MTA source code, disables the camera messing up when the player is driving and in driveby mode.

 

EDIT:

 

Another one I found myself: 0x8CD598 contains the IDE number for a pickup to have a VC style glow circle around it.

Edited September 20, 2009 by NTAuthority

[MaVe1337]

How do you guys find those addresses, mainly function addresses??

 

I need some function that handles inputs from DirectInput..

[gtamaster1990]

is it possible to put the player in a vehicle via memory ?

[Adler]

 

*(BYTE *)0x522423 = 0x90;*(BYTE *)0x522424 = 0x90;

 

 

From the MTA source code, disables the camera messing up when the player is driving and in driveby mode.

How do you incorporate this into a CLEO script?

[Wesser]

Here are all controls checked by the opcode 00E1. The last two are specials, so they won't be loaded by SCM but only by reading their value over the memory.

 

0xB73458 : Base Memory Address

+ 0x1AC : Block Size (for each player defined)

 

ON-FOOT CONTROLS

 

 

Offset	ID	Slot 1	Slot 2	Slot 3	On	Off
+ 0x0	0	Right			128	0
+ 0x1	^	Left			128	0
+ 0x2	1	Backwards			128	0
+ 0x3	^	Forward			128	0
+ 0x4	2	Look right			128	0
+ 0x5	^	Look left			128	0
+ 0x6	3	Look down			128	0
+ 0x7	^	Look up			128	0
+ 0x8	4	Action	Center camera	Secondary fire	255	0
+ 0xA	5	Previous weapon/target			255	0
+ 0xC	6	Aim weapon			255	0
+ 0xE	7	Next weapon/target			255	0
+ 0x10	8	Group CTRL forward			255	0
+ 0x12	9	Group CTRL back			255	0
+ 0x14	10	Conversation - NO			255	0
+ 0x16	11	Conversation - YES			255	0
+ 0x18	12	Unused			255	0
+ 0x1A	13	Change camera			255	0
+ 0x1C	14	Jump			255	0
+ 0x1E	15	Enter+exit			255	0
+ 0x20	16	Sprint			255	0
+ 0x22	17	Fire			255	0
+ 0x24	18	Crouch			255	0
+ 0x26	19	Look behind			255	0
+ 0x28	20	Unused			255	0
+ 0x2A	21	Walk			255	0
+ 0x2C	22	Unused			255	0
+ 0x2E	23	Unused			255	0

IN-CAR CONTROLS

 

 

Offset	ID	Slot 1	Slot 2	Slot 3	On	Off
+ 0x0	0	Right			128	0
+ 0x1	^	Left			128	0
+ 0x2	1	Steer down	Steer up		128	0
+ 0x3	^	Steer forward	Steer back		128	0
+ 0x4	2	Special CTRL right			128	0
+ 0x5	^	Special CTRL left			128	0
+ 0x6	3	Special CTRL down			128	0
+ 0x7	^	Special CTRL up			128	0
+ 0x8	4	Secondary fire			255	0
+ 0xA	5	Look left	Look behind		255	0
+ 0xC	6	Hand brake			255	0
+ 0xE	7	Look right	Look behind		255	0
+ 0x10	8	Next radio station			255	0
+ 0x12	9	Previous radio station			255	0
+ 0x14	10	Conversation - NO			255	0
+ 0x16	11	Trip skip			255	0
+ 0x18	12	Unused			255	0
+ 0x1A	13	Change camera			255	0
+ 0x1C	14	Brake/reverse			255	0
+ 0x1E	15	Enter+exit			255	0
+ 0x20	16	Accelerate			255	0
+ 0x22	17	Fire			255	0
+ 0x24	18	Horn			255	0
+ 0x26	19	Sub-mission			255	0
+ 0x28	20	Unused			255	0
+ 0x2A	21	Unused			255	0
+ 0x2C	22	Mouse look			255	0
+ 0x2E	23	User track skip			255	0

+ 0x.. : Some key state copies

 

By the way, follow the functions above to get your current key state and set it to another field so that we can control more players:

 

{$CLEO}0000: NOPgosub @Create2ndPlayer while true wait 0  if  0AB1: call_scm_func @getPad 3 1 2 1 // Look left then   0AB1: call_scm_func @setPad 3 2 0 1 // Left end if  0AB1: call_scm_func @getPad 3 1 2 0 // Look right then   0AB1: call_scm_func @setPad 3 2 0 0 // Right end if  0AB1: call_scm_func @getPad 3 1 3 1 // Look up then   0AB1: call_scm_func @setPad 3 2 1 1 // Forward end if  0AB1: call_scm_func @getPad 3 1 3 0 // Look down then   0AB1: call_scm_func @setPad 3 2 1 0 // Backwards endend:Create2ndPlayer#WMYAMMO.Load()repeat wait 0 until #WMYAMMO.Available()04C4: store_coords_to [email protected] [email protected] [email protected] from_actor $PLAYER_ACTOR with_offset 0.0 1.0 0.0 0053: $SECOND_PLAYER = create_player #CSPLAY at [email protected] [email protected] [email protected] 09C7: change_player $SECOND_PLAYER model_to #WMYAMMO 01F5: $SECOND_PLAYER_ACTOR = get_player_actor $SECOND_PLAYER 06F3: unknown flag 0 // 2Player ***0568: set_actor $PLAYER_ACTOR untargetable 1 0568: set_actor $SECOND_PLAYER_ACTOR untargetable 1 06E0: set_2_player_camera_mode_to 2 // ***094E: set_actor $SECOND_PLAYER_ACTOR disable_mutal_activity 1 06F1: set_2_player_distance_limit_to 20.0 // float x2 ***08F5: set_player_group_save return :getPad{ [email protected] - player num [email protected] - key press num [email protected] - key state  0 - standard  1 - next}if and [email protected] > -1  24 > [email protected] then [email protected] *= 0x2  if    [email protected] > 0  then   [email protected] += 0x1  end [email protected] += 0xB73458  [email protected] -= 1  [email protected] *= 0x1AC // skip to 2nd player 005A: [email protected] += [email protected]  0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0  if    [email protected] > 0  then   0485: return_true else   059A: return_false endelse 059A: return_falseend0AB2: ret 0 :setPad{ [email protected] - player num [email protected] - key press num [email protected] - key state  0 - standard  1 - next}if and [email protected] > -1  24 > [email protected] then if    4 > [email protected]  then   [email protected] = 128  else   [email protected] = 255  end [email protected] *= 0x2  if    [email protected] > 0  then   [email protected] += 0x1  end [email protected] += 0xB73458  [email protected] -= 1  [email protected] *= 0x1AC // skip to 2nd player 005A: [email protected] += [email protected]  0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0 end0AB2: ret 0 

 

Using the last parameter of these functions, you'll be able to get\set the up\down\left\right keys.

 

Unfortunately, we cannot check for example the up/down keys separately: that wouldn't work.

 

 

*(BYTE *)0x522423 = 0x90;*(BYTE *)0x522424 = 0x90;

 

 

From the MTA source code, disables the camera messing up when the player is driving and in driveby mode.

How do you incorporate this into a CLEO script?

Simply write 2 nop (0x90) bytes to the first address (untested):

 

0A8C: write_memory 0x522423 size 2 value 0x9090 virtual_protect 0 

 

Edited February 7, 2010 by Wesser

[Adler]

 

Simply write 2 nop (0x90) bytes to the first address (untested):

 

0A8C: write_memory 0x522423 size 2 value 0x9090 virtual_protect 0 

 

Damn I tried that but the game crashed. I tried changing things around in the script and adding a "Driving" check but it crashes when I get into a car then.

 

Maybe it's because I'm running SA on 7? A few scripts that worked when I had XP don't work now on 7.

Edited December 10, 2009 by Adler

[Wesser]

It crashed to me too. Try to enable the last value (1 = on) and see what happen but I doubt it'll work.

[DexX]

0x00C3F0D0;//number of active lights

0x00C3F0E0 - array of ingame "lights" for the current entity. This is the structure as near as i can tell;

 

struct gtalight{float worldposx;float worldposy;float worldposz;float directionx;float directiony;float directionz;float radius;//confirmedfloat red;float green;float blue;float alpha;//generally zero, although there are some exceptions (not alpha then?)unsigned char type;//*unsigned char bUnknown2;//sometimes 1unsigned char bUnknown3;//always 1?unsigned char bUnknown4;//always 0};//*//if 0, light has position, radius//if 1, light has position, radius, and directions (works like a spotlight, but has the cone angle is hardcoded, and it seems to only be used on vehicle headlights)//if 2, ???//if 3, ??? - checked in vehicle light loop//if 4, light has position ONLY, no radius - checked in vehicle light loop

 

Internally, R* uses the light position, direction and entity position to rotate the light and apply attenuation and coloring themselves on the cpu and apply it to an RpLight, which is the final light that renderware passes to Directx, with the R*-computed direction and color. One 'advantage' to this besides rendering speed, is that R* doesn't have to add any RpClump/RpAtomics to the RpWorld created by the game. The disadvantage is that directional lighting from a source besides the Sun doesn't look so good.

Only about 7 lights seem to affect an entity at any given time, and which lights they are depends on the entity. While only 7 can be active, i have seen well more than 20 in memory. The logic for determining which lights an entity is illuminated by is unknown to me.

Edited March 18, 2013 by DexX

[Deji]

 

Here are all controls checked by the opcode 00E1. The last two are specials, so they won't be loaded by SCM but only by reading their value over the memory.

 

0xB73458 : Base Memory Address

+ 0x2 : Block Size (for each keypress defined)

Haha, I tried getting this for ages with no luck... How did you manage to find it?

 

Any chance that you know the address for the last parameter (or maybe second to last... the one that isn't readable while not in car) in the get_joystick_data opcode? With it I may be able fix my CJ Surfer script.

 

 

Anyway, I also wanted to know 2 other things which I can't find myself, since I obviously don't have the nack of this whole finding addresses business...

 

 

1) Address of cop models (writable).

2) Address of Grove Street models (writable - and I'm guessing the other gangs models will come free )

 

 

These will help dearly in my Vigilante Justice mod. I'm starting to worry about the amount of memory I'm stuffing into it, though

 

 

 

 

0A8C: write_memory 0x4F62A0 size 1 value 137 virtual_protect 1 // Disable car engine sounds and siren (like when you exit cop car with sirens on)0A8C: write_memory 0x4F62A0 size 1 value 138 virtual_protect 1 // Re-enable. Never set the values too different or the game will crash

 

Edited January 11, 2010 by Deji

[NTAuthority]

 

Haha, I tried getting this for ages with no luck... How did you manage to find it?

Well, Racer_S had them for a long time in SAAC, and MTA's source code contains a lot of hints to them - debugging SAAC for instance could be a help... or reading SAAC's source code

 

 

Any chance that you know the address for the last parameter (or maybe second to last... the one that isn't readable while not in car) in the get_joystick_data opcode? With it I may be able fix my CJ Surfer script.

 

 

There's only data for the left analog stick (WASD on PC when on foot) and the right analog stick (somewhat linked to mouse). Do these last two parameters read the mouse movements? If so, this is contained in value '+ 0x4' and '+ 0x6', which are actually 2 bytes long (and signed). I don't know if CLEO's 'read_memory X size 2' will keep the minus values of them, but if so, -128 = top/left max, 128 = bottom/right max; though (like get_joystick_data?) these can differ between 0 and these values.

 

 

Anyway, I also wanted to know 2 other things which I can't find myself, since I obviously don't have the nack of this whole finding addresses business...

 

 

1) Address of cop models (writable).

 

 

According to the SALA source, there are 4 model ID addresses (4 bytes long) at 0x8A5AA0; you'll need to VirtualProtect I think.

 

 

2) Address of Grove Street models (writable - and I'm guessing the other gangs models will come free )

 

 

This would be in pedgroup data, looking for a list of the numeric IDs in pedgrp.dat in Cheat Engine would likely help.

 

On another CControllerState note, the MTA source indicates key 23 as being the 'skip User Track Player' key, F5.

Edited January 20, 2010 by NTAuthority

[ghost of delete key]

Hey youse,

 

I'm sure y'all read the crap I wrote in the VC thread.

 

Well, similar results are now popping up with SA.

I have about a hundred different patched, cracked, wrong, and otherwise smacked-around EXEs, but the one I got to disassemble cleanly was the "compact" version that Seeman recommends in his SB forums. It comes apart nicely, and I'm finding chunks of VC left inside of it.

 

This I now can see is a common trend with Rockshtar's development cycle:

Take your one big hit, and crowbar some new stuff into it.

Then when that hits, crowbar more stuff into it.

 

You'd think with all the time they had, they could afford a little work "from scratch"?

Seriously, though- there are pieces like the Hyman Stadium sign messages for example, and one or two other little bits I can't recall off the top of my sore head.

 

Again I'm finnding lots of code that equates to valves with the handles removed; code that never seems to get a chance to call the files that don't exist.

 

I'm thinking some of these mystery files could be deduced from the routines that read them,. if they're not too badly unwired.

 

I've just saved all 27 pages of this thread, and have now a few years worth of data to comb through, like the VC thread, so I'll know in just a bit- but I haven't seen or heard of any sort of "lost menu" in SA, although there is some nice fossils.

 

I'll get back soon, mebbe with some answers to some recent ponderings.

 

[/break over]

Back to work!

 

 

<edit:spp>

 

So as not to double-doublepost, I'll just mention I mistakenly posted SA info in the VC memory thread (go see it there)...

 

At this point, I'm supposing I should start a new VC-SA diff thread about mapping the functions, as at this point I'm finding quite a bit of similarity, and logic info gleaned from this endeavor would be useful for coding and scripting in BOTH games, if not ALL.

 

Imma put my head to this one for a bit, more later.

Edited January 21, 2010 by ghost of delete key

[Deji]

When making a sequel, game developers hardly ever start from scratch.

[Wesser]

Some corrections of what Sacky's posted here.

 

0xC8AAB8 : Base Memory Address

+ 0x70 : Block Size (for each weapon defined in weapons.dat)

 

+ 0x0 - Fire Type (1 byte) : 0 - Melee, 1 - Instant_hit, 2 - Projectile, 3 - Area_effect, 4 - Camera, 5 - Use

+ 0x4 - Target Range (float) : How far away a ped has to be before he gets that little triangle above his head

+ 0x8 - Weapon Range (float) : How far the bullets are effective

+ 0xC - Weapon Modelid 1 (2 byte) : Corresponds to the weapon.dat but changing it in the memory doesn't do anything

+ 0x10 - Weapon Modelid 2 (2 byte) : Usually 65535 (so -1) except for remote explosives (with detonator)

+ 0x14 - Slot (1 byte) : The Slot ID for the weapon

+ 0x18 - Hex flag (2 byte) : Still unknown

+ 0x1C - Unknown (1 byte) : Nope yet

+ 0x20 - Max Clip Ammo (2 byte) : How much ammo can be held in an individual clip when it is full

+ 0x22 - Damage (2 byte) : The damage given by the weapon

+ 0x24 - Fire X (float) : Fire weapon X offset

+ 0x28 - Fire Y (float) : Same as above but Y offset related

+ 0x2C - Fire Z (float) : Same as above but Z offset related

+ 0x30 - Skill level (1 byte) : Number of each skill level

+ 0x34 - Requested stat level (2 byte) : Stat level requested to get the weapon skill level

+ 0x38 - Weapon accuracy (float) : Precision of the weapon

+ 0x3C - Move speed (float) : Speed of actor's movements

 

(Skill level : 1st)

47 - Pistol

48 - Silenced Pistol

49 - Desert Eagle

50 - Shotgun

51 - Sawn Off Shotgun

52 - Combat Shotgun

53 - Micro Uzi (Mac 10)

54 - MP5

55 - AK47

56 - M4

57 - Tec9

 

(Skill level : 2nd)

0 - Unarmed

1 - Brass Knuckles

2 - Golf Club

3 - Night Stick

4 - Knife

5 - Baseball Bat

6 - Shovel

7 - Pool cue

8 - Katana

9 - Chainsaw

10 - Purple Dildo

11 - White Dildo

12 - Long White Dildo

13 - White Dildo 2

14 - Flowers

15 - Cane

16 - Grenades

17 - Tear Gas

18 - Molotovs

19 - Missile (crashes when firing)

20 - Missile (crashes when firing)

21 - Missile (crashes when firing)

22 - Pistol

23 - Silenced Pistol

24 - Desert Eagle

25 - Shotgun

26 - Sawn Off Shotgun

27 - Combat Shotgun

28 - Micro Uzi (Mac 10)

29 - MP5

30 - AK47

31 - M4

32 - Tec9

33 - Rifle

34 - Sniper Rifle

35 - RPG

36 - Missile Launcher

37 - Flame Thrower

38 - Minigun

39 - Sachet Charges

40 - Detonator

41 - Spray Paint

42 - Fire Extinguisher

43 - Camera

44 - Nightvision Goggles

45 - Thermal Goggles

46 - Parachute

 

(Skill level : 3rd)

58 - Pistol

59 - Silenced Pistol

60 - Desert Eagle

61 - Shotgun

62 - Sawn Off Shotgun

63 - Combat Shotgun

64 - Micro Uzi (Mac 10)

65 - MP5

66 - AK47

67 - M4

68 - Tec9

 

(Skill level : 4th)

69 - Pistol (cop)

 

This is the cleo script which helps us to get any weapons.dat value based on the current weapon skill stat:

 

{$CLEO}0000: NOPwhile true wait 0  0470: [email protected] = actor $PLAYER_ACTOR current_weapon 0AB1: call_scm_func @ReadWeaponsDat 2 [email protected] 0x20 [email protected] // Weapon num, offsetend:getWeapSkillsif and [email protected] > 21 // Pistol ... 33 > [email protected] // ... Tec9then [email protected] -= 22  [email protected] += 69  0653: [email protected] = float_stat [email protected] else if or   [email protected] == 33 // Rifle   [email protected] == 34 // Sniper Rifle then   [email protected] = 300.0  else   [email protected] = 0.0  endend0AB2: ret 1 [email protected] :ReadWeaponsDatfor [email protected] = 0 to 2  0085: [email protected] = [email protected]  if and   [email protected] > 21 // Pistol ...   33 > [email protected] // ... Tec9 then   if      [email protected] > 0    then     [email protected] -= 22      [email protected] += 47      0085: [email protected] = [email protected]      [email protected] -= 1      [email protected] *= 11      005A: [email protected] += [email protected]    end end [email protected] *= 0x70  [email protected] += 0xC8AAB8  0085: [email protected] = [email protected]  [email protected] += 0x34  0A8D: [email protected] = read_memory [email protected] size 2 virtual_protect 0  0AB1: call_scm_func @getWeapSkills 1 [email protected] [email protected]  0092: [email protected] = float [email protected] to_integer if  002D:  [email protected] >= [email protected]  then   0085: [email protected] = [email protected]  endend005A: [email protected] += [email protected] 0A8D: [email protected] = read_memory [email protected] size 2 virtual_protect 0 0AB2: ret 1 [email protected] 

 

[Silent]

Little correction to 5 years-old Squiddy's post:

 

0xC1CC03 - BYTE - Invert mouse vertically

 

It's wrong. Corrent definition is:

 

0xC1CC03 - BYTE - Fly with mouse

 

On www.gtamodding.com it's wrong too.

[Wesser]

In addition to the key presses used internal by the game (as explained here), I'll list the ones which are read from gta_sa.set.

 

0xB70198 : Base Memory Address

+ 0xB70 : Start of key controls

 

Total key presses are 59.

 

 

Offset	ON-FOOT CONTROLS		Offset	IN-CAR CONTROLS		Offset	?
+ 0x0	Fire		+ 0x240	Fire		+ 0x540	Unknown
+ 0x40	Next weapon/target		+ 0x260	Secondary fire		+ 0x560	Unknown
+ 0x60	Previous weapon/target		+ 0x300	Accelerate		+ 0x5C0	Unused
+ 0x620	Group CTRL forward		+ 0x320	Brake/reverse		+ 0x6A0	Unused
+ 0x640	Group CTRL back		+ 0x280	Left		+ 0x6C0	Unused
+ 0x600	Conversation - NO		+ 0x2A0	Right		+ 0x6E0	Unused
+ 0x5E0	Conversation - YES		+ 0x2C0	Steer forward/down		+ 0x700	Unused
+ 0x80	Forward		+ 0x2E0	Steer back/up		+ 0x720	Unused
+ 0xA0	Backwards		+ 0x140	Enter+exit		+ 0x740	Unused
+ 0xC0	Left		+ 0x5E0	Trip skip
+ 0xE0	Right		+ 0x340	Next radio station
+ 0x100	Zoom in		+ 0x360	Previous radio station
+ 0x120	Zoom out		+ 0x380	User track skip
+ 0x140	Enter+exit		+ 0x3A0	Horn
+ 0x160	Change camera		+ 0x3C0	Sub-mission
+ 0x180	Jump		+ 0x160	Change camera
+ 0x1A0	Sprint		+ 0x3E0	Handbrake
+ 0x5A0	Aim weapon		+ 0x480	Look behind
+ 0x1E0	Crouch		+ 0x4A0	Mouse look
+ 0x200	Action		+ 0x440	Look left
+ 0x220	Walk		+ 0x460	Look right
+ 0x1C0	Look behind		+ 0x4C0	Special CTRL left
+ 0x400	Look left		+ 0x4E0	Special CTRL right
+ 0x420	Look right		+ 0x520	Special CTRL up
+ 0x660	Look down		+ 0x500	Special CTRL down
+ 0x680	Look up
+ 0x580	Center camera
+ 0x20	Secondary fire

+ 0x4 : [1 byte] Each slot position (0 = null, 1 = first, 2 = second)

 

+ 0x8 : [2 byte] Next slot (even here ^)

 

These use all virtual key codes except some which are pre-defined in the .exe such as:

 

 

Key	Code		Key	Code		Key	Code
Esc	0x3E8		Num1	0x404		Unbound	0x420
F1	0x3E9		Num2	0x405
F2	0x3EA		Num3	0x406
F3	0x3EB		Num4	0x407
F4	0x3EC		Num5	0x408
F5	0x3ED		NumLock	0x409
F6	0x3EE		Num6	0x40A
F7	0x3EF		Num7	0x40B
F8	0x3F0		Num8	0x40C
F9	0x3F1		Num9	0x40D
F10	0x3F2		Num0	0x40E
F11	0x3F3		NumEnter	0x40F
F12	0x3F4		ScrollLock	0x410
Ins	0x3F5		Pause	0x411
Del	0x3F6		Backspace	0x412
Home	0x3F7		Tab	0x413
End	0x3F8		CapsLock	0x414
PagUp	0x3F9		Enter	0x415
PagDown	0x3FA		LShift	0x416
ArrowUp	0x3FB		RShift	0x417
ArrowDown	0x3FC		Shift	0x418
ArrowLeft	0x3FD		LCtrl	0x419
ArrowRight	0x3FE		RCtrl	0x41A
NumDiv	0x3FF		LAlt	0x41B
NumMul	0x400		RAlt	0x41C
NumAdd	0x401		LWin	0x41D
NumSub	0x402		RWin	0x41E
NumDel	0x403		WinClick	0x41F

The game shouldn't always update all slots so it might change the next instead of the first (only after changing a key by menu). This script may help you:

 

{$CLEO}0000: Starting code...while true wait 0  for [email protected] = 0x0 to 0x740 step 0x20    0AB1: call_scm_func @getKeyPadAddr 1 [email protected] [email protected]    [email protected] += 0x4    0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0    if      not [email protected] == 1    then     [email protected] -= 0x4      0A8D: [email protected] = read_memory [email protected] size 2 virtual_protect 0      0085: [email protected] = [email protected] // (int)      [email protected] += 0x8      0A8D: [email protected] = read_memory [email protected] size 2 virtual_protect 0      [email protected] += 0x4      0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0      0AB1: call_scm_func @getKeyPadAddr 1 [email protected] [email protected]      0A8C: write_memory [email protected] size 2 value [email protected] virtual_protect 0      [email protected] += 0x4      0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0      [email protected] += 0x4      0A8C: write_memory [email protected] size 2 value [email protected] virtual_protect 0      [email protected] += 0x4      0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0    end endend:[email protected] = 0xB70198 [email protected] += 0xB70 005C: [email protected] += [email protected] 0AB2: ret 1 [email protected] 

 

[ghost of delete key]

I found something very interesting today while reclaiming unused routines in SA...

 

I stumbled upon an entire source compiler buried in the exe.

 

It consists of what looks like 2 main branches, comprising a complex and exhaustive token parser/lexer handling both C sourcecode and HLSL sourcecode, complete with error checking and file streaming.

 

The entire network of routines feathers out into a wide array of unreferenced routines, that is, no code anywhere in the game calls into it. It is simply there, all tied neatly together.

 

I've been at it for about 18 hours straight, and while I still have loose branches to track down, I seem to be most of the way down this rabbit hole. The whole works seem to be perfectly complete, as nothing (yet) leads to a nullsub, like the game code often does. Then again, none of it seems to directly lead to game code either. Many of the resource strings (which are the library of C and HLSL tokens it reads) are found in close association with all the orphaned RenderWare SDK sourcecode path strings, which of course nothing references. They do tell a good tale of what modules the engine was compiled against, though.

 

What remains to be seen is what use it might have. I'm sure all of the call-in routines can either be exported manually by way of a patch, or otherwise hooked.

 

Of course, I found this while going through all the "unexplored" code, that which the disassembler doesn't resolve into functions, since it is never called into from other code. There is an amazing array of "duplicate" code, differing only slightly from the actual working code, all the way up to duplicate game loading routines with "extra functionality", but that's fodder for another post.

 

This is by no means exhaustive, but it's a general overview of the parser routines. The "dead-end" boxes at the top, and the white ones to the lower left are the unreferenced call-ins, the "bottom" routine in blue does some generic exception handling. Everything in between handles reading the sourcecode and writing to memory...

 

 

After I get some sleep I'll put something coherent together for the curious. Maybe somebody can do something fun with this.

 

Whew!

Edited February 14, 2010 by ghost of delete key

[DexX]

 

It consists of what looks like 2 main branches, comprising a complex and exhaustive token parser/lexer handling both C sourcecode and HLSL sourcecode, complete with error checking and file streaming.

There is no HLSL code in the exe, however there is some assembly code for a vertex shader that's used by renderware. The code is unique, as it is compiled at runtime, for each ped (Clump, Atomic?), to match the number of bones the ped has. If you run the game though PIX you can see slightly different versions of the vertex shader for each ped that has a different number of bones (no pixels shaders, skinned meshes use the fixed function pipeline for their materials).

 

You know that the graph image doesn't scale in the browser? The image is little more than a collection of unlabeled (too small to read) black boxes and lines. Not really useful

[ghost of delete key]

 

There is no HLSL code in the exe, however there is some assembly code for a vertex shader that's used by renderware. The code is unique, as it is compiled at runtime, for each ped (Clump, Atomic?), to match the number of bones the ped has. If you run the game though PIX you can see slightly different versions of the vertex shader for each ped that has a different number of bones (no pixels shaders, skinned meshes use the fixed function pipeline for their materials).

Hmm, I never knew that, that's good to know. Now some of what I'm finding here makes sense.

 

 

You know that the graph image doesn't scale in the browser? The image is little more than a collection of unlabeled (too small to read) black boxes and lines. Not really useful

 

 

It was only supposed to show the shape and scope of the thing. Actually, it's one of a few such that overlap, but that's the most complete graph. not all of them connect, as some stuff is referenced through jump tables that the grapher won't resolve, so I'm still hunting down all the sections.

I also need to find a GDL tool better than WinGraph32 so I can make more legible custom graphs. IDA does a nice job of generating GDL, it's WinGraph that's a bit lame. possibly aiSee, or if anyone knows of a good free GDL graph tool, let me know.

 

Like I said, I'll post more complete info soon, like links to full sized legible graphs and addresses of all the routines involved.

If one looks at this stuff in IDA, remember that these are unexplored areas of code, and you'll need to manually convert each to a function.

Naming these will be tedious, so far I've just prepended the "sub_XXXXXX" with "MYSTERY_COMPILER" for lack of better terminology.

It will be a while yet before I can release a coherent .idb, and I'll need to get to another machine to upload it, it's huge.

 

Stay tuned...

[ghost of delete key]

bada-BUMP.

 

According to http://ati.amd.com/developer/ShaderX2_IntroductionToHLSL.pdf

 

Keywords are predefined identifiers that are reserved for the HLSL language and

cannot be used as identifiers in your program. Keywords marked with '*' are case

insensitive.

 

asm* bool compile const

decl* do double else extern false float for

half if in inline inout int matrix* out

pass* pixelshader* return sampler

shared static string* struct technique* texture* true typedef

uniform vector* vertexshader* void volatile while

 

The following keywords are currently unused, but are reserved for potential future use:

 

auto break compile const char class case catch

default delete const_cast continue explicit friend dynamic_cast enum

mutable namespace goto long private protected new operator

reinterpret_cast short public register static_cast switch signed sizeof

throw try template this typename unsigned using union virtual

 

 

Some of these keywords are handled in the parser. Also are a number of ps and vs compiler targets and the associated error reports such as

"failed to open source file: '%s'"

'unexpected tokens following preprocessor directive'

"ps_1_0 is no longer supported; using ps_1_1"

and so on.

 

Also, there are a number C tokens and preprocessor directives that it reads, such as ...

pragma ifdef ifndef elif endif include line define

... and so-on, along with more error messages like

"invalid preprocessor command '%s'"

"syntax error"

"include interface required to support #include from resource or memory"

"too many nested #includes"

... and many others.

 

It appears that the routines that handle these are passed a unicode "C" mode character, much like passing "r" or "wb" as a mode to fopen()

It seems logical to me that it denotes reading C code.

 

Anyway, I recreated a fresh idb with the latest IDA, and discovered that it made a much better run at disassembling than previously, hence some of what I thought was purely uncalled code was resolved as fragments of other routines. But for the most part, the structure of this thing is mostly the same.

 

Here's a full-sized image of the shader compiler routine callmap; many of the functions remain with their auto-generated names, some are modified with loose descriptions of the tokens they read or errors they check along the way, and all of the top-level callers wind up being genuine orphan code which had to be reclaimed, as nothing at all calls them. (these are labeled with "mystery_compiler_callin_xxxxxx) They all bear addresses, so y'all can poke around to see for yourself what goes on there.

 

 

This doesn't include much of the other shader references, which appear to run up other call paths into game code here and there. There are also other seemingly C-specific references whose routines do not appear in this callgraph. That needs more hunting.

 

In other news, I've been finding and reclaiming "lost" routines that aren't called by anything, plenty of debugging code, and some routines that read and write to files like views.txt (.text:00619FA0) More later.

 

I think it's time to sleep again, dammit.

[NTAuthority]

The shader compiler is nothing special, it's part of the statically-linked D3DX library - older versions of D3DX were statically linked.

[ghost of delete key]

Heh, after digging around, I found a listing (I think DexX posted it) which has all these already named.

 

Anyhoo...

 

some other addresses (all double word) called by an initialization function @ 0x619600:

 

0xC8CF68 OSVersionInfo

0xC8CF6C D3DSuccess // success = 2304, otherwise an error code

0xC8CF70 GlobalMem_TotalPhys

0xC8CF74 GlobalMem_AvailPhys

0xC8CF78 GlobalMem_TotalVirtual

0xC8CF7C GlobalMem_AvailVirtual

 

 

Some errata...

Ryosuke has some structures listed at his site-

 

(nit-pick)

for the Corona info structure starting at 0xC3E058,

the size is 0x40 and the number of structures 0x3C, NOT THE OTHER WAY AROUND!

 

The definition for the Racing Checkpoint info structure (Start 0xC7F158) is incomplete and funny-

this is what I find:

 

 

00000000 CHECKPOINTINFO  struc; (sizeof=0x38)00000000 Unk_0           dw ?00000002 Type            db ?00000003 Unk_1           db ?                  ; flag set to 1 after struct is initialized00000004 SCMHandle       dd ?00000008 ColorR          db ?00000009 ColorG          db ?0000000A ColorB          db ?0000000B ColorA          db ?0000000C Unk_2           dw ?0000000E Unk_3           dw ?00000010 PosX            dd ?00000014 PosY            dd ?00000018 PosZ            dd ?0000001C DirX            dd ?00000020 DirY            dd ?00000024 DirZ            dd ?00000028 Unk_4           dd ?0000002C Size            dd ?00000030 Unk_5           dd ?00000034 Unk_6           dd ?00000038 CHECKPOINTINFO  ends

 

 

(RGBA are 4 separate bytes, not one dword)

Here's how its init function works it:

 

 

// 0x722880int __cdecl CheckPoint_Init(){ int result; // [email protected] result = (int)&CheckpointInfo.Type; do {   *(_WORD *)(result - 2) = 257;               // unk   *(_BYTE *)result = 0;                       // type?   *(_DWORD *)(result + 2) = 0;                // handle in SCM   *(_BYTE *)(result + 6) = -1;                // R   *(_BYTE *)(result + 7) = -1;                // G   *(_BYTE *)(result + 8) = -1;                // B   *(_BYTE *)(result + 9) = -1;                // A   *(_WORD *)(result + 10) = 1024;             // unk   *(_WORD *)(result + 12) = 5;                // unk   *(_DWORD *)(result + 14) = 0;               // posX   *(_DWORD *)(result + 18) = 0;               // posY   *(_DWORD *)(result + 22) = 0;               // posZ   *(_DWORD *)(result + 26) = 0;               // dirX   *(_DWORD *)(result + 30) = 0;               // dirY   *(_DWORD *)(result + 34) = 0;               // dirZ   *(_DWORD *)(result + 38) = 0x3E800000u;     // unk   *(_DWORD *)(result + 42) = 0x3F800000u;     // size?   *(_DWORD *)(result + 46) = 0;               // unk   *(_DWORD *)(result + 50) = 0;               // unk   *(_BYTE *)(result + 1) = 1;                 // unk   result += 56; } while ( result < (signed int)&unk_C7F85A );   // next address after last struct dword_C7C6D4 = 0;                             // nothing else calls this address! return result;}

 

 

Oddly, it grabs a pointer to the structure 2 bytes in from the start, and backtracks.

This is the only one I've seen like this so far.

Edited February 18, 2010 by ghost of delete key

[NTAuthority]

On the subject of racing checkpoints, 0x7212A4 contains a MOV instruction which loads a pointer to the RwClump for the direction arrow in the checkpoint, to change it independently from diamond_3.

[ghost of delete key]

Not only the checkpoint now I see, but also Explosion info structure is initialized by pointing to the second member, then pointing backward to the first.

 

Picking apart the routine that executes the explosion (0x736A50), I find uses for two unknown members:

 

 

00000000 EXPLOSIONINFO   struc; (sizeof=0x7C)00000000 ExplosionType   dd ?00000004 PosX            dd ?00000008 PosY            dd ?0000000C PosZ            dd ?00000010 fltUnk_1        dd ?00000014 fltUnk_2        dd ?00000018 ddUnk_3         dd ?[b]0000001C ddUnk_CrimeCommitted dd ?[/b] // if this == true then CStat_CrimeCommited() (0x532010) can be called00000020 EndTime         dd ?00000024 fltUnk_5        dd ?00000028 FramesFromCreated db ?00000029 bUnk_6          db ? 0000002A bUnk_7          db ?0000002B bUnk_8          db ?0000002C TimeCreated     dd ?[b]00000030 ddUnk_PerfCountTime dd ?[/b] // the performance counter time is stored here during lifespan calculation00000034 VisibleRadius   dd ?00000038 ddUnk_10        dd ?0000003C Lifespan        dd ?00000040 anonymous_0     dd ?00000044 anonymous_1     dd ?00000048 anonymous_2     dd ?0000004C anonymous_3     dd ?00000050 anonymous_4     dd ?00000054 anonymous_5     dd ?00000058 anonymous_6     dd ?0000005C anonymous_7     dd ?00000060 anonymous_8     dd ?00000064 anonymous_9     dd ?00000068 anonymous_10    dd ?0000006C anonymous_11    dd ?00000070 anonymous_12    dd ?00000074 anonymous_13    dd ?00000078 anonymous_14    dd ?0000007C EXPLOSIONINFO   ends

 

 

Can anyone correctly name the members +0x40 - +0x78?

Ryosuke has them listed as "+0x40 - +0x78 Float Effect Coords"

With these I can likely figure the uses of bUnk_6 -bUnk_8.

[Wesser]

0xC402B8 - [byte] Toggle night vision (1 = on, 0 = off)

0xC402B9 - [byte] Toggle thermal vision (1 = on, 0 = off)

 

Here is the memory location of all car colors assigned to each vehicle (212).

 

0xB1F650 : Base Memory Address

+ 0x4 - Start of CModelCars (size = 0x282A0)

• + 0x308 : Block Size (for each vehicle defined in vehicles.ide)
  • + 0x2B0 - Painting Color (size = 0x20)
    • + 0x0 - [byte] Primary Color (size = 0x8)
    • + 0x8 - [byte] Secondary Color (size = 0x8)
    • + 0x10 - [byte] Tertiary Color (size = 0x8)
    • + 0x18 - [byte] Quaternary Color (size = 0x8)
  • + 0x2D0 - [byte] Total Painting Colors

To get the offset of the primary color, you should do as follows:

 

0x308 * ModelID - 400 + 0x2B0

 

As regards the carcols.dat structure all vehicles can have a minimum of 2 and a maximum of 4 colors. This is an example of all possible painting colors related to landstal:

 

carlandstal, 0,0endcar3landstal, 0,0,0endcar4landstal, 0,0,0,0end

 

These couple of values are 8 as max, so to get all of them you have to do this:

 

0x308 * (ModelID - 400) + 0x2B0 + n - 1 + 0x0  "   *        "        +   "   +   "   + 0x8  "   *        "        +   "   +   "   + 0x10  "   *        "        +   "   +   "   + 0x18

 

The constant "n" refers to the number of your color.

 

A little help for coding:

 

{$CLEO}0000: NOPwhile true wait 0  if  00DF:  actor $PLAYER_ACTOR driving then   03C0: [email protected] = actor $PLAYER_ACTOR car   0AB1: @getVehCarcols 2 from_car [email protected] painting 8 store_to [email protected] [email protected] [email protected] [email protected]    0AB1: @setVehCarcols 6 from_car [email protected] painting 1 primary [email protected] secondary [email protected] tertiary [email protected] quaternary [email protected]  endend:getVehicleNum0441: [email protected] = car [email protected] [email protected] -= 400 0AB2: ret 1 [email protected] :getVehCarcols0AB1: @getVehicleNum 1 from_car [email protected] store_to [email protected] [email protected] *= 0x308 [email protected] += 0xB1F650 [email protected] += 0x2D4 0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0 if and [email protected] > 0 002D:  [email protected] >= [email protected] then [email protected] -= 0x20  [email protected] -= 1  005A: [email protected] += [email protected]  0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0  [email protected] += 0x8  0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0  [email protected] += 0x8  0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0  [email protected] += 0x8  0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0 else [email protected] = -1  [email protected] = -1  [email protected] = -1  [email protected] = -1 end0AB2: ret 4 [email protected] [email protected] [email protected] [email protected] :setVehCarcols0AB1: @getVehicleNum 1 from_car [email protected] store_to [email protected] [email protected] *= 0x308 [email protected] += 0xB1F650 [email protected] += 0x2D4 0A8D: [email protected] = read_memory [email protected] size 1 virtual_protect 0 if and [email protected] > 0 002D:  [email protected] >= [email protected] then [email protected] -= 0x20  [email protected] -= 1  005A: [email protected] += [email protected]  0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0  [email protected] += 0x8  0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0  [email protected] += 0x8  0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0  [email protected] += 0x8  0A8C: write_memory [email protected] size 1 value [email protected] virtual_protect 0 end0AB2: ret 0 

 

Edited March 29, 2010 by Wesser

[MindF*ck]

Thank you very much Wesser for finding those carcol offsets! That will really help me

 

 

I have just tried them for reading out the complete saved carcols line for each vehicle and actually, if you don't mind, I have a few little corrections:

 

Base Memory Address must be: 0xB1F654

blocksize for each vehicle is surely correct, it also works with vehicle.ide etc

 

Then you have

+ 0x2B0

-> +0 - [8 byte] all Primary Colors, each 1 byte size

-> +8 - [8 byte] all Secondary Colors, each 1 byte size

-> +16 - [8 byte] all Tertiary Colors, each 1 byte size

-> +24 - [8 byte] all Quaternatry Colors, each 1 byte size

Edited March 28, 2010 by MindF*ck

[Wesser]

The base memory address is right, but I was wrong when I talked about the color bytes because I had no time to make more tests.

 

Thanks for your advice too. I updated my last post.

[MindF*ck]

Thanks again for your efforts! Really great work

 

One little insight from a (vehicle-)modders view though.

There is actually no fourth carcol ingame. R* didn't include vehicles with four carcols and therefore it's impossible to assign a fourth carcol to any car, since it's not documented how to do it. Obviously, R* did include all the memory handling for the fourth carcol, but that's acutally useless for vehicle modders

So, all vehicles have 4 carcols at max, but still the ones with 3 carcols are stored under "car4" in the carcols.dat, with all fourth carcols zeroed out. There is acutally no "car3" section in the SA carcols.dat. I don't know if it wourks to add it though. But adding those cars with 3 carcols in the "car4" section is totally sufficient

 

About the base memory address ... well ... strictly speaking from practical use, it only works for me with my posted address. If I use your posted address, I get wrong values, especially at (+772), the last 4 bytes in each block, where the anims value from the vehicle.ide is saved.

 

 

 

Edited March 30, 2010 by MindF*ck

[DexX]

 

One little insight from a (vehicle-)modders view though.

There is actually no fourth carcol ingame.

Oh it's there, and it works. I used it on my escalade. From the San Andreas Vehicle Tech Doc;

 

 

Using Carcol materials on your model

Set the diffuse color of your material to one of the following colors, to have its color ingame, controlled by the carcols.dat file.

 

RGB colors for each carcol color:

Primary - 60, 255, 0 - This color

Secondary- 255, 0, 175 - This color

Third - 0 255, 255 - This color

Fourth - 255, 0, 255 - This color

 

To use the third and 4th colors, you need to put your vehicle in the "car4" section, at the end of your carcols.dat file.

 

Always read the pinned topics. I posted that info in 2006

 

The function for checking if a material is carcols-compatible is at 0x004C8220. The first argument the RpMaterial* to check, the second argument is some user-supplied data.

 

Color indices for current vehicle being processed;

0x00B4E3F0 - car color index for primary color

0x00B4E3F1 - car color index for secondary color

0x00B4E3F2 - car color index for third color

0x00B4E3F3 - car color index for fourth color

 

The actual array of carcol colors is at 0x00B4E480

There's space allocated for 128 colors (at 4 bytes per color, though alpha isn't used), although it would probably be possible to create a new array of colors, and modify the game to point to the new array. You'd have to update the carcols.dat file though to actually set the extra colors to a non-zero value, and actually have vehicles that use the new colors. You'd still be limited to 256 colors though, unless you changed the indices at B4E3F0x to use something with a larger storage capacity. This is all completely untested of course.

 

0x00B4E688 - pointer to vehicle.txd

0x00B4E68C - pointer to vehiclelightson128 texture

0x00B4E690 - pointer to vehiclelights128 texture