Quantcast

Jump to content

» «
Photo

Documenting GTA3/VC memory adresses

1,140 replies to this topic
sonka
  • sonka

    Player Hater

  • Members
  • Joined: 23 Dec 2006

#841

Posted 23 December 2006 - 03:45 PM

ÁÁ! Tudommár! Te egy baszott nagy vizilózabáló csirkefejű zsidó vagy! Akkor már értem miért nem értjük egymást! Na mivan te kis buzi, csak nem nem érted mit mondok? Szivjál le akkor nem kell a "segítséged"! Köcsög...

jarjar
  • jarjar

    Boss

  • BUSTED!
  • Joined: 07 Aug 2005

#842

Posted 24 December 2006 - 12:48 AM

Most people here are English speaking, so if you don't post in English, don't bet on a reply wink.gif.

DexX
  • DexX

    Black Hat

  • Feroci Racing
  • Joined: 16 May 2002

#843

Posted 06 January 2007 - 01:30 AM

This is a list of the function and lib addresses, generated from ida for VC. Of particular interest are the Renderware functions, which are preceded by either "_" or "__", using mixed cases (Rw vs rw). So for example, you should search for "_rw", or "__Rw". Some Renderware functions are also identified by "Rp" and "Rx".

http://www.3dhole.co...nction_dump.rar

Some of the functions i've named myself, most i haven't.

Andy80586
  • Andy80586

    Mark Chump

  • Members
  • Joined: 23 Jul 2003

#844

Posted 10 January 2007 - 09:13 PM

I have an issue/question about water in VC.

The game renders water starting either at the bottom-left or bottom-right of the VC map by the 0x5bff00 and 0x5c1710 functions. If you hack the waterpro.dat loading parameters to make an 8192x8192 water area instead of the default 4096x4096, the water still starts at y = -2048 (2048 units south) and goes up to y = 6144 units (north).

What I need is to move this south so that the water starts at y = -4096. Does anyone know how to move the water table northward or southward?

xanser
  • xanser

    Player Hater

  • Members
  • Joined: 12 Sep 2006
  • None

#845

Posted 16 February 2007 - 07:01 AM

QUOTE (Andy80586 @ Jan 10 2007, 21:13)
I have an issue/question about water in VC.

The game renders water starting either at the bottom-left or bottom-right of the VC map by the 0x5bff00 and 0x5c1710 functions. If you hack the waterpro.dat loading parameters to make an 8192x8192 water area instead of the default 4096x4096, the water still starts at y = -2048 (2048 units south) and goes up to y = 6144 units (north).

What I need is to move this south so that the water starts at y = -4096. Does anyone know how to move the water table northward or southward?

to Andy80586:
Do you found the way how to increase water space? I create my own sky and visible horizon. But I need more water (-8000x8000) even for beautiful view, not for sail.
user posted image
user posted image

AK-73
  • AK-73

    Hustler

  • Members
  • Joined: 31 Oct 2005

#846

Posted 02 March 2007 - 02:00 PM

QUOTE (Andy80586 @ Jan 10 2007, 21:13)
I have an issue/question about water in VC.

The game renders water starting either at the bottom-left or bottom-right of the VC map by the 0x5bff00 and 0x5c1710 functions. If you hack the waterpro.dat loading parameters to make an 8192x8192 water area instead of the default 4096x4096, the water still starts at y = -2048 (2048 units south) and goes up to y = 6144 units (north).

What I need is to move this south so that the water starts at y = -4096. Does anyone know how to move the water table northward or southward?


Has this problem been solved in the meantime?

Alex

maxorator
  • maxorator

    VC:MP lead developer

  • Members
  • Joined: 24 Feb 2006

#847

Posted 04 April 2007 - 05:59 PM Edited by maxorator, 14 April 2007 - 11:23 AM.

Some funny information about the debug menu (0x00A10B2D):
CODE
0x00A10A50 - 2B Word  - Which item is selected in the debug menu
0x00A10B39 - 1B Byte  - Debug menu select item, switch

So I created a car and an actor. I still don't know how Select Actor and Move actor and other such options work. Load movie sets the selection to the first item (New actor) and Play movie and END both disable the selection of the debug menu... not sure how to get it back.
I got the full list of it's items:
CODE
New actor
Move actor
Select actor
Delete actor
New vehicle
Move vehicle
Select vehicle
Delete vehicle
Give weapon
Goto
Goto (wait)
Get in car
Get out car
Kill
Flee
Wait
Position camera
Set camera target
Set camera mode
Save movie
Load movie
Play movie
END


Some more stuff I found (which are not mentioned here yet):
CODE
0x00A10AB2 - 1B Byte  - If this is set, some lights are disabled (like the night-lights in front of the hotel)
0x00A10ADC - 1B Byte  - "greenlights" cheat, switch
0x00A10B0F - 1B Byte  - "gripiseverything" cheat, switch
0x00A10B11 - 1B Byte  - Flying boat cheat, switch
0x00A10B15 - 1B Byte  - Radar map filled with grey when 1, switch
0x00A10B1E - 1B Byte  - If this is enabled, some regions of map don't have collisions (so Tommy falls through the surface), switch
0x00A10B26 - 1B Byte  - Pink cars cheat enabled, switch
0x00A10B28 - 1B Byte  - Flying car cheat, switch
0x00A10B47 - 1B Byte  - Miami Traffic cheat, switch
0x00A10B52 - 1B Byte  - Something with breaks? (set it higher and you will crash while breaking...)
0x00A10B5E - 1B Byte  - Setting this 1 crashes the game, so VC will just be not responding
0x00A10B6E - 1B Byte  - Menus act very strange (ESC is the only working key...), switch
0x00A10B82 - 1B Byte  - All cars black cheat activated, switch


I found one funny thing with the ped pointer
CODE
0x0094AD28 + 0x056C - there are 10 ped pointers in a row, which show to the 10 nearest peds


So I made this (C++/C):
CODE
int KillPeopleNear(){
   DWORD base,point;
   HWND hWnd = FindWindow(0, "GTA: Vice City");
   if(hWnd!=NULL){
       DWORD proc_id;
       GetWindowThreadProcessId(hWnd, &proc_id);  
       HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, proc_id);
       if(hProcess){
           ReadProcessMemory(hProcess, (LPVOID)(0x0094AD28), &base, 4, NULL);
           for(int i=0;i<10;i++){
               ReadProcessMemory(hProcess, (LPVOID)(base+0x56C+i*4), &point, 4, NULL);
               if(point){
                   float lval=0.0f;
                   WriteProcessMemory(hProcess,(LPVOID)(point+0x354),&lval,4,NULL);
               }
           }
           CloseHandle(hProcess);
       }
   }
   return 0;
}

Set a timer on it and all people near you die (I don't know the exact radius though and I'm too lazy to find it out). biggrin.gif

And I put some of the stuff on this thread together at http://maxx.5gigs.com/doam.txt.

Edit:
It seems as though some of the features in that menu are not developed:
CODE

//The code
L00603C90:
   movsx edi,[L00A10A50]
   cmp edi,00000013h
   ja  L006044A0
   jmp [CASE_PROCTABLE_006D71C0+edi*4]


//The proctable
CASE_PROCTABLE_006D71C0:
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0001
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0005
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0000
  dd CASE_006D71C0_PROC0009
  dd CASE_006D71C0_PROC000A
  dd CASE_006D71C0_PROC000A
  dd CASE_006D71C0_PROC000C
  dd CASE_006D71C0_PROC000D
  dd CASE_006D71C0_PROC000E
  dd CASE_006D71C0_PROC000F
  dd CASE_006D71C0_PROC0010
  dd CASE_006D71C0_PROC0011
  dd CASE_006D71C0_PROC0012
  dd CASE_006D71C0_PROC0013

CASE_006D71C0_PROC0000 does nothing. So things from "move actor" to "delete actor" and from "move vehicle" to "delete vehicle" are not developed. I will soon see what the next things do.

I found some information about car damage. When you change them, they will only update the car model when that piece gets damage (except tires, which have been mentioned here before).
CODE
677 (0x2A5), 678 (0x2A6), 679 (0x2A7), 680 (0x2A8) - tires
681 (0x2A9) - hood
683 (0x2AB), 684 (0x2AC) - doors
689 (0x2B1) - front bumper
694 (0x2B6) - front window
695 (0x2B7) - back bumper


And the tires of a bike:
CODE
812 (0x32C), 813 (0x32D) - bike tires


I also found something funny with ped pointer (I use the player pointer for example):
CODE
0x0094AD28 > 0x0B8 - 4B Float - The weight of the ped, affects jumping and collisions with cars

This has been mentioned only about cars. If you set it very high, you will bounce into the sky when entering a vehicle.

This has been mentioned by JerneyL, but I found one more very important flag and his stuff was quite a mess.
CODE
0x007E4E94 > 0x52 - 4B DWord - Car flags:
>0x00000001 - ? dent proof ? <by JerneyL>
>0x00000002 - explosion proof <by JerneyL>
>0x00000004 - visible (otherwise car is completely invisible and doesn't make any particle effects) <by JerneyL>
>0x00000008 - has driver <by JerneyL>
>0x00000010 - exploded darkened texture (you can still drive the vehicle, "tommy" is "burned" too) <by JerneyL>
>0x00000020 - ??
>0x00000040 - ??
>0x00000080 - ??

>0x00000100 - ??
>0x00000200 - fire proof <by JerneyL>
>0x00000400 - weapon damage proof <by JerneyL>
>0x00000800 - collision damage proof <by ME>
>0x00001000 - ??
>0x00002000 - ??
>0x00004000 - ??
>0x00008000 - car totally blown up (if you are in that car and set this you die! ) <by JerneyL>

>0x08000000 - set this and the car "stops responding", it won't move and it won't do any animations, you can't undo it


Yay! I found the actual maximum stars (and criminal points) you can have.
CODE

Criminal point graphic:
  0-  49 - 0 stars
 50- 179 - 1 star
180- 549 - 2 stars
550-1199 - 3 stars
1200-2399 - 4 stars
2400-4799 - 5 stars
4800-     - 6 stars

Now the offsets:
CODE
0x006910D8 - 4B DWord - maximum number of stars, only affects cheat codes (leavemealone and youwonttakemealive)
0x006910DC - 4B DWord - maximum number of criminal points, this affects every other way of earning stars

The current amount of criminal points is not a static address. And when I change it, the stars don't change and the game acts like you would have that amount of stars. The stars will update when you do something, that changes criminal points, like shoot someone or hit someone... I also found the location for stars, but they too didn't affect the gameplay. So there must be some third address...

I also messed a bit with the cheat texts. They are actually encoded very easily.
CODE

3,5,7,1,13,27,3,7,1,11,13,8,7,33,13,6,28,19,10,3,3,5,7,1,13,27,3,7

It subtracts 3 from the first character, 5 from the second one, 7 from the third one etc. And as the buffer for pressed keys is backwards, then it must be reversed. So I made a program just for encoding and decoding the values (there is one broken link here and one program, that changes the cheats in game, but doesn't decode them visually).
http://www.maxx.5gigs.com/vcencdec.rar - The program
http://www.maxx.5gig...cencdec-src.rar - And it's source

Found something interesting. Not very useful though.
CODE

0 for the islands and bridges in the center, 1 for the east side of the down, 2 for the west side of the down

0x0097F204 - 4B DWord - Shows in which part of the city you are
0x00A0D9AC - 4B DWord - Shows in which part of the city you are, if this one is not equal to the other one, then you will see the  welcome screen (Greetings from blabla).


Found more stuff smile.gif
CODE

0x00974B2C - 4B DWord - If you raise this value, then time goes fast for a moment (depending on how much you raise it) and some cars 'jump in time'. If you set this to a random value then time will always go fast, but cars 'jump in time' still only if you raise it by yourself. In some places it is called a global timer.

It was once mentioned before though...

Ped pointer fun biggrin.gif
CODE

0x0094AD28 - 0x052 - 1B Byte  - If floor((thisvalue%32)/16) is 1, then the ped won't have a texture (will be black), otherwise - normal
0x0094AD28 - 0x157 - 1B Byte  - Set this to 255 and the ped will 'abandon the car', so you're driving without the ped in the seat, you can't leave the car anymore. Combine it with setting 0x3AC (ispedincar) to 0, so you will see from the ped camera, but you will be driving the car (space - move backwards, shift - move forward)
0x0094AD28 - 0x1F8 - 1B Byte  - When on foot, it is 0 (and if you increase it then, you won't be able to enter a car), but every time you enter a car, it seems to get a new random value, even with the same car
0x0094AD28 - 0x1F9 - 1B Byte  - The same thing as above, only the random value is different
0x0094AD28 - 0x408 -216B Stuff- WEAPON_FIELD weapons[9]; // 0x408-0x4E0, 0x18 each
0x0094AD28 - 0x504 - 1B Byte  - Currently selected weapon slot
0x0094AD28 - 0x60C - 1B Byte  - Same as above, but changing this actually switches the weapon

About the WEAPON_FIELD:
CODE

typedef struct _WEAPON_FIELD {
DWORD weapon_type;
DWORD ammo_type; // I don't really know what this exactly does...
DWORD ammo_loaded;
DWORD ammo_total;
WORD mysterious1;
WORD mysterious2;
DWORD useless1;
} WEAPON_FIELD;

New stuff coming!
CODE
0x0094AD28 > 0x14F - 1B Byte  - Some ped flags:
>0x00000004 - is ped bleeding
>0x00000010 - setting this doesn't let the ped land when jumping

BTW, the flags at (CARPOINTER+0x52) work with the ped too. So you can make your ped invincible easily, it won't even fall when gets a shot with a rocket launcher (when explosion proof on). There are some differences though.

The texts on the top left corner (mentioned in the first post, 0x00939028 and 007D3E40) can be colored. As you have seen when you leave hospital the first time, there is a word in pink color there.
CODE

Set the text to:
~b~This text is dark blue!~w~ Not anymore...

b - dark blue
g - bright pink
h - bright white
o - orange
p - purple
q - pink
r - bright pink
t - bright green
w - white (default)
x - blue/lilac
y - yellow

I found one very interesting flag (I tested it with a car):
CODE
009B6A80 + 0x050 - 1B Word  - Some flags
0x08 > Driving disabled. Enable this flag and you won't be able to drive it (no acceleration nor turning). This is reset when leaving and entering the car.
0x10 > The car jumps to a random location. Often crashes.
0x20 > Same as 0x08.
0x40 > Same as 0x08.
0x80 > Same as 0x08.

And more. They are used separately, as the disassembly shows.
CODE

009B6A80 + 0x051 - 1B Word  - Some flags
0x01 > Is car solid. If you set this flag to 0, the car will go through other cars, walls etc. The only things that collides then are the wheels (that's why you don't fall through the surface). And when driving through other cars, the car grows in size (width).
0x04 > The car will become a static object, it won't move anymore (even when ramming it).
0x10 > Other vehicles and peds don't move when you hit them with your car; your car will stop as it would've hit a static object.

Screenshot of 0x01: Large | Small | Tiny | Nano
Ramming a solid car (0x04): Large | Small | Tiny | Nano

dustcrazy
  • dustcrazy

    Just simply, the crazy one.

  • BUSTED!
  • Joined: 11 Apr 2004

#848

Posted 07 April 2007 - 05:56 PM

Damn.... wow.gif I'm going to have some more fun with VC now. Thks.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#849

Posted 10 April 2007 - 10:40 AM

Well.. I guess this is the best place to put it.
I am using Spookie's D3DHook source to create a little project of mine.
I want to change the camera through the memory, but it doesn't seem to be working.
What I am doing:
I have defined the Camera positions as:
CODE
DWORD* dwCamX  = (DWORD*)0x7E46B8; //FLOATS!!
DWORD* dwCamY  = (DWORD*)0x7E46BC;
DWORD* dwCamZ  = (DWORD*)0x7E46C0;

Next I have set up some keys and all to set the camera through mission scripting, and then:
CODE
if (GetAsyncKeyState(VK_F8)&1)
{
 *dwCamX = *dwCamX + 10.0f;
 *dwCamY = *dwCamY + 10.0f;
 *dwCamZ = *dwCamZ + 10.0f;
}


Problem is, it does nothing tounge.gif
The compiler said that there's a possible loss of data due to the conversion from float to dWord, but I am not advanced enough in C++ to know whats wrong.
Can anyone help me?

ModelingMan
  • ModelingMan

    Crackalacking!

  • Members
  • Joined: 23 Jan 2004

#850

Posted 10 April 2007 - 12:33 PM

QUOTE (grovespaz @ Apr 10 2007, 11:40)
I have defined the Camera positions as:
CODE
DWORD* dwCamX  = (DWORD*)0x7E46B8; //FLOATS!!
DWORD* dwCamY  = (DWORD*)0x7E46BC;
DWORD* dwCamZ  = (DWORD*)0x7E46C0;

You should actually declare those like so:
CODE
float* dwCamX  = (float*)0x7E46B8;
float* dwCamY  = (float*)0x7E46BC;
float* dwCamZ  = (float*)0x7E46C0;


I've not actually tried to mess around with the camera myself, but I'm pretty sure the camera is locked onto the player. I think there is some other value(s) you need to change before you can move the camera freely.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#851

Posted 10 April 2007 - 12:43 PM Edited by grovespaz, 10 April 2007 - 01:28 PM.

QUOTE (ModelingMan @ Apr 10 2007, 12:33)
QUOTE (grovespaz @ Apr 10 2007, 11:40)
I have defined the Camera positions as:
CODE
DWORD* dwCamX  = (DWORD*)0x7E46B8; //FLOATS!!
DWORD* dwCamY  = (DWORD*)0x7E46BC;
DWORD* dwCamZ  = (DWORD*)0x7E46C0;

You should actually declare those like so:
CODE
float* dwCamX  = (float*)0x7E46B8;
float* dwCamY  = (float*)0x7E46BC;
float* dwCamZ  = (float*)0x7E46C0;


I've not actually tried to mess around with the camera myself, but I'm pretty sure the camera is locked onto the player. I think there is some other value(s) you need to change before you can move the camera freely.

Well, that indeed was a stupid mistake, i changed the dwords to floats, but it still wont work.

I have already set the camera to a certain position, so its not locked to the player anymore.
CODE
ScriptCommand(&set_cam_pos, 119.200f, -827.042f, 19.486f, 0.0f, 0.0f, 0.0f);
ScriptCommand(&cam_point_at_player, PLAYER_CHAR, 15, 2);
ScriptCommand(&widescreen, 1);
(I named those myself, their not the 'official' namings)

EDIT: I think i just realise what may be it.
I think float* dwCamZ = (float*)0x7E46C0; just assigns the current value of 0x7e46c0 tounge.gif
EDIT2: Nope, that doesn't seem to be it either.. I don't have enough knowledge however to be sure.

ModelingMan
  • ModelingMan

    Crackalacking!

  • Members
  • Joined: 23 Jan 2004

#852

Posted 10 April 2007 - 01:31 PM

QUOTE (grovespaz @ Apr 10 2007, 13:43)
EDIT: I think i just realise what may be it.
I think float* dwCamZ = (float*)0x7E46C0; just assigns the current value of 0x7e46c0 tounge.gif
Gonna check right now:P

Nah it won't do that. You are declaring dwCamZ as and initialising it with a pointer to a float, it wouldn't compile if it were trying to assign a float value to a pointer.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#853

Posted 10 April 2007 - 01:34 PM

QUOTE (ModelingMan @ Apr 10 2007, 13:31)
QUOTE (grovespaz @ Apr 10 2007, 13:43)
EDIT: I think i just realise what may be it.
I think float* dwCamZ  = (float*)0x7E46C0; just assigns the current value of 0x7e46c0 tounge.gif
Gonna check right now:P

Nah it won't do that. You are declaring dwCamZ as and initialising it with a pointer to a float, it wouldn't compile if it were trying to assign a float value to a pointer.

Thats what i thought too..
I even went as far as trying
CODE
*(float*)0x7E46B8 = *(float*)0x7E46B8 + 10.0f;
*(float*)0x7E46BC = *(float*)0x7E46BC + 10.0f;
*(float*)0x7E46C0 = *(float*)0x7E46C0 + 10.0f;
tounge.gif

I'm going a little insane here. I'll try some debuggish stuff wink.gif

dustcrazy
  • dustcrazy

    Just simply, the crazy one.

  • BUSTED!
  • Joined: 11 Apr 2004

#854

Posted 10 April 2007 - 02:08 PM

QUOTE (grovespaz @ Apr 10 2007, 13:34)
QUOTE (ModelingMan @ Apr 10 2007, 13:31)
QUOTE (grovespaz @ Apr 10 2007, 13:43)
EDIT: I think i just realise what may be it.
I think float* dwCamZ  = (float*)0x7E46C0; just assigns the current value of 0x7e46c0 tounge.gif
Gonna check right now:P

Nah it won't do that. You are declaring dwCamZ as and initialising it with a pointer to a float, it wouldn't compile if it were trying to assign a float value to a pointer.

Thats what i thought too..
I even went as far as trying
CODE
*(float*)0x7E46B8 = *(float*)0x7E46B8 + 10.0f;
*(float*)0x7E46BC = *(float*)0x7E46BC + 10.0f;
*(float*)0x7E46C0 = *(float*)0x7E46C0 + 10.0f;
tounge.gif

I'm going a little insane here. I'll try some debuggish stuff wink.gif

If the keys are global. Try pressing the key and opening up to TSearch. Then calulate the adress(Is it a pointer, can't rember??) and see if its changes. If it does then you using the wrong adress to change the camara.

Squiddy
  • Squiddy

    Back!

  • The Connection
  • Joined: 06 Oct 2004

#855

Posted 10 April 2007 - 03:15 PM

I remember stretchnutter saying something about nopping out some function that controls the camera, before having full control over it. Executing scm commands may work fine with the game's camera control, but you changing the values directly seems not.
He mentioned it somewhere on the first pages here.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#856

Posted 10 April 2007 - 04:05 PM

I hope your not referring to the post on the bottom.. Thats about keypresses I believe.

ModelingMan
  • ModelingMan

    Crackalacking!

  • Members
  • Joined: 23 Jan 2004

#857

Posted 10 April 2007 - 11:25 PM

What Stretchnutter says in this post is very useful to you, I actually did this myself earlier with TSearch.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#858

Posted 11 April 2007 - 02:59 PM

QUOTE (ModelingMan @ Apr 10 2007, 23:25)
What Stretchnutter says in this post is very useful to you, I actually did this myself earlier with TSearch.

Thats about keypresses I believe. confused.gif

I might be able to freeze it, but my VC installation seems twirled up. Everytime i alt+tab back in, it crashes..

Ah well, I will try a couple of things wink.gif

ModelingMan
  • ModelingMan

    Crackalacking!

  • Members
  • Joined: 23 Jan 2004

#859

Posted 11 April 2007 - 06:26 PM

QUOTE (grovespaz @ Apr 11 2007, 15:59)
QUOTE (ModelingMan @ Apr 10 2007, 23:25)
What Stretchnutter says in this post is very useful to you, I actually did this myself earlier with TSearch.

Thats about keypresses I believe. confused.gif

You can use the same concept for moving the camera as well though. If you use the AutoHack feature of TSearch it will give you the addresses of the instructions which store the camera rotation and position values. By getting those addresses, bringing them over to your DLL, and no-oping the instructions you'll be free to move the camera wherever you want.

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#860

Posted 11 April 2007 - 07:02 PM

QUOTE (ModelingMan @ Apr 11 2007, 18:26)
You can use the same concept for moving the camera as well though. If you use the AutoHack feature of TSearch it will give you the addresses of the instructions which store the camera rotation and position values. By getting those addresses, bringing them over to your DLL, and no-oping the instructions you'll be free to move the camera wherever you want.

Well, its kinda hard to do that, since i can't alt+tab back in, and the results i get back are quite alot. (Including the adresses Stretchnutter provided smile.gif )

Meh, I'll try a little something to prevent the crashing wink.gif

ntlofub
  • ntlofub

    x86 programmer

  • Members
  • Joined: 02 Apr 2007

#861

Posted 12 April 2007 - 07:27 PM

The camera is controlled by a function in the game that continuously calculates a three-element array of floats containing a predefined offset from your X, Y, and Z position.

CODE
46DA31: fstp dword ptr [ebx+0x30] ;; X Camera Position
46DA38: fstp dword ptr [ebx+0x34] ;; Y Camera Position
46DA3F: fstp dword ptr [ebx+0x38] ;; Z Camera Position


These instructions are three bytes a piece. To disable them from occuring (and thus enabling manual control of the camera), simply do the following:

CODE

void NOP(DWORD dwAddress, int iSize)
{
 DWORD dVP1, dVP2;
 VirtualProtect((PVOID)dwAddress,iSize,PAGE_EXECUTE_READWRITE,&dVP1);
 memset((PVOID)dwAddress,0x90,iSize); // nop * (int)iSize
 VirtualProtect((PVOID)dwAddress,iSize,dVP1,&dVP2);
}

void EnableCamera()
{
 NOP(0x46DA31, 3);
 NOP(0x46DA38, 3);
 NOP(0x46DA3F, 3);
}

AK-73
  • AK-73

    Hustler

  • Members
  • Joined: 31 Oct 2005

#862

Posted 17 April 2007 - 01:56 PM Edited by AK-73, 17 April 2007 - 02:13 PM.

QUOTE (ModelingMan @ Apr 10 2007, 12:33)
I've not actually tried to mess around with the camera myself, but I'm pretty sure the camera is locked onto the player. I think there is some other value(s) you need to change before you can move the camera freely.


0x7E49C0 is the ptr to the object the camera is locked to, I believe. smile.gif
I've done a bit camera stuff for the last few days because I am working on letting the camera move with the head when in fp mode, at least partially (not while aiming). smile.gif

As for camera position and rotation, I can look up the addresses for you, grovespaz. The camera data is stored in multiple locations, I think and it all seems interdependent. For example, in fps mode the up-down angle gets stored in 0x7E48BC and the left-right angle in 0x7E48CC; there's no tilt angle I believe. This in turn has in fp mode an influence on +0x374 into the player object (the player's horizontal angle which in turn influences the 4x4 matrix that is located at +4 into the player object. (Just to show you that information seems to get stored redundantly at times).

If you want to have *total* control over camera, I would suggest hooking into the game after the camera updater proc has been called and just overwriting the transform data. I would have to look up the address, also the addresses of the actual transform matrix. If you have found the position addresses of the cam on your own, just have a look at the floats preceeding the position xyz. Quite likely the position floats will likewise be part of a 4x4 transform matrix as with the player object. (The aforementioned offsets would suggest just that too... as they correspond to a41, a42, a43 matrix entries - where the pos data would be located.)

Alex

grovespaz
  • grovespaz

    Group: Morons

  • Members
  • Joined: 22 Feb 2004

#863

Posted 19 April 2007 - 06:00 PM

QUOTE (ntlofub @ Apr 12 2007, 19:27)
The camera is controlled by a function in the game that continuously calculates a three-element array of floats containing a predefined offset from your X, Y, and Z position.

CODE
46DA31: fstp dword ptr [ebx+0x30];; X Camera Position
46DA38: fstp dword ptr [ebx+0x34];; Y Camera Position
46DA3F: fstp dword ptr [ebx+0x38];; Z Camera Position


These instructions are three bytes a piece. To disable them from occuring (and thus enabling manual control of the camera), simply do the following:

CODE

void NOP(DWORD dwAddress, int iSize)
{
 DWORD dVP1, dVP2;
 VirtualProtect((PVOID)dwAddress,iSize,PAGE_EXECUTE_READWRITE,&dVP1);
 memset((PVOID)dwAddress,0x90,iSize); // nop * (int)iSize
 VirtualProtect((PVOID)dwAddress,iSize,dVP1,&dVP2);
}

void EnableCamera()
{
 NOP(0x46DA31, 3);
 NOP(0x46DA38, 3);
 NOP(0x46DA3F, 3);
}

Thank you so much! blush.gif
Worked at the first try biggrin.gif

This is great, how did you find these out?
Ah well, now I can get cracking at my little project smile.gif

(An interesting side effect is that if you DO try to set the camera position through SCM, the camera DOES recalculate there to look at smile.gif )

AK-73
  • AK-73

    Hustler

  • Members
  • Joined: 31 Oct 2005

#864

Posted 24 April 2007 - 02:05 PM


This may have become irrelevant to grovespaz problem but for the record:
@7E4688 begins a 4x4 float matrix , that specifies camera direction and position. You have to be able to read rotation matrices to make sense of it though. The first line seems to be multiplied with -1.0f, the identity matrix (first line multiplied with -1.0f) will cause the camera point horizontally to the north without any sideways tilt. I think this matrix is the best way to manipulate camera angle, as it allows *sideways tilt* of the camera. smile.gif

Alex

Demarest
  • Demarest

    what could be

  • BUSTED!
  • Joined: 12 Jul 2003

#865

Posted 01 June 2007 - 08:17 AM

Didn't see it documented anywhere. I was wondering if anybody has figured out what memory address stores the current screen resolution (Vice City) and if so, in what format. What I mean by that is I highly doubt it stores 1280x1024x16 tounge.gif I did a bit of legwork and so no explainable changes in the area of memory that TwoZero documented as housing the other display options. VC's text_draw GXT command seems to be resolution dependent. In Coordinator v2, I had a line the person could put in their current width and height, but I'd rather be able to detect it automatically.

Squiddy
  • Squiddy

    Back!

  • The Connection
  • Joined: 06 Oct 2004

#866

Posted 01 June 2007 - 08:30 AM

I'm at home right now, so I have no vice city or ida here, so I can't say it for sure. But judging from a mod I'm working on, (one offset) it is somewhere near 0x9B48E4.

I think 0x9B48E4 was screen height, 0x9B48E0 could be width then. But there were other offsets, I'm sure someone else can help too.

Demarest
  • Demarest

    what could be

  • BUSTED!
  • Joined: 12 Jul 2003

#867

Posted 01 June 2007 - 09:49 AM

Actually, starting with #9B48DC, it seems to be width, height, width, height with each being expressed as a DWORD. Tried three different resolutions. Curious that it uses a DWORD for what could be expressed with a WORD, but since I'm only capable of SCM based mem-hacking, that's actually better smile.gif Any idea why two sets?

Thank you for your very fast reply smile.gif

Squiddy
  • Squiddy

    Back!

  • The Connection
  • Joined: 06 Oct 2004

#868

Posted 01 June 2007 - 10:47 AM

Well, there are multiple locations where the resolution is stored iirc. The one I posted was used with displaying text for the hud, maybe they keep copies of the info for different things to do. One for the D3D Device, another one for font scaling etc.

I'm also pretty sure that there was some resolution data around 0xA1XXXX..

Demarest
  • Demarest

    what could be

  • BUSTED!
  • Joined: 12 Jul 2003

#869

Posted 01 June 2007 - 11:50 AM

Well it definitely works. I've got a Darkpacted thread will a built in kill switch that resets the Darkpact code. Run it in 640 and it takes up full screen. Save and restart VC in 1280 and it takes up quarter screen (because the 640 is still being used). Use the built in kill switch and save. Then on load, the Darkpactor runs again and determines 1280 nice and proper. Thanks again.

eye776
  • eye776

    Crackhead

  • Members
  • Joined: 11 May 2007

#870

Posted 01 August 2007 - 11:47 PM

I have a (rather dumb) question:
This shold get me the player's position (on foot, if not driving)

CODE

memcpy(&nPlayer_X,(DWORD*)0x7E49C0,52/sizeof(float));
memcpy(&nPlayer_Y,(DWORD*)0x7E49C0,(52+4)/sizeof(float));
memcpy(&nPlayer_Z,(DWORD*)0x7E49C0,(52+8)/sizeof(float));


However, this executes regardless:
CODE

if(nPlayer_Z < 7.5 && nStaminaBar)
{
bPlayerInWater = true;
*GRAVITY_BIT = 0.004f;
           ProcessSwim();
}
else
...


Even if nPlayer_Z is > 10 (technically, i'm on the top of a building.)




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users