timtimman

Yes, 1.10.40 came with large enough changes that it broke even though he tried to make it version independent. He is aware and we'll just patiently wait. Since this isn't an "official" mod of his, it doesn't get the same priority :)

Yep, minor code screw-up. "Install" is a function, not an event. Just changing it will make it work. Changed the original.

; Save the script as "##########.psc" in /Data/Scripts/Source/User/ ; In the CK compile the script: Gameplay>Papyrus Script Manager. Find script, rightclick compile ; Create a new quest. Go to Scripts Tab and add script, find it and add the keyword/formlist you chose to make ScriptName ########## extends Quest ; Replace this with the name of what you name your script FormList Property WorkshopMenuMain Auto Const ;;; Want to use a single menu, create a recipe filter keyword ;;; Keyword Property %%%%%%%%%%%%%% Auto Const ; Replace with the name of the keyword you created ;;; Want to use a menu with submenues, create a formlist ;;; Formlist Property %%%%%%%%%%%%%% Auto Const ; Replace with the name of the formlist you created Event OnQuestInit() RegisterForRemoteEvent(Game.GetPlayer(), "OnPlayerLoadGame") Install() EndEvent Event Actor.OnPlayerLoadGame(Actor akActorRef) Install() EndEvent Function Install() WorkshopMenuMain.AddForm(%%%%%%%%%%%%%) ; Name of the created Keyword or Formlist you chose to make above EndFunction Function Uninstall() {Call this uninstall function using your uninstall chem, holotape etc} WorkshopMenuMain.RemoveAddedForm(%%%%%%%%%%%%%) ; Name of the created Keyword or Formlist you chose to make above Stop() EndFunction Edit: A the Install function was wrongly written as an event. Fixed!

I didn't think about packing it in a ba2 archive as I assumed it would do the same, which was basing my arguments on faulty knowledge. But as you stated, deactivating the mod makes it unable to access the script, thereby cleaning up. I may have used some terminology the wrong way, and I do apologize my ignorance on the matter. I do appreciate you taking the time to write what you have, just wish you would write it in a slightly kinder way. Anyway, a big thank you!

Please, before moving to personal attacks you should: Actually read what the person not agreeing with you is saying, and understand it (or at least try to, I can be unclear sometimes) Maybe do another test (there's always a possibility you overlooked something).So first things first, the case I mainly made was that if the mod user were to disable/remove the mod without uninstalling (which most will do, unless we're disagreeing here too) your code will fail and produce errors. Also, with your current uninstall function, your code will fail and produce errors because you're not stopping the quest (when the game's loaded again). You are correct in that a stopped quest automatically unregistered from all registered events, I'm not arguing with your here. However, the issue that arises has nothing to do with how the threading system works, but all to do with how the saving of scripts works. This is mentioned here if I recall correctly: Save File Notes (Papyrus) (the current site is down now however, and it isn't cached). An active script is saved in the save file when a save is requested at the current position in the file so that it can continue exactly where it was (even mid line) when the game's loaded. And since registering for an event causes the script to be latent, it will be saved. However, if the mod is disabled, the reference to the Quest holding the script is None, and thereby it'll have NO WAY to exit itself. persist and continually reload itself every time (since that's what you've resisted for). So, do this very simple test script attached to a quest: ScriptName DerpTest extends Quest Event OnQuestInit() RegisterForRemoteEvent(Game.GetPlayer(), "OnPlayerLoadGame") EndEvent ; This will be called every time the game loads, even if the it's loaded without the mod Event Actor.OnPlayerLoadGame(Actor akSender) If (Game.IsPluginInstalled("DerpTest.esp")) ; <-- Name it to whatever the .esp it named Debug.Trace("Game Loaded with the mod active, no worries") Else Debug.Trace("Loaded WITHOUT mod enabled. Maybe try to stop Quest?") ;; Uncommment below if you want... ; Stop() ; Debug.Trace("Can't call Stop() on None; failed") EndIf EndEvent Make the quest Start Game Enabled and Read Once (which is default) and do the following. Start the game with the mod enabled. Save the game and reload it See that the "Game Loaded with the mod active, no worries" message shows up in the log Save again Close the game and disable the mod (just disable for now, this matters) Open up the game and see that the "Loaded WITHOUT mod enabled. Maybe try to stop Quest?" message shows up, optionally an error relating to Stop() should you uncomment that Save again (cus why not?) Close and open and load it again (same message repeats, because the Papyrus script state is saved) Close again and delete the .pex file (this is used to recreate the saved Papyrus script state, so no, the script isn't truly saved in the saved game; just instructions on how to create it) Open and load the game again, (see that it spits out a bunch of errors about not being able to recreate the Papyrus object because of missing class whatever) Save here and reload (NOW, finally the error messages will go away, but I don't know what damage it might have done in the process. Maybe all script saved stuff has been messed up)Here is the packed mod with script for the above test: http://s000.tinyupload.com/index.php?file_id=00688330215583553733 Edit: Just saw your edit now, and you should really read through the Save File Notes (Papyrus) I linked above. The results of your test situations are mentioned there. And gah! It was just up and now it's down again. You can look at the Skyrim page for it here, which basically say the same thing.

You are correct in the Revert() case, and I mentioned this under my post. Though your code will work, it's not a good way to do due to leaving the script in the save game and not giving it a way to exit. And if the mod user ever deactivates the mod (even if they use the uninstall) the code will be there and continue to fail each time the player loads the game (and enabling the mod again won't remedy this). Just adding Stop() at the end of the uninstall() function should remedy this if the user were to use the function (and that's a big if). The proper way to do it would be to make a Magic effect and attach a script with the event and have it call your function. To deliver it, you have to create a Magic Effect (the one with the script), a Spell (in the form of an ability) and a Perk (to add to the player) in the CK. The perk adds the ability spell, which applies the magic effect, upon which the script and thereby function is run. The script should check to see if your mod is installed first (using IsPluginInstalled) and if it's not, Dispel itself and RemovePerk; otherwise just run your code (which I find is easiest done by starting another quest will all your scripts etc.) The Init quest should just add the perk to the actor and start the "DoerQuest" and then stop itself (as should the "DoerQuest"). With that method you don't have any saved stuff in-game even if the mod user decides to disable/remove the mod without running the Uninstall (which most users will).

I think we are all self taught when it comes to Papyrus. Don't let that hold you back and give up! You shouldn't use the 'native' flag as we cannot make anything native. The native flag on a script tells the compiler that you've added new events (which you won't be able to use). And native scripts won't let you use properties or variables (not storing information) as they are intended to be extended (and never actually attached to an object). You have to extend the script which events you want to use (or one with inheritance of the script with the event). As for the function you wish to achieve. Just make a check on your effect to see if one of the armor pieces was unequipped (attached magiceffects receives events from the actor it's attached to), in which case Dispel the effect. If your not leaving it as is, try to implement that. If you don't succeed, return for more help! Happy modding!

To let everyone searching here know what fixed this particular issue: The BSLightingShaderProperty of the TriShape he'd added to the model was faulty. The following was done to fix it: The Skyrim Shader Type was changed form "Default" to "Environment Map".The Unknown Float 1 to "<float_max>"The bottom values, wetness and such to -1.0 (basically mimicked the working BSLigh.. nodes).A texture set was added and linked it (this is NOT necessary, you can use only materials if you wish). Changed the number to 10 (from six): you have to do "Spells>Sanitize>Reorder Link Arrays" for this to take.The blocks were reordered (Spells>Sanitize>Reorder blocks) and the .nif was saved saved.

Basically, you have 2 approaches. Making a single tier menu (no sub-menus) which requires only a recipe-filter keyword.Making a multiple tier menu (and custom menu icon). This requires a FormList, and at least 2 recipe-filter keywords. (more keywords and formlists for sub-menus) For a single menu you make a new keyword and set the type to 'recipe-filter', and write your mod menu name. To add object to it you just put the keyword in the Recipe-Filter keywords in you Constructable Objects for your objects. For a menu with submenus/custom icon. You make a Formlist and add the first recipe-filter keyword to it at the top with it's name (to this you also link any art-object icon). Then you add the second keyword (or a new formlist) which will become the sub-menu. Just link the constructable objects with these recipe-filter keywords instead for them to appear in their respective menus. To add it to the game you'll have to make a Quest to run when the game is first loaded (default values: Start-Game enabled, and Run Once). To it you add the following script, and pass in your keyword/formlist, and the main-menu formlist. Scriptname <ModName>_Init extends Quest FormList Property WorkshopMenuMain Auto Const ; Single menu keyword Keyword Property <ModName_MenuRecipeFilterKeyword> Auto Const ; Menu with sub-menus/custom icon formlist Formlist Property <ModName_MenuFormlist> Auto Const Event OnQuestInit() WorkshopMenuMain.AddForm(Keyword or Formlist) ; which ever you wish to use Stop() ; No use having the quest running anymore EndEvent I hope that's sufficient with information to get you going with it. You should really add a Magic Effect on the actor with the event OnPlayerLoadGame() and check if your mod is still enabled, if not: call Revert(Your keyword or Formlist) to remove it from the menu. Or just implement a "uninstall" holotape or chem. But that's a different story for another time.

There are quite a few things to look out for with .nif's. First is to always re-order blocks before a save (Spells>Sanitize>Re-order blocks). That is the major one. But there are a bunch of subtle things that will make the CK crash. I can't really help you from just an image if it isn't the blocks. But if you sent the .nif I could probably fix it for you and let you know what did it (played a lot with them).

Well, in the case of Magic Effects and Quests (maybe some other once I can't think of now) then the last OnEffectFinish is unnecessary then. But in all other cases, my approach is the "correct" one, and should be included for good measure (even if not necessary in this case). As for 'const', I've apparently got that ass backwards. I'll redact that part in my comment to avoid further confusion. And thanks for pointing it out so nicely with references!

This is not a very good practice, even if it does work. When the effect finishes you just remove the layer you created and not just change the settings. Also, making the properties 'const' will make them stick the way they are the first time the mod loaded, and not change even if you were to update the mod with new values (if a user made a save with the current mod version). Got it ass backwards on that part, corrected by steve40. 'const' cannot be modified by scripts, only in the CK (editor), See wiki Const. I suggest your script be like this: ("fixed" your first check) Scriptname ARMA_DisableSprintEffectScript extends ActiveMagicEffect Group Settings bool Property DisableSprinting auto bool Property DisableRunning auto EndGroup InputEnableLayer inputLayer Event OnEffectStart(Actor akTarget, Actor akCaster) inputLayer = InputEnableLayer.Create() if DisableRunning inputLayer.EnableRunning(false) inputLayer.EnableSprinting(false) ; If we disable running, we have to disable sprinting as well elseIf DisableSprinting inputLayer.EnableSprinting(false) endIf EndEvent Event OnEffectFinish(Actor akTarget, Actor akCaster) inputLayer.Delete() inputLayer = None EndEvent Edit: corrected my wrongful remark on how 'const' properties work.

Modular Settlement Machinery aims to do just this. It just released as proof-of-concept: http://www.nexusmods.com/fallout4/mods/18968

Ok. There are, unfortunately, several things which are available only to the CK and can't be set/changed using script. Layers could be one of them.

Sorry, I'm phrasing was a bit off. I don't think ObjectReference would get a hold of that script. As you pointed out, that would be very weird. But you could perhaps get hold of it and use it in script, by the means of setting the object which has the CloakingScript on it: ObjectReference Property ObjectWhichHasScript Auto. And maybe using that, (since you need a reference) casting it as a CloakingScript: (ObjectWhichHasScript as CloakingScript). I assume you've check your spelling, so it isn't an annoying mistake like that.. Both name of the file and name said in the file. Cloaking and Claoking might be a simple typo to make. Right now otherwise, I'm out of ideas. Hope some of them has been helpful at least.