About a month ago Shard Seekers started crashing/freezing/“bad allocation”-ing randomly during play-solo. Sometimes I can go an entire day without crashing, it is very inconsistent and difficult to repro. It’s also been crashing on the live game at a similar rate:
Sometimes the client freezes indefinitely with no error messages. I assumed one of my 1500 modulescripts might have an edge-case that causes something to infinitely recurse/loop, so I wrote a script that automatically transforms the lua of every script in my game right as play-solo starts. I made it read tokens and insert a test around every block and statement so that if the client freezes or memory usage sky-rockets, it will throw errors and I will know about it:
I continued to develop normally with this active and the crash continued to occur.
I’ve spent hours digging through the roblox log dumps for answers. The crash is often preceded by “bad allocation” and other memory errors, then a delay, then the crash:
I even wrapped the entire Roblox API (mainly Instances and RBXScriptSignals) in tables so I can monitor what’s happening and dump a log into the output once a predictable error message appears. I can also throw errors when deprecated members are used, or when a script attempts to interact with a destroyed instance.
I’ve been wanting to do this for a while, and it’s generally useful when testing. It just requires replacing the Instance, game, workspace, script, typeof, type, and require globals with something that wraps and unwraps the values.
I can visualize CFrame changes just by writing this:
More importantly I can write all recent API calls to a log, so I can see if a specific API is causing the crash:
I can also check how many instances are currently being referenced and everything cleans up normally, so I don’t think it’s caused by an instance memory leak.
Even with this I can’t seem to get anything meaningful, so I decided to simply take a look at what code I changed before the crash started happening. The first crash was on April 26 at 7:28 pm.
I wrote something that finds differences between place files, and there were a few dozen scripts that were mostly refactored. Mainly it seems I replaced the invisible anchored dummy character with player.ReplicationFocus. I replicate all character physics in Lua, so it made sense for me to make the switch and set it myself.
Over a year ago I had similar confusing crashes when using workspace.StreamingEnabled with Custom Characters. I tweaked how I was spawning and cframing dummy characters and the crashes stopped.
Right now Shard Seekers has streaming enabled set to false because terrain would often never load further than the character’s immediate area, and being able to see under the map is just a bad experience.
The server puts a local map with NPCs in workspace.CurrentCamera so it can run physics locally. I designed my game to be very scalable, and to do this I need replicate everything manually on a need-to-know basis. The server reuses the same character physics and map code that the client uses, so locally simulated server parts are essential. It happens in play-solo so I’m not sure if this is the cause, but it’s something to note. The ReplicationFocus parts are also located in the server’s local camera, because they don’t work when parented to nil and it doesn’t make sense to needlessly replicate them to everyone.
I think it’s most likely related to terrain loading/streaming in respect to ReplicationFocus, but Shard Seekers is a huge project and it could still be anything.
I’ve been working on Shard Seekers full-time for over 2 years and I’m not sure what to do. I haven’t made a post until now because I haven’t been able to find a repro, but I’ve been getting lots of complaints recently