Trains Behaviour in RedM OneSync

What happened?

Migration Issue

The train behaves differently depending on whether it is migrated. That is, if its owner has been changed the train begins to behave differently. For example, I tested the following scenario:

Scenario

The train moves away from the owner and goes beyond the streaming range (owner’s scope of 424.0 units). How will the train behave if:

  • It does not enter the scope of another player
  • It enters the scope of another player

Test Results

  1. Non-migrated train leaves the owner’s scope (original owner).

    • If it does not enter the scope of another player - it continues moving (i.e., it continues to exist even beyond the scope).
    • Enters the scope of another player - continues moving, but now belongs to the other player. Possible bugs with the train teleporting.
  2. Migrated train leaves the new owner’s scope:

    • If the train does not enter the scope of another player - it gets deleted.
    • Enters the scope of another player - continues moving, but now belongs to the other player. Possible bugs with the train teleporting.

So there is a difference in the behaviour of the train when leaving the owner’s scope - if the train leaves the original owner’s scope versus if the train leaves the new owner’s scope.

Some other issues I encountered during testing include:

  • Missing train wagons: Sometimes wagons disappear. This mainly happens during train migration.
  • Train teleportation: Sometimes the train gets teleported to certain coordinates, which are defined in trains3.dat or trains1.dat.
  • Train migration and deletion: When I create a train on Client 1, if the train is in Client 2’s zone, closer to Client 2 than to Client 1, or not in the scope of Client 1, then the train migrates to Client 2 and immediately gets deleted.

image

Teleportation Issue

Also, I mentioned possible teleportation bugs. Sometimes the train can teleport to specific points on the map, such as:

Train train1 position suddenly changed for more than 400.0 (2711.560546875) units from vector3(28.9978, 224.9934, 108.0022) to vector3(2659.636, -429.244, 42.57434)

These coordinates match the beginning of the trains3.dat file:

147 142 open
c 2659.79 -435.711 42.5659 2659.79 -435.711 42.5659 2659.12 -413.096 42.6814 72.8832 8 freight_group

Or:

Train train1 position suddenly changed for more than 400.0 (4002.8647460938) units (vector3(-513.5604, 1165.768, 137.3378) to vector3(2486.914, -1482.172, 45.1355))

These coordinates match the beginning of the trains1.dat file:

473 454 close
c 2493.36 -1482.21 45.1479 2495.37 -1482.21 45.1479 2491.35 -1482.21 45.1479 7.45003 0
2485.91 -1482.18 45.1401 7.24107 0

Sometimes, it’s not a beginning of the file, like in next example:

vector3(967.6385, -902.2346, 67.68607)

trains1.dat, line: 72

c 966.133 -898.878 66.8973 974.791 -911.115 66.7757 957.475 -886.642 67.0189 47.8262 0

vector3(1699.214, 545.2484, 98.29676)

trains3.dat, line 57

c 1692.86 544.329 97.7636 1700.63 545.084 98.4402 1685.09 543.575 97.087 24.5965 8 braithwaites2_track_config

Ghost Train Issue

When I was alone on the server, I was in a virtual world (Routing Bucket 1) while the trains were in the default world (Routing Bucket 0) and associated with me and no other players. When other player joined, the train were not visible to him, even though he was in the default world same as the train. So, scenario like this:

  1. Client 1 in Routing Bucket 1, while the train in Routing Bucket 0. Client 1 was is the only one on the server.

  2. Then, Client 2 joining the server in Routing Bucket 0 and couldn’t see the trains.

Seems, Kianimal mention the same issue when was testing https://github.com/Kianimal/BGS_Trains:

image

Source: Discord Link

Expected result

Same behaviour as without OneSync / Constant behaviour of migrated trains

Reproduction steps

For reproduction steps next code may be used for train creation on client-side (Client 1):

local function SpawnTrain(trainhash, startcoords, direction)
    SetRandomTrains(false)
    local trainWagons = Citizen.InvokeNative(0x635423D55CA84FC8, trainhash)
    for wagonIndex = 0, trainWagons - 1 do
        local trainWagonModel = Citizen.InvokeNative(0x8DF5F6A19F99F0D5, trainhash, wagonIndex)
        while not HasModelLoaded(trainWagonModel) do
            Citizen.InvokeNative(0xFA28FE3A6246FC30, trainWagonModel, 1)
            Citizen.Wait(100)
        end
    end

    local direction = direction or 0 
    local train = Citizen.InvokeNative(0xc239dbd9a57d2a71, trainhash, startcoords, direction, 0, 1, 0)

    while not DoesEntityExist(train) do
        Wait(0)
    end
    
    local netId = VehToNet(train)
    while not NetworkDoesNetworkIdExist(netId) do
        Wait(0)
        netId = VehToNet(train)
    end


    SetTrainSpeed(train, 0.0)
    SetTrainMaxSpeed(train, 30.0)

    Citizen.InvokeNative(0x05254BA0B44ADC16, train, false) -- SetVehicleCanBeTargetted
    Citizen.InvokeNative(0x06FAACD625D80CAA, train) -- NetworkRegisterEntityAsNetworked
    SetModelAsNoLongerNeeded(train)

    return train
end

SpawnTrain(-577630801, vector3(-348.5798, -353.8752, 86.49016), nil)
  1. Next you can make manipulation stated before in section with Migration Issue.

Importancy

Slight inconvenience

Area(s)

RedM, OneSync

Specific version(s)

RedM 1491, Server on Linux/Windows 7290

Additional information

If needed, I’ll try to provide some code for faster issue testing (self/semi-automated testing).


Related topic: Questions regarding ownership and synchronization of trains in RedM