@Deji, excuse me for a short reply, I usually work more than write.
You presented idea that indeed sounds good.
However it's nearly impossible to apply this technique for many of the limits in game when all we have is the compiled executable code, not R* source code.
Let's say you're going to hack ID limit (0-19999). You are unable to make this limit dynamic.
I don't see why. And as I'm saying, I wouldn't try to hack the limit on model ID's, I'd find another way to deal with additional content. One which specialised in allowing easier modification (LINK's modloader already takes in some concepts which would be shared with this) - what's the point in breaking model limits if it only introduces a new limit, is still just as hard to install and the format has all the limitations of the current? We could create a whole new format, designed for better modding potential, and transfer to using that in future. Old mods may still have problems, but since we can do this without modifying the original system, they only have the problems they started with, which could easily be solved by cheap limit adjusting tricks
You seem to refer to this a lot:
void __cdecl CStreaming__RequestModel(signed int dwModelId, int a2)
v4 = 20 * dwModelId;
v2 = CStreaming__ms_aInfoForModel[dwModelId].bLoaded;
if ( dwModelId >= 20000
|| (unsigned __int8)CModelInfo__ms_modelInfoPtrs[dwModelId]->__parent.__vmt->getType(CModelInfo__ms_modelInfoPtrs[dwModelId]) != 7
&& (unsigned __int8)((int (*)(void))CModelInfo__ms_modelInfoPtrs[dwModelId]->__parent.__vmt->getType)() != 6 )
if ( !(*(&CStreaming__ms_aInfoForModel.flags + v4) & 6) )
LoadedObjectInfo__addToQueue((LoadedObjectInfo *)((char *)CStreaming__ms_aInfoForModel + v4), dword_8E4C60);
Why insist that all objects must go through functions as cheaply written as that? Tthey could be loaded differently, and be a completely separate set of ID's altogether! They could be named instead, using hash maps to locate the object. CPU intensive you say? SA's system when linking model names to their ID's is to check EVERY hash (using SA's usual collision-prone CRC32 algorithm and ushering in plenty of room for naming conflicts since it doesn't verify the name) in that static array of 20,000 elements, starting at 0 and checking every one until it finds the first matching hash (0x4087E0), so a huge improvement could be made over that with C++'s associative containers alone. Even an std::list wouldn't be much slower, and at least it doesn't have a limited number of slots.
After adjusting limits, you still don't solve the problem of conflicting ID's - and you're adding more work for the game engine itself, which wasn't designed to cope with such high limits. If that 'CModelInfo::GetModelInfo' procedure was called with the limits merely adjusted, it could end up checking 50,000 individual keys one by one (multiple times per frame probably - even if it was found just a second ago). Adjusting causes problems, because it further heightens the games original code weaknesses - which were only acceptable in the game before as the limits were restricted enough it didn't matter.
The production cost of limit adjuster has to be considered, example nowadays you may use C# or Java languages where speed isn't highest when compared to CPU languages (C, C++, Pascal), although you don't care about the speed most of the times because CPU is very fast anyway. Someone may use C# to decrease a production cost and doesn't care about miliseconds of execution.
We have a lot of RAM today, so loosing a few KB of memory could be considered as better sollution than increasing production cost (difficulty) several times.
I don't understand what you're saying here at all. I'm a C++ programmer and have recently felt the warm embrace of following all the latest standards (C++11 ftw - until C++14 of course) - C# and Java aren't the only languages which provide dynamic memory storage. The problem with simply using "this big block of memory" is that it remains just that big block of memory. It might not be enough to store the models that will try to be loaded and the game will crash. Too many models may be loaded and you've just got wasted space that could be used for other things.
The cost of CPU doesn't matter - all the allocations would be made to happen during the games start-up - when the extra objects are being counted and loaded.
The bigger issue to worry about with my idea is formats. Why use a format we've hacked and reverse-engineered into making sense? One we had to learn from the game... Why not create our own, and teach the game how to use it? It's a similar problem throughout the SA engine (ones that R* have already improved upon in later games), as it was only made for a finite number of possible improvements. Some are great, actually, but most, even the interesting ones are severely limited. Creating a new format is hard, though, as I've been discovering for the past couple of months. Of course, when I'm done, what should be provided is a better way to mod, without affecting any original game files. Add the hook, drop in the new file type and let the application do the work of finding out where it even goes.
The cost of making limit adjuster like your idea specified is exceedingly high.
I'm ranting about the problems with limit adjusters.. I'm certainly not suggesting to write another one. There are alternative ways around most problems, but I believe those who create limit adjusters go for the first they see. "Oh look, there's a number - lets increase it" and "Oh look, we can't just increase the number because the data is static it will cause an overflow, lets just move the data completely". Sure, it's much easier than hacking or rewriting a load of functions or actually trying to gain an understanding of what you're trying to fiddle with, but if you aspire to truly understand how games work and learn about SA's techniques, as well as alternatives that are already out there (a lot of open-source stuff included) you may figure out that the old implementation isn't even worth salvaging. You might even feel the desire to completely rip out the system and replace it with a new, but "backwards compatible" one, which could fix a great number of issues with the game before you go and ruin it with more mods
EDIT: Gee, that's big. And GTAForums almost risked losing most of it.
EDIT 2: Oh yeah.. TL;DR...