foamyesque

Heh, Ishara beat me to it. Yeah, you have to use Stop/Start to do repeated searches. It works beautifully when you do so, though; I stress-tested the process pretty hard when I was looking into building a Detect Loot enchantment.

I'm not sure why you're having trouble with the aliases. In the past I have found using quest alias filling to be, by far, the fastest and most reliable way to find objects in the world. If you could post the alias and its conditions, and the code which triggers it, it would help diagnose things.

OK, so, what you want to do is create an alias and point it at the player, as you've done in the second screenshot there. At this point, you have a few choices in what you want to do. You can add an ability to the player in the Alias Spells list. This would work fine for things like boosting HMS or particular skills; the Altmer Magicka boost is done through an ability, for example, though applied at the race level. If there's some more unique effect that you want to do, you could add a perk proper. Unfortunately perks aren't spells and so can't be added using the other alias stuff, you have to use a script. To do that, hit the Add button in the Scripts list, and when the popup appears, choose [New Script]. You'd think there'd be a default script to do it, but AFAICT there's not. Anyway, this will bring up a naming menu. You'll want to name the script something that a. makes sense to you and b. can be easily distinguished from scripts from other sources. Something like LBP_AddPerk, for example. Don't alter the Extends field. Doing all of that should get you a new script editor popup with a single line saying "scriptname [whatever] extends ReferenceAlias". That's one of the five lines of code needed already done for you. The rest are: Perk Property newPerk Auto Event OnInit() GetRef().AddPerk(newPerk) EndEvent Save & compile, then go back to the alias screen. The script you just created should now be listed. If you select it, the two greyed out buttons, "Remove" and "Properties", will become active. You want to hit Properties, which are how scripts are linked to the actual game data. This will bring up a screen with the 'newPerk' property listed. If you select it, and hit 'Edit Value', you can choose a perk to assign to that property. Select whatever one you want (presumably the one you've made!) and press OK. At this point, for either, hit OK on the alias screen, then OK on the Quest screen. Then save the ESP. I get that this sounds like a lot of steps and it sort of is, but they're only slow when you're learning it. Took me more time to write the lines describing it than it does to actually do 'em. EDIT: Note that this only works with the player. NPCs can't have perks modified dynamically and must have their base actor form edited directly.

So it wouldn't work on an already-started game, right? Also; player race is actually decided a while after the game starts, isn't it? - You have to go through race menu first.. It does work. Start-enabled quests will fire the first time the mod is loaded in a game, regardless of whether the game is a fresh one or loaded from save. The player always has a race. By default, it's Nord, and then changed following the cart ride to whatever the player selects. You can observe this by using the console 'coc' command to start the game instead of the cart ride; if you haven't modded the player record, you'll spawn in as a Nord male in iron armour. However, the condition system can handle that for you. The health bonus portion of the perk can be set to only activate if the player is of the Nord race.

Smithing XP is based, in vanilla, on the value of the item (along with a flat base amount). I believe those are controlled by game settings in the CK, like other skill effects, but I haven't personally worked with them.

Easiest way would be to add a perk to the player, via an alias. It will require a bit of scripting, but of a very, very simple and straightforward kind. Perks can be conditioned based on things like the actor's race (among many many others), so you wouldn't need to personally track the player's race; the game itself would do it for you. All you'd need to do would be a little bit of run-once stuff in a dummy, start-game-enabled quest: When the quest starts, it adds the perk.

Dialogue scripts are fragments, which means getting properties into them is a bit trickier. By default they have access to akSpeaker, which is the Actor saying it, and akSpeakerRef, which is the ObjectReference saying it. https://www.creationkit.com/index.php?title=Topic_Info_Fragments Self, in the context of a topic info fragment, will be the topic info script, not the speaker or target of the dialogue. As such passing it to Activate() won't work. If your goal is to have an object be activated by the speaker on a given line of dialogue, you'd want to put the object in as a property, either directly or using it's alias, and then call ObjectRef.Activate(akSpeakerRef).

I was thinking you'd just make a perk that'd add an extra activation option to all animals with a certain keyword if they're alive and you have the item equipped. Like how the Tower Stone operates, or alternatively you could use an Activation Override to straight up overwrite the default behaviour.

Are you insistent on it being automatic? Because I think you could scrap a lot of the script if it was just an extra activation option.

The janky approach would be to add a script that listens for the crafted item being added to the player, rolls the dice, and if it decides they blew it, removes it from 'em.

The problem with adding directly to the levelled lists is that I believe those are shared amongst the alchemists. OP needs to add a unique one to each merchant chest, in such a way as it a. refreshes and b. doesn't interfere with any other edits of that chest. Editing the merchant chest directly means it will have compatibility issues. So what probably needs to be done is to put an alias on each chest with the desired items in the aliases' inventory, and a brief script that fires every 48 ingame hours to, 1, remove any remaining added items from it (easy since they're going to be unique potions), 2, clear the alias, and 3, re-add the chest to the alias (which will in turn force the alias's inventory to be added to the chest). If however there *is* a unique levelled list for each merchant chest, you could do a script-based injection into that. However stuff added by script to a levelled list can also be *removed* by script to a levelled list, and if someone calls Revert() to what you've edited your stuff will go away. Same applies if you do it, to any changes someone else may have made. The alias method only fails if someone deletes the chest or edits the merchant faction to use a different one.

Regarding inheritance: Most things in Skyrim descend from the Form type. There are a few exceptions, notably Aliases and ActiveMagicEffects. The full tree is found here: https://www.creationkit.com/index.php?title=Script_Objects EDIT: Whoops didn't realize this thread was posted two years ago.

There's a couple of ways. Simplest is to put a script fragment that changes a state (e.g., quest stage) in after whatever line of dialogue that's supposed to enable it fires. Then have a condition check on the hiring branch of dialogue that only enables it if that state is true.

Dialogue is managed by quests and the condition system. That allows you to limit available dialogues based on, e.g., a quest stage being reached, a quest being complete, a global variable being set, etc. I believe the 'how to build a quest' tutorial on the Wiki covers this piece.

OnQuestInit() is not a default Skyrim event, so the compiler thinks you're defining a custom one of your own, which the game engine, obviously, can't call. You need OnInit() instead.

A Clear() will remove whatever's in the alias, but with a cloak spell it's possible for the magic effect to then be re-applied, with a fresh set of variables and properties. The equipping of the rags should prevent the forceref from firing again, but something's up. Going to a ForceRefIfEmpty and checking whether it was successful sounds like a good idea. Because packages can have latency the NPC flickering in and out of the alias might not be noticeable. Ordinarily I'd ask if the alias was set to optional, but a. you say you've got working clears elsewhere and b. explicitly say that it is. (Also that five second wait makes my teeth grit. I think you'd be better off with a RegisterForSingleUpdate call.)

Hm. The call looks correct syntax-wise. I'm wondering if the alias might've been re-filled by another instance of the magic effect, since cloak spells can spam them. Could you post the conditions of the spell?

You should be able to clear a referencealias from anything. The same function should be called. If you can provide exact code it might be possible to spot the specific issue.

That's incorrect on three counts: OnMagicEffectApply() doesn't have a return value -- the MagicEffect is specified in an argument; MagicEffects are not spells or shouts, but components of them; and they work perfectly fine in HasForm(), since MagicEffect extends Form.

i dont know what that would look like, but i sure would love to try it out! Functions are things like the SetStage() call you're making; you can define your own custom functions with whatever arguments you choose and up to one return value. In this case you'd want something like Function AdvanceStage() debug.messagebox("Success!") Utility.Wait(0.2) targetNPC.ForceActorValue("Aggression", 0) targetNPC.StopCombat() EndFunction And then your if statements would just look like: if spellCast if spellCast == SPELL001 || spellCast == SPELL002 || spellCast == SPELL003 (...etc) AdvanceStage() endif endif This structure of the if statements also avoids having to write your code again and again, so the function is redundant, but it's often good practice to subdivide tasks like this anyway. Further, and the reason I go back to the formlist, a formlist approach means any time you want to change the spells you're interested in, you don't need to alter your code nor to fill properties. So you'd get the code down to if spellCast if spellList.HasForm(spellCast) AdvanceStage() endif endif You want the check of whether you're in the correct stage of the quest to be done early, to avoid any of the other processing and avoid race conditions (e.g. a player fires off two spells more or less simultaneously), and you want it to be done only once, since it isn't going to change in any of the cases (which should probably be structured as if-elseifs in order to make the branches all mutually exclusive). There are some more sophisticated ways to do this that have advantages, involving script states, but the simplest one is to add a property that stores the stage the quest the quest needs to be in when you care about this, and then go: if myQuest.GetStage() != TargetStage return endif right at the very start of the OnSpellCast() event.

Yes, the code looks like it should execute. Albeit it's wordy; I'd stick the spells in a FormList, use HasForm on that FormList, and then have just one if statement. Alternatively, if you want the explicit list in the properties instead (I don't think it's good practice, but whatever), I'd bundle the repeated debug.messagebox("Success!") myQuest.setStage(myStage) Utility.Wait(0.2) targetNPC.ForceActorValue("Aggression", 0) targetNPC.StopCombat() Into a function, and then call that from the if blocks. Means you can change the behaviour of all of them at once by editing the code in just one place, which improves debugging reliability and code comprehension. Have you tried putting in a debug notification call before the if blocks in OnSpellCast()? Something like Debug.Notification("Casting spell..."), just to see if the event fires at all?

Have you tried using the sqv console command to check the quest's status and make sure that the quest is started and the aliases filled correctly?

What is the *full* text of the script, including the scriptname & extends piece? Are the properties filled and filled with the correct spells?

Put the condition on the magic effect in the *effects list of the spell* and it will be checked continuously. Ones placed on the magic effect on the magic effect form are only checked once.

Alternatively, if this is meant to be player-specific, you could add a script to a player alias and listen for equips/unequips.