Sparafucile

Ok. Sorry I wasn't more explicit the first time. Here is what I was suggesting. Copy one of the summon spells to use for your teleport visual effects and sounds. To do this, first look in Magic > Spell list for the spell to use, say Conjure Familiar. The 'RightHand'/'LeftHand' spells are usually for NPCs I think, so don't use one of those. Alright, so you found ConjureFamiliar and have it open. Edit the effect and you'll see that the Magic Effect used in the spell is SummonFamiliar. In the Object Window, go to the Magic Effect list and open SummonFamiliar. Make a few changes: ID = TeleportFXActor Name = Teleport FX Archetype = Script Delivery = Target Actor Base Cost = 0 No Duration = YES Painless = YES Keywords = delete Description = delete Casting Time = 0 Click OK. It will ask if you want to create a new Form. Click YES. Back in the spell window, close the effect item dialog. Delete the current effect from the Effects list. Make a few changes to the spell: ID = TeleportFX Name = Teleport FX Delivery = Target Actor Casting Perk = NONE Disallow Spell Absorb = YES Ignore Resistance = YES Add a new effect and pick TeleportFXActor from the combo. Click OK, OK. It will ask you if you want to make a new Form. Click YES. Ok. So we have a spell that should look the same as Conjure Familiar but not actually summon anything. Right. Onward to the script. Scriptname a00TeleporterCityScript extends ObjectReference ObjectReference Property teleDest Auto Spell Property TeleportFX Auto Event OnActivate(ObjectReference akActionRef) ; cast the flashy spell at whoever activated me TeleportFX.Cast(self, akActionRef) ; wait a bit while the effects play Utility.Wait(2.5) ; teleport whoever to the destination akActionRef.MoveTo(Destination) EndEvent Alright. Edit your a00TeleporterCityScript script and past in my version. Save. Properties, TeleportFX, Auto-Fill. OK. You'll have to Auto-Fill the TeleportFX property on each button your script is attached to.

I thought that was already answered. As fg109 said some time ago, Whirlwind Sprint's "effect" is an animation. You can examine it via the Gameplay menu > Animations... > Actors\Character\Behaviors\0_Master.hkx > ActionVoiceRelease > VoiceWhirlwindSprint. As for making a new Effect Archetype, no, that's definitely not going to happen. Hmm.. Instead of trying to "fix" Slow Time, why not add a Fortify Speed effect to the shout's spells?

Hmm... DefaultCastOnTriggerSCRIPT or ApplyMagicDamageOnEnter? Something like that maybe. Heh. You should copy one of the summoning spells that have the effects you want, remove the part that summons the creature, and have the activator cast it at the player.

For clarification: you are adding new spells to the ArgonianRace Specials list and / or modifying the spells currently listed there, yes?

Hey. I'm not sure that the current version of NMM is actually using the new mod activation scheme which is why I'm still using an old version. Have you tried running SkyrimLauncher and looking at the Data Files list to see if Skyrim agrees with NMM about what ESPs are active?

I'm not really sure what you guys are complaining about. I just made a new shout and tested it out. Worked fine. Sure, you have to create the Shout, the Words of Power, and the Spells. Then you have to obtain the Shout via some combination of TeachWord, UnlockWord, and AddShout but that's just how Shouts work. What's the problem?

I don't think there is a way to do this dynamically for a few reasons: There does not appear to be script methods to return the casting type of a Spell / MagicEffect. Your mod only knows about itself and its parent master(s). It doesn't know anything about other loaded mods so how would your script get a reference to those spells? There is Actor.OnSpell but waiting for a spell to already be cast doesn't sound like what you want, even if you could determine its casting type. Perhaps there is a way to do this with ScriptDragon or SKSE... You can still do it but you'll need to make an additional plugin for each 3rd-party mod you will support. Add the 3rd-party mod's concentration spells to your FormList via an init script quest.

You'd actually keep debug messages in your released scripts?? They're in the example so you can see in-game that things are happening as intended during testing but should definitely be commented out or deleted from the release version. Why would anyone use your mod if it required console commands (hacks) to function properly? Why does a script need to run or start running each time the game is loaded? Is there state that is not saved by the game that needs to be re-set? Certainly some mods contain special items or spells to configure them but they are triggered when used by the player. Do you mean a script that registers for the Update event? If one of the scripts 'attached to' a stage does RegisterForUpdate, that will continue to receive updates and will not interfere with other scripts. Yes, one of the 'problems' is that Quest-based init script will normally be run once. Is that really a problem? I would think that behavior is usually desired instead of a difficulty. My example shows you how to make this behavior work to your benefit. Here's an example: YourMod v1 has an initialize quest with one script and stages 0, 1: Script_Init0: when stage is 0, do stuff now and set stage to 1 YourMod v2 has the initialize quest with three scripts and stages 0 - 3. The init process now needs to RegisterForUpdate to react to changes sometime in the future. Also, you found some errors in Script_Init0 and need to be patched over. Script_Init0: when stage is 0, do stuff (bugfixed) now and set stage to 2 Script_Init1: when stage is 1, fix bugs from old Script_Init0 now and set stage to 2 Script_Init2: when stage is 2, RegisterForUpdate to do some stuff sometime, and set stage to 3 Users of your mod that had v1, their game will do this when v2 runs for the first time: Script_Init0: not run because the game remembers it as already ran Script_Init1: runs because it's new; fixes bugs from old Script_Init0 that is saved into their game Script_Init2: runs because it's new; OnUpdate runs on the set interval Users of your mod that never had v1, their game will do this when v2 runs for the first time: Script_Init0: run because it is new; does not contain the errors of v1 Script_Init1: runs but does not execute its payload because stage is never 1 Script_Init2: run because it is new; OnUpdate runs on the set interval YourMod v3 has the initialize quest with four scripts and stages 0 - 4. There is even more stuff to do in your init process: Script_Init0: when stage is 0, do stuff (bugfixed) and set stage to 2 Script_Init1: when stage is 1, fix bugs from old Script_Init0 and set stage to 2 Script_Init2: when stage is 2, RegisterForUpdate to do some stuff sometime, and set stage to 3 Script_Init3: when stage is 3, do more stuff now and set stage to 4 I won't bother with the details of new users and users that had v1. Users that had v2, their game will do this when v3 runs for the first time: Script_Init0: not run; game remembers it as done Script_Init1: not run; game remembers it as done Script_Init2: still receives Update events if sometime has not yet occurred Script_Init3: run

Um. Actually... heh. Weapon reach is "melee range" and the range min and max fields are only for AI behavior. Bow "range" has no effect on how far you can shoot an arrow. That is controlled by a) the arrow's projectile's range (which is already enormous: 60,000 units), and b) an INI setting. If you search the nexus for "arrow", you'll come across mods recommending that you add fVisibleNavmeshMoveDist to your Skyrim.ini. The UESPWiki Archery page explains why at the bottom.

Grey79's example will get the job done but a lot of it is unnecessary complication. If you want a script that runs whenever your plugin is activated for the first time, here is how to do that via a Quest: Create a new Quest. Enter an ID. Click OK to close the dialog. Reopen the quest and switch to the Scripts tab. Add a [New Script]. Give it a Name and mark it as Hidden. Edit the source... If you're making a plugin called MyMod, you might name your quest _MyMod and the script _MyMod_INIT. If so, here's what the script source will look like Scriptname _MyMod_INIT extends Quest Hidden Add a code block to handle the Init event like so Scriptname _MyMod_INIT extends Quest Hidden Event OnInit() Debug.Notification("MyMod Initializing") EndEvent If you save your plugin now and run the game, you should see the message in the upper left corner of your screen. The message will not be repeated (script will not run again) unless you start a new game or load a save from before MyMod was active. Prefixing your quest and script names with an underscore isn't necessary but it will make them sort at the top of the list in the CK and your file system. Marking the script as Hidden is not necessary; it prevents it from appearing in the script list unless you check the Show Hidden box which usually means that it is not intended for reuse. What if you release a new version and need to change the script? If the script will never change and your mod will never be updated, then the above directions are sufficient. However, if you follow the above directions, view it in-game, save, then edit the existing script, your changed script will not be run because the game thinks it already ran it. You could create a new quest but that's not the best way. Better to plan ahead and build version control into your initialization quest. Here's how to do that: Edit the quest and switch to the Quest Stages tab. Add two stages Leave the first as 0 and change the second to 1. Switch to the Scripts tab. Remove the existing script. Add a new script and edit it like so: Scriptname _MyMod_INIT0 extends Quest Hidden Event OnInit() If self.GetStage() == 0 Debug.Notification("MyMod v1.0 Initialize") self.SetStage(1) EndIf EndEvent What this does is, if the quest is at stage 0 (never ran before), it will do it's thing and then set the quest to stage 1. You do not need to flesh out the stages at all by adding log entries or setting the flags. The stages just need to exist. If you save the plugin now and run the game, the message should appear. Save the game. Then do the following: Add another stage. If you already have 0 and 1, the new stage should be 2, etc. Add a new script: Scriptname _MyMod_INIT1 extends Quest Hidden Event OnInit() While self.GetStage() < 1 Utility.Wait(0.1) EndWhile If self.GetStage() == 1 Debug.Notification("MyMod v1.1 Initializing") self.SetStage(2) EndIf EndEvent What that does: if the quest is not at stage 1 yet, it means the first script is still running so we should wait until it's done. Then, we do our thing and set the quest to the next stage. If you save the plugin now, run the game, and Continue, you should see the v1.1 init message. If you load a previous save, you should see the v1.0 and v1.1 messages appear in order.

Users each have their own INI files. Make sure you got [Launcher] bEnableFileSelection=1 set in your Admin's SkyrimPrefs.ini

If you're just tinkering with stuff, you could try to combine SkyEdit with TESVSnip. It takes some getting used to (much closer to the metal) but, IMO, it's way better than SkyEdit for non-CK modding. If you're using TESVSnip, the recordstructure is often deficient so use UESPWiki to help decipher.

Read: http://www.creationkit.com/Bethesda_Tutorial_Customizing_Weapons_&_Armor

Like I said, if you compare some of the vanilla Workbench, etc. recipes against the Tanning Rack recipes, you'll see that Condition entries on the ones for the Tanning Rack have a different Target. I have no idea why this is... If you can't get it working, maybe you should see how someone else did it: Complete Crafting Overhaul?