foamyesque

To the best of my knowledge, on an empty list, AddForm will insert the form at index 0, and shift the rest of the list to match.

This. As far as what level a character should be after completing a questline, that's a crapshoot. Some people don't finish questlines until they're level sixty or better. You can probably expect someone to be level 20-30 by the time they finish the Civil War, though.

Cheers, you'd think it'd be easy to get all the resources to learn from but the creation kit wiki barely ever helps (maybe I'm just a bad reader?). I have no idea how modders do what they do and make these grand mods which are so well polished. Anyways I got that problem with the donating sorted out now so yay! The CK resource is one of those things that's a lot easier to understand once you stop needing to understand it. The tutorials are okay, but the reference pages are very much written as reminders, not to teach. The dialogue UI is a nightmare and a half and the claim on the Wiki that you can write nearly as quickly in it as you can type dialogue in a textbox is a flat lie, and that's before you get into the horrorshow of dealing with voiced lines. The actual logical structure of dialogue isn't too bad though, and adding fragments is more or less the same as it is on quest stages or whatnot -- frequently it is used to manipulate quest stages, even.

Okay, so the code itself is pretty simple -- I think there's multiple tutorials on this exact question, but it's four lines or so -- but how familiar are you with navigating the dialogue trees in quests?

Hey, yes. At the first time I overhauled that mod I ran into a similar issue but there it was backed into the savegame. Hm. Did you try the sqv console command to check the quest's status?

Not really an advice, but a wild guess... My modding level does not let me give you advices... I'm mostly expirienced in languages, where declaring variables after using it won't work, so I thought: what if moving properties declarations to the beginning of the script will do the trick? Low probability is more than less probability. First I checked CK docs, the properties are declared always in the beginning there [1], and then posted that... ^^ https://www.creationkit.com/index.php?title=Variables_and_Properties @shumkar FYI - Papyrus is a little more flexible than other languages. Properties can be declared above, below or in between functions and events so long as they are within the empty state and not within any function or event. Even functions need not be declared before the events that call them. People who declare properties between event or function declarations are monsters.

@JustChill: Were you testing on a clean save? Stuff can get baked into saves weirdly and might have been causing your problem.

The best options in Skyrim, for anyone else who comes across this thread, are to you scripts to modify the leveled lists in the chest (e.g. if you want to add something to all blacksmiths) or to use a Quest Alias pointing at the merchant chest. From there you can add your items, including through leveled lists and all the flexibility they bring. Ordinarily they will persist through refresh, but with a bit of script work you can make them refresh much like any ordinary merchandise (albeit possibly not wholly synchronously with it).

Only one thing can edit any given record at a time. That's why, whenever possible, you shouldn't: if this is a question about mods you are making, use quest aliases to do it, or, if those won't work because you're trying to remove a faction, scripts.

I've had filter lists run into the hundreds of items without issue. I wouldn't worry about it.

I don't know if they have a performance impact as such -- I've never instrumented it despite using some very large filters -- but I *do* know the performance impact's a lot less than having events hit Skyrim's Papyrus engine. Filters stop the event from ever firing at all and are presumably checked at the game engine level, which is lightning fast compared to even the fast Papyrus functions. This is especially relevant if one of the actors is the player, because a player doing a 'take all' or dumping their whole inventory at once can cause, if unfiltered, so many events to fire that the stack starts dumping events, and as soon as *that* occurs all sorts of things that rely on events happening start breaking.

Quest Aliases are actually arguably one of the most potent things in the CK. In particular, they allow multiple mods to edit the same thing, alongside all the other stuff they enable like searching, radiant stuff, temporary changes to a thing, naming items, etc.

It depends on how the faction was added. It's possible to do so via script or through quest aliases, neither of which will (directly) conflict with any other mod.

I'd use the FormList, for the extensibility. If speed becomes a concern, but SKSE requirement is not, ToArray it and run the searches on that. Remember to safety-proof for the player having more diseases than expected. I don't think there's a way in the condition system to avoid code, since you're interested in the absolute count here.

That point 2 is interesting! I've been using perks to do that.

Ishara's correct. It's a classic script toubleshooting thing that catches, in particular, people coming in from a programming background: Simply compiling the code up does not necessarily create a complete script. If a script needs to interact with a game object, you need to feed it the link between that game object and whatever variable you've coded in. There's three ways of doing that: You pull the information out of a function or event that can provide it, you attach the script to it directly or through an alias, or you fill properties. They aren't just a weird name for variables. In your particular case I would put the script on a player alias. ReferenceAliases like that will receive basically the same events as the Actor they're attached to, as well as certain ones tied to whatever the quest the alias belongs to. This will include an OnInit() event that will fire when the quest is first loaded (which will be a double-fire for a start-game-enabled quest, but that's only relevant if your OnInit() stuff pipes information to a script outside the quest). And no, you can only ever inherit from one line of inheritance at a time. One of the handiest references on the CK wiki is this one, which shows the inheritance tree: https://www.creationkit.com/index.php?title=Category:Script_Objects It's also possible your quest isn't starting or the player alias isn't being filled -- I have found using a forced reference to PlayerRef seems to behave better than the UniqueActor for making player aliases -- and to check that, you want the 'sqv QuestName' console command. It'll spit back the quest status and stage and the objectIDs of everything in aliases, among others. Also as Ishara said, when testing mods, and especially when making changes to mods, start new games. I've used 'coc whiterun' so many times to start a new one for a test that I can recite Adriane's conversation with Idolaf word for word. :p

Yeah, this. You can teleport people to door markers and stuff, but what exactly is the context here?

Could be either, really. OP'll need to clarify. The position check described looks like it's after *any* position shift, though.

@maxarturo: I believe the LocationChange event only fires when the player actually changes Location, not, say, simply moves around within a cell (or, outdoors, set of cells, e.g. Whiterun). Am I mistaken? There's also ways to check if the player has changed cells. But neither one of those gets if the player is just, you know, walking around.

I think the conditional function GetMovementSpeed might do what you need: Set up an ability conditioned to trigger when it's above 0, and you can then process it being on, or off, with script logic You can override default activations through perks, and/or filter out the activation at all. This should work for doors, too. Key interception is, as far as I know, not possible. By the time you've registered the keypress with SKSE, the game engine has processed it already. It might be possible to screw around with the controls and pre-emptively unmap the jump function, and replace it with a listener for doing your ragdoll effect, but I don't think you can stop the player from mapping it back. If anyone *does* have a way to do it I'd be interested.

Could edit the base magic effect or, more targetedly, the enchantments, to do nothing. Stuff would still appear with the useless enchantment on it, but it wouldn't make you any stealthier.

I believe Chesko uses the technique in Frostfall, as well, to find heat sources.

Okay, my code is now Scriptname RacialAddPerk extends ReferenceAlias {Documentation: This script is used for adding a perk.} Perk Property newPerk Auto Event OnInit() GetActorRef().AddPerk(newPerk) EndEvent And I can add a perk when editing properties. But, last question I swear, how do I add more than one perk? The script just has one property which picks one perk. But I have 10 or so I wish to add - and I can't add the script in multiple times. Please tell me it's not adding the same 4 lines of script nine times over? That seems... wrong. Well, if you want to add multiple perks -- I was assuming it was just one that bundled all the effects -- it's not too much more trouble. Code'll need to be switched to use an array. Perk[] Property newPerk Auto Event OnInit() int i = newPerk.Length Actor PlayerRef = Game.GetPlayer() while i > 0 i -= 1 PlayerRef.AddPerk(newPerk[i]) endwhile EndEvent The [] means that newPerk is now an array, which you can fill with as many perks as you like in the CK. The code will then iterate through the list, starting from the last one and working it's way towards the first, and add them all one after the other. To avoid calling GetActorRef() every time I've moved (equivalent thereto in this application) it outside the loop and stored the result in a variable, for speed reasons.

Oh, I know what the error is. AddPerk only applies to Actors and GetRef returns an ObjectReference. Sloppy on my part. Replace it with GetActorRef() or (GetRef() as Actor) instead. Sorry! EDIT: Or, yes, you can store the player in a Actor property, as in the code snippet you posted. There's really not much difference for this application either way.

You should need just one quest. You can put a condition on all the perks or abilities you add to check the race of the actor it has been given to. They will all then be present but only the correct one will be active. This adds some polling, but it's polling done through the game engine and isn't a noticeable load IME. The error in the second one suggests you don't have your scripts folder set up so the CK can find it. You'll want to check a. that you have a scripts folder, with a pile of .pex files in (you should-- Skyrim won't run otherwise) and b. that the CK's been told where to find it.