I'll definitely consider it. I'm not sure giving a bonus for high opinion is a good idea though (at least not all the way up to 100), but a penalty for low opinion does seem in order.
Yeah, I think it should be more of a malus overall than a bonus, and, at the extremes of opinion, it should never swing a bonus/malus larger than equivalent swing from 1.5-2 skill points (probably 0.5-0.75 of a skill point on the maximum bonus side). The whole spectrum should still make a difference (which player-visibly changes the advertised "yearly chance" for job action events), though.
The AI doesn't reason about councillor opinions directly (though is encouraged in other ways to do things that lead to high councillor opinion), and councillors at game start are auto-assigned purely on skill level. Ergo, one should tread lightly, 'lest the AI receive a net malus at the expense of the informed player (well, limit the extent).
I'll look into this then. And actually balance it.
EDIT:
I whipped up my favorite tool for net MTTH calculation and calibration, a simple perl script that encodes the MTTH spec, generates an appropriate data set over which to evaluate it, and prints out the code for me (then just tweak the ranges and modifiers until one likes the properties of the curve), and I worked out what I think to be an appropriately-balanced set of MTTH modifiers for councillor opinion. It rather harshly penalizes poor opinion (<0), generally penalizes all opinion <20 (they have a countervailing opinion bonus for being on the council, so +20 is essentially the balancing point), extra harshly penalizes the -100 (e.g., you revoked their title) case, is neutral for 20-35 (the only interval which is not in grades of 20), then provides a more slight and predictable bonus curve up to 95, where it maxes at a total -15% bonus modifier (only 60% of the bonus provided by a single, marginal councillor attribute point in these events).
At -100 opinion, it magically works out to a whopping 50% MTTH malus. At [-99,-80), it drops to a 38% malus, then a 30% malus [-80,-60), then 23% [-60,-40), then 16% [-40,-20), then 9% [-20,0), then 3% [0,20), neutral for [20,35), then -4% bonus for [35,55), -8% bonus for [55,75), and, as already mentioned, finally caps out at a -15% bonus (0.85) at 95 opinion and up.
I think this will play very well with all the existing MTTHs, as if anything, it's erring on the side of slowing things down when your councillors are selected purely for skill, and in the most perfectly optimized of councils (not that it's terribly hard to select compatible councillors and treat them right), we only see a 15% speed-up, which is greatly overshadowed by other MTTH factors in most cases. Despite the relative subtlety, it should still succeed at mattering enough to add more depth to council management with very little added complexity (particularly when you're playing a character that is no True Christian Knight and it's a choice between either a -40 courtier with higher skill or a less-skilled vassal for which you can pull-in a few favors). The granularity is sufficient to make all your actions toward your councillors potentially have a noticeable effect on their work quality, yet the stacking modifiers only take a total of 11 single-cheap-condition one-liners.
FWIW:
Code:
modifier = { factor = 1.09 not = { opinion = { who = liege value = -99 } } }
modifier = { factor = 1.06 not = { opinion = { who = liege value = -80 } } }
modifier = { factor = 1.06 not = { opinion = { who = liege value = -60 } } }
modifier = { factor = 1.06 not = { opinion = { who = liege value = -40 } } }
modifier = { factor = 1.06 not = { opinion = { who = liege value = -20 } } }
modifier = { factor = 1.06 not = { opinion = { who = liege value = 0 } } }
modifier = { factor = 1.03 not = { opinion = { who = liege value = 20 } } }
modifier = { factor = 0.96 opinion = { who = liege value = 35 } }
modifier = { factor = 0.96 opinion = { who = liege value = 55 } }
modifier = { factor = 0.96 opinion = { who = liege value = 75 } }
modifier = { factor = 0.96 opinion = { who = liege value = 95 } }
All easily tune-able, of course. I'll let that sit for a short bit before I move to the relatively tedious task of actually applying it (and potentially its inverse, appropriately) to all the relevant job events. After that, expect a pull request.
Note: I can merely generate and copy/paste a differently-tuned modifier set into the modified events, if it should seem so appropriate, so there's no hurry to get the MTTH curve correct on the first swing. I still have to go through them all [the events] and select those which should be affected (incl. some of those nasty events where you want the inverse MTTH curve; e.g., perhaps the ai_chance modifiers for a noble successfully bribing your chancellor, although technically in that case it's the same curve since it's an ai_chance rather than a MTTH). I've just put these one-size-fits-all numbers out for RFC purposes.
.png){kind=avatar}
