Quantcast

Jump to content

» «
Photo

[V] Script/Native Documentation and Research

1,000 replies to this topic
Fireboyd78
  • Fireboyd78

    Strangely Animated

  • Members
  • Joined: 30 Apr 2011
  • United-States

#991

Posted 30 December 2016 - 03:38 AM Edited by Fireboyd78, 30 December 2016 - 03:47 AM.

Here are native addresses for b944 (social club version): http://camx.me/gtav/...sses-b944_2.txt

 
Why post the addresses when the base is dynamic?
 
http://pastebin.com/WA8c4Zan

You need to patch the exe with a hex editor to disable layout randomization. Change offset 0x186 from 0x22 to 0x23.


A bit late to responding to this, but I finally figured out what Cam meant. Basically, you want to turn on the "Relocation stripped" flag for the Characteristics of the PE. Steam version offset is 0x17E as of 944.

Thank you so much for this tip. I can finally create my own dumps!

uNiverselEgacy
  • uNiverselEgacy

    Player Hater

  • Members
  • Joined: 15 Jul 2015
  • United-States

#992

Posted 16 January 2017 - 09:28 PM

I was always wondering why SHV is not written in a way that a direct translation table is generated at startup instead of having to go through 10+ tables (now that we got 10+ updates since 335) every time a native is called? Is it because such optimization has little impact on the overall performance? But I think with scripts that call hundreds if not thousands of natives each frame, such change might make a slightly noticeable difference.


unknown modder
  • unknown modder

    Bon Jon Bovi

  • Members
  • Joined: 04 Jul 2012
  • United-Kingdom

#993

Posted 18 January 2017 - 04:16 PM

I was always wondering why SHV is not written in a way that a direct translation table is generated at startup instead of having to go through 10+ tables (now that we got 10+ updates since 335) every time a native is called? Is it because such optimization has little impact on the overall performance? But I think with scripts that call hundreds if not thousands of natives each frame, such change might make a slightly noticeable difference.

Its not done like that. When you call a native, the hash gets translated to current game version, then it finds the handler for the native and stores it in a map to cache it. Next time you call that native it just retrieves the cached handler. Though It still takes time searching for the cached native. A much nicer solution would be like this

inline static Ped GET_PLAYER_PED(Player player){ static NativeHandler handler(0x43A66C31C68491C0); return handler.invoke<Ped>(player); }

This would make it so that when you call a native for the first time it will still translate and cache the native, but each successive call it doenst need to do any searching at all.

Obviouslt NativeHandler would need to be defined in SHV and do translation in the ctor

  • Jitnaught and MAFINS like this

uNiverselEgacy
  • uNiverselEgacy

    Player Hater

  • Members
  • Joined: 15 Jul 2015
  • United-States

#994

Posted 18 January 2017 - 08:01 PM

 

I was always wondering why SHV is not written in a way that a direct translation table is generated at startup instead of having to go through 10+ tables (now that we got 10+ updates since 335) every time a native is called? Is it because such optimization has little impact on the overall performance? But I think with scripts that call hundreds if not thousands of natives each frame, such change might make a slightly noticeable difference.

Its not done like that. When you call a native, the hash gets translated to current game version, then it finds the handler for the native and stores it in a map to cache it. Next time you call that native it just retrieves the cached handler. Though It still takes time searching for the cached native. A much nicer solution would be like this

inline static Ped GET_PLAYER_PED(Player player){ static NativeHandler handler(0x43A66C31C68491C0); return handler.invoke<Ped>(player); }

This would make it so that when you call a native for the first time it will still translate and cache the native, but each successive call it doenst need to do any searching at all.

Obviouslt NativeHandler would need to be defined in SHV and do translation in the ctor

 

Ah my bad. I disabled or somehow messed up the cache without the knowledge of it existing, and that explains why I was always doing translations.

I like your proposed solution but obviously it requires some nontrivial change to SHV and the natives header file.


uNiverselEgacy
  • uNiverselEgacy

    Player Hater

  • Members
  • Joined: 15 Jul 2015
  • United-States

#995

Posted 18 January 2017 - 08:10 PM

0x44CD1F493DB2A0A6 seems to be the native that sets vehicle weapon ammo. I'm surprised it's a new native in 944.

Maybe it's because previous you always get infinite ammo.


unknown modder
  • unknown modder

    Bon Jon Bovi

  • Members
  • Joined: 04 Jul 2012
  • United-Kingdom

#996

Posted 18 January 2017 - 09:33 PM

0x44CD1F493DB2A0A6 seems to be the native that sets vehicle weapon ammo. I'm surprised it's a new native in 944.

Maybe it's because previous you always get infinite ammo.

Its only been added now as its needed to limit the ruiner2 missiles


 

 

I was always wondering why SHV is not written in a way that a direct translation table is generated at startup instead of having to go through 10+ tables (now that we got 10+ updates since 335) every time a native is called? Is it because such optimization has little impact on the overall performance? But I think with scripts that call hundreds if not thousands of natives each frame, such change might make a slightly noticeable difference.

Its not done like that. When you call a native, the hash gets translated to current game version, then it finds the handler for the native and stores it in a map to cache it. Next time you call that native it just retrieves the cached handler. Though It still takes time searching for the cached native. A much nicer solution would be like this

inline static Ped GET_PLAYER_PED(Player player){ static NativeHandler handler(0x43A66C31C68491C0); return handler.invoke<Ped>(player); }

This would make it so that when you call a native for the first time it will still translate and cache the native, but each successive call it doenst need to do any searching at all.

Obviouslt NativeHandler would need to be defined in SHV and do translation in the ctor

 

Ah my bad. I disabled or somehow messed up the cache without the knowledge of it existing, and that explains why I was always doing translations.

I like your proposed solution but obviously it requires some nontrivial change to SHV and the natives header file.

Yeah, While its nice, Its not going to be implemented unfortunately. Though it could easily be added alongside the current method for SHV.


Unknown_Modder
  • Unknown_Modder

    ⭐⭐⭐⭐⭐

  • Members
  • Joined: 07 May 2015
  • Germany

#997

Posted 4 weeks ago Edited by Unknown_Modder, 2 weeks ago.

Here's another new (build 944) native:
static BOOL _DOES_VEHICLE_HAVE_DOOR(Vehicle vehicle, int doorIndex) { return invoke<BOOL>(0x645F4B6E8499F632, vehicle, doorIndex); } // 0x645F4B6E8499F632
Spoiler
  • sasuke78200, Jitnaught and R3QQ like this

Unknown_Modder
  • Unknown_Modder

    ⭐⭐⭐⭐⭐

  • Members
  • Joined: 07 May 2015
  • Germany

#998

Posted 3 weeks ago Edited by Unknown_Modder, 2 weeks ago.

Sorry for the double post but I can't believe no one named 0xFC695459D4D0E219 yet so I did it. It's that obvious:
Spoiler

http://www.dev-c.com...c695459d4d0e219

qiangqiang101
  • qiangqiang101

    I'm Not MentaL

  • Members
  • Joined: 02 Feb 2010
  • Malaysia

#999

Posted 3 weeks ago Edited by qiangqiang101, 3 weeks ago.

Can someone change int PATHFIND::GENERATE_DIRECTIONS_TO_COORD to void?

 

int GENERATE_DIRECTIONS_TO_COORD(float x, float y, float z, BOOL p3, float *direction, float *p5, float *distToNxJunction) // 0xF90125F1F79ECDF8 0xED35C094

 

BOOL p3 was 1

 

direction:
0 = You Have Arrive
1 = Recalculating Route, Please make a u-turn where safe
2 = Please Proceed the Highlighted Route
3 = Keep Left (unsure)
4 = In (distToNxJunction) Turn Left
5 = In (distToNxJunction) Turn Right
6 = Keep Right (unsure)
7 = In (distToNxJunction) Go Straight Ahead
8 = In (distToNxJunction) Join the freeway
9 = In (distToNxJunction) Exit Freeway

 

http://dev-c.com/nat...90125f1f79ecdf8

  • R3QQ likes this

unknown modder
  • unknown modder

    Bon Jon Bovi

  • Members
  • Joined: 04 Jul 2012
  • United-Kingdom

#1000

Posted 3 weeks ago Edited by unknown modder, 3 weeks ago.

snip

Just because it always returns 0, doesnt mean its a void

void __fastcall pathfind__generate_directions_to_coord(NativeContext *a1)
{
  NativeContext *v1; // [email protected]
  NativeVector3 v2; // [sp+30h] [bp-28h]@1

  v1 = a1;
  sub_13FF34F98(
    &v2,
    (NativeVector3 *)a1->Args,
    a1->Args->Arg4.DWORD,
    a1->Args->Arg5.PDWORD,
    a1->Args->Arg6.PDWORD,
    (float *)a1->Args->Arg7.QWORD);
  v1->Returns->Item1.DWORD = 0;
}

this behavior is still seen on the current game version, though R*s native obfuscation makes it harder to find


Keklol
  • Keklol

    Player Hater

  • Members
  • Joined: A week ago
  • None

#1001

Posted A week ago

where I could download the latest version of the SDK? :r*:





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users