New custom objects, anims, vehs, skins...

[Piorun]

Hi.

I've got an idea to create functions like "loadCustomDFF", "loadCustomTXD" etc. with different IDs (not replacing old models, anims...)

What do you think about it?

[Oz.]

Do you mean adding new DFFs, not just replacing existing ones? Sounds good, I'd probably get a lot of use out of something like that. Could you explain more?

[Dark Dragon]

Just like gravitation limits you from going straight up into the sky there are some things that limit you in gta as well.

[Faw[Ful]]

about objects : replacing existing one its very OK , because you can replace alot of unused gta sa object.

about vehicle : could be useful if you want the old one and the new one at the same time.

[Oz.]

Just like gravitation limits you from going straight up into the sky there are some things that limit you in gta as well.

The limitation you are referring to is the unique object limitation in gta3.img?

I was under the impression that he was proposing something for MTA which would bypass gta3.img's object limitation, since (presumably) objects would be 'added' using LUA, rather than inserted into GTA's game files. Maybe I'm misunderstanding what he is suggesting.

I'd secretly been hoping something like that would be possible in MTA1.1, it's a pain in the arse scouting for unused objects to replace.

[dzek (varez)]

Adding custom ID's would be possible, but GTA have some limits for adding ID's. Adding more than (rounded value, idk exact, in VC it was around 70?) ~100 will cause game not to load (and trying to hack into GTA memory (like MTA) - so after game is loaded - will probably crash MTA).

As for vehicles - it's not so easy to add vehicle ID. Probably it's limited (low limit) too.

[DiSaMe]

If MTA SA could imitate new IDs itself by replacing models which are not in use and restoring them when needed, there would be no need to change GTA SA limits. That's scriptable, but custom models functions don't work well enough. MTA SA already does a little bit of replacing/restoring: when you replace some ID, new objects are created with it, but GTA SA internal objects remain the same. However, they are replaced too, if a custom object with the same model ID is streamed in. So what MTA does is replacing models when objects using them are visible and restoring them when no object using that ID is near.

[Remi-X]

Build in limit adjuster?

[Oz.]

Yes please

I'm slowly running out of interior objects to replace

[dzek (varez)]

when you replace some ID, new objects are created with it, but GTA SA internal objects remain the same

not true, at least for me, and i believe it SHOULD be not true. test it again mate

[DiSaMe]

when you replace some ID, new objects are created with it, but GTA SA internal objects remain the same

not true, at least for me, and i believe it SHOULD be not true. test it again mate

I tested it again and it works exactly how I described that. I used ID 13050, which is used by world object at the center of the map. When I replace that ID and create an object far from the center of the map, original object remains the same. When I create object near the original one, then original object has custom model too, resulting in a hole at the center of the map. So why shouldn't what I wrote be true if that would mess up the original map? I think YOU should test it again by putting custom object further from the world object.

[dzek (varez)]

I downloaded "sk8park" or however this res was called - it's located in Santa Maria's Beach (or however its called - this one in LS). After running this - if you will go for a trip to SF - you will see huge skatepark and hovering ramps and loops around the city. It was working like that for me, my sister, 2 friends, and probably everyone on the server. Maybe something is updated recently to change this behaviour? I'll try this today's evening.

[DiSaMe]

I had already told you that this bug does occur with some IDs. When I replaced many models with Liberty City models, starting from ID 1000, then world trees were replaced, but when I made the list start from ID 2000, GTA SA map was just fine.

[dzek (varez)]

Oh, "some IDs". Missed that.

Give me one ID - so I can test it.

[DiSaMe]

I tried replacing IDs from 1000 to 2000 at the same time. Results: sometimes some dynamic objects such as 1407 or 1419 are replaced even when there are no nearby MTA objects with the same ID.

[nowofresh]

It is very good idea. I want add new custom objects, too !

[Remi-X]

Fix for everyone who has trouble with this:

-Import an object, but be sure the original object is far away from your replacement

-Replace it when you come nearby your custom object

-Revert it to the default object if you leave the replaced object

Like this you would be able to even replace the biggest buildings, without anyone notices.

[dzek (varez)]

The problem is when you want to use your object multiple times

onClientElementStreamIn and onClientElementStreamOut wouldn't be enough, every stream out you will have to get all objects within stream range, check if there is object with your ID, then unload object if there isn't any other object with this id.

[Oz.]

Where possible, just use object IDs that are native to the Interiors. That way there will never be conflicts with objects that exist in San Andreas int 0 (unless you are using those objects in a map edit or something).

[DiSaMe]

I already tried replacing and restoring those objects, depending on the distance, and that wasn't very stable.

[Oz.]

You tried replacing and restoring Interior objects? Kayl and I had been using interior objects as the basis for custom model replacements for months, I don't think we encountered any instability or problems with them that made them unusable. Not that I can recall, anyway. Though he's got some l33t scripting skillz so he may have tried a few different techniques or something, I don't know.

Either way, the main advantage is that they do not conflict with other objects on the map, so you can put it wherever you like on the map without having to worry about your replacement being too close to an original object.

[dzek (varez)]

Interior objects liked to losing their collision after replacing, or generally: all "small" objects (with low LOD default value). At least in 1.0.3, not tested in 1.0.4 or 1.1.