Daggerfall Workshop Forums

The town I'm in (Oxton, Dwynnen) has 3 taverns but only 2 are available in conversation. The Devil's Dagger is not an option.

Maybe a duplicate of "Build #127 - Daggerfall/Lucky Stag Hostel -- The Rat and Dog not showing up under Taverns in Talk UI"?

Ha, ha. Well, I used to make frivolous reports a lot more before Sorry for the repetition. Thanks pango.

Thanks for report. I'll leave this one here until Nystul confirms duplicate.

Two taverns having word "dagger" in them. Just like before where before when it was two with "rat" in the name.

thanks for reporting - interesting one - will take a look when I find the time

I've done some investigation of this issue and found the problem. Basically any building in the first block (i.e. x,y = 0,0) that is the first in the RMB BuildingDataList (i.e. i = 0) gets a building key of 0.

Line 456 of RMBLayout get zero for 3 zero parameters: Then lines 2333 & 2334 of TalkManager only adds buildings with non-zero building keys to list: Which results in a building not appearing in the list.

I'm not sure whether the problem here is with buildings getting zero as a building key or the conditional that ignores them. I suspect the former, and my suggested fix would be to have the for loop in RMBLayout.GetBuildingData() to start from 1 rather than 0, or just add a fixed integer to i when passing to MakeBuildingKey(). However, I'm not really sure what knock-on consequences of changing building keys might be, but I suspect it might need a bit of thought.

Interkarma, unfortunately I think this is your issue and not Nystuls' - although I may be wrong. (happens occasionally or so my other half tells me )

EDIT: I was looking at the data for "The Lucky Stag Hostel" from the other report. This is block TVRNAS04.RMB which you can dump to json using the dumpblock command.

Thanks for chasing down.

That does look like bit of bad design on my part. Currently building keys start from 0 and go to N (depending on how many blocks and buildings there are). The first building in the first block will have a building key of 0. It's really a calculated building index and 0 is a valid value with this method of key generation.

The problem is that we're also using buildingKey == 0 as a way of filtering out "building not found/invalid" in a few places. I just checked and I'm doing this myself. The two obviously can't work together in this way.

I'll take this on and engineer a fix that doesn't break anything else like cached discovery data. And of course building key still needs to be reversible back to index for other purposes. I got this.

Interkarma wrote: ↑Tue Oct 16, 2018 9:12 pm Thanks for chasing down.

You're welcome, I'm trying to be useful.

Interkarma wrote: ↑Tue Oct 16, 2018 9:12 pm That does look like bit of bad design on my part. Currently building keys start from 0 and go to N (depending on how many blocks and buildings there are). The first building in the first block will have a building key of 0. It's really a calculated building index and 0 is a valid value with this method of key generation.

The problem is that we're also using buildingKey == 0 as a way of filtering out "building not found/invalid" in a few places. I just checked and I'm doing this myself. The two obviously can't work together in this way.

I'll take this on and engineer a fix that doesn't break anything else like cached discovery data. This should be interesting.

One simple fix would be to replace 0 with MAXINT in MakeBuildingKey. Something like this, although maybe int.MaxValue is too big. Just a thought for a quick fix...

I'm doing something similar by adding a "generation" value to key bitfield. Now I can tick up generation as needed with a simple bit compare, check gen of any key, and convert between generations easily. It's a bit like having a "serialised version" built into the key where all current keys have "version 0" in those bits.