tejon

Oh ack. Indeed, one of the greatest.

Well... best way to start is with a code suggestion. Then if anything's unclear, ask me what it does. array_var horses ref thing begin ScriptEffectStart let horses := ar_Construct Array let thing := GetFirstRef 36 2 ; Begin scanning creatures within a 2-cell radius while (thing) ; Continue until thing == 0 if (GetCreatureType thing == 4) ; Horse if (GetOwner thing == player) let horses[(ar_Size horses)] := thing ; (ar_Size horses) starts at zero and increases every time we add an entry. ; Conveniently, array indices also start at zero. This saves managing an index variable! endif endif let thing := GetNextRef ; If there are no more creatures this returns 0 Loop ; You now have an array of all local player-owned horses. ; Do something with it! end

BLUE STEEL That's over a year old, I think... should probably get photographed more often.

Running it twice will have no major ill effects, only the last one found will take precedence. To optimize a little you can use the OBSE FileExists command in an If/ElseIf block, so you only ever read one file.

There's a built-in effect called "resist normal weapons," and there's a checkbox for each weapon saying whether or not it's "normal." By default only silver and daedric pierce this resistance. Enchantments go around it, but only the actual enchantment... a steel claymore with fire damage will do the fire damage, but not the steel damage. You can check the box for any weapon in the CS, and with OBSE you can toggle it during gameplay, so technically the behavior you're looking for could be achieved. The question is just how much effort it would take to increase the complexity level so that, for instance, silver can hit a ghost but not a daedroth. Other than that checkbox and the item's text name, there's no record for what material an item is made of. It would be a challenge, but probably not impossible. I think there's a new function coming in 0019 (could have slipped into 0018, doubt it but I'll check) which will help tremendously, especially with mod compatibility; currently you can script an actor with an OnHit effect (triggers on any weapon, doesn't tell you what triggered it), or with OnHitWith (triggers on one specific weapon, so you'd have to write such a block for every specific relevant weapon). There's talk of adding a function for use in regular OnHit blocks which tells you what the striking implement was.

Yeah, this one. The whole system can be wrapped into a birthsign. This first and foremost guarantees that the player doesn't screw up balance by tossing a birthsign on top of it since the slot's already filled; but also, it means that you can just leave this mod active whether you're using it or not. When you want to start a character Daggerfall-style, select the Daggerfall Birthsign!

To be honest, while working out the math is fun (IMO: 1 + skill/200), after some consideration I think I prefer having the number of stacks be Armorer-based, with a fixed exponent. The reason is that it turns out to be in the user's favor not to stack any items until late-game when he can get the best bonus; even an early-game 2-stack item having a 3rd stack added by a Master, isn't as good as if the Master just starts with three and stacks them all at once. Players are very good at hoarding things for later, any encouragement to Do It Now is a good thing IMO. Regarding weapons... might as well just use the same method, really. Top end in the vanilla game is 20, IIRC? Things can't get too out of hand. Just refuse to stack anything with 99+ damage! Also, this should exercise Armorer skill if that skill is to have any effect on it! And by quite a lot, I think... 5 repairs' worth or so. Re: the Daedric Shield -- I picked that because it's the absolute highest AR in the game, and 26% is only 6% more than the 1.2x multiplier you'd been using. And then it drops fast. I think it's good.

Read the comments in Progress.ini, the advancement formulas are all explained there. Changing them in real time works. Speaking of which, for general compatibility purposes making this a Progress plug-in is probably a good idea; the purpose of Progress.esm is to let multiple mods keep track of whether a given change is temporary or permanent!

re: inherent stacking limits through math... I can solve the problem for you right quick for armor. (Weapons will take a bit more thinking; they can potentially have damage > 100, though none in Vanilla do. If you want to assume they won't, this will work for them too.) Daedric shield AR: 22.5 Total immunity: 100 100 - 22.5 = 77.5% This is the amount of damage which passes through a Daedric shield. Convert it from percent to multiplier. 77.5 / 100 = 0.775 Now instead of putting a multiplier on this, we're going to use my favorite trick: exponents on values between 0 and 1 will always yield values between 0 and 1, and you can get all sorts of nice curves out of this. Picking the exponent is a pretty random process; let's just grab the one for calculating spell cost from magnitude, which is a similar balance point when you think about it. So: 1.28. 0.775 ^ 1.28 = 0.721616 Convert it back to an AR value... 1 - 0.721616 = 0.278384 * 100 = 27.8384 for a Daedric Shield stacked with itself; about a 23.7% improvement. Stacking another on top requires no special handling, just follow the same process. I'll shortcut the beginning math since we already know how it converts to decimal-damage-received: 0.721616 ^ 1.28 = 0.658615 = AR 34.1385, only 22.6% better. Stack it again: 0.658615 ^ 1.28 = 0.607844 = AR 39.2156, down to a mere 14.8% improvement. The benefit will continue to shrink. To see how it stacks up (haha) at the other end: Fur Bracer = AR 2 = 0.98 damage through. 0.98 ^ 1.28 = 0.974472 = AR 2.5528 (first stack: +27.6%) 0.974472 ^ 1.28 = 0.967442 = AR 3.2558 (second stack: +27.5%) 0.967442 ^ 1.28 = 0.958517 = AR 4.1483 (third stack: +27.4%) ...as you can see, the decay in effectiveness is slower, which IMO is a desirable result; the worst stuff has the most room for improvement! If you want to get REALLY clever, make the exponent itself a function of the player's Armorer skill... that would replace gaining extra stacks from Armorer. Anyway, in OBSE v0018 code, here's the formula: let temp := 1 - (oldAR / 100) let temp ^= 1.28 let newAR := 100 * (1 - temp)

Ini files are dead simple, you just set up some variables in a quest script and use GetGameLoaded->RunBatchScript to assign them. Take a quick peek at nearly any of my mods for a crash course. The hardest part, when necessary, is synchronizing multiple scripts to make sure nothing happens until the initialization is processed. You could construct a monstrosity of arrays and conditions, but I think the simplest solution here is to append the stack count to the modified item's name: "Fur Bracer" + "Fur Bracer" = "Fur Bracer (2)" Of course this should still be kept in an array and re-used if you need another Fur Bracer (2), but you don't need to manage any extra info.

Something I would never think of! I've been known to add stupidly unbalanced options for users, but the default configuration is my baby, will conform to my balance standards, and those who don't like it can go... cultivate intimate self-awareness. Configuration, now there's my forte! I'd recommend two config options: base maximum (can be 0 or a positive number, negative numbers mean no cap) and a divisor on Armorer to allow bonus stacks (zero or less = disable). So for instance: Default configuration - MaxStacks : -1 ArmorerBonusPer : 0 Flat 10-stack maximum - MaxStacks : 10 ArmorerBonusPer : 0 Base of 5 stacks, plus 1 per 10 Armorer - MaxStacks : 5 ArmorerBonusPer : 10 How I'd probably configure it - MaxStacks : 0 ArmorerBonusPer : 25