Handy. Out of curiosity, if that cap is left in place, does it take effect before or after your adjustment?

No way! I'm not sure everyone realizes the possibilities of this!

I missed this earlier, but just to comment: I distinctly remember behippo coming to the exact same conclusion years ago. So I suspect you are correct.

Then again, he also said that adding new magic effects couldn't be done, so... who knows?

The armor cap takes effect before the DP is calculated. I could probably change that, but I was honestly hoping to eliminate the cap altogether.


Since obse allows one to freely patch the game, essentially anything is possible. I don't think adding new skills (complete with icons, perks, etc.) is unreasonable at this point. On the other hand, it will be a while before anyone gets there.

Ideally, I agree with that goal. Before committing to it, though, I'm going to spend some time considering what effect this will have on the relative usefulness of real armor, bound armor, Shield, and Resist Normal Weapons.

Related considerations will be posted momentarily in the OBME thread.

Say, what are the chances of making Luck into something slightly less stupid?

You can disable the luck bonus/penalty to skills using existing game settings. From there, I think the chances depend on what you have in mind.

"A completely different formula." Mainly the question is, if you've poked around those bits, whether there's a single point where Luck's effects can easily be edited, or whether it's baked in to several locations. Was going for a plausibility/reasonability check before coming up with alternatives.

Its current implementation is just plain horrid for several reasons. So any thoughts of what it could be have thus far been completely irrelevant because it couldn't be changed; I can ramble on at quite some length about all the problems it causes, but all of my solution-thoughts have been aimed toward working around it rather than fixing it. So I haven't got any great ideas there just yet. But if there's a possibility now, I'll start thinking about it.

Luck bonuses seem to be applied through a single function in the engine. In theory, changing they way it affects skills is just a matter of patching that function.
However, the same function is also responsible for applying a number of skill caps, so a patch could cause conflicts with plugins that uncap skills.

I'm actually a little curious about why you don't like the current implementation. I never bothered with luck as a player, so I also tend to ignore it as a modder. Could you (briefly ) elaborate?

Briefly, eh? I'll try. No promises.

One major problem with Luck IS the capping code. If your skill is at 100, Luck gives no benefit. If your Luck is at 100, skills over 80 give no benefit (until you hit 100 and get the master perk). This is a weird enough interaction in the vanilla game, but consider smooth-leveling mods where attributes rise directly from skill increases rather than by the player saying so: how do you handle it? Raise it along with everything else, because no skills affect it? Mechanically bad -- early in the game you wind up making everything easier than it should be, and later in the game it might as well have stayed at 50; and just for fun, it can't raise a skill above 100, making it dead even sooner if the user runs an uncapper. Doing the same thing but letting it start below 50, so at least you're not giving fat bonuses right out the gate? Equally bad, because the penalties actually hurt more than the bonuses help (and most players don't understand the mechanics of it anyway, especially if it causes skills to hit zero, which can have nasty tech support ramifications). Currently nGCD just leaves it at 50 by default, because anything else breaks something. But this is terribly unpopular, because the idea of luck is great and everyone wants to see that number go up... so I've got an option in there to do as mentioned above, and many users activate that option against my suggestions that they don't, and weird things happen like ingredients not producing effects when eaten and everyone gets confused as to why (including me, often enough).

So Luck does far too much for a low-level character, and pathetically little for a high-level character; but only a high-level character can have high Luck. As it stands, the only place I personally feel comfortable using it (as a designer) is in Fortify/Drain Ability effects, where it's not a part of the character but a deliberate bonus or penalty. Of course, it's rather unbalanced there too because with the default settings, for example, 5 points of Luck (equals 2 points of skill) has a slightly bigger effect on weapon damage than 5 points of Strength -- AND Luck affects every other skill too. (This, at least, can potentially be fixed with OBME by breaking Luck out separate from the other attributes for those effects.)

In vanilla, it's questionable. For a modder, especially one who has to take other mods into account, it's basically unworkable and best left alone. But no player (including the one sharing brainspace with the modder) wants to see it left alone. Conundrum, baby.

A big problem is that very little in Oblivion is actually random, so there's nowhere for Luck to behave as, well, Luck. But it's a traditional TES attribute, so it's still there and has to do something. I'd sure like to come up with something better...

The next version of AddActorValues uncaps functions that use skills and attributes (not all of them yet, but most). So for what it's worth, skill values above 100 really will be meaningful. If I'm understanding you correctly, this would ease your concern that luck doesn't benefit higher level players.

I do agree that it's a difficult attribute to balance, since it affects so many aspects of gameplay. And I certainly wouldn't want to play a starting character with a luck of 37. On the other hand, if you ignore the issues with caps, it does exactly what you'd expect luck to do - makes your character better at everything. And in a game so littered with odd mechanics, there's something to be said for simplicity.

Anyway, if you do come up with a better scheme, let me know.

"Uncaps," or just moves the cap to 255? If you can make the base values accept more than 8 bits, I'll probably be re-writing nGCD from scratch to assume truly un-capped values. The problem is that if there's ANY cap below four digits, a sizeable number of people WILL want to reach it, and these problems will remain.

How are you managing the uncapping with regards to things like the spell cost calculation, which goes negative shortly after 100? Completely rewriting the formulas? If you're already doing that, then yes, there's definitely a better way to handle luck; roll it into each formula as a completely separate factor, as was done in Morrowind. And for the love of Azura, put a curve on it. (Also don't worry about conflicts, because you're effectively replacing Elys Uncapper already.)

The 'base' value of skills and attributes is limited to 255 due to the way they're stored. However, the base value is really only intended to track increases from normal skill use and leveling. The only situations I'm aware of that use *just* this value are perks and formulas like potion strength. The former stop after level 100 anyway, and the latter can simply be changed to use the current skill value instead of the base. So if you *must* have an obscenely high skill value, just use another modifier to raise it - the non-base modifiers are all 32-bit floats and can hold quite large values.

It should be noted, too, that for non-skill/attribute AVs (health, magicka, resistances, etc) the base value is not capped at 255.

Anyway, tejon, the answer to your question is 'both'. As stated above, base skills and attributes can only be raised up to 255 through normal experience and levelling. However, the formulas that use these values (weapon damage, detection level, potion strength, etc) will now accept arbitrarily high (or low) values. Spell cost, armor rating, resistances, and other formulas that could be described as 'The percentage of XXXX' are also uncapped, in the sense that they're run through the 'Diminshed Percentage' function or something similar. And these formulas use the current AV value, so bonuses from luck and magic effects are all included.

I think I like it.

So as for Luck: a good, easily-implemented compromise might be to leave it as a skill adjustment, but radically change the way it actually affects skills. For starters, make it multiplicative rather than additive; for instance, +10 Luck might increase your skill results by 4% instead of simply by 4. Adding a DP calculation to that might do wonders. Though it shouldn't vanish completely at the top end, there probably should be a stronger influence from Luck if you have low skills; adjusting the base percentage factor according to the base value of each skill should allow this. (Edit: and so far as that goes, I definitely think only the base skill should be considered, not magical enhancements. That applies to both determining the factor, and applying it.)

Some numbers, let's see...

Okay, first and foremost, 50 Luck has to stay at 0 adjustment. Too many race mods would be broken otherwise. To solve many other headaches, 0 luck and 5 skill should not yield zero skill. Safe for it to yield 1, though. Let's try to pin that at -80%. Let's also try to make positive and negative luck equivalent; so 100 Luck and 5 skill should yield 9.

Based on comparison to other attributes, I think a solid anchor for Luck 100, Skill 100 is +10% (half of what it is now). Granularity might be a problem, though; will fractional skill ranks be meaningful in your new formulas? If so, we're probably good. DP will mean that smaller luck bonuses are more useful anyway.

Apologies for Englishing all over the math, but I'm fairly sure you've got a bigger, more interesting library of applicable formulas in your head than I do, and I believe I've defined the paramaters and behavior I'm thinking of well enough, so hopefully you'll be able to whip out a more generic and extensible model into which it all fits, as you have already done with resistances.

Fair enough. That should be pretty easy to implement.


I assume you mean "use only base skill when calculating the luck bonus" and not "use only the base skill for everything and ignore all magical bonuses entirely"? The former seems reasonable enough; the latter is something you'd have to take up with Bethesda.

:bonk:

Aside, just to double-check: you've fixed Ability bonuses so they won't prevent natural advancement of base skills/attributes? The old check was whether base + attributes >= 100, sounds like the "+ attributes" part of that serves no internal purpose and shouldn't be maintained even if 100 is pushed to 255...

No, I haven't. The 'base value' is just a number; there's no (good) way to tell how much of it comes from leveling vs. the value set in the CS vs. bonuses from abilities. For all intents and purposes, vanilla ability bonuses behave exactly the same as if the actor had advanced the skill naturally. This is precisely what Bethesda had in mind; it's the Ability's raison d'etre.

You can "fix" this using OBME - making a given ability affect the 'Max' modifier like other magic items - but I have a feeling that's not what you had in mind.

Oh... huh. For some reason I thought Abilities had their own modifier part. Misremembered! Complicates things somewhat, but not too badly.

Hmm. Could Abilities (in general) be made to affect the script modifier instead? And GetBaseAV tweaked to read that and add it so existing scripts don't break. Probably more trouble than it's worth...

With OBME you can do the first part. But I think the second part would cause a lot of problems.

However - one feature planned for AddActorValues is a scripted 'event handler' that will override the http://cs.elderscrolls.com/constwiki/index.php/Category:Actor_Values#Actor_Value_Mechanics factor of an AV. This calculated part is not stored anywhere but is computed every time that GetBaseAV() is called. It's intended to allow one AV to depend on other AVs, but you could use it to add special bonuses/penalties to skills & attributes that don't contribute to the overall 255 cap. And, despite what the wiki article says, this event handler will override the calculated part for all actors, not just the player.

Edit: Now that I think about it, with along with a "skill level increase" event handler (something you should request from the OBSE team), you could use this feature to store level increases in another av as well, which would allow you to work around the caps entirely.

Edit: Wrong thread. :spotted owl:

maybe a little BUMP?
it looks like powerfull plugin for OBSE
but rarely one know it as topic got at late pages of TOC

New beta with a refined feature set is in the works, I've just been distracted by other things.

If anyone reads this and is interested, I'm looking for ways to meaningfully uncap the Mercantile, Security, and Armorer skills. It's tricky because the master perks & skeleton key make the main skill benefit irrelevent, e.g. once your repair hammer is indestructible your true armorer skill doesn't matter. I can always introduce a secondary benefit, for example armor skill > 100 allows repair past 125%, but the purpose of this plugin isn't really to add new mechanics to the game. So any suggestions would be welcome.

Security: give the Player a detect life effect if he's in contact with a door, resembling the Player looking through the keyhole? And for locked containers, maybe give the Player the ability to find out (through messagebox or something) the combined worth of gold of all items in a locked container.

Can't think of anything else at this moment

simple - calling OBSE user-function with ID contained in GMST
and it should be done in two ways - one type of function instantly after getting skill amount needed for the perk, one called every n frames when the perk-amount is still availible
of course if the gmst is zeroed - the script wouldn't be called

so in that way it can be adjusted by a mod - it will be something similair to obsev19's event handler

Thanks for the suggestion. A 'skill level increased' event has already been requested for obse. I don't think it belongs here; the purpose of this mod is to uncap the existing formulas, not introduce new behavior. And any new behavior that is introduced will be hard-coded - scripted benefits have already been done, and done well, by mods like Legendary Abilities.