VC path hack and spawn area hack

[Swoorup]

I think we should contact R* about how the spawn area limits and work! By having the idea about this maybe it will be easier and certain.

[ALMOST610]

You can try but I think you would be lucky if you got a useful response or if they even helped you.

[Swoorup]

I think the deleting of 16x multiplier hack should be revised properly(connecting them right) if there's no other way round

[Swoorup]

Found something related to renderware AI path data!!!MAXorator you might want to check this

http://www.mediafire.com/?2yy4ax4tfm9htod

 

EDIT: Nothing useful. Don't bother downloading this

Edited February 8, 2012 by Swoorup

[Swoorup]

I know this is an several months old topic and Yup I posted without editing ( I was a noob before )

But I just would like to ask if anyone has anything that documents dis-assembly of things related to this path and world coords hack.

 

Just want to give it a try myself but I have only documented a very functions myself.

 

Thank you

[AK-73]

I know this is an several months old topic and Yup I posted without editing ( I was a noob before )

But I just would like to ask if anyone has anything that documents dis-assembly of things related to this path and world coords hack.

 

Just want to give it a try myself but I have only documented a very functions myself.

 

Thank you

My advice: don't. It's possibly very burdensome for a single coder and there is no guarantee of success even if you have 3 coders at hand. There is a fair likelihood of ever new holes opening up. And you'll likely cause bugs that only appear years down the drain where nobody will be able to pinpoint the actual cause easily.

 

If R* had been using constants instead of enums, it would have been easy.

 

 

Alex

[Swoorup]

You meant constant stores data in a variable/ memory address whereas enum is directly converted to numbers at the compile time right?

But wouldn't it be easier if a lot a functions and local/global variables were labelled after years and years of discovery? Combining every works of knowledgeable and wise person like you?

 

Thank you.

[Swoorup]

I am pretty much wanting to work on the spawn grid limit. However, as R* has imposed several 8 bits limits, I want to look at the workaround which Andy was working with, By removing the 1/16 multiplier and multiplying the all the paths cords by that number.

 

Post by Steve-m:

http://www.gtaforums.com/index.php?showtop...dpost&p=2869336

 

 

That's some interesting info there... I knew where the buffers were and moved all of those upward (to make more space for them) but I had to leave some of the links in their original places (they caused the game to crash)... and I think that might have something to do with the game crashing whenever cop cars chase you.  The actual path boundary limit is probably linked to one of the 1/32768 float values, so maybe it can be found by hacking each value. All I did was hack the multiplier so that it doesn't multiply by 16, but the paths don't connect right.

 

I did some more work with the water levels, and found two points that caused the main water to be extended beyond the boundaries. Unfortunately, changing them causes weird gray strips to show up in the water... and some of the water disappears randomly which is kind of weird.

 

 

 

[PlatinumSerb]

I am pretty much wanting to work on the spawn grid limit. However, as R* has imposed several 8 bits limits, I want to look at the workaround which Andy was working with, By removing the 1/16 multiplier and multiplying the all the paths cords by that number.

 

Post by Steve-m:

http://www.gtaforums.com/index.php?showtop...dpost&p=2869336

 

 

That's some interesting info there... I knew where the buffers were and moved all of those upward (to make more space for them) but I had to leave some of the links in their original places (they caused the game to crash)... and I think that might have something to do with the game crashing whenever cop cars chase you.  The actual path boundary limit is probably linked to one of the 1/32768 float values, so maybe it can be found by hacking each value. All I did was hack the multiplier so that it doesn't multiply by 16, but the paths don't connect right.

 

I did some more work with the water levels, and found two points that caused the main water to be extended beyond the boundaries. Unfortunately, changing them causes weird gray strips to show up in the water... and some of the water disappears randomly which is kind of weird.

Im pretty sure one of the Limit Adjusters by Andy had the ability to automatically take a path file and divide the coords to work with whatever the multiplier was defined in the exe.. "fit paths to bounds" or something similar is the name of the option. See if you can get some of the previous versions of the Limit Adjuster from Keith. I'll see if I can find some of the older ones when I get home later on today.

[Swoorup]

I removed the 1/16 multiplier at here 687C88 and replaced it with 1. And I divided all the path co-ords by 16. And it seems to work well with the ped paths.

For the car paths, at some point the game can't find the next GOTO coords and it simply returns back the path it was coming from.

 

I think that could be solved by putting the all the node coords very close to each other so that the node does not break in between.

 

There might a other way round for the paths too. Making custom functions that redirect the paths function for processing the coords, next point index.

 

EDIT:

 

struct CPed{0x338 CPathNode* CurrentWanderingNode;0x33C CPathNode** NextWanderingNode;};

 

 

There might not be easy way to increase the paths. The path's coordinates from ipl file is truncated and is multiplied by 8 (after multiplying it by 1/16) and stored in a signed 2 bytes space in PathNode struct.

Now the signed values have limits ranging from -32767 to 32767. So the limits for path coords would be -4095 to +4095 after division by 8.

The 16 bit limit is same for GTA SA and the values are stored after multiplying by 8

 

 

GTA Vice City

From (-2300,-1900,-INF.) to (1540,1900,INF.) approximately, standard units.

Total area: 14.6 square kilometers.

GTA San Andreas

From (-3000,-3000,-INF.) to (3000,3000,INF.) standard units.

Total area: 36.0 square kilometers

 

The 16x multiplier hack may be able to increase the original limits but it would increase not above that number.

The solution to this may be redirecting every function that accesses this struct. But that would of course take a very long time.

 

 

struct CPathNode //size 0x14{_uint16 unk1; Always 0xFFFF_uint16 unk2; Current Index?_int16 x;  Divided by 8_int16 y;_int16 z;_int8 unk3;_int8 unk4;_int16 nextPointIndex;_int8 unk5;_int8 unk6_int8 flags; _int8 unk7_int8 unk8_int8 unk9;}

 

 

As for the nodes not connecting properly after 16x multiplier hack, It might have to do something with the closest Node search radius. This function CPathFind::FindNodeClosestToCoors returns -1 if the node is not found. If it finds it would return a pointer to a pathnode struct.

 

This might be occuring with the vehicle paths only since the peds path are close to each other in every nodes (Or most of the nodes I should say). Vehicles node tends to break up in a straight highway since the nodes are placed very far to each other.

Also there might be an angle problem while taking a turn.

I have not seen this issue with peds path though.

 

I have fairly decompiled that function.

 

signed int __userpurge CPathFind__FindNodeClosestToCoors<eax>(GlobalMap *global<ecx>, signed int curObjecttypetIndex<ebx>, signed int LastObjecttypeIndex<edi>, float x, float y, float z, char type, float searchRadius, char skipForbidden, char flag2, char flag3, char flag4){ signed int v12; // [email protected] double v2; // [email protected] double VfY; // [email protected] signed int _curObjecttypetIndex; // [email protected] CPathNode *curRouteNode; // [email protected] int curRouteNodeOffset; // [email protected] double curRouteNodeY; // [email protected] float curRouteNodeX; // [email protected] double v3; // [email protected] double v21; // [email protected] double xOffset; // [email protected] double yOffset; // [email protected] double curRouteNodeZOffset; // [email protected] double zOffset; // [email protected] double v26; // [email protected] signed int result; // [email protected] v12 = 0; VfY = y; v2 = f10000; switch ( type ) {   case 0:                                     // For vehicles     curObjecttypetIndex = 0;     LastObjecttypeIndex = global->lastVehicleRoutePointIndex;     break;   case 1:                                     // For Peds     LastObjecttypeIndex = global->lastPedRoutePointIndex;     curObjecttypetIndex = global->lastVehicleRoutePointIndex;     break;   default:     break; } _curObjecttypetIndex = curObjecttypetIndex; if ( curObjecttypetIndex < LastObjecttypeIndex ) {   curRouteNodeOffset = 20 * curObjecttypetIndex;// Since size of CPathNode is 0x14 = 20   curRouteNode = (global->paths + curRouteNodeOffset);   do   {     if ( !skipForbidden || !((curRouteNode->flags >> 5) & 1) )     {       if ( !flag2 || !((curRouteNode->flags >> 6) & 1) )       {         if ( !flag3 || !((curRouteNode->field_11 >> 2) & 1) )         {           if ( flag4 == (curRouteNode->field_11 & 1) )           {             curRouteNodeY = *(&global->paths[0]._y + curRouteNodeOffset) * f8Divider;             if ( curRouteNodeY - VfY < f0 )               v3 = curRouteNodeY - VfY;             else               v3 = -(curRouteNodeY - VfY);             yOffset = v3;             curRouteNodeX = *(&global->paths[0]._x + curRouteNodeOffset) * f8Divider;             v21 = curRouteNodeX - x;             xOffset = v21;             if ( v21 >= f0 )               xOffset = -v21;             curRouteNodeZOffset = *(&global->paths[0]._z + curRouteNodeOffset) * f8Divider - z;             if ( curRouteNodeZOffset < f0 )               zOffset = curRouteNodeZOffset;             else               zOffset = -curRouteNodeZOffset;             v26 = xOffset + yOffset + f3 * zOffset;             if ( v26 >= v2 )             {               v2 = v26;               v12 = _curObjecttypetIndex;             }           }         }       }     }     ++_curObjecttypetIndex;     ++curRouteNode;     curRouteNodeOffset += 20;   }   while ( _curObjecttypetIndex < LastObjecttypeIndex ); } if ( v2 < searchRadius )   result = -1; else   result = v12; return result;}

 

 

Anyone could give a suggestion to do those hacks?

The peds are controlled in this function 00505790 CPed::ProcessControl((void)) using all the data from this struct. They include Buoyancy, Heading to PathNode ,etc

We might be able to make a custom path system if we have enough knowledge on it. Well can't say for sure.

 

Same for the Vehicles by redirecting functions from CCarCtrl?

 

CPed::SetWanderPath 004FA680

At this address RET the first opcode,

Peds will have no specfic paths they will go wherever they like but, spawns are still handled from paths positions

Edited March 9, 2012 by Swoorup