(adsbygoogle = window.adsbygoogle || []).push({}); So if i may ask, why does everyone say there is an 'injection limit' for GSC size on PS3? Im pretty much 100% certain there is no such thing and that the block of memory we are injecting at just isnt big enough. Anyone have any rebuttals? If you say there is, please provide actual evidence and not 'i tried to inject xyz and it didnt work so there has to be' and more like 'size must be less than uint maxvalue' or something legitimate . Thanks.

Answer explained for those who did not understand initially:
1: The only limit to GSC is the maximum memory partition you can reach before overwriting crucial system information or other files loaded into memory. This means that by finding a bigger memory space, you are able to inject much larger files.
2: The technical limit to GSC is impossible to reach, but is a fun trivia piece of information for those who want it (uint max value: 4294967295 bytes ) because GSC specifies file size in uint as a compilation parameter.
3: 0x51000000 will give you approximately 7.5MB of space for your GSC. (Not 100% sure of size because it was a tool i made that detected it and the tool cant handle non existant mem regions, but, its still a fuckload)
I have personally tested injection to this offset and it works fine. Only bug is that this apparently sticks in memory after ps3 restarts (no idea why, must be something important ) so you will need to null out the space before injecting, but elsewise, enjoy.
Credit for this 'discovery' if you could call it that, would be nice. Thanks. Admins, you are good to close it.

It isn't required until you get the "maximum amount of parent script variables has been reached" error, otherwise it isn't necessary.

oh alright thanks for the clearing that up for me

Of course there is "no limit" you'll ever reach if you distribute your injection across different GSC files and make sure the memory region occupied by the new scripts is "unused" by the game because if you overflow into something important you might crash. That's the actual limit that people might encounter. I also found that using "big" GSCs can be bad so splitting them up is useful. I wrote an injector.

That isnt how you get the error .

It may not be how you get the error but it's a way to fix it, I've fixed it many times by splitting GSC's.

Bro, that makes no sense. From a development perspective, splitting the files literally makes 0 difference.

It makes no sense to me how it works either, but as I said it does and has for me.

If you look at the address in memory a GSC Injector like GSC Studio is writing to you will see that it will eventually get to an address that is constantly getting written to. I had mapped it out before when xTurntUpLobbies asked me about it, though I don't currently recall though how much space you have until you reach that area in memory where it's constantly getting written to as it was months ago.

Anyway once your GSC gets to a certain size part of it will be written into the address that the game is writing to and get overwritten by the game and when that happens the game freezes.

Not really a size constraint, just a bad spot for injecting as if you inject multiple files with GSC Studio eventually one of your GSC files will write to a game written address and cause you to freeze.

The best method I can think of to solve this is to allow GSCs to be written to addresses that you know will not be written to by the game, so once you find an address find how far you can go into it until it get's written to by the game. Once you have that, you will know big of a GSC file you can store there and find more addresses if you need more room for injecting other GSC files.

Most people messing with GSC don't really understand how injecting works so they just assume it's a size limitation and is why people think of it as that.

Thanks. Thats what i assumed to begin with but when you have people in the community who have somehow managed to get menus big enough to fill that space, they assume it is a size constraint and i wanted to be sure.