kromey

Ah, good point. I could easily test that by seeing what the Player and/or LunarForge aliases look like in text (although they're reference aliases, not location aliases, I'd imagine the behavior should be at least approximate). And I'll try your script fragment as well -- couldn't hurt at any rate. My thoughts on the quest starting despite the failure were that that was why it wasn't starting automatically, despite "starts game enabled" being checked, and that my console commands (which I now note I failed to mention -- oops) were forcing the quest to start despite failing to fill non-optional aliases. Good point on the "stores text" thing, I would have been back here asking about it when my text replacement failed later on, so thanks for that! :cool:

Well, it depends. If you're working under the theory that these fragments were deliberately hidden by someone trying to keep them secret, then yes, perhaps. However, while it's never explicitly explained as such, the journal fragments were simply lost over time by people who didn't understand what they had found, and it wasn't until later that it became known just how valuable they really were. The note that you can find in the College of Winterhold is by someone the previous Archmage hired to track them down; he went through all the hassle to figure out where all 5 are so that you don't have to! (Otherwise it would really strain credulity that you could reasonably find them at all -- basically you're stumbling into the tail end of this centuries-long quest just in time to snag the reward and claim the glory, you lucky bastard!!)

Using the tutorial on the CK wiki as a guide, I tried to set up the first of what will become half a dozen Radiant locations; the idea is to find a random bandit, Forsworn, or necromancer boss and give them an item the player has to track down. Starting small I tried to do just the first, and when it failed I backed it down to just a random bandit boss -- just like the tutorial on the CK wiki! Here's my list of quest aliases (if I can figure out how to insert an image here...): (Boy, that's hard to read at the size the site scales it to...) LunarForge and Player are plain ol' "regular" reference aliases, pointing to exactly what you think they would. They work fine. Fragment01Location, however, does not. As far as I can tell, this alias is failing to fill. Here's how it is defined: Aside from the name, I see no difference between it and the ThiefLocation alias from the CK wiki's tutorial. I'm determining that Fragment01Location is failing to fill based on this snippet in a quest fragment: Debug.Notification("Fragment 1 is in "+Alias_Fragment01Location.GetLocation()) SetObjectiveDisplayed(10, True) ;Display our objective Alias_Fragment01MapMarker.GetReference().AddToMap()Edit: Weird, the last paragraph got eaten by the site apparently... Can anyone help me figure out why my Radiant location alias is failing to fill? I could put the items out in the world myself, but that's boring, and besides this should work -- so why isn't it? I'm also assuming that the quest failing to fill in these non-optional aliases is the reason for two other issues I'm now having (the "start game enabled" quest doesn't start, and the text replacement variables in a quest objective have stopped filling in (were working perfectly before I added these Radiant aliases)), but if not that'll be something else to figure out later... Double Edit: Also eaten in the former last paragraph was the note that the Notification does appear, and says, "Fragment 1 is in None". This is the primary reason I believe this alias is failing to fill, I just can't figure out why.

My scripts are in so much flux right now that it's not practical to outsource anything to anyone else. I will get Dragonborn and update the script, I just want to get the mod released before I do that. It'll be annoying to anyone who becomes a lich and then goes wandering through Apocrypha (and gets killed there), but it's far from game-breaking so I'm not too worried about it right now. And, like I said, it'll be noted as a known issue upon release, so unless people don't read the mod page before downloading and installing they'll know what they're getting in for (and if they don't read it, well, frankly I don't have any sympathy for them). Awesome lich, Skulleris!!

From my own experimentation with trying to do stuff on player death, I'm pretty sure once the player dies (or starts dying), you're basically done. The way I worked around it was to make the player essential: PlayerREF.SetEssential(true)Which makes them immortal -- they never die! Then use the OnEnterBleedout event: Event OnEnterBleedout() Debug.MessageBox("This is a message") EndEventDon't forget to kill them (you should be able to use KillEssential(), or set them unessential again and use old-fashioned Kill()) when you're done, or do whatever else you want to be doing.

The way vanilla Twin Souls is implemented is extremely frustrating -- short of changing it, there is no way to increase your number of summons (e.g. adding a new perk/ability/whatever that doubles your summons gives you the expected 2 without Twin Souls, but also limits you to two with Twin Souls). This is quite annoying to those of us who try to maintain maximum compatibility by not modifying anything vanilla, only to be completely blocked out of what could very easily have been a simple addition. In other words, your perk mod there is still able to add its new Twin Souls 2, 3, etc. perks, but their effects are basically overwritten by the vanilla Twin Souls perk that some mod's dirty edit in effect put back. If I were you I'd disable all the mods after that perk overhaul, and then turn them on again one-by-one until I found the culprit responsible. Then try cleaning that mod with TES5Edit, and/or get in touch with the author to let them know about the conflict.

All it takes is one mod with a dirty edit to effectively undo any changes to the vanilla perk -- and it could easily leave all the others undisturbed.

Abilities are always-on. If you want a 10-second duration effect, use a spell instead.

Your script has an EndEvent, but you don't have any events in there! That's why it won't compile. Here's what I would do for this: Use a trigger. Set it somewhere that the player has to walk through to get to the vault, but where the vault's contents are still out of sight. Use GetGoldAmount() instead of GetItemCount() -- it's a bit more obvious what you're doing and why that way. :wink: You just need a series of if/else condition blocks: Event OnTriggerEnter(ObjectReference akActionRef) Actor Player = Game.GetPlayer() Int Gold = Player.GetGoldAmount() If akActionRef == Player ; only do anything if the player is entering the trigger If Gold >= 100 SmallGoldPile.Enable() ; Make it appear if the player is rich Else SmallGoldPile.Disable() ; Make it go away if the player gets poor EndIf If Gold >= 1000 MediumGoldPile.Enable() ; Make it appear if the player is rich Else MediumGoldPile.Disable() ; Make it go away if the player gets poor EndIf ; etc. EndIf EndEvent

Try this tutorial, it looks like it's doing exactly what you're trying to accomplish.

Yes, you can call other scripts from your scripts. For example, in my upcoming mod Lichdom, my 11 scripts (so far) frequently make calls to one another, e.g. the script sitting on the player watching for them entering bleedout calls the script on the "status quest" to perform the "lich death" check, which in turn calls the relevant function to transform the player into the correct lich state (which is actually part of that same script, but could easily be moved to another). There's a few ways to do it: FileName.FunctionName()Probably the most straightforward, doesn't require any imports or anything, and works just like using the Game or Utility scripts. Import Filename ; ... snip ... FunctionName()Personally I don't like doing this, as I feel it breaks the encapsulation that treating scripts as objects give you, but it works. (QuestProperty as ScriptFileName).FunctionName()I use this frequently, because most of my scripts are attached to quests that I already have properties for anyway. For example the aforementioned bleedout check is done more-or-less like this (recounted from memory, as I don't have the scripts in front of me at work): Event OnEnterBleedout() (Lich01 as Lich_StatusScript).LichDeath() EndEvent If you don't already have lots of functions in your script, identify sections of code that logically could be turned into functions (e.g. that 10-line section that calculates the new value of your variable). Then start moving functions out into other scripts. Keeps your script files nice and tidy, which makes your life a heckuva lot easier when it comes time to track down bugs users are reporting! 1,000-line files aren't all that bad, but I dislike it when my scripts get even half that long. YMMV, though, and for the most part (i.e. barring any technical limitations) script length is mostly a matter of personal choice.

If there's a specific spot you want to detect the player entering, why not set up a trigger and use the OnTriggerEnter and OnTriggerLeave events?

Apparently "dying" while in Apocrypha is supposed to just send your consciousness back to your body, but if you die as a lich there your consciousness returns and you're now a nether lich! You should instead return to your body without any change being made. Fixing this would require the script to check whether or not you're in Apocrypha, but of course that's not something I can check for without knowing what the conditions will end up being -- which means I need the DLC first. Fortunately there's a simple workaround: Don't die in Apocrypha. :P

Some general comments: It takes time to instantiate variables and assign values to them. All of your *_FACTOR, USE_QUALITY_BONUS, and SHOW_* variables take time to create, and I would suggest moving them outside of this function; in fact, since these obviously only change when you go in and manually change them, I would make them script properties, and handle assigning their values in the CK. Calling functions takes time. Notably Game.GetPlayer() has been noted to take quite some time itself; a much more efficient way of getting the player is to use a property: Actor Property PlayerREF AutoThat handily auto-fills with the player in the CK, and by some benchmarks is several orders of magnitude faster. Additionally, your Armor.GetMask() calls are going to be constant, so it would behoove you to set up script properties for those as well, and use a run-once initialization routine (the event OnInit is perfect for this) to populate them with their values. Your various armor variables will only change when the player dons something else; make them script properties and use the OnObjectEquipped and OnObjectUnequipped events on the player to update them only when they will conceivably change. Ditto your calculation functions for iBonus and iOldBonus. Actually, this whole function could be placed into these events, to only run when these values could change (you don't mention how it's called). Debug.TraceConditional() takes some time, too -- potentially a lot of time, as branching logic is an expensive operation, but file I/O is even more expensive! -- so try commenting those lines out (not merely setting your variables to false, but actually commenting them out) and see what happens to your script execution time. If you use SetAV instead of ModAV to set the unarmed damage bonus, you save yourself quite a few calculations -- I'm assuming iBonus is what the damage bonus should be, so just apply that via SetAV rather than going through and calculating the old bonus, the delta, etc. This cuts out an entire function call, which is another expensive operation. I really can't tell what you're doing with Version, frankly, but I'm not sure it's really helping your cause here at all...

I don't know of any limits on script size, however as a programmer I very strongly urge you to refactor that script into several smaller ones. It may seem like more of a hassle than simply writing one giant one, but trust me when I say that having functionality broken out into separate, bite-size files makes maintenance and future development a lot easier! It may seem like a good idea right now to keep everything in one centralized location, however when you put it aside and then come back to it later a single 10,000-line script is a royal nightmare, especially when compared with 5 2,000-line scripts or 10 1,000-line scripts. I say this from years of experience -- that 10,000-line script is not a good idea!!

I could use some suggestions, guys! A part of the quest to become a lich, the player has to find 5 journal fragments from around Skyrim. I intend to use the Radiant Quest system to place these in the world, thereby ensuring that no two play-throughs are exactly the same (and that no one can cheat the quest by simply looking up the locations of the fragments (although of course if you really want to cheat, you can just console your way to victory...)). My plan is to distribute the journal fragments to bandits, necromancers, and forsworn. My question to y'all is: Good choices? Should some on this list not be? Should some not on this list be on it? My reasoning for each group is: Necromancers: Should be obvious -- they're after the secrets of lichdom themselves! Forsworn: They seem to have a similar interest in undeath, perhaps looking for a way to enhance the powers of their briarhearts. I'm most uncertain on this one, though. Bandits: It's impossible to miss that this journal is valuable if you happen upon someone who has a fragment, or is after one, and bandits love things that are valuable. Maybe hagravens could have a fragment, trying to unlock the secrets of lichdom to further their own agendas vis-a-vis the briarhearts they create? The only hard requirement is that the fragments be attainable by any player, regardless of the status of other quests (so putting one in the Dark Brotherhood's sanctuary is a no). There is also a second book, The Immortality of Artun, with information about Artun, the necromancer whose journal you're seeking; alongside this book is a note that includes the locations of all 5 journal fragments, and is the only way to get quest markers on them. This book and note will be locked away in a chest in the College of Winterhold's library; the only key will be kept in the Archmage's quarters. Getting this book thus requires the player becoming the Archmage, or picking a very difficult lock, however either way it's entirely optional -- you don't actually need this to finish the quest, it just makes it a heckuva lot easier to find the journal fragments.

It's getting exciting, folks! I just sent Alpha 2 (actually the third alpha, for reasons even I don't fathom the second one was Alpha 1.1...) out to my testers, with the quests fully functional and all known bugs* fixed! Alpha 3, which I hope to have to them by this next weekend, will distribute the quest books out into the world (and give them content!), which is the last major obstacle still standing. Unless my testers or I find some egregious bug, I should have a public release in just 2 short weeks!! :thumbsup: *There is one known bug that won't be fixed by release, mainly because, as I currently lack the Dragonborn DLC, I simply can't fix it. It'll go into the "known issues" section upon release.

There's the OnLocationChange event, but that goes on an actor and triggers for every single location change. There's got to be a more efficient/more better way of doing it, but I don't know what it would be.

I've gotten one submission so far, that's actually going to be held back a bit because it's just too perfect to not have a dungeon attached to it (and I'm not releasing any dungeons until I get the core mechanics done and released). However, even if I'd gotten a bunch more, there's always room for multiple of any given type (e.g. we could have lots of liches leaving journals around Skyrim, or lots of scholars writing about liches, etc.).

So long as you don't call bat black_hole, you'll be fine. ;)

Simple! For your Werebear, assign an ability for your extra unarmed damage. As part of that ability, naturally, you have a Magic Effect that boosts unarmed damage by 20%, however you add a Condition to this Magic Effect that uses the HasPerk Conditional Function. Done! Repeat for each Werewolf perk you want to apply to your Werebear. Alternatively, you could use a perk to apply the ability, and use the conditional in said perk's Entry Point to only apply the ability when the player has that Werewolf perk.

Why don't you try it out and see? Any of us who could answer for certain would only be able to do so if we had tried it... My hunch is that it'll work just fine, as batch files are really just collections of console commands, and bat is a console command...

Yeah, you'll have to do this in Papyrus I think. Cover the relevant area with a trigger, and attach a script to it, then you'll want to use the OnTriggerEnter() event to make the NPC hostile, and OnTriggerLeave() to make him non-hostile again; a simple way to handle the hostility might be to call SetAttackOnSight(True) on the player when he enters, and SetAttackOnSight(False) when he leaves, however this is only a good idea if there are no other actors around who should not be hostile to the player (this function does exactly what it says on the tin, makes the player fair game for anyone to attack on sight). If you do have other actors about, then call the function SetRelationshipRank(PlayerREF, -4) on your NPC to make him hostile, and SetRelationshipRank(PlayerREF, 0) to make him non-hostile. All of this being said, though, I'm not 100% sure that your NPC will stop attacking in the middle of a fight with either of these methods, especially if you've hit him at some point during the fight. You may need to cast Fury and Calm spells (which, too, can be done via Papyrus). You'll have to do some testing to figure out what works, but hopefully this is enough information to get you started.

No wall-punching necessary here, Lichdom will be released and y'all will get to play it! Actually, Lichdom would probably still exist even if True Lichdom hadn't been shut down (albeit probably under a different name), as I was looking for a new project and TL wasn't really matching up with my own vision of what lichdom should be about.

Ancient liches will not be part of the initial release, and as of yet there are very few definite plans about them. However, one of the things I can indeed say for certain is that, yes, ancient liches will have multiple phylacteries, and in fact creating your second phylactery will be part of the process of "upgrading" yourself from lich to ancient lich.