xkkmEl

Perhaps Personalized Music - Add your own music to Skyrim.

The respawn flag on the Shadowmere reference record says that it's inventory should respawn when the cell it is in resets. I don't understand enough the cell reset mechanism to help you further, unfortunately.

Oh yeah... the point of all this was to allow you to add 83Willows as a master and have CK honor it. Your existing records will need fixing, or remaking. I have never put myself in that situation, but the theory is that once you have 83Willows as a master of your patch, you should be able to use xEdit to change the formId on your records to match the originals. It's in the right-client menu in the left pane. With luck, xEdit will show you right away that your fixed records now are seen as changes to the original 83Willows forms. If that works, you should run xEdit's in autoclean mode to remove redundant field updates. If it doesn't work, see below... You can also scrap your current patch and make a new one using 83Willows as master and redo your edits in the CK. That's what I end up doing, but mostly because I notice my error before I have too much vested in the patch. Just remember never to save your patch in the CK while 83Willows does not have the master bit ON.

I doubt package conditions can be this reactive. Use an actorless scene instead. Their completion conditions get evaluated every frame (> 20/s).

The full instructions for Wrye Bash is to right click on your esp, select the "Add ESM flag" menu entry, then exit Wrye Bash. I have never seen it touch anything except what I told it to (aside from generating the generally empty "bashed patch.esp"). If you search on-line instructions for using WB, it will generally tell you to use the "Rebuild patch ..." in that same menu. This operation is definitely aggressive, deselecting plugins and such. I have had no trouble from it... it's just a matter of turning the plugins back on... but it can still be tricky if you start with a complex mix of active and inactive plugins. If you stick to "Add ESM flag" (as I do) you should not encounter any problems.

xEdit does a fine job of turning OFF the master bit (click on your mod in the left pane, then click on "ESM" in the right pane, and finally set ESM to 0), but it somehow doesn't do it right for turning it ON. I am told (but haven't tried) that you can rename to esm, load up in the CK and save. This should turn the master bit ON. Renaming the plugin has other impacts though so you should renamed it right back to esp. This may work, but it's untried on my end. Wrye Bash is the common method. Turning ON the master bit is the only thing I use it for... Never had trouble with it. It automatically creates a "bashed patch plugin" but I leave it unselected.

You have to make 83Willows a master, using Wrye Bash, then make your edits in the CK, and finally remove the master bit from 83Willows. The CK will allow you to load multiple esp plugins, so you can copy forms to the active plugin. However it will not save in your plugin any references to other esp files, only masters. The game engine on the other hand does not care about who is master or not. When doing this type of thing, I'd recommend you keep backups of your patch plugin (in case you get master bits confused). You should also see how things look in xEdit, and check that your edits apply to the original objects. It's also the occasion to double check on involuntary edits.

Recently had to reinstall my whole system, and got the same. Skyrim just won't start. No feedback. Turns out you need to install DirectX. CK needs to run as administrator the first time you use "dialogue views" or "scenes". Nifskope needs some VS library, but at least it tells you so.

My actual suggested code is: event OnInit() if getOwningQuest().isRunning() forceRefTo( ...) else getOwningQuest().start() endif endevent I don't think the isStarting case is possible, though you can add "&& !getOwningQuest().isStarting()" to the if's condition. If isRunning returns true, ".start()" is guaranteed to be a noop. If not true, then you are guaranteed to get another OnInit with isRunning true. Edit: I should have mentioned... I think your code will work as long as the quest is not SEQ. Just felt like putting in my own version as well.

Well, call me Thomas. I don't believe you, so I went in to see for myself. I made a few tests, and well, I'm sorry to say there is indeed a game engine bug It appears that in any situation where you start a quest with "Specific Reference, None" fill type, if the specific reference already has a value (that was forceRef'd while the quest is stopped), any new value you force into the alias after starting the quest will be replaced by None in the save file whereas the running game continues using the new value. I even tried moving the forceRefTo outside of the OnInit (in an OnUpdate event) with the same result. Specifically, what I observe is that the alias is reset to None when you start the quest. If this reset actually clears a value that was forceRef'd while the quest was stopped, the None value will be propagated to the save file and any new forceRef'd values will be ignored by the save file. I did not test to see how long this situation persists... it may return to normal is you save and reload, allowing new forceRef'd values to then reach the save file... @staalo18 I'd like to point out that although your proposed solution of switching the 2 lines of code seems to work, you are likely still creating two objects. I would suggest making the forceRefTo and placeAtMe conditional on getOwningQuest().isRunning() as a better fix.

Quest OnInit events fire multiple times, unlike most other OnInit events. It fires when the game starts (or rather when the quest first appears). On that run, isRunning() will return false. It then fires again when the quest starts. This time isRunning returns true. It fires once more everytime setStage is called, again is isRunning returning true, and getStage returning the new stage number. Start Enabled Quests fire two events right off the bat, with isRunning false and then isRunning true. Checking Run Only Once suppresses the first (the one with isRunning false). You should always test isRunning and getStage within your quests' OnInit scripts.... @staalo18 I'm not sure any of this explains your cleared aliases... it certainly does not explain how reloading a save game triggers this.

Well, scorrp10 is right, but there are caveats with using the CK to "make a patch". Without special care, the CK will erase from the patch esp all references to the original esp (making them "None" references). To use the CK, you will first need to turn on the "master" bit in Pilgrim.esp, then copy the conditions and save, and finally remove the master bit. Do keep a copy of your patch esp as backup to try again if this fails. Saving the patch esp in the CK can do severe damage to it if Pilgrim.esp does not have the master bit set.

Change your wait() after the THGF_RelicHunter003.stop to: while THGF_RelicHunter003.isStopping() Utility.wait( 0.1) endwhile Only then is it safe to setStage or start THGF_RelicHunter003. This of course applies to the other quests.

I'll add that there are bugs in the game engine. Specifically, there are rare circumstances in which it mishandles memory allocations which can lead to all sorts of errors and exceptions. Very little is known about where and why they occur, otherwise someone would go in and fix them. I have seen for example one instance in which a small rectangular "light and shadow mask" got attached to the display, showing pale highlights from a door that was fixed on the screen and not following the door itself. I was able to go through a load door, with that shadow mask still stuck... and the game crashed a few seconds later. Reloading fixed it. Most of the time, you just get strange malfunctions, followed by a CTD a few minutes later. Fortunately, they seldom impact the saved games.

Not likely the explanation for your wrongly enabled chest, but... Your while loop should be "while index > 0".