LoginToDownload

I notice the PlaceAtMe functionality has increased significantly since Oblivion days, including a 'force persistent' variable, but I'm having some trouble finding out what this means for its usage. Does this mean that you can use PlaceAtMe indefinitely without bloating the savegame, so long as Force Persistent remains false? Just for Actors? For everything, from WorldObjects to swords? Thanks to all. My current scripts are piling up references at an uncomfortable rate, and I would love to be able to use forms instead.

No worries. Certainly, I agree with that.

Okay. We can divide this into a few specific problems. -How to run a script on the player. -How to check the player's health. -How to move the player to jail (actually, there's a specific scripting function for this). -How to check the direction in which we should move the player. Using the Creation Kit Wiki's tutorials, its scripting reference and/or the Creation Kit itself, I'd like you to come as close as possible to doing it yourself. To be blunt, if you need help with everything of this complexity or higher, you're basically going to need help with it all. The important thing here isn't to succeed on your own, but to get an idea of how to go about it and more specific problems you can ask for help with. I'm sorry if I'm coming off as a jerk, but it's not uncommon for people to try projects they're woefully unprepared for.

Please don't start this again. Yes, Skyrim was rushed, and yes, it stings that they could do so much in so little time (and didn't), but that isn't a week from start to release-ready. It's a week from start to demo-ready. I strongly doubt they got it up to the same bug-status as the rest of the game in that time, and a lot of it needs sizeable art asset and area design changes to go with it.

How much 'help' do you need? Conceptual advice? Starting points for the mod's issues? More in-depth help on specific areas of the mod? Advanced, ultra-specific tutorials? Just making the mod for you? Have you browsed through the Creation Kit Wiki's tutorials? Most of what you want to do is viable, but it would be quite a lot of work (and the new animations would be really a lot of work), and it doesn't seem like such an effort-effective, high-quality addition that it will attract people to work for you. I don't mean to be rude, but this is really work-intensive and it's important to be specific when asking for help. "Help would be appreciated or just make the mod yourself" isn't an encouraging start. Neither is such a crazy-elaborate first mod.

You have scripting functions called Play and Stop (though you can also just use Play and give it a set duration), that are called by an EffectShader and take an ObjectReference. EffectShaders can apply membrane effects (for example, the glowing white outline when the player heals themselves) and particle effects (for example, the flames surrounding something you just set on fire). Particles can be manipulated in a bunch of ways, and making a fountain that spews flame is very viable with them. EffectShaders are complicated, so I'm going to make you study making it look good on your own time. Feel free to ask again if you're having trouble with them, but this post will be long enough for now. Anyway, a script to apply them would look something like this: Now, let's talk about that Property variable we declared. If you're already familiar with the basics of Papyrus scripting, feel free to skip to a five-line break. By default, scripts in Papyrus only know about whatever they're attached to. If you want to tell the script about anything else, you need to declare it at the beginning of the script as a Property. So, to break down that Property... EffectShader Property MyFireFountainShader Auto {The EffectShader we want to play.} EffectShader: The type of thing the variable is. Property: Turning the variable into a property that can hold things outside the script. If we just say "EffectShader MyFireFountainShader", it could only be used internally (pretty useless for an EffectShader, but it can be important when dealing with simpler variables). MyFireFountainShader: The Property's name. You could technically name this whatever, but giving it the same name as our EffectShader makes a future step easier. Auto: Defines the Property "automatically", as in outside scripting functions. This bit isn't important for now. Suffice to say, you need to put it at the end for properties and you don't need to for variables. {The EffectShader we want to play.}: When someone mouses over this Property in the Property list, this is what they'll see. It's not necessary, and it doesn't work for non-Property variables (I think). To put all that together, let's discuss making a new script and attaching it to the game. Once again, feel free to skip this if you already know basic Papyrus scripting. Step 1: Open up the object you want to attach the script to. If the fountain (or, if you want to get fancy, something invisible denoting the exact fountainhead we want the flames to spew from) is a Static, or something that shares use with non-firey fountains we don't want to mess with, double-click the Reference in the Render Window, scroll to the right through the tabs until you find Scripts. If you have more than one fountain, you'll need to do this whole thing separately for every one. If it's a unique Activator, we can just script the Base (accessible through the Object Window or by clicking Edit Base while editing a reference). Step 2: There should be an 'add' button next to the already-present list of scripts. Click it and select [New Script]. Give it whatever name you want (I named it MyFireFountainScript), and a basic description for anyone who mouses over it. Its extension should default to ObjectReference, which is what we want, but if it doesn't type ObjectReference in the extension text box. Step 3: We should be back to the script list. Right-click on our new script and select "Edit Source", bringing up a huge text field. Note that it's already given us a 'scriptname' function and some squiggly brackets with our description inside. Paste the stuff from that earlier code-box below, and click File/Save. If you've done everything right, it should compile with no problems. Close the script editor. Step 4: We're back at the script list. Highlight our script and click the Properties button. This should bring up a list of 1 property; MyFireFountainShader. If our EffectShader is also named MyFireFountainShader, we can just click 'Auto-Fill All' and the Creation Kit will slide in the matchingly-named EffectShader. If not, highlight the property, click Edit Value and select your EffectShader from a list. And that's that. After the jump, we get down to the lightning altar. The other way of doing pretty visual effects is just to cast spells at stuff. This is done through the Cast function, which takes a source and a target and is called by a spell. After wading through a full-on scripting primer with a brand new type of Object, this will feel delightfully simple. Step 1: Find a nice, invisible Activator we can make shoot lightning. XMarkerActivator will serve for our purposes. Open it up and change its ID to something else like MyLightningSource, click OK and tell it, yes, we want to make a new Form. Step 2: Place MyLightningSources all around the altar you want to attract the lightning. Make sure the altar has a specific Reference Editor ID, so we can point at it in a Property. Step 3: Give MyLightningSource a new script, extending an ObjectReference as before (I called it MyLightningSourceScript). Paste the following into it. Step 4: Set up the Properties just like before, and we're done. If you want to be fancy, you can even use the same script to shoot different spells at different things by changing what MyLightningAltar and LightningBolt refer to (though, since we're declaring it in a Base, the source would need to be a new base). If so, you might want to give the Properties more politically correct names like Target and Spell. That's the power of Properties! DISCLAIMER: I only tested this insofar as making sure all the scripts compile. Results are not guaranteed.

Thank you - that might be useful to me, depending on how the CK decides which scripts are responsible for what - but won't that just create an entirely new MyFunctionScript to go along with the MyFunction call? EDIT: I'm an idiot and the Conditional flag does something completely different. I don't know what I was thinking. I guess my questions are answered, and I can just hope that's enough if I override smartly. Thank you again.

Let's say I have two scripts attached to the same Actor Base. MyFunctionScript and MyUpdateScript (Yes, this is absolutely necessary). MyFunctionScript says: scriptname MyFunctionScript Extends Actor Conditional Function MyFunction() ;Do stuff EndFunction MyUpdateScript says: MyFunction() MyUpdateScript fails to compile, telling me MyFunction isn't a function or doesn't exist. This also occurs if I use a variable (MyActorBase) to hold the ActorBase in question. I can't actually turn MyFunctionScript into an ActorBase script, because it uses reference-specific junk like IsDead(). Admittedly, I don't understand the Conditional tag whatsoever, and have failed to find any real tutorial for it. In the past, I've only ever called custom functions in the script they were made, or using kMyQuest. Can anyone enlighten me?

I'm working on a dragon overhaul, to give them a bunch of new combat mechanics. Currently finding insane workarounds for Papyrus' per-script processing power limits (MAKE TEN SCRIPTS. HAVE THEM ALL CALL THE SAME CUSTOM FUNCTION. I GOOD SCRIPTER).

From what I can see: -Event blocks should always be copied directly from the wiki. In other words, OnActivate should always have ObjectReference akActionRef in the brackets. If you want to check who's using it, you would later ask who akActionRef is. -"Player" isn't used any more. Use Game.GetPlayer() instead. -The abilities you're adding/removing aren't perks, but spells (Powers or Abilities, technically, but both under the umbrella of Spells). Perks are never visible in your Active Effects section, and can never be cast. -Unlike Oblivion, scripts are completely unaware of any objects you don't explicitly pass in. You need to declare them just like (well, not just like) script-only variables. I'm not quite sure how to tutorialize this (and I kind of want to go to sleep), so I'll make it a freebie. Some basic checks: You are, of course, attaching this script to a specific Lever reference or a new Lever form? And you're accessing the script by right-clicking on it and selecting Edit Source (If you open it with Notepad, as I tried at first, it won't compile)? Step 1: Replace your script with the following. SPELL Property PowerKhajiitNightEye Auto SPELL Property RaceKhajiitClaws Auto SPELL Property PowerArgonianHistskin Auto SPELL Property RaceArgonianResistDisease Auto SPELL Property RaceArgonianWaterBreathing Auto SPELL Property PowerBretonAbsorbSpell Auto SPELL Property RaceBreton Auto SPELL Property PowerDarkElfFlameCloak Auto SPELL Property RaceDarkElf Auto SPELL Property AbHighElfMagicka Auto SPELL Property PowerHighElfMagickaRegen Auto SPELL Property PowerImperialPacify Auto SPELL Property RaceImperial Auto SPELL Property PowerNordBattleCry Auto SPELL Property RaceNord Auto SPELL Property RaceOrkBerserk Auto SPELL Property PowerRedguardStaminaRegen Auto SPELL Property RaceRedguard Auto SPELL Property PowerWoodElfCommandAnimal Auto SPELL Property RaceWoodElf Auto Event OnActivate(ObjectReference akActionRef) Game.GetPlayer().RemoveSpell(PowerKhajiitNightEye) Game.GetPlayer().RemoveSpell(RaceKhajiitClaws) Game.GetPlayer().RemoveSpell(PowerArgonianHistskin) Game.GetPlayer().RemoveSpell(RaceArgonianResistDisease) Game.GetPlayer().RemoveSpell(RaceArgonianWaterBreathing) Game.GetPlayer().RemoveSpell(PowerBretonAbsorbSpell) Game.GetPlayer().RemoveSpell(RaceBreton) Game.GetPlayer().RemoveSpell(PowerDarkElfFlameCloak) Game.GetPlayer().RemoveSpell(RaceDarkElf) Game.GetPlayer().RemoveSpell(AbHighElfMagicka) Game.GetPlayer().RemoveSpell(PowerHighElfMagickaRegen) Game.GetPlayer().RemoveSpell(PowerImperialPacify) Game.GetPlayer().RemoveSpell(RaceImperial) Game.GetPlayer().RemoveSpell(PowerNordBattleCry) Game.GetPlayer().RemoveSpell(RaceNord) Game.GetPlayer().RemoveSpell(RaceOrcBerserk) Game.GetPlayer().RemoveSpell(PowerRedguardStaminaRegen) Game.GetPlayer().RemoveSpell(RaceRedguard) Game.GetPlayer().RemoveSpell(PowerWoodElfCommandAnimal) Game.GetPlayer().RemoveSpell(RaceWoodElf) EndEvent Step 2: Right-click on your script (attached to your lever) and select 'Edit Properties'. You should have a gigantic list of properties, since we declared a bunch of them in-script. We could set them all manually, but because we named them after actual in-game stuff we can just click Auto-Fill All. The script should now work. If you still run into any confusions about the syntax (which is totally understandable; it's practically a programming language), you might want to run through the wiki's scripting tutorials (I certainly wouldn't suggest learning from the reference). They were quite useful getting me up to speed, coming from Oblivion, and they're comparatively simple and well-explained. NOTE: The extent of my testing was making sure everything compiled and auto-filled properly. Sorry if there's a problem I missed.

Elder Scrolls Plugin.

If I'm reading the wiki right, debug.trace doesn't display anything in-game, but writes it to a text file elsewhere. Have you tried Debug.Notification or Debug.Messagebox?

Wait a second, does the Oblivion method (place a platform right under the player and angle it about) no longer work?

It looks like mannequins are done by first placing the mannequin (an Actor called PlayerHouseMannequin) just like any other WorldObject, then placing a MannequinActivateTrig (an Activator that looks like a transparent red box) at the exact same location, facing the exact same direction, as the mannequin. Now double-click the mannequin (use the Cell View window if you're having trouble clicking it through the ActivateTrig), move to the Activate Parents tab and point it to the ActivateTrig. That is, right-click on the empty field, select New, and select the ActivateTrig one of the two ways the window lets you. Clicking on it in the Render Window or through a list of cells and objects. Set the Delay to 0 (you want to poke around with the mannequin as soon as you click it) and toggle Parent Activate Only (so you can't activate it in two different ways, I suppose?). One last step. Place an XMarkerHeading static (a bigger transparent red box with an arrow sticking out) at the exact same place (as always, make sure the angles are the same as well) as the mannequin. Now we have a mannequin wrapped in a MannequinActivateTrig wrapped in an XMarkerHeading. Double-click the XMarkerHeading, open up the Linked Ref (NOT Activate Parents. This is something else) tab and point it to the mannequin. Do the same with the mannequin, linking it to the XMarkerHeading. I would need to read the scripts to know why this is important, but I'm a bit strapped for time. Weapon Racks have two visual objects. The WeaponRackMidPlayerHouse (also non-PlayerHouse versions, but we naturally want the PlayerHouse ones) Activator and the WeaponRackEndCap Static. Place a bunch of WeaponRackMids in a line depending on how long you want the rack to be, then place a WeaponRackEndCap (basically just a wooden post) at each side. Once you've built your Weapon Rack, place a WeaponRackMidACTIVATORPlayerHouse (looks like an orange box) at the exact same place as each WeaponRackMid. Link the ACTIVATOR to the WeaponRackMid, just like with the mannequin, but this time we need to give it a keyword. The drop-down box is right there when you're looking at the link, so it shouldn't be a problem. We want the WRackTrigger keyword. Do the same for the WeaponRackMid to the ACTIVATOR on top of it, this time using the WRackActivator keyword. Plaques are done exactly the same as WeaponRacks. Their name is even WeaponRackPlaquePlayerHouse. Put a WeaponRackPlaquePlayerHouse wherever you want it on the wall, and place a WeaponRackPlaqueACTIVATORPlayerHouse (looks like a big white decagon) at the exact same location. The ACTIVATOR is linked to the Plaque with the WRackTrigger keyword and the plaque is linked to the Activator with the WRackActivator keyword. And that should be that. As a fair warning, this is all COMPLETELY UNTESTED. If you're still having problems I can make another tutorial with images and actual testing, but I literally need to be out the door in 5 minutes. Best of luck to you.

If you don't need to change the sizes of dragons in-game, you can use the 'height' Trait for the Actor Base (the name is deceptive; it shrinks all parts of the dragon equally) or the Scale for the Reference. I haven't tested it extensively, but all of these methods don't seem to play perfectly nice with the dragon's hitboxes. At Scale 0.6 the dragon will never use melee attacks, and you can run right into its nose swinging your sword and be unable to reach. At Scale 0.8 there are no obvious problems.

I'm trying to make a certain dragon glide through the sky at a slower pace than usual, but it doesn't seem to care what I set its Speed to. The SetAV SpeedMult console command seemed to work fine (slowing, that is; speeding never seems to work) with men and mer, but any other creature seems to shrug it off entirely. Using an Ability based off the Frost Slow Magic Effect also doesn't get a result. Is there any other way?

Have you set kMyQuest (the little drop-down box above the Papyrus fragment) to the quest in question? (Thanks very much for the tutorial. I needed it.)

Step 1: Set your Quest to Start Game Enabled. But then, you probably saw that coming. Step 2: Select the Quest Stage you want to run right away and toggle the "Start Up Stage" checkbox at the top of the Stages window. This stage will run immediately after the Quest starts, and the Quest will start as soon as the mod is booted up. Note that this might not work if you've saved the game in-between first running the Start Game Enabled quest and adding/toggling the Start Up Stage. The important distinction is between starting a Quest and running a Quest Stage/displaying a Quest Objective (I think? I'm still new to the Creation Kit as well) that shows the Quest to the player. Setting a Quest to Start Game Enabled or giving it a Start scripting command will just cause its scripts to run, its dialogue to be used, etc. You don't get a journal message until you run a Stage that gives you said journal message.

This is a bit late, but have you replaced KematuFaction with a faction specifically designed for your NPC, or with the NPC itself? SetEnemy doesn't work with individual NPCs.

EDIT: Thank you. There's no rush, but unless Papyrus has introduced a form of NPC detection other than "cast an AoE spell on the player over and over again", it would come in handy

Hello. I'm trying to access the Creation Kit by appending an -editor tag to the skse_loader path, just like it was done in Oblivion (and the readme suggests it's the same system), but trying to run it results in an error. I'm running v1.4.10, which is almost certainly up to date. Is SKSE actually unusable with the Creation Kit until it receives an update, or am I doing something wrong?

I don't know a lot about inebriation effects in Oblivion, but I'm pretty sure the standard "blurred vision" effect is done with repeated uses of TriggerHitShader.

Sounds like cell-designing would be a huge amount of work, and Inuhead would be doing that.

Very nifty. You might consider reading this, though.

Steam does have an offline mode...