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

Is there any sort of capping on this, or does a big stack of fur eventually beat unstacked daedric?

Precisely. Actually, the best technical implementation is a script on a token, which is applied by the script on the birthsign; but that's just details. Spells (including powers and abilities) which are added when you select a race or birthsign are exactly that: added when you select a race or birthsign. After the selection menu closes, nothing keeps them there except for the fact that normally nothing removes them. Set up a birthsign with a scripted ability and you kill two birds with one stone: the script can do anything any other script could, and you've filled the birthsign slot, which guarantees nothing else will do so and prevents you having to find some other work-around there. My recollection is that major skills were the only ones which could reach 100 at all. Minors were capped at 90, Misc at 80, the rest at 70. So it really was the first skill to 100... you just didn't have to worry about accidentally doing it with Run. (Unless you made that major. Generally a bad idea. Which was also a flaw... any skill should be worth putting in any slot, I think.) This actually could be done in Oblivion. You can stop a skill from advancing by setting its use rates to zero. And we have four OBSE-detectable categories to work with: Major, Specialization, Both, and Neither. By default, all of these have different advancement rates. nGCD grants them different attribute and level influence, so I can guarantee all the functions are available to set caps very similar to Daggerfall, if not quite identical! I agree... my current solution is Progress's Global Slowdown module, but I've actually got a better idea. It's not remotely Daggerfall-like and might wind up winning the record for Fewest Downloads Ever, and at the moment there's no truly clean way to implement it, but IMO skill decay is the best and most realistic answer. A better solution might be, instead of skill advancement speed, to change the number of skills required for a level-up. This would create something closer to the Daggerfall balance point, where your ultimate reward for gimping out the basic character abilities was a higher advancement cap. The downside of this is the world scaling... if the user has a static-scaling mod in place it's fine, but otherwise gaining levels too fast is actually a detriment. Hehe... design is fun! And it's so different that I can just look at it as a completely different game, rather than competition. Yep! Any formula is possible. You can even have a good old-fashioned die roll if you want.

Noble seamstress! But... but that's like... paperwork. Sans paper. Hmm. If all the BBcode translates it won't be too tough to do a one-time copy. Problem is that I edit the first page of my thread with updated info on a fairly regular basis, and that already sends me into grumble fits sometimes. Edit readme, edit Nexus, edit Beth forums... why can't you all just be psychic, damn it! edited by WhoGuru edited better by tejón

Okay, it was totally worth it signing up here. I've done a fair bit of work in this corner of the CS, and IMO the best solution here is to use the birthsign itself to provide the powers you're looking for. OBSE doesn't have a lot of birthsign-manipulation tools yet, but you won't actually need them; instead, create a birthsign with a single ability. That ability's script can then add or remove whatever powers you want (including vanilla racials), adjust starting stats, etc. Correct... a few of them. I can give you all the details you could ever want. Character definition and advancement is about 90% of my modding experience, and I'm happy to be a resource for this. On the flip side, I won't use it myself if it comes out as a truly faithful reproduction of Daggerfall's system, because the original was terribly executed and rife with exploits. Restoring the concepts has merit, but the implementation really could use some work. Thinking about it, I don't believe adjusting the skill-up speed per Daggerfall is a good idea either. The system is so different, it's just not an accurate conversion. Perhaps the biggest difference is in the cap: Daggerfall stopped all progress when one skill hit 100. Now technically, this could be achieved in Oblivion; but are we aiming for a total conversion, or a best-of-both situation? Of course I'm slightly biased on this topic, having written a total conversion for level advancement which would be utterly incompatible with a proper Daggerfall conversion. Cliff, I just realized that since the last time I bugged you re: Daggerfallesque mods list, I released Fizzle! which is intended as a replacement for TTT's Spell Failure. Its parameters are in line with the way Oblivion does things (e.g. cost scaling, Luck influence) whereas Spell Failure lifted the formula directly from Morrowind, so there's an argument for keeping both on the list. EDIT: Oh, there's a page two. Cliff, yes: it's 100% possible to select your health-per-level. Trivial if the Vanilla advancement is entirely disabled; still not especially difficult even if the standard level-up screen is maintained.

Well, here's my Bethesda forum thread which has most of it nicely gathered. I'll just say I'm not from Wisconsin, and gesture dismissively toward the avatar. Now that I've uploaded it.

Hehe... depends on what you want overhauled. I work on one piece at a time, and mostly on the character-abilities side of things; not so much the great big world. At least not yet. Hmm. If there's one thing I'm worse at than following multiple forums, it's utilizing multiple file repositories. But maybe. After I get comfortable with the snazztastic interface!

Hi all. I recognize many of the names here, but not all... I'm sure that's mutual! I've been tangentially aware of TES Alliance for a little while, and with the relaunch I figured I might as well drop by, especially since I've been far more active in the community lately. I'm notoriously (at least to myself) awful at keeping up with multiple forums so I don't know how strong my presence here will be, but hey, at least I have one. And every time I see one of WhoGuru's posts I'll be reminded to come see what's up. For those unfamiliar with my work: the vast majority of it has to do with overhauling game mechanics. I've got no skill whatsoever with 3D modeling or textures, so very little of what I do shows up in screenshots anywhere. Still, I think I've got a pretty good head for design, and I'm getting better at implementation... though I still feel a rush of doubt and surprise every time a new script compiles without an error! By the way DarkRider, I haven't forgotten about the voice work. Been wrapped up in my own stuff and I'm terribly sorry not to have shown anything yet.