Qwinn´s Ultimate DAO Fixpack v3 (no longer beta!)

[squareinc]

squareinc: On the soundset thing, yeah, as soon as you told me you were looking at sys_soundset_h.nss, I found the faulty bit of code. Just downloaded your script, and there's nothing wrong with the way you fixed it, it's how I would have as well. One interesting thing is that, having found where those soundset constants are set in 2da_constants_h.nss, there's one that isn't implemented:

 

const int SS_EXPLORE_SELECT_HATE = 38;

 

 

When I do the fix, I'm going to set it to just play that soundset, and see if they're all there for every party member and see if there's any reason they shouldn't be implemented. If it all looks okay, might make them work as a fix as well.

 

Incidentally, though - I don't think this bug would be triggered only at approval 100. It should be triggered for any follower whose personal quest you have completed and with whom you have approval 76+. That's why I haven't seen it this run through... I've postponed doing any of the romanceable character's personal quests till just before the landsmeet, so I won't have to rerun through everything if I need to test stuff in the endgame both with and without their personal quests complete.

 

That's great about the werewolf pelt! About the soundset, when I tested it in its vanilla state and looked at the code, it only played the LOVE range at 100 approval. So in my game I had romanced Morrigan, done her quest, but she was only in the 90's and so I got the adore dialogue. Alistair, having done his quest as well, was 100 approval and he started calling me 'my love.'

 

In my code, I changed the range for love to be 76 (the adore level in the game) AND having a romance active, so it would play even if you're not 100 with the character. The original it was just the 100 level for love whether or not the romance was active. I think the developers knew that was a problem too. The comments on that file said they didn't have time to fix it up and it was the E3 test script or something.

[Qwinn]

Okay - just rewriting this post from scratch, too many edits.

 

First of all, I was wrong earlier - the HATE soundset *is* used. Boy is it used.

 

Cause I did some testing and you're right, 100 is required. It looks like those values it's checking against (GetLocalInt(GetModule(), APP_RANGE_VALUE_FRIENDLY)), for example - are the TOP of the range, not the bottom. That's why the LOVE soundset only kicks in at 100.

 

Which it stood to reason meant that the WARM and NEUTRAL checks in that section were also looking for the TOP of those ranges rather than the bottom. So I went back to Lothering, where everyone was still in the 0-10 approval range.... and sure enough. What I get there *has* to be the HATE soundset. "What now?!" "Do this, do that..."

 

So the way it works now, you get their HATE soundset until approval 26, their NEUTRAL soundset until 76, and then their FRIENDLY soundset until 100, at which point you get their LOVE soundset.

 

So I'll be fixing that as well. Shouldn't be getting their HATE soundsets from the moment you pick them up. Have to find a way to get the *low* end of those ranges, not the high end.

 

EDIT: I just now saw what you did at the top of the script, with the functions to get the proper flags. I see now why you thought it might not be efficient, but really, unless we can add #include "approval_h" here, I'm not seeing how else to do it, and doing that would be risky since it wouldn't surprise at all if one of the functions calling this include also calls that one, and calling the same include twice is bad.

Edited March 20, 2017 by Qwinn

[Qwinn]

Okay, did a full analysis now. Your method was pretty good, actually. I see you wisely didn't name your follower variables the same as they are named in approval_h (you changed "FOLLOWER" to "MEMBER" in the variable names. That was smart, because other scripts like module_core call both approval_h and sys_soundset_h, If any other mod were to compile module_core, and you had named your variables the same, things would've broken. I will probably go even further and put SS (for soundset) in the variable names or something, to make it even less likely someone might pick the same variable names somewhere else.

 

Can't just add #include "approval_h" to sys_soundset_h because that sets off a recursive include. I'm going to see if I can determine if *all* the functions calling sys_soundset_h also have approval_h somewhere (player_core does), meaning we could porentially use the approval_h functions directly.

 

I'm going to try some experiments and will report back.

Edited March 20, 2017 by Qwinn

[LadyHonor]

I have nothing useful to add but I did want to say I love watching your enthusiasm when you're on to something. :p

[Qwinn]

OKAY. Got it working. For maximum safety, I offloaded all the work to a new script and plot that don't exist anywhere else - Qwinn_approval.plo and Qwinn_approval.nss. (Would've called them _romance but I can see further uses for these dealing with approval more generally).

 

They just deal with 4 defined flags, each just returning whether the 4 possible romantic followers actually are in a romance. Then in sys_soundset_h, I can JUST include my single plot file (and not have to include all the follower plot files, which might already be included in one of the calling functions) and then just do this:

 

case SOUND_SITUATION_SELECTED:
{
nSound = SS_EXPLORE_SELECT_NEUTRAL;
if (IsFollower(oCreature))
{

nSound = SS_EXPLORE_SELECT_HATE;
int nApproval = GetFollowerApproval(oCreature);

// Qwinn code starts here

string sTag = GetTag(oCreature);

int nRomance = FALSE;

if(sTag == GEN_FL_ALISTAIR)
nRomance = WR_GetPlotFlag(PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_ALISTAIR);
if(sTag == GEN_FL_MORRIGAN)
nRomance = WR_GetPlotFlag(PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_MORRIGAN);
if(sTag == GEN_FL_LELIANA)
nRomance = WR_GetPlotFlag(PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_LELIANA);
if(sTag == GEN_FL_ZEVRAN)
nRomance = WR_GetPlotFlag(PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_ZEVRAN);

 

 

if (nApproval > GetM2DAInt(TABLE_APPROVAL_NORMAL_RANGES, "Range", APP_RANGE_HOSTILE))
nSound = SS_EXPLORE_SELECT_NEUTRAL;
if (nApproval > GetM2DAInt(TABLE_APPROVAL_NORMAL_RANGES, "Range", APP_RANGE_NEUTRAL))
nSound = SS_EXPLORE_SELECT_FRIENDLY;
if ((nApproval > GetM2DAInt(TABLE_APPROVAL_ROMANCE_RANGES, "Range", APP_ROMANCE_RANGE_CARE)) && nRomance)
nSound = SS_EXPLORE_SELECT_LOVE;
}
break;
}

This shouldn't be able to cause conflicts with anything based on duplicate #includes, even if other scripts that use this get recompiled. All ranges from top to bottom are corrected.

 

So, here's how it's going in the Readme:

 

1) (v3.0) The sound clips that played when selecting a party member were completely screwed up. You'd get their HATE soundset at anything below 26 approval, their NEUTRAL soundset from 26 to 75, and their FRIENDLY from 76 to 99.... and then at 100 you'd get their LOVE soundset, whether you were in a romance with them or not (so Alistair at 100 approval would respond to a click from a male warden with "My love?"). Note that Sten, Wynne, Oghren and the rest of the non-romancable followers have no LOVE soundset, so at 100 approval they'd just stop saying anything. You will now get the HATE soundset only below -25, the NEUTRAL soundset from -25 to 25 (which is the actual "Neutral" range), and the FRIENDLY soundset if you are warm or better (26+), unless you are actually in a romance with them and they are 71+ (Adore), in which case you get their LOVE soundset. Many thanks and much credit to squareinc on the Nexus Forums for making me aware of the issue at 100 approval and showing me what he did to fix that issue on his own, which led me to further discover that my followers utterly despised me at 20 approval.

 

 

EDIT: After doing this, I just had to check - do the non-romance followers have a LOVE soundset? Was thinking if there was, and they were just super friendly without being romance oriented, I could have them play at 75+ or something. But no, they don't have a LOVE soundset at all. Which means at 100 approval all the other followers would just stop saying anything. Added that to the readme description above.

 

EDIT 2: BTW: The way this is implemented, I can change it very easily, so if anyone thinks I shouldn't activate the LOVE soundset until the follower is actually IN LOVE (i.e. finished personal quest and 91+ approval), let me know. Leliana's LOVE soundset is actually not all that lovey-dovey, so I think adore easily works for her, and I suspect Morrigan's probably isn't either, but Alistair saying "My love?" before technically being in love... I can see someone having an issue with that. No clue on Zevran's yet. I'll check out his LOVE soundset tomorrow. Time to sleep, 3:30am here (that's what my enthusiasm does to me, LadyHonor! I'll be a zombie at work tomorrow, dangit.) My argument for keeping it as implemented is this: while Alistair saying "My love?" at merely Adore might be a bit inappropriate, having them all say "Yes, my friend?" and other totally unromantic lines at Adore seems even more inappropriate. Do tell me if Alistair makes a big deal of "the first time saying the word love" in his dialogue though, since I haven't ever played through his romance. If so, I could make just him have to be actually IN LOVE and leave the rest at Adore.

Edited March 20, 2017 by Qwinn

[Qwinn]

Cleaned sys_soundset_h.nss up a little bit further... for the version I posted previously, I did have to add #include "wrappers_h" to use the WR_GetPlotFlag functions, but those aren't really necessary. This works just as well:

if(sTag == GEN_FL_ALISTAIR)
nRomance = GetPartyPlotFlag(GetParty(GetHero()),PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_ALISTAIR);
if(sTag == GEN_FL_MORRIGAN)
nRomance = GetPartyPlotFlag(GetParty(GetHero()),PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_MORRIGAN);
if(sTag == GEN_FL_LELIANA)
nRomance = GetPartyPlotFlag(GetParty(GetHero()),PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_LELIANA);
if(sTag == GEN_FL_ZEVRAN)
nRomance = GetPartyPlotFlag(GetParty(GetHero()),PLT_QWINN_APPROVAL,QW_ROMANCE_ACTIVE_ZEVRAN);

 

So now the only #include I add is #include "plt_qwinn_aprpoval", and the only code I change is directly within the case SOUND_SITUATIONAL_SELECTED. If that can cause conflicts with anything else or any other mod touching the same file (given my mod's lower priority setting), I sure can't see how.

 

(Didn't make it to work - my girlfriend slipped on the ice and banged her head :sad: Took her to the hospital instead of going to work. Luckily nothing broken, just a concussion. She's in bed sleeping it off now. I'm still a zombie though!)

Edited March 20, 2017 by Qwinn

[Qwinn]

So, squareinc, wasn't inclined to work this one in in this version of the fixpack, but in appreciation of your help on that soundset fix, it's done:

 

26. (v3.0) "Nature of the Beast": It will no longer be possible to destroy all werewolf pelts acquired prior to passing through the barrier, which prevents further game progress if the Grand Oak has been killed. The first werewolf pelt acquired will now become a plot item, and will be used by the Hermit to get you through the barrier should the need arise. If the player still has this plot item version of the werewolf pelt when passing through the barrier, it will be turned back into a non-plot, sellable werewolf pelt at that time.

 

EDIT: Just tested the hell out of it. Works great. I even managed to get the conversion from plot item back to regular pelt to not kick off an "Item Received" notification, so I'm very happy with it.

 

Back to Denerim!

Edited March 20, 2017 by Qwinn

[squareinc]

So, squareinc, wasn't inclined to work this one in in this version of the fixpack, but in appreciation of your help on that soundset fix, it's done:

 

26. (v3.0) "Nature of the Beast": It will no longer be possible to destroy all werewolf pelts acquired prior to passing through the barrier, which prevents further game progress if the Grand Oak has been killed. The first werewolf pelt acquired will now become a plot item, and will be used by the Hermit to get you through the barrier should the need arise. If the player still has this plot item version of the werewolf pelt when passing through the barrier, it will be turned back into a non-plot, sellable werewolf pelt at that time.

 

EDIT: Just tested the hell out of it. Works great. I even managed to get the conversion from plot item back to regular pelt to not kick off an "Item Received" notification, so I'm very happy with it.

 

Back to Denerim!

 

Now got home from work. Thanks for including the werewolf pelt :). For the soundset I'll have to ask my gf about Alistair's romance since she's the one who played it through. The others romance dialogues are not as direct. I suspect that the devs wanted it to be vague and passable as friendship since they had to know what their code would do at 100 approval. Then Alistair's clinginess changed all that. I'm glad that your fix is more compartmentalized than mines. I couldn't include any of the h files in the original fix so I had to recreate the functions.

 

In Denerim and Redcliffe, I notice that the chanters board quest markers sometimes don't go even if you complete all the quests. I'm not sure if I experienced it in Denerim explicitly (I think I did) but definitely in Redcliffe. I don't know if that's something to look at. I usually made my small fixes as I came across the bugs in the game. Right now I'm at Orzammar (haven't played in six months) and so that's where my fixes stopped. The politics in Orzammar make the dialogue tricky to trigger. In the Dagna quest (I know you said you fixed it) there was an issue where the dialogue tree order was messing up her responses if you told her you wouldnt help her go to the Circle.

 

Also, in the slum area of Orzammar, the merchant there that can give you info about the cartel takes the wrong amount of gold (this is true with Sten's personal quest too). Also, the lyrium quest dwarf, Rogek or something, doesn't do the right money checks either. This is because in his script, he uses a constant figure for the money checks that is stored in orzammar_constants_h (I probably got the name wrong). So the constant figures are 50, 40, 20 and he uses that for all his money checks, even if it is not relevant to the lyrium quest and it does not match his dialogue. I had fixed this my changing the checks.

 

One other Orzammar thing. The beggar woman who asks for money, can never take money. This is due to the dialogue restrictions. Her dialogue checks to see if she talked to you before and if she did, she plays a different version of her begging line. As such, she can't do a money check and so the game never takes money from the player even if you say you will give to her. I couldn't fix this since that would require dialogues to have more than one conditionals or checks and I could not get it to work.

 

I hope this hasn't been too rambling or confusing. I now got home from work and know this isn't written well. Sorry about that. I hope I could help more!

[aeroldoth]

A minor issue. I just discovered that if you don't buy the rock salve recipe in Ostagar (around L4), you can't buy it until the elven alienage opens up after the landsmeet (after doing all the other regions)(around L18+?). That's silly.

 

http://dragonage.wikia.com/wiki/Rock_Salve_Recipe

 

Suggest adding it to a store where players have easy access, maybe one of the merchants outside the dwarven gates.

[Qwinn]

Squareinc: All the money check issues you mentioned in Orzammar have already been fixed. You might want to read the thread from the beginning (well,page 2 anyway, when I showed up), I posted a full description of every fix I've done somewhere in this thread, lots of good stuff I think you'll enjoy reading about. Just a few pages ago I described how I change the Chanters, Mage Collective and Irregulars quest marker stuff too.

Aeroldoth - not a bugfix I'm afraid.

EDIT: Squarenic, in your last post you did alert me to one bug with Dagna I didn't notice the first time through, thanks:

99. (v3.0) "An Unlikely Scholar": If you accepted Dagna's quest, talked to Janar, then told Dagna she should stay in Orzammar (all before getting permission from the Circle), the quest would close as failed, but then when you spoke to her again her response would be unchanged and the quest could be continued. Credit to squarenic on the Nexus Forums for making me aware of this one.

Oh, and P.S., multiple conditions on a dialogue branch are handled via defined flags in a script, take a look at some and you'll see how it works.

Edited March 21, 2017 by Qwinn