Quantcast

Jump to content

» «
Photo

[SA] Replace Sacky's SA Limit Adjuster

5 replies to this topic
Webmaster2015
  • Webmaster2015

    Agent86 Productions

  • Members
  • Joined: 27 Mar 2013

#1

Posted 19 June 2014 - 07:04 PM

Hello. I'm sure this question was mentioned before, but I'm not getting a straight answer from any other topics on this forum. I'd like to replace SALA with something more stable that covers nearly everything that SALA modifies. Preferably an ASI or CLEO limit adjuster. Now, I've seen the ASI limit adjuster from the 2dfx mod, but it only modifies some of the limits that SALA covers. Is there a mod, or a combination of mods, that will be just as good as SALA? I'm not talking about Streaming Memory fixes, I've got that covered. I'd also like to add another d3d9.dll. I've tried the "fixed" SALA to add a second d3d9.dll, but it made my game crash.

 

I would really appreciate some suggestions.

Thanks.

 

-Webmaster2015


TJGM
  • TJGM

    Gangsta

  • Feroci Racing
  • Joined: 14 Jun 2011
  • None

#2

Posted 19 June 2014 - 07:22 PM

Nope. SALA has a bunch of useless limits that nobody needs, a lot of them aren't even limits either.

Webmaster2015
  • Webmaster2015

    Agent86 Productions

  • Members
  • Joined: 27 Mar 2013

#3

Posted 19 June 2014 - 08:01 PM

Can you tell me which limits are not necessary?


Deji
  • Deji

    Coding like a Rockstar!

  • Feroci Racing
  • Joined: 24 Dec 2007
  • None

#4

Posted 19 June 2014 - 10:39 PM

I know what's not necessary... a rant about limit adjusters!


Limit 'adjusting' itself is a weird and ugly concept. As good as it is to want to surpass limits, you'd be better off doing so by bypassing the limit altogether. Adjusting the limits doesn't solve the problem, but delays it. There is still a limit and unless you know exactly how much of everything you need in the game, the ultimate problem exists, which is that the game wasn't designed to allow for expansion. And especially given how well documented this game is internally now, simply adjusting the limits can be considered a lazy option.

The models in the game are stored in a statically allocated part of the memory, which will always exist. Adjusting the limits requires creating a similar but bigger area of memory. "Static adjusters" will commit the biggest sin, by replacing it with another static area of memory instead of letting its limits be further increased later - they might as well not exist at all. Adjusting dynamically is OK, but it's not really dynamic... if it comes with a file asking the user how many models are in the game - that's pretty bad. How should the user know? A good tool would be more considerate and dynamically determine the adjusted size. Unfortunately its common for a modders skills to be pretty limited. Most are writing in C and/or don't understand the supreme advantages of dynamic containers.

It's not enough to just adjust the values. You also need to make up for all the speed decreases and possible excessive memory usage. It's like over-filling a lift (an English elevator - or maybe an elevator is an American lift...) when the lift had a very specific maximum weight. Not only that, but you're adding a tonne of extra floors overhead (get it?). Building another, bigger lift seems like a quick solution, but how many lifts can you fit around the frail foundations of the GTA SA game engine? It's not a reliable technique to introduce a more manageable problem in place of a pre-existing one, which is basically the same problem. And now the original lift, which was perfectly fine until you started cramming things into it, is going to waste.

It may sound a little sci-fi, but what if you were to keep the original lift, give it a back door, and then have a new lift, where 'extra' passengers could be wait temporarily until the original lift was free enough for them to walk through to their floor? Then, they can still get to where they're going without occupying the main lift permanently. Better yet, since the old lift is the one we don't like, have IT lead into the new lift, which is outfitted with all sorts of other sci-fi things to better manage the distribution of people to their respective floors.


So, while it's easy to just hack limits the way you want them, contemplate hackyness with a bit more of an understanding of those boring advanced programming techniques (which it seems are made for a reason) and you could build something way more powerful. Everyone tries to make and even remake limit adjusters, when what is really needed is better management of the content being served out. Instead of trying to shape something not right to do what you want it to, create what you're trying to create and design it around that shape. What will come out will be MUCH better. And since you're trying to improve upon something, you might as well go all the way.

This, is certainly why have yet to even attempt a "limit adjuster". Not like I haven't thought of it, but I tend to think too much and figure out why it'd be better to do something way more complex and time-consuming that I haven't any time for. But also there's the fact that a lot can and really should done to SA's game engine - and I am attempting to do this in a way which should leave a trail of tightly-connected, helpful modding tools and game expansions and follow an order to ensure that I work on the things I'd need to work on others for first. Hopefully someone will beat me to it, because it will take a while for my plans to start coming into fruition and I'm sure I'm not the only one with big plans right now. Revolutionary things should start happening that will be able to echo through GTA's past, present and future. That's another advantage of the "build your own" technique over the "adjust theirs" one, by the way... once you build it fully, you can use most of it for other things, such as implementing it in another game or even your own game. Much more worth waiting and working harder for, if you ask me.


A couple of other valid metaphors would have been: people eating too much food off the same plate and too many people sharing a taxi - just sayin' :p

  • LINK/2012 likes this

fastman92
  • fastman92

    фастман92 | ف

  • Members
  • Joined: 28 Jul 2009
  • None

#5

Posted 20 June 2014 - 06:32 AM Edited by fastman92, 20 June 2014 - 06:51 AM.

@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.

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.

The cost of making limit adjuster like your idea specified is exceedingly high.

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci Racing
  • Joined: 24 Dec 2007
  • None

#6

Posted 20 June 2014 - 12:06 PM Edited by Deji, 20 June 2014 - 12:14 PM.

 

@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 :p

 

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[0].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 :p

 

 

EDIT: Gee, that's big. And GTAForums almost risked losing most of it.

EDIT 2: Oh yeah.. TL;DR...

 





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users