0.7.126: %n missing implementation [RESOLVED]

[Jay_H]

Code in L0B00Y02:

Code: Select all

After slaying %n,

Current result:



UESP defines it as follows:

After slaying (random name),

[BansheeXYZ]

For clarification, the name is of no concern in the quest. The purpose of the note is to lead you to the employer of the assassin you just killed, whose name is on the bottom of the note and that's the name that counts. So yes, %n is just a random name. Nothing specific at all.

I just played through this quest in classic, and got the note. There's an amusing bug, each time you use the note, the %n name is different.

[Hazelnut]

Should be a quick fix. Will see if I can do it this weekend. Should the name be of any specific type? Nord, Breton etc?

[Jay_H]

Could it be derived from the local region? Gender appears to be indiscriminate. I don't know if it includes surname; Banshee, did you notice when you tested it?

[BansheeXYZ]

Yeah, it appears to change based on region. If I go to a desert region with the note and use the note, the name changes to stuff like "C'ertke" and "Serpka". But in Daggerfall region, it was stuff like "Belladanna Kingsley".

The names were also male or female.

[Hazelnut]

Thanks for the info. It now generates a random name specific to the local region with a random gender.

It was a little more complex as Nystul had an implementation for the talk window that just returned the name of the npc being talked to. I looked at some of the places %n is used and it seems to consistently be refering to a third party so I changed it for all uses.

Nystul, hopefully you can check this to be sure I'm not missing something here.

[Ferital]

I tested part of your PR related to this %n macro bug, it works perfectly, great work The problem is it now behaves exactly like in classic, with the same issue: a new name is generated each time the letter is read. I'm not sure if it's easy to fix with current DFU implementation, but it's not a very important bug since the name is not used outside the letter. Btw, the only other quest which actually makes some use of the %n macro is K0C00Y06, however this one is really difficult to test as it is plagued with many bugs.

[Interkarma]

The quickest fix would be to use quest UID as a seed before generating gender and name. Then it will be the same each time %n is called. Of course that's a problem if %n appears more than once in the quest. There's bound to be something else that could be used to improve uniqueness while keeping it deterministic.

[Jay_H]

%n occurs 4 times during K0C00Y06, but in parallel instances, not concurrent. It should be impossible to have two documents that show %n during the same instance of the quest. It appears once in L0B00Y02. I don't know of any further uses.

Thus far a seeded approach appears to work, assuming %n won't be expanded into any non-quest use.

[Hazelnut]

It's also used in the number indexed text strings from rsc file. I'll check those before taking the seed approach.