Path Clumping and Phantom Tile Fixes
Hey Folks! Hope everyone had a good weekend. Nice weather here, and a lot of quality father-daughter time, as mom attended a recertification course and did some painting. Exhausting, but fulfilling!
Back at the office, Michael heard my cries for pathfinding help, and checked-in some code which fixes most of the clumping issues we were seeing. AI preferentially chooses spots which are unoccupied now when walking to a task. And you can see the results in today's screenshot.
With that solved, I thought I might run a quick test to see if I could record a new video for today. But as you're probably well aware by now, that didn't pan out.
I decided I'd try OBS today instead of BandiCam, to see if the smaller video sizes made the workflow faster. And I have OBS setup to record a windowed game (while my BandiCam records a region of the desktop). So I generated a release build to run in a separate window, loaded a test ship in the editor, then tried to run it. But I got an empty screen. No crash or anything, but nothing loaded, either.
And what's worse, it only happens in release. The editor runs the test fine.
I'll spare you the long, boring process I went through trying to figure that out. Especially without my usual debug tools available in the release build. But by late afternoon I had it. The culprit was raycasting expired ship tiles.
Basically, when the game is editing a ship, and the user clicks "Crew Sim" to test it, it first clears the scene, then starts a new game with the layout we were just editing. However, objects destroyed are not immediately removed from the game in Unity. They're marked as "destroyed" and the game cleans them up later. So when the game destroys a ship and starts building a new one immediately after, the process of checking what tile is below each object as it is placed detects not only the current ship's tile, but the destroyed one.
Now, I could've solved this by null-checking each time I did a raycast, but this doesn't ever happen in the Editor. So I checked why. And as it turns out, I was using DestroyImmediate() when in editor mode, but plain old Destroy() in release mode.
Switching this to always use DestroyImmediate solved the problem. I think it makes loading/unloading a bit slower, since it has to clean up "right now" instead of in the background. But not enough for me to go back into all the places the code raycasts to add null checks. In short, this just makes release work like the editor mode. And if/when the time comes for me to optimize for speed, I can decide if refactoring the raycasts to be safer is the better way to go.
Anyway, I think it might be safe to record now. So I'll try again tomorrow!