TaleSpire Dev Log 437

Heya folks.

We've got a bit going on, so lets get into it!

Bug month

I’ve made some progress on the bug from this log. We’ve eliminated the server side of the issue, so the client side was all that remained. I’ve got significantly closer to a fix, but I’m mainly battling with code written by past me. That guy was an idiot :P

I want to look over the solution with fresh eyes, so today, I decided to jump onto a different bug to focus on a different kind of problem. The problem I picked is a stinker that has been around for a long time. Under certain strange circumstances, you can end up with tiles seemingly hidden by a hide-volume but not actually inside one.

We’ve tried to track this down before, so we have some notes and ideas on how to find it. We knew there would be one hide volume that, if you deleted it and then reloaded the board, would be replaced by a previously unknown hide-volume responsible for the hidden tiles. With that, we slowly removed parts of the board until we only had this remaining:

I took a quick look at the zone boundaries to see if anything stood out.

The fact that the zone lined up with the zone boundary distracted me for a while. I’m still not entirely sure it isn’t involved.

That said, I did find the problem and the fix, but we have to talk a little about the board.

Boards in TaleSpire can be big [0], and because of this, we don’t save them in one file. All boards are split into cuboid sectors, which are then pulled on demand based on where you and your party are looking. Hide-volumes can span multiple sectors. Given a hide-volume that spans many sectors, which sector would you save it in? The answer: all of them. We do this as we don’t know which will load first. But then what if the hide-volume is changed, and one sector doesn’t get the update? Every hide-volume has a ‘version,’ which is just a number that is only ever increased. We increase it with every change, so when we load sectors, we know which change was the latest. They should always be the same, but in the case of a conflict, the version lets us resolve it.

Or it would, but the deserialization code had a mistake, which meant that the old versions were not being removed. The volume edit tool used one of them, but the job that applied the jobs to the tiles was applying all of them. Fixing the primary issue was simple…stop doing it wrong :P

There are a couple more edge cases I need to think about and then I can get this fix to you.

Tags

In tag news, the contractor has been doing great work tagging a bunch of creatures using the new system. Their results have highlighted an issue in the tagging of humanoids that we knew about but had left until later. @Chairmander and I will make a decision on that, and then we can tell the contractor to do the lot! With that done, we can upload the tags to mod.io and then update TaleWeaverLite to support tagging. In the future, I’d like to add mod.io support directly to TaleWeaverLite so you can download, edit, and re-upload your minis in the tool.

Build machine

The server we used to build the game’s releases died the other week. We set up a temporary replacement in AWS, but as that is over ten times as expensive (for basically the same performance), we were eager to get a new physical machine running. @borodust is working on that now, and so once that is back up we’ll start shipping fixes again.

Wrapping up

That’s all for today.

Have a good one!

Disclaimer: This DevLog is from the perspective of one developer. It doesn’t reflect everything going on with the team

[0] We haven’t actually unlocked how big they can be yet, we have capped them at a couple of thousand tiles across iirc.