"Random collisionless objects" still exist

[Einheit-101]

Describe the bug Months ago MTA team fixed a bug that caused random objects to lose collisions. Most users reported that this bug has been fixed once and for all. Shortly after that fix i noticed some collisionless objects again but they were extremely rare and i thought i am crazy, but now i can confirm that this bug still exists, it is just much more rare.

A reconnect does not fix it.

crun for i, obj in pairs(getElementsByType("object")) do setElementCollisionsEnabled(obj, true) end --> This does not fix it either.

Only restarting MTA fixes this

To reproduce No idea. Sometimes a random object loses its collision. I have that issue in Map editor (with custom objects) and on my server.

Screenshots

Version 1.5.6-release-16718

[ghost]

Does it happen during replacing models? Somebody should find a way to reproduce this.

[Einheit-101]

I have seen that some objects fail to get replaced when the game is minimized (another unreported bug), but i have not found a way to reproduce this here.

[Brian9221]

Do you use engineRestoreCOL or engineRestoreModel somewhere? I noticed these functions still cause objects to randomly lose their collision.

[Einheit-101]

No, what i do is "do a lot of replace models when resource starts" and while playing i have seen that (for example) the carrier lift loses collision or some other random objects.

[Einheit-101]

https://www.youtube.com/watch?v=iPA7lt-oT1E&feature=youtu.be

This is really annoying, one of my scripts does no longer work because object 3065 loses its collision 90% of the time. But the ridiculous thing is: It depends on the map that is currently loaded.

Stalingrad Railroad: Collisions messed up. Loading map Carrier: Collisions work again. What could be going on here? Its a miracle!!!

[PlatinMTA]

Could be that this happens because you are replacing an object that has physics by default? Just as 3065 does.

Did you test if by replacing other model it just starts working?

Try these IDs and see if that bug still happens:

1640 1641 1642 2404 2405 2410

[Einheit-101]

Thats the basket ball and i dont even replace it. It just loses collision along with the a51_jetdoor and (most likely) many other objects. It works on some maps and it stops working on others, but it works again when re-loading a map where it is known to work.

€DIT: Now i restarted my local server today to test again and the issue does not appear, wtf. I cant reproduce it all the time.

[CubE135]

@qaisjp This issue is not yet resolved. I experience this everyday on my race server. We are on the latest version and this is really ruining the experience for the players. People from other servers confirmed that this bug is still happening very frequently.

Could this please get reopened and fixed as soon as possible? :)

[TheNormalnij]

Can we revert b6cf87a if de6b51b is not reason for latest crashes?

[ghost]

Can we revert b6cf87a if de6b51b is not reason for latest crashes?

Not yet, we need to wait for a few days at least.

[Pieter-Dewachter]

This bug is now already back for more than half a year and has only gotten worse in the meantime unfortunately. It happens usually after 30 min to 1 hour of playing DM race maps now and it's really random as to which object(s) will be affected. The object _garys_luvjump seems to be the one that's most affected, but it can really be any object (today I saw it with plasticsgates after 10min of playing).

To recap: everyone who is playing in the server at the moment of the bug happening loses collisions for a certain object type. The only way to fix it is by restarting MTA (each client individually) completely, lots of people have tried scripting methods but nothing seems to help at all.

It renders the whole gamemode unplayable and affects a lot of servers daily, MTA is losing a lot of players because of this, does someone have a clue as what might be happening here? The average DM player has to restart MTA at least 3-4 times a day when playing a few maps.

[Dutchman101]

@Pieter-Dewachter wait for PR #1930 and it'll be solved

[Dutchman101]

Re-opened because sadly we had to revert the fix in 2c14639

I hope someone wants to investigate and fix the bug it causes, as fixing "Random collision objects" soon is important to gameplay experience

cc @TheNormalnij

[ds1-e]

I do have a reproduction resource which might help solve this issue. I've talked with TheNormalnij about it month ago, but probably he couldn't fix this. It's quite easy to reproduce that (see https://discord.com/channels/278474088903606273/366384007535001612/787473438687100958). In my case after replacing a building, some furniture objects lose its collisions. Overall i might say it's somewhat related to model replacing and streaming, because: 1) I've started resource today, but i couldn't make that object lose collision, i guess it's because of another resource which was replacing models. 2) Restarting resource when building is out of stream zone doesn't make it collisionless.

Reproduction video: https://www.youtube.com/watch?v=EuoX0bMU1m8

[ffsPLASMA]

@majqqq your discord links points to nowhere because the development channel got removed. Please upload it somewhere else.

Anyway I would like to point out this issue increased drasticly lately. Last few weeks ago, I encountered this issue on a default gta world model (street, not replaced or anything) aswell as a custom placed object via createObject.

I cannot reproduce this issue conistent, but it started to happen on FFS very often recently. Especially in a minigames mode where I do following:

1) create two objects serversided: uBasePlatform = createObject(13607, x, y, z); uBaseFence = createObject(13623, x, y, z); Both objects are at same x and y position, only z coordinate is offset by some units.

2) on the clientside when the mode starts, I dynamicly load a custom colission file and replace it with model ID 13623, which is the uBaseFence object. Once the mode is over, it restores the colission of model ID 13623 and destroy the custom loaded colision element.

--- start --- uCol = engineLoadCOL("fence.col"); engineReplaceCOL(uCol, 13623);

--- end --- engineRestoreCOL(13623); destroyElement(uCol);

Nothing to fancy, but heres comes the issue. The uBaseFence object/model never gets this colission bug, it will always have the right colission, yet somehow the uBasePlatform object with model ID 13607 loses colission at some point. I often see players loading the mode and falling through the object due to missing colissions even though it never got replaced for this model ID. Once the affected players restart MTA, the bug is gone and they can stay on the platform. It looks like the colission gets unloaded for the wrong model ID either by misbehaving script (engineReplaceCOL) or some other random effects. As I said previously I cannot reproduce it in a consistent way, but after ~20 rounds of playing this mini mode with dynamicly loading and unloading, I got this issue once so far and only restarting MTA could solve this issue. It was still present if I just rejoined the server without restarting MTA.

EDIT: Also I would like to point out the model IDs reported by Platin: 1640 1641 1642 2404 2405 2410 They all share the same DFF/COL, only textures change. Maybe that's the reason why certain models got the issue, they are linked in one or antother way. The issue I described above is the round kickstar platform from LV stadium together with the fitting fence.

Check the models here: https://dev.prineside.com/en/gtasa_samp_model_id/

[ds1-e]

@ffsPLASMA nothing lost, this link was leading to discussion in #development channel, where i explained how does it works, and I sent same video. I just want to add that starting resource initially doesn't make it collisionless, bug appears just after restarting (either stopping and starting) resource.

[thisdp]

I've tested this bug. Here I share the test result of this bug. While I was playing DM maps, I found 3095 and 3115 are collisionless. And I was thinking it is dimension related, but finally find it is Player position related.

Test Model: 3115,3095 x1,y1,x2,y2 are estimated values x1,y1 = 2300,1745 x2,y2 = -347,-1645

assume x,y,z = getElementPosition(localPlayer) when x2<=x<=x1, Object 3115 has collision, collisionless otherwise. when y2<=y<=y1, Object 3115 has collision, collisionless otherwise. test result doesn't seem to relate with "z", -4000~9990 works.

And i found something ineteresting: I created 3115 at 2300,0,0. And created a vehicle at 2304,0,1 My CJ in 2299,0,0.

Vehicle didn't fall, and the result of processLineOfSight showed object had collision When CJ went to 2301,0,0 and started to fall, the vehicle fell too (Ped also),and the result of processLineOfSight showed the object was collisionless.

And I think this is at least model related. Because this still happens even the vehicle and my CJ stand on different objects whose model are 3115.

1.The test result shows when localPlayer is outside of that area, model 3115 will be collisionless.

2.And this "feature" will be inherited when using "engineRequestModel"

3.engineRestreamWorld doesn't help.

4.getElementCollisionsEnabled returns true even the object is collisionless

5.When losing collisions, 3115 and 3095 are at the same time.

[thisdp]

obj3095 = createObject(3095,0,0,0,0,0)
obj3458 = createObject(3458,0,0,0,0,0)
setElementData(root,"3905",obj3095)
setElementData(root,"3458",obj3458)
setElementCollidableWith(obj3095,localPlayer,false)
setElementCollidableWith(obj3458,localPlayer,false)
isCollisionLess = false
outputChatBox("Collisionless Bug Detector Started",0,255,0)
tick = getTickCount()
filter = 20
valueRecord = 0
addEventHandler("onClientPreRender",root,function()
    local x,y,z = getCameraMatrix()
    setElementPosition(obj3095,x,y,z+8)
    setElementPosition(obj3458,x,y,z+8)
    local dimen = getElementDimension(localPlayer)
    setElementDimension(obj3095,dimen)
    setElementDimension(obj3458,dimen)
    setObjectScale(obj3095,0)
    setObjectScale(obj3458,0)
    local inte = getElementInterior(getCamera())
    setElementInterior(obj3095,inte)
    setElementInterior(obj3458,inte)
    local veh = getPedOccupiedVehicle(localPlayer)
    if isElement(veh) then
        setElementCollidableWith(obj3095,veh,false)
        setElementCollidableWith(obj3458,veh,false)
    end
    if getTickCount()-tick > 1000 then
        local hit3095, hx,hy,hz, ele1 = processLineOfSight(x,y,z+6,x,y,z+10,false,false,false,true,false,false,false,false,obj3458)
        local hit3458, hx,hy,hz, ele2 = processLineOfSight(x,y,z+6,x,y,z+10,false,false,false,true,false,false,false,false,obj3095)
        if ele2 == obj3458 then
            if ele1 == obj3095 then
                if isCollisionLess then
                    outputChatBox("Collisionless Bug Detector Reset",255,255,0)
                end
                isCollisionLess = false
                valueRecord = 0
            elseif not hit3095 then
                valueRecord = valueRecord+1
                if valueRecord >= filter then
                    if not isCollisionLess then
                        outputChatBox("Error: Collisionless Bug Triggered",255,0,0)
                        outputChatBox("Please restart your MTA",255,0,0)
                        triggerEvent("onClientOccurCollisionlessBug",obj3095)
                    end
                    isCollisionLess = true
                end
            end
        end
    end
end)

This code can help to know when this issue happens

[MrDadosz]

I'm having the same problem on the server I am working on. When you join a server with custom models and then join a server without custom models, some objects lose collisions (ID 2990). https://youtu.be/j0IxUO3SDtw And when you replace collisions on some roads, other roads lose their collision.

[thisdp]

I'm having the same problem on the server I am working on. When you join a server with custom models and then join a server without custom models, some objects lose collisions (ID 2990). https://youtu.be/j0IxUO3SDtw And when you replace collisions on some roads, other roads lose their collision.

Your issue is related to #377

[thisdp]

reproduced collisionless.zip