Fatigue's effect on selling price is backwards
Low fatigue negatively affects purchasing price, which is reasonable. However, low fatigue also negatively affects selling price, which I think is incorrect.
#3 Updated by scrawl . almost 3 years ago
- Target version set to openmw-future
That is a problem in the original engine too, though to reproduce it you need to have a character with a high value of the Mercantile skill. Buying the "Saint's Shield" from Galbedir and then selling it back, I got these values:
5 mercantile, 0% fatigue: shield sells for 5568 gold
5 mercantile, 100% fatigue: shield sells for 5718 gold
100 mercantile, 0% fatigue: shield sells for 10912 gold
100 mercantile, 100% fatigue: shield sells for 7874 gold
The reason is this statement in the barter mechanics :
if selling: x = min(buyTerm, sellTerm)
Simplest solution would seem to be to remove the fatigue effect on selling/buying price, since it's obscure and doesn't make sense. I don't get charged a different amount at the grocery store or a restaurant on the basis of whether I need a nap or just had a three cups of coffee, so why would this be a factor in MW game mechanics? It seems like an easter egg they threw in for number-crunchers, but it's broken and serves no purpose.
Does anyone know the Mercantile level at which this bug is triggered and the price point for selling flips into a reduction?
I believe that the rejected "duplicates" addressed a somewhat different issue.
The fatigue issue, if I understand it correctly, is clearly a bug and should be fixed.
The mercantile/personality issue is not a bug, it's a continuation of vanilla behaviour which I find rather illogical. It's not a high priority, but I would like to have the option of more logical behaviour available, which is what I wanted in the rejected #4063.
I don't think it can be fixed by mods - I haven't come across any which do so. Perhaps it has to wait for post 1.0 advances to make it moddable.
Agreed with David Walley. It also goes beyond Fatigue, and so is much worse than reported here: Your sell-to-merchant price drops both as your Mercantile skill increases and as merchant Disposition increases! To get a reasonable selling price, you often have to first use Persuasion (e.g. Intimidate) to reduce Disposition to around 50 or so. If your Intimidate succeeds, Disposition temporarily raises, then is reduced to below what it was before, after you exit and re-open dialogue. If you have low Personality and Speechcraft, you can often manage to incrementally lower Disposition more directly by repeated failed Intimidate attempts. Second, if you have TB/BM/GotY, you can then use a strong Drain Mercantile on Self.
It's absurd, and wrecks the immersion.
My typical routine at a merchant is to use Intimidate to reduce the Disposition (which keeps creeping up as Personality grows); this is an unrealistic "maintenance of dislike" routine, but proves necessary. If I actually want to buy something, wait for Fatigue to be full, use Fortify Personality or Charm to temporarily put Disposition at 100, plus use Fortify Mercantile. When that temporary boost is not in effect, and I want to sell, I use Drain Mercantile and Drain Fatigue. It's very time-consuming and ridiculous. "I love you, and you're the best bargainer I've ever met, so I'll offer you a deal you'd be an idiot to accept." "I detest you, and your bargaining skills are awful, so I will offer you prices that I'm crazy for giving you."
It's clearly a flat-out bug in the game mechanics, quite literally the opposite of the intention. I realize an OpenMW project goal is to mimic Bethesda's gameplay to the letter, but we really need to have ways to work around it when the original gameplay has flaws that were clearly not intended and which break the game.
A workaround for this should even be turned on by default, since no one would want the broken behavior unless they were doing some kind of testing, e.g. for consistent performance of their new mod in OpenMW and Bethesda.
#13 Updated by Alexei Dobrohotov 14 days ago
The point is to reverse the fatigue effect, I'm sure you understand that, Darklocq. Since Morrowind also has this issue, this isn't a 1.0 blocker and Morrowind behavior is kept. For now.
The duplicate issues (and your report as well, David! It's just a rephrased bug report, no actual feature request since illogical calculations are a bug) are
obviously apparently not so obviously referencing virtually the same issue, and scrawl is the lead developer, he knows better. If it makes anyone feel better, David's report can be marked as duplicate of these other issues. Won't change anything.
For Darklocq's note, any new OpenMW release isn't even supposed to be mechanically compatible with the previous releases since OpenMW is in heavy development. Some cautions are taken (like save format specifically changing very rarely). You may have played OpenMW for its entire 9 year development if that's what you wanted, alright, it's fine. But it never was 1.0 and isn't at the moment.
I understand. However, I've seen it said repeatedly by the devs here that OpenMW is going to mimic Bethesda mechanics as closely as possible, except for serious problems, and this appears to qualify. I'm at least squeaking the wheel in that direction hoping this gets greased. Or another way of looking at it: it's not necessary that every improvement be put off for post-1.0 if a fix is figured out sooner, and for something this bad there's a strong incentive to fix it sooner – even if the general rule of thumb is to postpone improvements.
I understand. However, I've seen it said repeatedly by the devs here that OpenMW is going to mimic Bethesda mechanics as closely as possible, except for serious problems, and this appears to qualify.
Maybe it does. But what if the blocker isn't whether or not we want to fix this, but how to do it? This issue appears to be a result of a design flaw in the formula, so we need a new formula which will behave differently, will not have been playtested, and will probably not match the intended difficulty curve of the original one in every respect. My point is that this isn't a simple 'bug' that can be fixed, rather a design flaw, and a solution will involve some amount of arbitrary-ness that we may not feel comfortable with. But if you can suggest one, go ahead.