JonathanOstrus

This is going to sound stupid, but did you go into the source\scripts folder and open one of the scripts you extracted from SKSE64 to verify it's the correct one? The Ammo.psc is a good sample to check. The vanilla file is just 1 line. The SKSE file is like 12 lines including a comment about it being SKSE additions.

I'm thinking it's a translation error, and OP means either sandbox, or travel to. Most likely sandbox.

Just a small troubleshooting tidbit, but have you tried changing the model that the base object uses to a vanilla one? Just to see if it shows up in game then? Trying to narrow down if it's a problem just using that nif model, or something else.

Surprised it wasn't mentioned, but this all requires that the placed references be temporary and not persistent. If they're marked persistent, or are held persistent due to other factors (alias, script variable, etc) then they won't move even with a reset. I ran into this particular issue with xMarkers.

So...Using your plugin as-is, does not match the state from the other thread. The specific problem is you're missing stage 0. I have uploaded a fixed esp file here https://mega.nz/#!545iEQAJ!pTeJkGZPhjIDV8Lj__C-nvlVjHL9bUgfdeT_T8l4KdA All I did was create a stage 0. That way when the quest first starts on a save where the mod has never been seen, it will be stage 0. Then your opening dialogue will trigger. Though when I looked through the dialogue the linkages didn't seem to work right. But I didn't play with it much. After I eventually got to the point where I could choose "Yeah I'll kill her. Don't forget the caps. " it then ended dialogue and set the stage to give me the objective. Screenshots https://imgur.com/a/1jj1ip3

If you're modifying vanilla NPCs, then exporting facegen, it's creating the facegen for *your plugin*. You'll have to go into the meshes and textures folders and move them from the path for your plugin to the original plugin you're overriding. So if the NPCs are from Skyrim.esm you need to go find the files in Meshes\actors\character\FaceGenData\FaceGeom\<the new plugin.esp> and move them to Meshes\actors\character\FaceGenData\FaceGeom\Skyrim.esm. Same for Textures\actors\character\FaceGenData\FaceTint\<the new plugin.esp> to Textures\actors\character\FaceGenData\FaceTint\Skyrim.esm.

CK has a built in export dialogue function as well. I've not used it to try what you described but it could probably work for it too. Another side-tip, if you know part of the dialogue line and are trying to find it. There's the "Find Text" option on the Edit menu. Can use it to find all sorts of stuff.

Not that I've ever seen. There's plenty of other mods where that type of thing happens. I would think most players probably "are use to it." If they aren't, they can be taught to "get used to it." :ermm: The only suggestion I might have, is to add/remove the items more than one at a time. That would reduce the amount of the spam as much as possible.

The only place I've ever seen kmyQuest actually used previously is within Quest stage fragments. For the less advanced that may be reading this, the Creation Kit UI assists the developer by giving you a simple dropdown list to set a casting on the open quest to any script attached to it. Thus setting a visually hidden variable kmyQuest = (self as <chosen script from dropdown>). Visually hidden from the fragment window in Creation Kit anyway. The actual code it produces looks something like this from QF_C00_0004B2D9.psc varying depending on the chosen script. ;BEGIN AUTOCAST TYPE companionshousekeepingscript Quest __temp = self as Quest companionshousekeepingscript kmyQuest = __temp as companionshousekeepingscript ;END AUTOCAST

I see you took the advice and added a stage 0 startup stage which does nothing other than enable the dialogue to work. I'm a bit confused why the stage is 10 if you are not able to speak to the NPC to start it. Can you upload the mod (esp + sources for fragments) as it is for review somewhere? It's generally easier to look at "the mess" and figure out what is wrong, than look at the end result and try to figure out what went wrong.

I should have been more detailed about the use of Game.GetPlayer(). The end functionality wise is the same as setting a property. Like @IsharaMeradin said, getting the object from a property or a variable is faster than calling out to Game.GetPlayer(). However, I recall reading somewhere that the more properties scripts use, the more strings tables it enters into the save game. There is a limit and eventually it will cause a save game to be unusable. I did a quick search and I believe this is a relevant page to the issue https://forums.nexusmods.com/index.php?/topic/3924850-corrupt-saves-strcount-0xffff-ctd-on-load/ Reusing the same variable/property names does sort of work around the potential of the issue. If you look at vanilla Bethesda scripts they use Game.GetPlayer() always exclusively. If they need to use it multiple times they set a local function variable and use that. A good simple example is DLC2SV01ClawPickupScript.psc. Because it is slower to use Game.GetPlayer(), and requires pausing your script when going to get the value, if you need to use the player reference multiple times it is recommended to set a local variable and call it once. Function SomeRoutine() Actor PlayerREF = Game.GetPlayer() ; insert lots of code that accesses PlayerREF instead of calling Game.GetPlayer() each time. EndFunction

@cdcooley good info. I never put 2 and 2 together but that all makes perfect sense. I'll have to keep my own personal save/reload in check.

Specifically I can't say as I have a clue why that works. Most likely due to the way the engine handles persistent references internally being very different. So the save reloads will act differently because of the reference being "temporary" vs "persistent".

This sounds like an engine bug I came across myself recently. I found some weeks back dealing with start enabled quests and aliases. If you load up a save with a newly added quest is fills the alias. But if you reload a save where the quest hasn't been seen, the aliases fail to fill. Reloading additional times doesn't work. Only closing the game and reloading from scratch fixes it. Affected manual saves, quick saves, and auto saves. So the behavior you have seen, requiring a complete restart of the game, is a similar symptom and frankly there's nothing you can do about it short of the full game restart as you've found. I suspect it's all related to the shortcuts the devs take to enable faster loading of saves without having to reset the entire game world and reload things. Their "state" reset routines are broken. An exploit related to this is to force store and npc personal inventory resets by attacking an npc (not killing) and then quick reloading.

Glad to hear you got that figured out. So is everything working correctly now or are you still having issue with something?

Ok for the ID are you using the Form ID number or the editor id? The console command requires the Form ID number including the load order position prefix. You can check with xEdit to verify the scene is actually saved into the plugin. Which if you were to close and reopen the plugin in CK and it shows up, then it's safe to say it's saved. There could be a number of reasons why it may not properly start. Firstly, how are you trying to start it? Using a quest stage? A trigger box? A dialogue fragment? You also need to check the flags for the npcs in the scene. I had a problem where the scene was being started from a dialogue fragment, but had the npc I was in dialogue with as one of the scene actors. The scene kept failing because the actor was tied up in dialogue. I forget the specifics of how I fixed it. I think it was setting pause flag on dialogue which made the scene pause until the current dialogue ended, then it did the actual start up. However that made it so the scene could be interrupted by trying to talk to the npc.

You might want to rethink your script names before continuing too far. Those names are atrociously ambiguous. In the case of "ScriptObject" that name is even reserved in Fallout 4 (and probably additional games going forward). I realize this is for Skyrim and is not currently an issue. But it's always good practice to keep your names of things descriptive so they're not confusing and ambiguous. It's also good practice to use descriptive variables and property names. Ok rant done. I think you're going about something the wrong way. I get the activator has the "ScriptObject" script on it. How are you planning to get your quest as a useable object? You need to set it as a property. Or get it by some other means like GetForm or GetFormFromFile.Does the property Quest1 on ScriptQuest point to the same quest it is attached to? If so, why? You don't need a property to point to itself.Your stated code is failing because: In ScriptObject your "LocalQuest" is undefined so therefore "NONE". When you try to set kmyQuest1 it will produce a papyrus error in the log (if you turn it on you'll see it) about casting a NONE and then it can't find the property you try to reference.The second line where you try to set kmyQuest2 will then fail because kmyQuest1 is NONE.Then of course trying to call "NONE".TestLinkFunction() is invalid.In the interest of time something like this would probably be what you want: ScriptName ScriptQuest Extends Quest Function TestLinkFunction() Debug.Notification("TestLinkFunction Runs Hooray!!!") EndFunction You will need to statically assign the property on the activator with the following script to point to your quest. ScriptName ScriptObject Extends ObjectReference Quest Property LocalQuest Auto Event OnActivate(ObjectReference akActionRef) ; always good to validate the player is activating. unless you want npcs to also activate it. if akActionRef != Game.GetPlayer() return endif ScriptQuest kmyQuest = (LocalQuest as ScriptQuest) kmyQuest.TestLinkFunction() EndEventYou could even pre-cast the property so it only shows you quests that are of the script type you want. ScriptName ScriptObject Extends ObjectReference ScriptQuest Property kmyQuest Auto Event OnActivate(ObjectReference akActionRef) ; always good to validate the player is activating. unless you want npcs to also activate it. if akActionRef != Game.GetPlayer() return endif kmyQuest.TestLinkFunction() EndEvent

RE PM, Yea sure that's fine. I didn't actually try the mod, just browsed through the plugin. The way you would do a "quick clean" like I did is to: Open the plugin with xEdit.In the left tree view right click.Choose "Apply filter for cleaning". Let it run.When finished right click on your plugin in the tree view and choose "Remove identical to master records"Then right click again and choose "Undelete and disable references"At this point I like to save the plugin before doing a deeper clean manually looking for accidental dirty edits. Those are things that you might have clicked on and accidentally moved without realizing you did, or without meaning to. It will make an override in your mod that is unnecessary and could cause potential conflicts with other things if they intentionally modify the same record. As for your "hope" that your mod won't cause issue for other mods also editing cells. That's a bit newbish and naive. Whichever mod has the later load order slot will get the final override status. So if yours is last then you could very likely break other mods without intending to. It's good practice to go through your plugin with xEdit and check everything that is there to make sure it's intentional edits. This can get pretty lengthy in larger projects, but if you take a look at it early it's not so bad to keep up with. But that's just my opinion. I noticed there were some small edits that *might* be dirty but could also be intentional. They just moved height, or small location position movements. A cautionary warning about packing with CK though. Before telling it to go ahead, review the file list and make sure it's only adding things that you intend to. Specifically if you have F4SE scripts installed, it likes to pack those as well. The reason being, you're referencing scripts which extend from the replacement ones that F4SE installs so it thinks you need them. You could still pack manually if you're packing from the game's data folder. Just navigate to the scripts that you need and drag them into the archive tool. It should keep the correct path since it has a full data path structure on it. If you use a staging folder to hold all your mod files then that gets a little trickier as it may lose the path info if it doesn't have a full data\scripts\... style path. Like mine are J:\Storage Dump\wip - models\<ModName>\scripts\... and like. So I have to drag everything from the modname folder into the archiver or it screws the paths up. The source code .psc file is only necessary to the person making the mod. The user only needs the compiled output .pex which is in the base data\scripts folder. If the user were to open the mod in CK themselves then they'll get a error message in the fragment boxes (or anywhere script source is necessary) stating that the source is not found. CK will automatically try to pack the source and the compiled script. A lot of authors just leave it be and include it. I personally do not, but then I also use a custom packing method. You can use a leveled list with a name override to spawn items with a custom name. Though that doesn't work if you want to craft it. Only for direct placement or spawning in a container via the leveled list.

I'm going to start with my normal rant about how mods (especially those with scripts) should never be removed mid game (after being baked in a save). So many things can go wrong. Even if you do your best to stop quests, timers, etc. Skyrim is especially bad at trying to cleanup removed things and something *will* break. /endrant I would avoid at all costs modifying vanilla scripts. Adding a stage to the quest has its own issues. It sounds like you don't need your quests to start up exactly after certain stages, which maybe that was my fault misunderstanding. So that opens up a few other alternatives. *Maybe the best choice* You could use the built in story manager and hook in on location changes. This has pros and cons as well. The pro is there's no constant running timer. A con is that the player will have to cross a "location" border. So if they're roaming around in the wilderness with no location it could take time. But it sounds like the criteria you want to use for your starts will require them to be in location tagged areas. This will also require a new quest that is event started to do the work you want. If the mod isn't distributed and no saves have seen it, you can just change the side quest Event types to be Change Location event. You could condition the start criteria to be the prerequisite stages of the vanilla quests. So you can have something like, when the location is changed, check if the other vanilla quest is started/at stage n, then start SQnn or whatever. To see how this is done check out Object Window > Character > SM Event Node > Change Location Event. Make sure if you use this that when you add a node you check the box that says "Shares Event" otherwise you *will* break things.Your timer can be expanded like you said to a longer delay. I would probably go up to maybe 1 or 2 minutes. 10-15 seems really far out there.You can set up trigger boxes in major areas, like city entrances. Not the most accurate but it may get the job done in an acceptable fashion. You can use either the OnTriggerEnter or OnCellAttach then do your if checks within. This alleviates the need for a constantly running timer. But will require the player go back to the area where the trigger box is.

There's 3 script references I see that are missing. Scripts\Fragments\Quests\QF_Pipsy_zzzTheGiftShopQuest_0100F6A7.pex (the quest stages fragments)Scripts\MapToggle on PipsyzzButtonMap "Hologram Activator"Scripts\LightsToggle on PipsyzzButtonShutterControl "Shutter Control"If you used the archive feature in CK that should have packed them for you. Or are you using a staging area and packing things manually? Also you need to clean the plugin. You have a whole lot of ITM (Identical To Master) overrides. This *could* cause conflicts with other mods unintentionally. Also some deleted records. It's normally good practice to use xEdit to remove the ITM and undelete and disable refs instead. There may also be some dirty edits (records that were touched and re-saved with (probably) accidental edits. Those would have to be manually deleted. For reference[Removing "Identical to Master" records done] Processed Records: 1038, Removed Records: 118, Elapsed Time: 00:00[undeleting and Disabling References done] Processed Records: 920, Undeleted Records: 20, Elapsed Time: 00:00

pls delete. editor didn't update properly to show post completed.

The short...it's going to take a bunch of ugly hacks to do what you want. Without modifying the vanilla quests there's really only one way I know of to pull this off. The best solution I have is checking periodically to see if your trigger quest stages are passed/completed. Though that brings its own list of drawbacks, primarily you have a script running a check every so often for things that realistically may never happen. Depending how the player plays. The "best" way to do that would be using a one time timer on a quest script to activate and then see if the stage you want is fired. If not, register the timer again to check later. This prevents the script from endlessly looping with Waits which can cause other problems. So on your main quest, have the startup stage (or some other trigger) start the timer. So the check for your SQ02 would be FreeformRiften10.GetStage() >= 20. 20 is the stage that is set when the player is tasked to find fire salts. If you're trying to get an immediate trigger of your SQ02 the only way is to modify the vanilla quest script stage to start up yours. The others would use similar checks for stages and then react accordingly. For your timer you'll want RegisterForSingleUpdate and the callback is OnUpdate Edit: Just thought of another way. I've not actually tried this so the exact method may be slightly off, and I'm not sure how I feel about using this method but I'll document it anyway. You could use a spell that works like an ability. It's placed on the player via a start enabled quest. The spell then has 3 (or more) conditioned magic effects. Each one having the conditions of your quest start logic. Then when that condition is valid that effect is applied. The effect then has an archtype of script and when it's applied runs the script. The script has an event for the OnEffectStart which then fires up your side quest. Adding a n-th effect with conditions for all of your side quests have started then causing a dispell would be suggested but optional. This may not be a good solution if you plan to add additional quests later as the list of triggers may grow quite large.

No it won't. Having them named anything other than "PluginName.bsa" will cause them not to be found. The exception is on Special Edition there's a second file "PluginName - Textures.bsa" (space before and after the hyphen). You can use a .ini edit to include them if you're doing it just for yourself. Either edit the Skyrim.ini or SkyrimCustom.ini Then in the Archive section where the bsa's are listed add yours. There is a line length limit of something like 300 characters (I don't remember the exact number) so be aware of that. [Archive] sResourceArchiveList=Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes0.bsa, Skyrim - Meshes1.bsa, Skyrim - Sounds.bsa sResourceArchiveList2=Skyrim - Voices_en0.bsa, Skyrim - Textures0.bsa, Skyrim - Textures1.bsa, Skyrim - Textures2.bsa, Skyrim - Textures3.bsa, Skyrim - Textures4.bsa, Skyrim - Textures5.bsa, Skyrim - Textures6.bsa, Skyrim - Textures7.bsa, Skyrim - Textures8.bsa, Skyrim - Patch.bsa Since this sounds like a mod you're distributing, requiring ini edits is not a great option. Another option is to use dummy plugins to load the extra archives. So you could just load up CK (no plugin file) and save a dummy file. Name it something like "PluginName1.esp". Then convert it to esl so it doesn't steal a full load order slot. Now just name one of the texture archives "PluginName1 - Textures.bsa". You could even have a second one named "PluginName1.bsa". Though that could get confusing having both and actually having textures inside them. I would probably opt for just having the "Textures" named one as my first example. Either one or both can exist and the game will load them provided the plugin with the matching name is flagged for loading. Another trick if you don't want them to be actual .esl files is to save the .esp and use xEdit to set the ESL header flag. This will cause the .esp to be sortable within the esp space in case you need it to be in a particular order for override precedence. Note NMM as of 0.65.10.0 on GitHub still sorts .esp with the flag up into the "ESL" space after ESM flagged files. I've pushed a code fix for this but it hasn't been merged in. If you use the in game mod manager you can sort the ESL flagged .esps in the right spot. Other mod managers besides NMM may work as well.

My understanding is OP doesn't want the source workshop ref name changed though. Though I suppose a roundabout way would be to intercept the activation, throw the source workshop into an alias to cause the name change, retrigger activation for the inventory movement, then upon leaving clear the alias to return the source workshop name to normal. To me that seems like a mess though. and what about idea 3 i mentioned earlier do you know a way to do that? cuz i think that will do it but only if there is such a script that triggers a quest when i activate the crate ("OnActivate"or something). thnx anyway :thumbsup: i will try to find a way to do that if not ill give up and give the workshop the name of the crate. See response to SKK50. Not elegant but might get you there.

Heh. This is why every sorting mod I've ever seen asks the player to put the stuff they want sorted into a designated container. Then it sorts it from there instead of straight out of the player inventory. Then it doesn't have to care whether it's an equipped item or not. The player has already designated that they want it sorted out for them. I would argue that is a better process as some players (myself included) carry "extra" gear that can be switched in and out depending on the circumstances. Having a mod yank everything except the active equipped items would be totally useless in such cases. That said, generally speaking your issues about #1 are right on. There is no reliable way to distinguish between a plain or player upgraded/enchanted item if you have one of each. RE #2. That won't work. Even if you set the bool to prevent removal, scripts can still remove it. The flag only prevents the player from removing it themselves. You also still have the same problem as #1 where you can't tell whether it's a plain or a player modified item. RE #3. That still won't work. Removing n-1 will not always leave the equipped item. It may not always be the last in the list as the game returns it. Besides the issue as you stated for speed.