Jump to content

Open Limit Adjuster


Recommended Posts

Well, try to use a value big enough to run the game, instead of unlimited then. Currently we're not sure what's wrong.

 

Sure thing, no problem. Like I said in one of my previous posts, I've only mentioned this issue for the sake of bugs & further LA development... As far as the gameplay goes it's all taken care of by removing unlimited & replacing it with 10000, just like in MVL. My bigger concern is the memory thing, because I can't finish my graphical overhaul, modding the game to a real-life level. Well, technically I can - I just don't see the point since the game is unplayable :(

 

SA also has the memory issue, but maximum is 1.5-1.6GB. Like an engine limit.

 

I've gotten SA to go around 2.4+GB RAM before, as shown by Task Manager.

But yeah, funny things happened after I hit the 1.6GB-ish mark. It was like I didn't have a StreamMemFix solution.

 

Yes, it does! It's been a loooong time since I've messed around with SA (in 2011 I believe), but yes - I've had the similar issues back then, as well. Honestly not trying to sound mean or hateful, but I just don't see the point of all the limit adjusters & memory "tweakers", since all of them seem to be having the same problem. And let's be honest, the only reason why ppl actually use limit adjusters, is because they want to overload their games with lots of new stuff & fancy graphics .... so therefore it's only a matter of time before people will start experiencing the same problems, all over the place. Come to think of it, they actually /did/, that's why Alexander Blade (I believe that's his name) made one of the 1st memory streaming fixes for SA, back in 2008/9 maybe? That's how all this memory-tweaking era started.

Edited by SomeGuy86

https://github.com/ThirteenAG/limit_adjuster_gta3vcsa/releases/latest

v1.5.4 released, just AtomicModels isn't unlimited anymore in VC and implemented the limits fastman92 posted earlier.

  • Like 1

 

	void ChangeLimit(int id, const std::string& value)	{				if (id = MAINsegmentSize)		{			Game_GTASA::SCMlimits::iMAINsegmentSize = std::stoi(value);		}		if (id = MissionSize)		{			Game_GTASA::SCMlimits::iMissionSize = std::stoi(value);		}		Game_GTASA::SCMlimits::PatchScriptLimits();	}
I think it might be wrong.

 

If someone changes two limits, MAINsegmentSize and MissionSize, why should PatchScriptLimits be executed twice?

 

 

		// Patches script space limits, should be executed when all 2 limits are set.		static void PatchScriptLimits();

You should change all limits, if they are changed, then execute PatchScriptLimits();

Edited by fastman92

Probably better to ask here: http://gtaforums.com/topic/733982-relsa-fastman92-limit-adjuster/

Because we don't have those even.

Edited by ThirteenAG
  • 2 weeks later...

Is handling lines ID adjuster going to be added?

Not at this time.

 

Is handling lines ID adjuster going to be added?

Not at this time.

 

Wasn´t it already being added in an erlier version?

 

 

Is handling lines ID adjuster going to be added?

Not at this time.

 

Wasn´t it already being added in an erlier version?

 

It's part of my limit adjuster, not openLA which this thread belongs to.
  • 3 weeks later...

this limit adjuster have two bugs, when you start a new game the game crashes on the first game cutscene liberty city airport message, and cj are invisible in all cutscenes...

 

Not this mod !

 

I had that very same problem while using an old version of SA Delta time fix (from Mix-Mod blog)

 

With the latest version...those kind of problems now are gone.

 

.

Edited by pep legal
  • 1 month later...

Is there any chance to make this compatible to Steam versions?

Doubt it. In any case most of SA modding only works in 1.0 US so you best bet is to downgrade really.

Edited by LINK/2012
  • 4 months later...

Aight so since this thread has been bumped, I want to ask something I was meaning to ask for some time now.

 

About the collision limits, I don't really understand how it works, I've been remaking a few collision models in SA in hopes to make shadows display on all surfaces, but the thing is, I have no idea how crazy I can go with it, I fear some day the game may crash or something because I hit the collision limit.

 

So the question is, do I have to worry about increasing the amount of detail in various collision models if I use OpenLA? Or for that I need to use fastman's limit adjuster?

 

If that's the case can you guys please implement the hacked collision limits into OpenLA? Cause I don't really feel like using the Hoodlum EXE again just for fastman's limit adjuster :s

wasn't it collision resource indices? That's, lae_1.col, lae_2.col occupies collision indices (which you need F92LA), while the cols inside them occupies collision models (which is unlimited here).

 

Other collision limits are purely file format limitations (collision spheres per colmodel, collision cones per colmodel, shadow faces per colmodel, whatever per colmodel), which is 65535 (or 32767?) for most stuff.

Edited by LINK/2012

wasn't it collision resource indices? That's, lae_1.col, lae_2.col occupies collision indices (which you need F92LA), while the cols inside them occupies collision models (which is unlimited here).

 

Other collision limits are purely file format limitations (collision spheres per colmodel, collision cones per colmodel, shadow faces per colmodel, whatever per colmodel), which is 65535 (or 32767?) for most stuff.

Oh I see, so if I understand it correctly if I use new/extra .col files I will need fastman's adjuster. But if I modify the original collision models inside the vanilla .col files like crazy I will be fine?

 

I say this because I'm using Blender to convert .dff files to .3ds files and then using CollEditorII to import the .3ds files as a perfect collision model, this way the collision models are pretty much identical to the .dff files, ofc I'm not doing it to all models, only the ones that use boxes wich don't receive shadows.

 

Man if this is really the case then, oh boy... :sly:

Yes, you'll be fine if you don't add any more .col files. Adding more collision models to existing .col files is fine too.

Edited by LINK/2012

Yes, you'll be fine if you don't add any more .col files. Adding more collision models to existing .col files is fine too.

That's amazing! :D

 

Thank you for the explanation mate, now time to fix those damn original R* collision models and get rid of those boxes once and for all :p

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 0 User Currently Viewing
    0 members, 0 Anonymous, 0 Guests

×
×
  • Create New...

Important Information

By using GTAForums.com, you agree to our Terms of Use and Privacy Policy.