trira

Nope, default Papyrus doesn't have the setters for Game Settings. You'll need SKSE for that. Not sure if it's been implemented yet.

Minor adjustment

Storing the points for Point's getter in an array would be more efficient; the worst case scenario would execute much faster (no comparisons required vs. maximum of eight comparisons required, or if you want to get technical: O(1) vs. O(n) ). Something like this (note: not sure about array syntax for Papyrus): ObjectReference Function Get() return PointXx[Increment-1] EndFunction You'd then have to declare an array of ObjectReferences as a property (is that possible? If it's not, you'd have to initialize the array/its elements). Also, this assumes that Increment will have a minimum value of 1 (would be better if it started at 0, since you could eliminate the subtraction (not that it'd make much of a difference)) and that Papyrus arrays use zero-based indexing. Another benefit of doing it this way: adding/removing points requires only modification of the array property. To be honest, you could completely remove the getter and just access the array directly in the OnTranslationComplete() event. Float PlayerPosX = getPlayer().GetPositionX() Float PlayerPosY = getPlayer().GetPositionY() Float PlayerPosZ = getPlayer().getPositionZ() Wouldn't hurt to store GetPlayer() in a variable, instead of calling the function three times. Save a couple of clock cycles, could make a difference due to Papyrus' multi-threaded nature. If Increment < 9 If PlayerPosX == OBJPosX If PlayerPosY == OBJPosY If PlayerPosZ == OBJPosZ GetPlayer().TranslateToRef(Point, 5000) EndIf EndIf EndIf EndIf If Increment == 9 ;Do my other secret stuff! GoToState ("Finished") EndIf Setting this up like this: if( Increment < 9) ; do whatever elseif( Increment == 9) ; using just an 'else' is another possibility. Based on what TK posted, I'd recommend it since there's no chance of Increment being larger than 9. ; do whatever, version 2 endif Would be a minor improvement since only one of the two conditions is ever going to execute. Hopefully this made sense. Kinda drunk and I make not very much sense when drunk.

Why would certain functions not be available in an OnUpdate event? He's getting errors because Container inherits from Form. GetItemCount() is a part of ObjectReference (first error). The compiler can't find the function he's trying to use so it's replacing the result of the call with null (second error). If TOSInn01CourierSackScript is being attached directly to ContainerTOSInn01CourierSack, you could use self.GetItemCount() (self isn't necessary, I'm just using it to show who's making the call). You also wouldn't need the ContainerTOSInn01CourierSack property that way. I also second WillieSea's suggestion of using the OnClose event. It was written for these types of scenario and, overall, will be more accurate and less resource-intensive than OnUpdate. Edit: My grammars. And I accidentally some words.

I think SKSE's the only hope for something like that. Another way would be to use Global values and give the user a way to set them in-game (e.g. a spell/item that brings up a message box with possible choices)

The ini file you're talking about is only meant to override settings found in SkyrimPrefs.ini and Skyrim.ini. More info here!

Papyrus isn't too bad. Like WilliSea said, the most confusing about Papyrus is properties (fragments are annoying as well, but don't show up as frequently as properties). Once you get that down, it really isn't that different from other languages.

What you're trying to do should be possible. How far are you getting in the script? By that I mean do you see this in-game: "Debug.Notification("Updating Merchant Prices")"? If you don't, then your script isn't initializing or it's runnning into a run-time error before it reaches that statement. One thing to try would be inserting Debug.Notification() statements at certain parts of your code. See which ones show up. Also, I don't think you can cast from Form to ObjectReference. It's a one-to-many relation (one Form can have many ObjectReferences pointing to it) so the game probably wouldn't know which reference to choose. I could be wrong though and it might be possible to cast from Form to ObjectReference. Try making an ObjectReference property that points to a specific merchant/merchant's chest and try it out with that merchant. I hope any of this helps.

You're overthinking this. This should work: Scriptname script_name extends [something] int Property ItemCountInt Auto Ingredient[] Property Imports Auto Ingredient[] Property Base Auto Event OnInit() RegisterForUpdate(0.5) Debug.Notification("Economy Control Script active") EndEvent Event OnUpdate() int i = 0 While( i < Imports.length ) If (Game.getPlayer().getItemCount( Imports[i] ) > 0) ItemCountInt = ( Game.GetPlayer().getItemCount( Imports[i] ) ) Game.getPlayer().RemoveItem(Imports[i], ItemCountInt, true) Game.getPlayer().AddItem (Base[i], ItemCountInt, true) EndIf i += 1 EndWhile EndEvent Edit: Note that this loop assumes Imports and Base are of equal length. If you want to be safe, there's two things that could be done to avoid potential issues. 1) Compare length of both lists before executing the loop and completely avoid the loop if they're of unequal length (safest) 2) Compare length, if they're unequal, take the smaller of two and have the loop iterate that many times. (less safe) Edit2: Grammar.

The "Topic Info" has a slot for Papyrus fragments that are executed either at the beginning or end of the dialogue line. You can insert that code snippet there. Defining properties in fragments is a bit more annoying than in normal scripts though. I still haven't fully figured out that part. Only got it working once.

Have you considered using a while loop for this? It'd make your code significantly shorter. Also, you missed the third element (index 2).

If you're attaching your script to a Quest, it needs to extend Quest. Otherwise nothing will happen. @WillieSea: I think by container quest he means he's using a dummy quest to attach his script so he doesn't have to attach it directly to a vanilla record (compatibility reasons, I'm guessing).