Alright, so I’ve come to a near halt in development because of this issue, and have wasted hours trying to reproduce the problem without success. Basically, there’s an issue in my kart game where if a player resets, there’s a chance that their kart/body will remain rendered until you reset for yourself. I’m not using the traditional respawn method, I’m using :Destroy() server-side on both the character and the kart model, then :LoadCharacter() after a set time. The karts and characters are initialized server-side as well, so there’s no reason they should still be rendering after being destroyed. Occasionally a player will spawn and their kart/character won’t render, but it’s still readable from the server. The parts that are stuck rendering after destruction are not readable server-side and have no collisions. This issue isn’t caused by any flaws in my code, as this problem persists when using :Destroy() on any instance. This is a huge problem because eventually I’d like to add in more features that require instantiating parts and destroying them.
As I was writing this I came across a thread from October that points out a similar(if not the same) issue: Rendering Issues
A few examples of karts & characters still being rendered after destruction:
Example 1
https://i.gyazo.com/362aea29c81dd3ba5ac79b01696015b3.gif
Example 2
https://i.gyazo.com/42daf5a00cd2d265b3d608520e0c545e.gif
Example 3
https://i.gyazo.com/368af73cb411cedc4271c0fb41cc81dd.gif
Is it possible to extract a minimal example that showcases parts being rendered while they should not be there? I think they would appreciate that so it’s easier to track down the issue.
Doesn’t this bug happen a lot in Phantom Forces? Your character being visible when they shouldn’t be and ghost dead bodies that have no collision/physics floating around.
Plus I’ve noticed that somtimes, equipping a low detail gun in PF immediately removes all/most the ghost parts.
I’d love to, but as I stated before, I’ve spent hours trying to find the root of the problem. If I could make a showcase of the problem I would, but I’d rather not just go and share all of my code. I have a feeling it may be linked to RenderStepped.
I suspect it’s caused by high latency, where movement replication and other data is prioritized, so ROBLOX doesn’t get the “please delete” request for a while.
It’d be helpful if you could check your ping from the server log, and see if this is the actual issue.
Does no one have any idea how this could be resolved? It’s really upsetting to think that I just spent several months developing something that won’t see daylight because of a silly rendering issue.
If you replace all unions in the carts with regular bricks only, does it still happen? Or maybe try having a single brick per part for a bit and see if the error still persists, that may help narrow down the problem.
I went ahead and removed the unions from the karts and the issue happened less than usual. Maybe the client can’t handle rendering the karts/wheels while replicating the physics. I’m going to see if I can’t fix the problem by localizing the unions(and maybe the characters too). It’ll suck if I can’t use unions because the build quality will drop exponentially.
[11/23/2015 9:19:17 AM] AxisAngles / Trey: You can tell that the physical gun is working right because the arms are being jointed to it.
[11/23/2015 9:19:20 AM] AxisAngles / Trey: You just can’t see it.
I don’t think it has anything to do with networking because the client knows exactly where the gun should be to be able to move the arms with it. It must be something with the rendering, which is odd because I play Phantom Forces on level 10 graphics with 60 fps, so I wouldn’t think my machine didn’t have enough resources to render the gun. It could be a bottleneck in ROBLOX’s rendering code I guess.
@LeitrisArcade@imnotaguestimagirl@Sharksie@leates Move to client bugs? (or merge with other thread linked in OP) This is definitely a bug.
We know that this happens sometimes but so far I’ve never seen a repro. I had @VolcanoINC show me this bug in his game once, but I could never replicate it in his game on my computer IIRC…
If there’s a way to see this happen with reasonable chance on an online or offline level we can investigate it. It’s really hard to find this otherwise.
P.S. It does not matter too much if the level has other parts - like, if you have a level with cars and I can get the car to disappear from the physics world but keep rendering even if there are thousands other parts in the level - that’s good enough as long as the repro is consistent (e.g. can get it by playing a few minutes).
Go to Phantom Forces with a friend, hope you’re on the same team, and then meet up somewhere in the map. Get your friend to spam switch their weapons (switch to secondary, primary, secondary, primary, etc) and you’ll see it happen pretty quickly – the times I’ve tested it it happens no later than ~10 seconds (complete guess but by quickly I don’t mean in a couple of minutes) every time. Not sure if it happens in a server with 2 or 3 people because every time I’ve tested it in a full server.
Edit: here are my hardware specs if they’re relevant http://pastebin.com/ncXDgsbM
Edit2: Resource usage screenshot:
Shouldn’t be too hard to reproduce in my kart game at all online. On an active server this happens very frequently, just don’t reset and drive around looking for characters/karts that have no collisions/sound emitting.
Ok, so in your case (and I bet Phantom Forces is the same) the problem is relatively straightforward.
Parts are grouped for rendering purposes into clusters, and a cluster has to be invalidated if parts inside it change other than CFrames being updated. I know that Phantom Forces does that all the time for the humanoids by animating the welds (which is bad for performance and I still don’t really understand why it does not use Motor6Ds but that’s a separate conversation); I’m not sure yet why your game has the same behavior - will look into it tomorrow.
Anyway, so what happens is that these clusters are put in a queue whenever they have to be updated, and we only process a few clusters from that queue to try to keep the game realtime. Unfortunately, this queue does not have a well defined ordering so if some clusters are constantly invalidated they can get “in front” of other clusters every time something changes so we end up constantly updating some clusters and never updating other. Which is why you’re seeing what you’re seeing.
It should not be hard to maintain a proper update order. I’ll look into doing this (not sure about next week, probably the week after that).
Sounds great, at least I know what the issue is now! Please do let me know when you look into this so that I know when I can get back to work. In the meantime I’ll work on some other projects.
