kromey

I could be wrong, but I believe Beth's DLC changes to leveled lists are effectively replacers -- exactly the same thing as happens when modders change leveled lists. This means that while any mod is free to change them -- just like Beth's DLCs do -- multiple mods changing the same ones effectively results in only the last mod in your load order getting its changes in. This is why Wrye Bash is needed, although it does seem possible to effect changes in leveled lists via scripts that would obviate the need for Wrye Bash as any number of mods could do the same thing without breaking each other -- but then you have "bake-in" issues in saves, so even that's not a perfect solution.

Feedback from my alpha testers has been remarkably positive so far. I've still got a lot of work to do to make it fully playable, but I think most of the big pieces are sorted, done, and so far seem to be working quite well! I think the biggest piece still left to do is to distribute the quest books around Skyrim, which I intend to do via the Radiant Quest system so that no two play throughs will be the same -- always a new adventure to find the books! ;) Speaking of which, I've still got to write those books -- maybe that's the biggest piece still to do... Also speaking of which, I'm still soliciting lich-themed lore books from anyone who wants to write one! More information in that thread.

Always glad to hear there's more interest! The current plan is to maintain a zero-DLC requirement for the mod, which will remain true at least through the 1.x versions. I've heard hints of some pretty sweet stuff in Dragonborn that may be irresistible for the ancient lich, but that's a ways off and not something to worry about just yet.

Ending the quest (not merely setting it completed, but actually stopping it) should remove that quest item status. Another option would be to use a script on the item itself that uses the OnContainerChanged() event to put itself right back into the player's inventory should it be removed, unless the quest as progressed past a certain stage. Then you don't have to make the alias a quest object. Yet another option (that's maybe a bit of a cheat) is, when the quest is done, use a script to remove the quest alias from the player, but then immediately add another copy of the item to the player's inventory. Something like this: Player.RemoveItem(Alias_Journal, 1, True) ;Remove it, but suppress any message Player.AddItem(Alias_Journale.GetBaseItem(), 1, True) ;Add a non-quest duplicate, also silently And yet one more option (maybe) would be to use Clear() on the alias, which if I understand correctly leaves the item where it is but the alias no longer points to it (have to make sure the alias is optional for this to work).

Keeping in mind again that I've not messed with weather, I think what will happen with ReleaseOverride() is that the override you started with ForceActive() will be released, and the weather will change to whatever the game thinks should be the current weather -- which most often will probably be whatever you overrode initially, but if the game engine decided the weather should change during the time the ForceActive() override was active, I believe you'll see this new weather. Either way, now that you've got a script it should be easy to test.

How about a simpler conditional? With just the one stormcloud property: If Weather.GetCurrentWeather() != stormcloud stormcloud.ForceActive(True) EndIf Now you're even compatible with mods that might add new Weathers! :) If that doesn't work (I've never played with weather at all in the CK or in Papyrus, I'm mostly just making semi-educated guesses based on what I've found on the CK wiki), try this conditional: If Weather.GetCurrentWeather().GetClassification() != 1 ;True for any weather not classed as "cloudy"

How? That's what the Black Sacrament is, a ritual that summons the Dark Brotherhood for your contract. See e.g. the description in A Kiss, Sweet Mother.

This seems pretty awesome to me! I'm currently working my way through the DB -- in between working on my own mod, of course -- and I'm loving it so far. Pretty exciting who all you get to assassinate as you go... I would strongly recommend that most of these ideas -- a full council of Speakers, recruiting NPCs, etc. -- not be available until the player has restored the DB. The whole point of that quest line is that they've fallen from where they once were, and until you complete a certain very-high-profile contract they're really in no position to have or be doing any of that. I may have more thoughts to add once I finish the quest line myself. One thing I'd love to see (may already be there in vanilla, I dunno, haven't finished the quest line yet) is Radiant quests to run off to the various cities and towns around Skyrim to murder random NPCs. Better yet, you should get wind of someone performing the Black Sacrament, go there and get the contract directly from the source. Something like the Thieves' Guild's jobs in each of the major cities, culminating in the creation of a new sanctuary nearby, could be pretty sweet, since you're talking about new sanctuaries already. Not sure what the DB equivalent jobs would be, probably murdering nosy guard captains so they can be replaced by someone more willing to look the other way, or something. Has a risk of seeming too trite and cliche if not done very well, though.

Yup, that's me -- thanks!

The formula is only approximate (as UESP mentions), and your calculated result is (once you account for rounding) only six one hundredths off of the displayed rating -- which, when you think about it, is really really close. I doubt you did anything wrong, it's just the formula is only an approximation, combined with the fact that the result in the UI is rounded.

Other way 'round -- if you extend Actor, then you can call ObjectReference methods in it. However, you can always get an Actor object and call methods on it from your ObjectReference script. I suggest heading over to the Creation Kit website and starting with the tutorials; they'll give you a good start on the basics of how to script.

If you use Game.GetPlayer(), you don't have to import game. Also, if you use Actor Property PlayerREF Auto, and auto-fill it, and then use PlayerREF in your code instead of either form of GetPlayer(), that's actually a more efficient way of referencing the player -- a hundred times faster, by some benchmarks! Anyway, glad you got it working. :)

Some elaboration on my responses: 1) The Companions clearly have enemies, and while I myself have no feelings one way or the other about either side, the player's rather rail-roaded in that they have only one option -- and I hate rail-roading! 2) If not Krev per se, someone high up in the Silver Hand. I mean, you're not talking to Whitemane right off the bat if you join the Companions, why would you get to go straight to the top with their enemies? That doesn't make sense! (In hindsight maybe I should have voted for option 2 on that one...) 3) Each murder should have the same risk of getting a bounty as any other murder -- but if you do it all sneaky-like, and/or murder all witnesses, you shouldn't automatically get a bounty. Also, why would you get perma-banned or perma-hated out of Whiterun? The Companions don't run the place, they just happen to have a home there! At the absolute most you should get a higher bounty than any "normal" murder would get you, and maybe a few individuals would refuse to talk to you afterward, but really that's it. That the Companions happen to have their home base in Whiterun doesn't mean they or their murders gets any kind of super-special treatment. 3a) Now, if destroying the Companions is your path into joining the Silver Hand, then maybe you'd find yourself on a few more s#*!-lists -- not because of the murders, but because of your current affiliations.

Looks like what you have will work once you create a property for the weather you want. In the CK, where you've attached the script, double-click on it and click Add Property, then add a Weather property and call it something like CloudyWeather. Hit okay, then select it in the properties window and choose your weather from the drop-down list on the right. You'll then have to change your Weather.ForceActive(True) and Weather.ReleaseOverride() lines to use your property instead of the type.

Status update: Spent pretty much the entire weekend working on the "lich death" script, finally got that working. A couple more things crossed off the to-do list, and I've sent the first test version out to my testers! There's still a lot to do -- 12 issues still open, and I'm sure more will be opened as my testers find bugs -- but this is the first major milestone crossed! :thumbsup:

I ended up going a different route: Still using the alias on the player (and still attaching the script via the alias), but the alias no longer makes the player essential. Instead, MakeLich() makes the player essential via script: PlayerREF.GetActorBase().SetEssential(True) Then, MakeNetherLich() un-makes the player essential (er, makes the player non-essential :whistling: ): PlayerREF.GetActorBase().SetEssential(False) With a touch of semi-clever scripting, this actually produces a somewhat interesting mini-scene when the player is transformed into a nether lich! It's not perfect, it's got a few flaws, but it's more than serviceable for now.

That is some good information, I had no idea that changes made via an alias would persist, nor that ActiveMagicEffect scripts received their actor's events! I think it's time to get back in the hotseat and see if I can't make a functional "lich death" script now -- kudos to you! :thumbsup:

Actually, I can't not use the alias, as it's the only way to add a keyword to the player at a scripted point (start the quest, the player becomes undead by gaining the ActorTypeUndead keyword). But if I could find a way to work it such that the player doesn't have to be made essential... Hm... does the OnHit event trigger before or after damage is applied to the character? If before, is there a way to find out how much damage it will do? That might be an option... Really, I just need a way to detect when the player would die, and prevent that from happening.

Hm... I haven't had any issues with aliases myself, but then again I haven't scripted on many aliases. How would I use an ability to capture these events? MagicEffect doesn't have them; can I use a script that extends ActorReference in an ability? I was using the alias because that's the only way I know of to get these events...

Well, I'm stuck. I've been hacking at the "lich death" script for my Lichdom mod for the last... 5 hours? Really?? Damn... Anyway, I'm stuck. I can get the player into either one of two states: 1) No different -- player just dies 2) Player is immortal What I'm trying to do (and apparently failing miserably at) is to write a script such that when the player would be killed, if they are a lich, their health is recovered and they get downgraded to a nether lich; if they are a nether lich already, they actually die. My closest attempt thus far uses the following scripts (snipped for clarity/brevity, all properties are properly defined and assigned in the CK): On the player (via a quest alias): Scriptname Lich_DeathScript extends ReferenceAlias Event OnEnterBleedout() Debug.Notification("We're dying!") (LichStatus as Lich_StatusScript).LichDeath() EndEvent And the quest script function being called: Scriptname Lich_StatusScript extends Quest ;For all intents and purposes, think of CurrentStage as an int that is initially 20 Function LichDeath() If CurrentStage == 10 Debug.Notification("Nether lich death -- die!") ;Player is already a nether lich -- time to die! CurrentStage = 0 ;Not a lich no more ;PlayerREF.GetActorBase().SetEssential(false) PlayerREF.KillEssential() ElseIf CurrentStage == 20 Debug.Notification("Lich death -- become nether lich!") ;Heal the player up PlayerREF.ModAV("health", PlayerREF.GetBaseAV("health")) ;Make the player a nether lich MakeNetherLich() ElseIf CurrentStage != 0 ;Bwuh??? Debug.Notification("Unknown lich state!") ;Failsafe -- just make 'em a lich MakeLich() Else ;"Lich state" is 0, which means not a lich -- do nothing EndIf EndFunction All the debug notifications appear as I would expect, which means this code is doing what I want it to, except that the player never actually dies. The player is made essential via the quest alias, but the KillEssential() function should be overriding that; instead it appears to be triggering the OnEnterBleedout event. Trying to make the player be not essential doesn't change anything either. I've tried also not making the player essential, and using the OnDying event instead; that one just seems to never fire at all for the player! At least, I'm not getting any notifications on my screen. What's really weird is that the following script, which is attached to a potion, works (also snipped for brevity): Scriptname Lich_ElixirEndlessNightScript extends activemagiceffect Event OnEffectStart(Actor Target, Actor Caster) Target.GetActorBase().SetEssential() ;Make the victim essential Target.Kill(Caster) ;Send the victim into bleedout... Utility.Wait(deathDelay) ;...wait a bit... Target.KillEssential(Caster) ;...then kill him for good EndEvent So obviously KillEssential() works even on the player (tested by quaffing the potion, which despite its fatal nature I've made sure to make it not a poison). The only difference is that with the potion the player is made essential by the same script that kills him/her, but with the "lich death" script a quest alias is used with the Essential checkbox ticked. Anyone have any ideas? I'm fresh out.

Brain fart sorry bout that but still do something with the stone So much lore :dance: Epic fail :wallbash: We'll see, although to be honest what I see about them on Wikia doesn't really appeal to me in any way. I'm also rather doubtful that I'll want to maintain multiple versions of the mod...

I wonder... try taking one of the standard "raise dead" spells (i.e. not Dead Thrall, we want one that does the ash pile thing), duplicating it, and shortening the duration to 0 seconds. Unless a 0-second duration does something totally unexpected, you should be able to cast the spell, which technically resurrects the corpse, but then immediately expires and turns the body into an ash pile. Just a thought, I really have no idea about targeting dead actors, it's not something I can say I've ever tried before. Of course, then you have issue of this de-summoning/de-rezzing any atronachs/zombies the caster already has... Another option is to change your condition from "health = 0" on your current spell to simply "isdead" -- it's possible dead actors simply have no health, as opposed to a health of 0...

Take a look at any of the raise zombie spells (except Dead Thrall) -- the ash-pile-on-death thing is all handled via a secondary magic effect. I wouldn't at all be surprised if you simply had to include that exact magic effect in your enchantment, but at the very least seeing how it's done there will likely get you going in the right direction. :thumbsup:

USKP does this -- it's one of the things it does that leads me to simply not using it. If you're using that mod, that's probably your culprit.

All of this is no longer necessary, guys -- as of Skyrim patch 1.4 or 1.6 (I forget which), loose files now override BSAs, instead of the other way 'round. I'm quite happily enjoying various textures installed as loose files, with the official high-res DLC BSAs installed exactly as they were when I downloaded them from Steam. So the short version: Just lease the high-res texture pack .esp/.bsa files untouched in your load order, and install as many other texture mods as you wish. :thumbsup: