Talk:AddPerk

Codearound

Added a codearound for the bug. Not sure this is the cleanest way of doing it: it requires a minimum five base objects (Perk, Quest, QuestScript, Token, TokenScript).

Would a GameMode block in TokenScript with a RunOnce flag be better? Then you'd just need (Perk, Token, TokenScript). I suspect the quest is the cleanest solution for mod initialisation, since it's not checking a flag every frame, but am I wrong? Is there a better way, for any value of "better"? DewiMorgan 23:44, 15 April 2009 (UTC)

Using a quest that runs a GameMode block once before calling StopQuest on itself is a good way to initialise a plugin, but I'm not really sure why you've used a token to add/remove the perk - why not just use AddPerk and RemovePerk instead of using AddItem and RemoveItem to essentially do the same thing? And how does this help with the bug of loading after removing the plugin?
-- Cipscis 01:08, 16 April 2009 (UTC)

1) Without dropping a token, how would the player be able to trigger removal of the perk?

2) The bug hits when you load a game with an active-on-the-player perk that no longer has a mod to describe it. Removing the perk prior to uninstalling (in this case by dropping the token) will prevent the bug. Allegedly. DewiMorgan 07:21, 16 April 2009 (UTC)

Did you intend for the token to be a playable item? I assumed that it would be an unplayable piece of armour, like most items referred to as tokens in the context of Fallout 3. If this is the case, then you'll want to undo the relevant part of my most recent edit to the page.

An easier route would be to either have a book (appears in the aid section, yet runs an OnEquip block) that removes all perks when activated, or a de-isolated "uninstall" plugin that runs a quest like the initialisation quest that you've talked about here that removes all of the perks from the player.

-- Cipscis 08:02, 16 April 2009 (UTC)

It'd need to be visible in the inventory, at least, so that they could drop it. In tests, I used a fork.

I like the idea of a book, though - using is much more intuitive than dropping, and it means you can drop it and leave it at home, rather than having to carry the stupid thing around with you. A proper version would have menus and stuff, but I'm aiming here for the simplest possible system, so that people can build on it.

Because I'm aiming for simple, I went for the simplest suggestion: however, a book version is below if desired. DewiMorgan 19:00, 16 April 2009 (UTC)

First, a BOOK-type item called "ExampleBook", with an Object-type script like the following is created:

   ScriptName ExampleTokenScript
   
   Begin OnEquip player
       If player.HasPerk ExamplePerk
           player.RemovePerk ExamplePerk
           ShowMessage "ExamplePerk Disabled - mod is now safe to remove."
       Else
           player.AddPerk ExamplePerk
           ShowMessage "ExamplePerk Enabled - don't uninstall this mod without disabling!"
       EndIf
   End

Then a quest called "ExampleQuest" is created and set to "start game enabled", with a Quest-type script:

   ScriptName ExampleQuestScript
   
   Begin GameMode
       player.AddItem ExampleBook 1
       player.AddPerk ExamplePerk
       StopQuest ExampleQuest
   End

One minor point - the name of the function for making a message appear is ShowMessage, not "Message".

One idea that I saw come up a while ago that I found quite interesting was to "catch" when the player was saving their game, and remove the perks from the save, then adding them back again afterwards. While this was possible for regular saves and console saves, it was not so for quicksaves, autosaves, or scripted saves.

Once FOSE v2 is released, it will be possible to create a plugin that can detect autosaves, and activate all Activators within a dummy cell before and after a quicksave is created. This could be used to utilise "save-catching" in a mod so that an uninstallation method is not (necessarily) required. However, such a method would require FOSE, and some perks may need to be set up a little differently so that there aren't any bugs when they are added back after saving.
-- Cipscis 22:39, 16 April 2009 (UTC)

Thanks, fixed the showmessages! The save-catching method sounds the best so far: a best-practice version of the code would be a great resource, especially after the release of FOSE v2. I guess ideally the code should fail back to just doing it for regular saves if FOSE isn't installed, if that could be detected.

Regular saves can only be made in specific types of MenuMode, so detecting them shouldn't be difficult. I've already created a system that detects regular saves in CASM, so that the quicksave and quickload controls will be enabled after it is uninstalled. The fact that CASM replaces regular quicksaves has, of course, made it possible for me to detect them as well, but for players not using CASM FOSE v2 will be required. Pending that release, if I get time I'll implement something like this in CASM and provide instructions as to how to set up a mod to use CASM for uninstallation.
-- Cipscis 22:21, 17 April 2009 (UTC)