Does anyone know of a method to get persistent sync’d trains without them overlapping or breaking apart constantly? Using SetRandomTrains native currently and there’s definitely a lot of odd behavior.
1 Like
By reporting reproduction steps for this ‘odd behavior’ so it can be investigated and fixed.
Reproduction steps:
Citizen.CreateThread(function()
SwitchTrainTrack(0, true)
SwitchTrainTrack(3, true)
N_0x21973bbf8d17edfa(0, 120000)
SetRandomTrains(true)
end)
I’m sure I’m just handling the native wrong, but if I knew for sure I’d not be posting here.
No, that’s not the case.
Similarly, when I ask for ‘reproduction steps’, I don’t mean ‘just provide code’. I mean ‘deduce and provide exact steps in-game that lead to whatever behavior you’re reporting with sufficient certainty that you can induce it within a minute or so from starting the game’.
I suppose you are just assuming I left things out - I didn’t. That thread is always running, trains will spawn inside of eachother, or detach and slowly move down (single cars) the tracks, stop entirely, derail, or just have missing train cars on the moving train. The only step of reproduction is to just happen upon the train. Sometimes it’s scuffed, sometimes it appears to be working as intended.
I have no scripts modifying AI behavior, driving styles, traffic, or otherwise. This only occurs with onesync enabled. This happens with every variation of scripts on my server on or off.
I assume that multiple trains are spawning for multiple clients, or that there is desync causing trains to appear slightly differently(or something) to each respective client.
I’m not.
However, the code (all that is needed is to enable the tracks and trains, yes), and the fact ‘it happens sometimes’ is known and there’s nothing unusual about that, but it’s non-actionable unless you or someone else figures out a way to near-certainly cause it without ‘just happening upon a train’, which may take 30 minutes or some other unpredictable amount of time per investigation attempt, and may even be less consistent if it e.g. needs other clients nearby in a particular pattern as well.
Nice, then try to find out exact steps with one or two clients only that lead to this state of “being ‘scuffed’”.
As a good example, take the reproduction steps from one of these reports:
- Crash when spawning peds on the server with createped using artifact 5790 and newer · Issue #1565 · citizenfx/fivem · GitHub
- Vehicles created server-side using CREATE_AUTOMOBILE are not persistent
… which are scripts that try to find and cause a scenario of their respective issue breaking, with minimal user interaction.
Not the case.
Somewhat, but ‘desync’ isn’t really the appropriate term here. Running theory is that something regarding the order in which these get created leads to attachment state not being applied correctly, but without a consistent repro this can’t be fixed as it’s impossible to verify any fix.
There’s a OneSync report at Train Carriages becoming detached which has a reproduction script included.
I’ve just tested the reproduction on the latest artifacts and it still reliably causes the trains to become visibility detached and break.
2 Likes
I appreciate your thoroughness/prompt responses but if I’m being honest I was really just poking to see if anyone had come up with a solution to just consistently produce “proper” behavior. Trains acting like this is pretty well known, but there are certainly servers with my same artifact+onesync using them (maybe using network ID natives or client hosts in a specific way? not sure) without issue.
If I were trying to run a server that revolved around trains I’d be more than happy to document/report/debug to the best of my ability, but I really only utilize them for one script so I’m not too invested.
Thanks again for all of the responses, I suppose I’ll just script work a work around to just spawn them/clean them up instead of having them roam freely or for extended periods of time.
Did you ever solve the issue for AI driven trains glitching out? Specifically near Sandy.