Looks like my issues got worse, if you hit vehicle that is bugged like that, sometimes game completely pauses physics and never unpauses it, forcing players to rejoin
additionally if people try to enter bugged vehicle, their character gets flung very far away
i will try to look into this issue by myself but as of now i have no way to replicate it
UPD: physics pause because hitting not properly replicated vehicles causes your physical assemblies (your vehicle/your character) to fly to nan-ind
This features is still pretty buggy⌠Replication bug and dysync players is still an issue. I had to revert to low memory.
Ive fixed all car issues by setting their joints parents to the car itself maybe you could try that if you havent already?
As i said absolutely all welds are parented inside a vehicle itself
What prevents you from parenting those parts into non-physics containers such as ReplicatedStorage?
lots and lots of desyncs, especially with tools.
am having the same issue is there any fix for this?
If you are using A-Chasis then changing where the joints are stored to be in the workspace instead of JointsService should resolve the issue. See previous discussions.
changing where joints are stored makes the game unloadable for me and other players and it fixes itself by changing Opportunistic to Default
I know other developers have successfully migrated their A-Chassis scripts away from JointsService. JointsService is deprecated, and should not be used. Changing from Opportunistic to Default only makes the problem less likely to occur. Players using low memory devices may still experience issues.
Oh okay iâll try to see if i could get it working thank you i really appreciate it.
Do you know where they stored Joints? I also have the same issue where migrating the joints to Workspace makes the game unloadable.
One simple suggestion is to just store the joint under one of the parts being attached.
Wouldnât that still be stored in Workspace? Workspace storing made my game unloadable.
My game has âStreaming Out Behaviorâ Opportunistic and my testers telling me that somehow Opportunistic turns its self off while playing. I donât really know how this can happen but i guess its a bug.
But this bug only happend the second time so should be really rare.
Iâm having an issue with Opportunistic when teleporting players to and from a specific location, usually, it works fine. But occasionally, a random client, (Client A) will be fine and joints will be fine for every client except the occasional other client, (Client B) who will see the player with broken joints. Iâll attach a video example -
I donât think this is anything code-related, as it seemed to work fine before I turned on Opportunistic.
I have also experienced this kind of situation, having players and parts to be broken apart. From my perspective they look fine but on another playerâs perspective everything is broken flying around.
*just saw the post above about A-Chassis storing joints in workspace. Iâll be trying that but the avatar being seperated is another issue i guess.
Donât use joint service, use weld constraints. Go into the initialize script of a-chassis and replace âweldâ with weld constraints.
This feature is fine. However target radius is editable on client, but otherwise it could prevent ESP cheats very easily. I hope you guys will make it not editable on client.
While using Opportunistic, Iâve noticed some pretty bad memory leakage when moving across the map, especially prevalent when teleporting.
Consider this scenario:
Memory usage is at 1000 MB. You teleport to the other side of the map. It raises to 1100 MB. You then teleport back to where you previously were, it goes to 1200 MB. Teleport back to the other side, and 1300 MB. And this continues after multiple teleports. It does not go down to the original memory usage as expected, even after waiting an extended period of time, and only goes down a very, very small amount (which stops eventually). Happy to provide access to my place to a Staff member to investigate.
I can guarantee that any connections or operations tied to instances that are streamed in on the client is being cleaned up when streamed out.
