REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions [RESOLVED]

User avatar
Jay_H
Posts: 4059
Joined: Tue Aug 25, 2015 1:54 am
Contact:

REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions [RESOLVED]

Post by Jay_H »

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.

Image
Attachments
SAVE5.zip
(125.66 KiB) Downloaded 84 times
Last edited by Jay_H on Sat Oct 06, 2018 1:48 am, edited 1 time in total.

User avatar
pango
Posts: 3344
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by pango »

Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Jay_H
Posts: 4059
Joined: Tue Aug 25, 2015 1:54 am
Contact:

Re: (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Jay_H »

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

User avatar
Interkarma
Posts: 7234
Joined: Sun Mar 22, 2015 1:51 am

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Interkarma »

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

BansheeXYZ
Posts: 555
Joined: Fri Oct 23, 2015 8:19 pm

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by BansheeXYZ »

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

User avatar
Nystul
Posts: 1501
Joined: Mon Mar 23, 2015 8:31 am

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Nystul »

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

User avatar
Hazelnut
Posts: 3014
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Hazelnut »

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:

Code: Select all

buildings[i].buildingKey = BuildingDirectory.MakeBuildingKey((byte)layoutX, (byte)layoutY, (byte)i);
Then lines 2333 & 2334 of TalkManager only adds buildings with non-zero building keys to list:

Code: Select all

                            if (item.buildingKey != 0)
                                listBuildings.Add(item);
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 :lol: )

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.
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 7234
Joined: Sun Mar 22, 2015 1:51 am

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Interkarma »

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. :)

User avatar
Hazelnut
Posts: 3014
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Hazelnut »

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...

Code: Select all

            if (layoutX == 0 && layoutY == 0 && recordIndex == 0) 
                return int.MaxValue;
See my mod code for examples of how to change various aspects of DFU: https://github.com/ajrb/dfunity-mods

User avatar
Interkarma
Posts: 7234
Joined: Sun Mar 22, 2015 1:51 am

Re: REPEAT BUG (Nystul) Linux #132: Missing a tavern in dialogue directions

Post by Interkarma »

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.

Locked