Add mapfixes resource

[Fernando-A-Rocha]

This is intended to patch some flaws in the default MTA world, caused by missing objects that would usually be loaded in the singleplayer game.

Contributors to this mini-project:

• Me @Fernando-A-Rocha
• @THEGizmoOfficial

List of map fixes

Objects were spawned using the exact positions provided in the game's IPL files.

• Big Smoke Crack Palace wall covering the hole (1 object spawned)
• Big Smoke Crack Palace open-world interior (2 objects spawned) - disabled by default
• Commerce Atrium Lobby open-world interior (2 objects spawned, 4 door objects replaced with openable doors of the same model)
• Doherty Safehouse Garage open-world interior (7 objects spawned and 1 garage opened)
• Restored Undamaged SF Crack Factory with open-world interior (27 objects spawned and 4 objects removed)

[Fernando-A-Rocha]

Big Smoke's Crack Palace

Hole patched with 2 objects loaded from the game's carter.ipl binary IPL file.

Before:

After:

I believe this is essential for most servers.

Feel free to contribute 😄

[jlillis]

It would be best if each patch had a separate identifier or name, and could be turned on and off in meta.xml,

I think that's a bit overkill for this purpose. This should just be a simple map resource that fixes obvious holes for the purposes of the freeroam gamemode and other simmilar modes. Ideally I'd have it be a literal .map and nothing else, but there is no integration of the new building functions in the map editor yet.

[Fernando-A-Rocha]

I think we should make this resource much more customizable. It would be best if each patch had a separate identifier or name, and could be turned on and off in meta.xml, or even configured if there are multiple available options.

What I can think of is having meta.xml settings to enable/disable each patch individually. Wouldn't this be okay?

[Fernando-A-Rocha]

Lazy server owners would be able to toggle the patches via the Admin Panel by accessing the resource settings menu.

[Nico8345]

What I can think of is having meta.xml settings to enable/disable each patch individually. Wouldn't this be okay?

I mean that's quite enough, yes. If we don't use a map, it might be worth using the new building functions, right?

[Fernando-A-Rocha]

What I can think of is having meta.xml settings to enable/disable each patch individually. Wouldn't this be okay?

I mean that's quite enough, yes. If we don't use a map, it might be worth using the new building functions, right?

Yes sir, if you look closely at the code I used createBuilding and meta.xml has the min version adequately xD

[Nico8345]

My bad, sorry.

[Fernando-A-Rocha]

Let's get more feedback from the community on how this should work.

[Dark-Dragon]

Personally I'd say the highest priority are obvious erroneous differences between singleplayer and mta, such as big smokes crack den or the blown up warehouse in san fierro. However discussion on discord seems to indicate the scope should be much wider and include the more minor issues like missing collision in geometry that could result in accidentally or purposely falling through the map. While I don't see a desperate need for these issues to be addressed, I don't see any problem with taking on the task if enough people are interested in dealing with it. I would however say these should be resolved by fixing the models rather than band-aiding around them.

If this resource ends up addressing more than the couple glaring mistakes, I'd say a setting for each fix in the meta.xml is desirable.

[NanoBob]

I think if you want this to be of any value it needs to be configurable. Being able to enable or disable specific fixes would allow a server to use this if they do use some of these areas.

Another thing that's worth considering is making multiple alternatives for a single "fix". For example in this case one fix would place the interior behind it like you've done now. And another would be to place the wall that covers up the hole. As some servers might not want the interior there.

This also would be done by making them configurable, as you could just disable the wall if you want the interior bit.

[Fernando-A-Rocha]

Ok. Solid points.

My idea to make it configurable is create several meta.xml settings and listen to changes using the event onSettingChange to reload the patches accordingly. Any better alternatives?

[Fernando-A-Rocha]

Did as suggested. Demo video:

https://streamable.com/cdkhgq

[Fernando-A-Rocha]

I think the system doesn't need to get more complex than this. Let's keep adding actual map fixes related to spawning/removing objects. We'll sorry about game model modifications later imo.

[THEGizmoOfficial]

I would add two more interiors that are the same size as their buildings, so they do not protrude beyond the outline and are not available in the open world :D

[Fernando-A-Rocha]

@THEGizmoOfficial These are nice map improvements. We can definitely add them to this resource. Obviously they will be toggle-able, but I think they really fit the freeroam gamemode which is the Default MTA Server gamemode.

[Fernando-A-Rocha]

Added 2 more original open-world interiors.

Here the interior was placed, and the garage ID 22 was opened using setGarageOpen.

//

Here the interior was placed and the entrance doors removed.

I'm thinking of spawning the doors at the same position, and making them pushable (setting model group to the same as Gen_doorINT04 which the player can push to open).

[Fernando-A-Rocha]

This project is evolving. For those reading, more is about to be done :shipit:

[Fernando-A-Rocha]

@T-MaxWiese-T

There should be a setting with which you can open and close the garages. It should be closed by default. There should also be a setting for doors.

This opens up several possibilities. Why not make something to open/close any garage ID in the server, because they all behave the same?

I'm not sure yet how to proceed with this feature of allowing control garage open/close

[Fernando-A-Rocha]

Added undamaged SF factory

FYI it looked very different without this fix:

The building flickered and looked bad

[T-MaxWiese-T]

This opens up several possibilities. Why not make something to open/close any garage ID in the server, because they all behave the same?

I'm not sure yet how to proceed with this feature of allowing control garage open/close

The purpose of this resource is not made for opening or closing garages. The only purpose of opening a garage is to have a look at the interiors. I thought about creating a new resource where you can open and close garages individually via the resource settings. I can imagine that such a resource already exists, but I think it is so essential that it should be included by default.

[Fernando-A-Rocha]

This opens up several possibilities. Why not make something to open/close any garage ID in the server, because they all behave the same? I'm not sure yet how to proceed with this feature of allowing control garage open/close

The purpose of this resource is not made for opening or closing garages. The only purpose of opening a garage is to have a look at the interiors. I thought about creating a new resource where you can open and close garages individually via the resource settings. I can imagine that such a resource already exists, but I think it is so essential that it should be included by default.

Idk about such a resource to control garages, but yes it seems essential. I'll probably keep this automatically opening the garage to access the interior for now.

[Fernando-A-Rocha]

Added doors that can be pushed open at the open-world atrium interior

Demo video: https://streamable.com/qyqfgp

[Fernando-A-Rocha]

Added a fix for holes in apartment complex building walls in Idlewood

This bug in Rockstar's laeIdleProj02 model allowed the player to jump inside the building.

Demo video: https://streamable.com/b381eh

Credits to @THEGizmoOfficial for making the .col from scratch. More to come 🎉

[Fernando-A-Rocha]

[jlillis]

Well the scope of this has escalated quickly... which I'm fine with, I would just caution against going too crazy. The only issue I see at this point is that as of now there are interior warp points within the interiors resource that will conflict (namely the atrium in LS, potentially others).

[Fernando-A-Rocha]

The only issue I see at this point is that as of now there are interior warp points within the interiors resource that will conflict (namely the atrium in LS, potentially others).

I wasn't aware of the interiors resource, I checked that it doesn't start by default. When testing, I didn't see anything there at the atrium entrance.

Indeed, it conflicts with the it (we don't have any others now). Should the atrium open world interior be disabled by default then, even if it the interiors resource is not a default feature?

[Fernando-A-Rocha]

Well the scope of this has escalated quickly... which I'm fine with, I would just caution against going too crazy.

I'm happy with the direction this is taking! We won't include anything out of the scope mentioned in the original post of this PR. It's really meant to be an useful resource for a variety of server gamemodes. We won't be doing non "vanilla" map modifications.

Thank you for the comments, jlillis!

[Fernando-A-Rocha]

Palomino Creek bridge road bug fixed by @THEGizmoOfficial (CE_groundPALO03.col)

https://www.youtube.com/watch?v=1XrHmuMY-do

[THEGizmoOfficial]

Column And Ceiling Collision Fix (aircarpark_09_SFSe.col and mall_01_SFS.col)

https://www.youtube.com/watch?v=fMe8aGGn_UA

[tut001]

If MTA wants to remain lightweight and avoid shipping hundreds of slightly modified original assets, then you'd be better off adding COL/DFF/TXD fixes as a community resource and letting other users contribute. There are hundreds of broken COL models, if not thousands of exploits for access to blue hell, or the insides of buildings. I have, like others, created many fixes for these but they keep becoming more obvious when working with different models. That's only COL issues. There's a lot of DFF issues as well if you take into consideration minor issues like zfighting, prelight, or IPL/mesh offsets that create tiny blue hell gaps in the world. At some point you'd be looking at redistributing a large portion of the original game's files, like a mod pack would.

If this is something that's maintained by MTA then it would add quite a lot of file sizing to servers that either have their own fixes already, or just don't really care for non-gamebreaking issues. Whether it's toggled on I imagine it would still be distributed as part of MTA installation.

What about file standards? A game modder with sufficient knowledge of art, topology & RW data would be required to inspect & approve every file that's submitted, and to set an official standard. Also, if people begin using different importers/exporters, which is known as destructive-editing (i.e. saving JPEG photographs instead of RAW for grading, or continously re-compressing images by editing & saving as JPEG), then there is a risk of breaking the file data because different plugins handle data differently. This is something that is all too common in the world of modding, and sadly many talented game modders still actively encourage without considering that it breaks stuff. It isn't the same as submitting a piece of text that says "Hello world". When someone modifies the file it may become "Hell world" and you have a problem. This happens a lot more frequent than some may think. Instead of per-server mods we're talking official resources meant for everyone, where a set file quality & size standard is expected.

Missing interiors on the other hand, sound reasonable as it's easily kept non-destructive and exclusively code based