I have questions regarding the synchronization of autonomous self moving entities, in my specific case - trains. I need some advice on how to deal with ownership and if there are ways to manually change them reliably. I also need some help with understanding some concepts like “owning a grid” and “owned by a script”. After some different approaches to tackle the challenge with the autonomous driving train, I am uncertain if it is solvable via scripts only. Maybe an addition to the OneSync code would be the best way to solve it, but I am unsure about that as I never had any contact point with any cfx part outside the redm scripting framework.
I will just start with explaining what I did the last few weeks:
I tried to get autonomous self-driving trains running in RedM so that they follow a route even when no player is around. I tried many approaches and all of them failed so far. My first attempt was to use SetEntityDistanceCullingRadius and just after I had to accept my failure because of sync problems when having more than just a handful of players online, I read that it is strongly recommended to not use it in many other threads. I was then willing to write my own synchronization logic for the train and npc train driver entities covering also the “faked out” positions mentioned by d-bubble by having a virtual train object “driving” until a player is in culling range and then spawning a train entity. Also, having a dynamic sync logic for dealing with changing train owners to seemingly take over the movement of the train entity. As the train data is synchronized via the owner, and in the specific case of trains, the owner don’t have to actually be on the train and the train is still moving automatically, plenty of things go wrong. I think I could bypass most of the sync problems when I would be able to manually enforce an owner change in this specific situation. But I was unable to reliably do that. I also read in other posts and on discord, that it strongly recommended not to make use of NetworkRequestControlOfNetworkId and NetworkRequestControlOfEntity. But I think we in RedM don’t have so many options like they have in FiveM. I especially eyeballed the seemingly FiveM exclusive SetNetworkIdCanMigrate native, that looks to be exactly what I would wish for in this case. I also tried to change sv_filterRequestControl to 0 to be more free in requesting control, but it does not seem to have any real influence in tests I did, and I am uncertain if it is even a thing for RedM.
I tried to understand how the background synchronization works and in think I have now a somehow reasonable understanding, but it seems I still lack some more profound knowledge, as I am still not able to pinpoint my problems exactly.
The onesync logic is not helpful for autonomous moving trains as there are many cases where it is not working properly. I think this is mainly because the train moves automatically, and the owner could be “far” away and even when he is not far away, he will be in few seconds when not on the train. Other non owning players around the train are easily in a situation, where they are relatively close to the train but out of scope for the original owner, resulting in problems. Also, sometimes the train driver entity has a different owner than the train entity, which is weird and result in a stop of the train. The train entity somehow requires a npc train driver ped to be in place to be able to be remotely controlled. It often results in a situation where the train is owned by person A and the train driver by person B, which when at different positions sometimes lead to a constellation where the train owner A does not see the train driver entity as it is not existent on his client and therefore can not move the train. This leads to situations where the train is stranded at the edge of different culling radius of the player’s. Even when players are around, that would be closer and the train is more relevant to them, the ownership is often not changed.
At this point, I am uncertain if it even can be tackled via scripts or if it has to be solved at onesync level. I also explained this all here, to ask, how the current plans are regarding such topics in onesync. Are there intentions to work on related issues, or are there currently no plans to do so? If someone gives me the right hints on where to start, I could also imagine taking on some work units.
Furthermore, I would be happy in general for information on possible workarounds or approaches to deal with these challenges. Maybe there are additional things I could test. I tried so many things and in the end every approach was not feasible in production.
I recently read that players can also own grids. How does that work? Is the whole grid with all containing entities transferred to a different owner when the owner change, or is the grid owner just the singe point of truth for all the sync stuff that happens on his grid, but the entities on this grid could be owned by someone else?
I also read that entities can be “owned by a script”. What does that exactly mean and which implications do that have?
Is there a reliable way to force an owner change to a specific other player for a specific entity?
Sorry for asking so many questions, but I kind of lost here now and not able to find reliable answers to these questions.
Just a note to make this clear: Trains seems to work fine when actually driven by a player because then the onesync logic is correct. The player is always at the same position as the train and therefore can propagate the train object data to nearby players around the train.