Keep the doors open after a scene

Hello everyone, I run a scene to open the container, but the doors close instantly after the scene. Could someone tell me how to keep the doors open ?

Thank you :slight_smile:

Could you share some of the code? That might help

1 Like

Thank you for answering MojitoBurrito, of course :slight_smile:

        local animPos = GetOffsetFromEntityInWorldCoords(container, 0.0, 0.0, 0.0)
        local netScene = NetworkCreateSynchronisedScene(animPos, targetRotation, 2, false, false, 1065353216, 0.0, 1.3)
        local grinder = CreateObject(GetHashKey("tr_prop_tr_grinder_01a"), targetPosition, true, true, false)
        local bag = CreateObject(GetHashKey("ch_p_m_bag_var04_arm_s"), targetPosition, true, true, false)

        lib.requestAnimDict(animDict)
        lib.requestNamedPtfxAsset(fxName)

        NetworkAddPedToSynchronisedScene(ped, netScene, animDict, "action", 1.5, -4.0, 1, 16, 1148846080, 0)
        NetworkAddEntityToSynchronisedScene(ped, netScene, animDict, "action_lock", 4.0, -8.0, 1)
        NetworkAddEntityToSynchronisedScene(grinder, netScene, animDict, "action_angle_grinder", 4.0, -8.0, 1)
        NetworkAddEntityToSynchronisedScene(bag, netScene, animDict, "action_bag", 4.0, -8.0, 1)
        NetworkAddEntityToSynchronisedScene(container, netScene, animDict, "action_container", 4.0, -8.0, 1)

        NetworkStartSynchronisedScene(netScene)
        Wait(7300)
        NetworkStopSynchronisedScene(netScene)
        DeleteObject(grinder)
        DeleteObject(bag)

No idea ? :slight_smile:

I don’t have enough experience with scenes but you could try creating another ped that is in the scene and you don’t stop the scene until you are ready. After this wait you could make this ped invisible, it might work. Idk

1 Like

Thanks, i’ll try to see the result, but I had already tried without stopping the scene, but it didn’t change anything

Try this SET_SYNCHRONIZED_SCENE_HOLD_LAST_FRAME, it’s worth giving it a try.

1 Like

No change :thinking:

Have you looked at this scene in decompiled scripts? It might require switching the prop to an alternate version that has the doors open or some odd workaround

1 Like

yes, either there is nothing, or I did not see it

I did not see any container with the doors open :person_shrugging:t2:

in fm_mission_controller_2020.c

				case 3:
					if (func_2828(iLocal_4270))
					{
						*uParam1 = "ANIM@SCRIPTED@PLAYER@MISSION@TUNF_TRAIN_IG1_CONTAINER_P1@HEELED@";
					}
					else
					{
						*uParam1 = "ANIM@SCRIPTED@PLAYER@MISSION@TUNF_TRAIN_IG1_CONTAINER_P1@MALE@";
					}
					StringCopy(&(uParam1->f_1), "ACTION", 64);
					StringCopy(&(uParam1->f_111), "ACTION_LOCK", 64);
					uParam1->f_111.f_49 = 1;
					uParam1->f_1063++;
					uParam1->f_442[0 /*55*/].f_48 = joaat("tr_prop_tr_grinder_01a");
					StringCopy(&(uParam1->f_442[0 /*55*/]), "ACTION_ANGLE_GRINDER", 64);
					uParam1->f_1063++;
					uParam1->f_442[1 /*55*/].f_48 = func_4986();
					StringCopy(&(uParam1->f_442[1 /*55*/]), "ACTION_BAG", 64);
					uParam1->f_276.f_49 = 1;
					uParam1->f_276.f_51 = 1;
					StringCopy(&(uParam1->f_276), "action_container", 64);
					uParam1->f_1061 = "scr_tn_tr";
					break;

Hey, did you find the answer? Since 2 days I’m trying to learn about synchronized scenes and I found your post. In the NetworkCreateSynchronisedScene the 4th argument is called holdLastFrame so maybe se it to true. Btw I’m looking for the 6th argument “number” (1065353216) can u tell me where did u get it from?

Hey Scorpio!

Unsure if you still dabble in FiveM development. I’ve recently re-done the same thing as you and rebuilt this entire syncronised scene. I thought finding the sparks particle was the tricky part but no, it turns out it’s keeping those pesky doors open!

Did you ever find a solution? I’ve tried freezing the syncronised scene at specific frames but no luck! There must be a way to trigger the state of this object? I wonder if Rockstar had some state management coupled to specific objects like this, such as OPEN/CLOSE that they could switch between after animations… :thinking:

Note:

I did find if I put a Wait of say (50000) before calling the syncronised scene to a stop, it does keep it open. The only issue is they’ll close again once the Wait is over.

Hi, if your still having problems with it.

 local scene = CreateSynchronizedScene(GetEntityCoords(newContEntity), GetEntityRotation(newContEntity), 2, true, false, 1.0, 0)
    PlaySynchronizedEntityAnim(newContEntity, scene, 'action_container', animDict, 1.0, -1.0, 0, 0)
    ForceEntityAiAndAnimationUpdate(newContEntity)
    PlaySynchronizedEntityAnim(newLockEntity, scene, 'action_lock', animDict, 1.0, -1.0, 0, 0)
    ForceEntityAiAndAnimationUpdate(newLockEntity)

    SetSynchronizedScenePhase(scene, 0.99)
    SetEntityCollision(newContEntity, false, true)
    FreezeEntityPosition(newContEntity, true)

You have to create another scene, and run the process again without adding the ped to the scene, let it run by itself. I’ve personally done it by creating two same props, on is hidden, I run this scene on the hidden one, run the normal on the visible one, then after deleting the visible make the hidden visible so as you got to see the prop its doors are open, thats it

Oh interesting, I did somewhat make a solution but it was to spawn a different container (Around the same dimensions as the container in the syncronised animation) and make it’s visibility false. That way I could maintain the collision of the inner container but not have it’s visibility. It felt janky and very hacky. I also would play the animation separately on the container but like you, freeze it at the last frame, that kept the doors open and the container spawned. It just had no collision, hence why I added the inner container

I’ve yet to test this code you’ve done but this seems like a proper way to do it. This is incredible. Any idea what ForceEntityAiAndAnimationUpdate does? If this works on something that is not a vehicle, then the FiveM native documentation is wrong as it describes it as: Based on carmod_shop script decompile this takes a vehicle parameter. It is called when repair is done on initial enter.

Curious to know, are the doors solid? One thing I found with my workaround was the doors remained to have no collsion. I looked through a bunch of decompiled scripts but I just could not work out how they were doing it. Needless to say, there is no other container (That I know of) that represents it’s open state to easily switch objects after the networked scene.

The doors have no collision :frowning:

I’ve seen on GTA Online they’ve managed to make this object solid. They’re either A) Replacing it with an open version of it that we somehow haven’t found the object ID for, or B) There is a native we’ve yet to discover, perhaps something that changes collision models on objects so they can switch it between scenes