Arocide

Not sure I agree, I personally have little issue with Skyrim CTDing or Freezing and never have. In Fallout / Oblivion I tended to crash a lot, but that may just have been due to not really knowing or caring about mod 'cleanliness' back then.

Because it seems like they might be planning on more updates and previously if they did that it would override any scripts you modified

Agreed, put over 3,000 hours into Creation Kit so far and I only remember ever crashing once or twice and that was only when I was using the render window. More often then not I never use it.

Aye, it's good at what it does! Well good enough it has many optimisations under the hood the only real issue is the way it interfaces with the engine...Script Instances just can't perform more then one call (which in a way is actually a strength) to the engine a frame which introduces oh so much delay. TESScript instances were able to perform hundreds of Engine calls a frame, but it could also slow down the game. Papyrus usually won't let that happen so overall I think papyrus is a major improvement over TESScript in terms of stablility, to be quite honest I think the PapyrusVM itself is the most stable part of the engine it's just what it is told to send out and receive that is sometimes junk.

It's Really Debug.Notification(""), you can use any function you want though (as long as it is valid) or comments I think commenting works as well in generating fragments. EDIT: Looks like BigBiz answered that :D

Ahh, I should mention then since you aren't familiar with papyrus fragments? These are fragments so they have auto generated scripts you just specify the functions you wish for them to perform so you only need: Game.GetPlayer().AddItem(SCG_Mead,1) However you will need to add SCG_Mead as a property beforehand easiest way to do that is to write: Debug.Notification() and let it compile, then head over to the auto generated scripts properties then add it. Remove Debug.Notification and Then add your line and it should be golden.

Hey there! Have you looked at this topic here it may have been due to the updated Creation kit. If everything there checks out it may be for other reasons but I reckon it is probably why you are receiving that error

Hm.... Don't Dialogues have Papyrus Fragments for that purpose? I think they'll do what you are looking for. Look at the Topic that you want this to happen on and write the script in one of the fragments (Start is at the start of the dialogue End is run at the end of dialogue) and you should be fine :tongue: !

Depending on how you set it up, you could do what Bethesda typically does when it comes to generic dialogue. They have a separate dialogue quest (sounds like you already have that?) which contains the topics you wish to allow people to say then place conditions in the Quest Dialogue Conditions box of the Quest, doesn't require any scripting to do which is nice. If it is only for certain stages of your quest or while certain scenes are running you could use the IsScenePlaying and GetStage conditions to prevent the dialogue from working during those times.

Well yea, you can access properties of any script I haven't actually scripted for FO so I am not sure I can really draw comparisons with that... hm... I guess the best way to describe it is... It is the similar to way you've already been calling functions. Say I have a Quest and on that Quest I have a ReferenceAlias which is filled with the players reference, I want the alias to be able to access a float property called JumpValue on a Script that is attached to the Quest, lets call that TestQuestScript and on the ReferenceAlias I have a script called TestQuestPlayerAliasScript I could grab a reference of the quest and access the property through the following means: Scriptname TestQuestScript extends Quest Float Property JumpValue Auto Event OnInit() JumpValue = 20 EndEvent Which of course would be the script attached to the Quest, which just sets it's property to 20 when OnInit is called. Scriptname TestQuestPlayerAliasScript extends ReferenceAlias TestQuestScript Property TestQuest Auto Event OnInit() TestQuest = self.GetOwningQuest() as TestQuestScript EndEvent Event OnRaceSwitchComplete() Game.SetGameSettingFloat("fJumpFallHeightMin", 300 + TestQuest.JumpValue) EndEvent This script is attached to the players alias, when OnInit happens it grabs a reference of the TestQuest as a quest using the GetOwningQuest function of Reference Alias. It then Casts the quest as TestQuestScript, if the quest didn't have the TestQuestScript attached this would return none but since it does, it will return the scripts reference. Then when the player's race changes we just set the game setting 'fJumpFallHeightMin' to 300 plus the TestQuest Property. And that's a crash course in property access there's plenty of info around on how it works like here... well maybe not that much but it does cover it sorta.

You can access a scripts properties from anywhere else if you so wish, you just need the scripts reference. Personally, I like to follow OOPs (Object Oriented Programming) single responsibility principle even though papyrus isn't technically OOP (well it is but it isn't) I just find it a useful guideline in thinking about how scripts should turn out. Single responsibility essentially just means it should only do one thing, what that thing is? well that is up to you. It could be Player Movement, it could be applying maintenance code that you need to run each game load, it could be monitoring for changes on an object and performing changes as required... Think of only one thing you want that script to do and stick with it. This doesn't mean start creating hundreds of script files which are extremely short but think of one general thing you want that script to do, and make it fulfill that purpose and that purpose only. Well, that's how I like to approach it anyway if that works for you... well that's for you to decide.

I like to think I know a lot about scripting, whether or not I do... well that remains to be seen :D . Papyrus will save script state to saves, so variables, the currently running functions and the call stacks are all saved, there's a page on save files and how papyrus will handle different situations here. How people deal with updating scripts, well that differs from person to person I think. Most will (depending on what their scripts do) probably use the OnPlayerLoadGame() event to check for version changes and then update variables that need to be updated for the new version there (A short example of this is shown on the OnPlayerLoadGame page on the wiki). You may find working in smaller chunks is better (and easier), personally I hate working with large script files I try to keep them under 500-600 lines as a general rule find it much easier to navigate but sometimes more can't be helped, usually it's pretty easy to see where you could split functionality. Calling Papyrus functions doesn't actually produce that much overhead so where you re-use a lot of script code you could probably place it in a function and work that into something shorter without sacrificing too much.

Might be, it does in quest script. But doesnt matter, because the event would actually say to my quest script that the race changed and than after the change, with some delay, the code would reapply the animation registration again but only that time instead of all the time. + there would be the maintenance on load where its always a safe guard. And it will be in the description (if the mod bugges, quick save/load) that should be an easy but a good way to fix stuff. That sorta came out wrong, what I ment to say was that changing race apparently screws with it* I need a coffee. :sweat:

You could or you could attach it as another, stacking a few scripts on an alias is fine.

OnRaceSwitchComplete is the Event you would be looking for I believe, for that logic. It does need to be attached to either the player form directly (can't recommend that), a quest alias with the player in it or a magic effect that is affecting the player. I've heard that it does prevents registering for animation events in aliases though, I don't actually know if that's true since I've actually never used the event myself

That would be directed at my quip assuming that what Elathia said was in my direction, don't worry about it. I'm terrible when it comes to reading post intents, sorry Elathia. Elathias method will get you the FormID which is a integer value that is the numerical reference the engine uses to distinguish forms rather then the editorID which is the string name someone has made for it. Usually people would just use properties for this sort of thing and compare to those which greatly simplifies the process. But that wasn't the OPs question :tongue:

Welp, this is awkward :sweat:

You are constantly calling for the values from the engine, so it's getting throttled you need to be caching the values locally that is the real bottle neck to your script, look for places where you are calling the same function over and over again, and instead cache that value to a local variable (e.g your GetEditorID(PlayerRef.GetRace()) if block). That would be the first thing I would look for anyway. Papyrus' slowest point is the interface with the engine. After that I would suggest thinking about what actually is needed in that update block, personally I think there is some parts in there that could be better placed elsewhere, look for other events you could hook into to reduce the volume of the code that runs when it doesn't particularly need to. Doing those two things would be a great start in getting that script into a nice clean state!

I know right? How dare they! :tongue:

Noticed I didn't answer some of your questions: I mean that since HasKeywordString() exists the GetEditorID function is a little redundant for keywords as HasKeywordString() is native code and will execute much faster.. well maybe not I am not sure if it is frame locked or not it might be. Oh and anything I post you can use, I'm not fussed about threads since I posted it with the intent for it to be used if it was helpful. You might want to cache what the function gives you before your if blocks so it's not constantly calling the function which makes papyrus work more then it needs to so something like this would work a treat: string editorID = GetEditorID(PlayerRef.GetRace()) if editorID == MyBigBirdRace ;Do stuff for Big Birds elseif editorID == MyBirdRace ;Do stuff for Birds EndIf

Oh I was afraid that would happen, I think you'll find it is also including the " " at the end of the word... I always seem to do that it should be: string Function GetEditorID(Form akForm) Global string fullID = akForm int temp = StringUtil.Find(fullID,"<",0) + 1 int subLength = StringUtil.Find(fullID," ", temp) - temp return StringUtil.SubString(fullID, temp, subLength ) EndFunction That should work. If it was the mistake... which I think it was. My bad.

TESVEdit can't tell what you were thinking :tongue:, so it's not a dirty edit (these are sometimes referred to as wild edits) that TESVEdit can pick up on if you were applying a filter it won't pick it up you'll have to manually check the esp to see if the change is there. If you can't find the change in your plugins records then it probably didn't save in creation kit and you're golden. You'll probably find the record somewhere under the Cell header in your plugin. EDIT: I should Mention and I totally forgot to, Creation kit does have an Undo function for the render window just hit ctrl+z (ctrl+ y will redo if you ever need to) so if you do notice the mistake early you can undo it if you want.

The function would work with any object with a form base type (and yea it's a function I made up so it's not part of StringUtil, so you'll need to write it), you know I never thought about using it to dynamically gather keywords hm... I guess it could do that but since you would need the keyword in the first place to gather the editorID it seems a bit redundant. HasKeywordString() would serve the same purpose and is native so personally I would go with that which would be: Event OnInit() if PlayerRef.HasKeywordString("ActorTypeUndead") Debug.Notification("ZOMBIE!") elseif PlayerRef.HasKeywordString("MyKwSlow") Debug.Notification("So Slow!") elseif PlayerRef.HasKeywordString("MyKwFast") Debug.Notification("Just right.") endif EndEvent or alternatively there is always properties instead if you dislike strings, w/e works for ya.

You'll find you aren't the only one who does that :D I tend to do it accidentally as well. It is difficult to fix easily in CK so leave it until you are finished then use TESVEdit to delete the edit from your plugin. You can find information on how to do that here since you created the plugin you should know what you intended to edit and what you didn't so it should be a fairly simple process once you get used to it.

Yes the first two hex values show what number the plugin is in your load order so 00 would be Skyrim.esm 34009669 would be the 52nd Plugin in your current load order, just remember these are hex values otherwise you might get confused :D.