Operating system: Windows 10 Artifact version: 4086 IP address: localhost Resources: spawnmanager, vMenu, sessionmanager and the reproduction resource
Summary: When using OneSync, train carriages can become visibility detached if the player varies their distance around the train in a certain way Expected behavior: Trains should stay together as one on the track Actual behavior: Trains carriages become visibility detached or separated by a large distance. Though all carriages still move as one. Steps to reproduce: Download the attached resource, and load up a server with 2 clients. Position them around (X: 2414 Y: 1095 Z: 79) and then run the /train command on one player. The players positions will automatically be adjusted a couple times to show the issue Server/Client? Client Files for repro (if any):Reproduction.zip (1.4 KB) Error screenshot (if any): None .dmp files/report IDs: None
After seeing dbub comment about this post in the recent community pulse discussion, I can confirm this bug is still present as of today, latest artifact being 6302.
I just wanted to do some investigation myself with the very little knowledge I have.
This repro seems to be working on 2612, 2699 and 2802 (didnt test with any version prior to this), testing done with OneSync Infinity.
The method seems to be related to ownership change breaking the link between the engine and the carriage.
Printing the carriage engine with GetTrainCarriageEngine server side does reveal something of importance, it seems like during the ownership change, the data is lost on all carriage (except the engine that returns itself), all carriage now returns 0.
Printing the owner of every carriage seems to be working fine on the server side, all wagons are changing ownership in a single frame all at once.
Printing the carriage index doesn’t reveal anything weird, all wagons exist with correct carriage index during the repro.
When leaving the repro going to the very end, when the train is exiting the scope of the player, the engine is deleted first, leaving all the carriage going without any engine during a few seconds.
That’s all I noted, it seems like this bug will be kinda hard to debug as is everything related to owership weirdness.
Also, doesn’t seems to be a priority at the moment as they are clearly not main gameplay, just wanted to add all this information somewhere at least
Right, I recall the intended fix actually being something like ‘parse the train attachment data and make sure the entire chain only gets migrated and created as a whole’, though I also believe there was something about ‘try to check what game code does here’.
At the time I don’t think this repro had been seen though so testing it was an issue, as is the other thing with cloning changes namely regression testing.