BrettM

"Missing EOF" stands for "Missing Event or Function" in Papyrus, which is a little confusing. What that means is that the compiler found code that is not contained within a proper "Event ... EndEvent" or "Function ... EndFunction" block. I'm not sure where you got your "Begin GameMode ... End" statements from, but those are not what Papyrus is looking for. You might want to take a look at the Papyrus Basics tutorial in this forum and the scripting tutorial series at the Creation Kit wiki. Bookmarking the Scripting Reference in your browser is also a good idea, since it contains information about nearly every native script and function in Papyrus, plus a selection of sample scripts, lists of error messages, SKSE functions, and other useful material.

Hmmm. Then a small package of loose nifs will work as a patch? Shiny!

It looks like I'm going to have to replace a handful of meshes in the FPI Gallery that are causing users to CTD or giving them other collision problems. I don't need any changes to the ESP, I just need to replace a few nifs with new versions. As I understand it, the BSA will take precedence over loose files, so I can't just zip up the replacements and post them as a small patch. Is this correct? Yet, I really hate the idea of repacking the whole BSA and re-uploading, since it takes hours for one upload and I'd have to do it twice, here and at the Nexus. Is there any alternative utility that users can run to incrementally patch a BSA? This IS 2013, not 1983. But me and google can't seem to find anything.

I took a little time and whipped up a complete example for you. This setup has an open barrel with a water plane in it and a "magic valve" to fill it. The water is invisible until the barrel is filled by the valve, at which point it fades into view. 1. In the Object Window under Miscellaneous-Keyword, define two new keywords that the valve will use to find the barrel and water. I used fpiKYWDBarrel and fpiKYWDBarrelWater for this. All you need to do is give each a unique name. There are no values you need to set or anything. 2. Under WorldObjects-Activator, set up three new activators for the barrel, water, and valve. I used fpiBarrel, fpiBarrelWater, and fpiBarrelValve. For the barrel, I used the model BFXOilBarrelOpen01.nif, since it was a handy small, open barrel. I gave it a Name of Water Barrel, and put "Talk to" down in the Activate Override Text. So, when you activate the barrel, the prompt will say "Talk to Water Barrel" instead of "Activate Water Barrel". For the water, I used the circular water plane from the TESA resource kit. I just picked some kind of murky marsh water for the water type. For the magic valve, I just used a glowing doohickey from my FPI Gallery mod. But I could just as easily have used a chair, a chunk of rock, or any other random static item. I put "Magic Valve" in the Name field. 3. For fpiBarrel, I clicked Add-[New Script] and entered the following script: The function at the end will be called by the script on the Magic Valve to tell the barrel that it has been filled. 4. For fpiBarrelValve, I added the following script: After the script was compiled and saved, I clicked the Properties button and set the two Keyword properties to the keywords I added in step 1. Edit: Note that the function call "BarrelRef.SetIsDry(false)" is not really necessary unless you want the barrel to do other things when told that it now has water. If you just need to set the property, as I did here, you could use "BarrelRef.IsDry = false" to set the property directly. 5. I dragged the new barrel activator into the Render Window to put it in my test cell. Then I dragged in the water, sized it to the barrel, and checked the Initially Disabled box to make it invisible. Finally I dragged in my Magic Valve and went to the Linked Ref tab of the edit window to add references to both the barrel and the water. Each reference was tagged with the appropriate keyword. And that finished it. I had a working valve that would add water to the barrel, making it magically fade into view. I had a barrel that I could talk to that would tell me whether it was empty or full. I could just as easily have set the valve up with a menu to choose whether to fill the barrel or empty it, making the water appear and disappear. Or, I could have added another valve for draining the barrel using the same technique for telling the barrel and water what to do, using the same keywords and linked refs used by the filling valve.

I'm getting confused. Call the main script from what, for what purpose? Which one do you consider the "main script" and what is this "separate script" you mention? You have to remember that we aren't as intimately familiar with the logical structure of what you're setting up as you are, and we lose track while working on our own projects and reading other threads. You need to refresh us and show us what you're trying to do to get a useful comment. At least from me. I bewilder easily.

The barrel would have to be an activator with a script attached, or would have to have a player-activated trigger with a script attached to it. That script would have to have a function that the valve activator could call to tell it when water has been added. Here is a sample function from a script on an activator (a fish spawner) that calls a function on another activator (a fish) to pass information. Function SpawnFishAtRef(ObjectReference arSpawnRef) ; Spawns one fish inside the spawner ref. The type of fish ; is chosen at random from the FishTypes list. The reference ; is cast to the fpiAquariumFish base class. Activator FishType = FishTypes.GetAt(RandomInt(0, FishTypes.GetSize() - 1)) as Activator ObjectReference FishRef = arSpawnRef.PlaceAtMe(FishType, 1, false, true) fpiAquariumFish NewFish = FishRef as fpiAquariumFish ; Now we pass information about our properties to the new fish, so ; he knows who owns him and where he can go within our volume. NewFish.SetInitialSpawnerProperties(Self, fVolMaxZ, fVolMinZ, fVolMaxX, fVolMinX, fVolMaxY, fVolMinY, iCornerCount, fVolCornerX, fVolCornerY) EndFunction In your case, your valve would not have to create the barrel like this script creates the fish. It would just need a linked ref to the barrel that it uses. Here is a bit of code used on an activator that talks to an item with a script attached to retrieve a string. It could just as easily pass information. The activator has a linked ref to the item. "Self" in this case is the activator, which would be your valve activator. "fpiGalleryItem" is the name of the script attached to the item, which has a function named "GetGalleryDesc." In your case, the item would be the barrel activator or a trigger attached to the barrel, which would have a script named <whatever> with a function named <something> to receive the message that water has been added. LookupRef = Self.GetLinkedRef() if LookupRef ItemDesc = (LookupRef as fpiGalleryItem).GetGalleryDesc() endif Come to think of it, you wouldn't even necessarily have to call a funtion. If the barrel or trigger has a property such as "HasWater" then the valve script could just set that property to true or false directly. If you want an example of this, perhaps you should read the Papyrus 101 tutorial on properties here.

I did tell you way up there that you would need to define the sound file in a property before you could call Play() on it. Glad you figured it out, though. I haven't done any quest scripting, but I would guess that you would need to define your trigger as "Initially Disabled" to keep it non functional until it's time to activate it. Then you would need whatever script sets the stage to 10 to send an Enable command to the trigger to make it appear. As I said earlier, you need to make sure that the trigger is disabled after the player no longer should use it, if it's a one-time thing. But you also need a way to re-enable it if the player uses the console to set the stage back to an earlier stage. If quest objects can have scripts attached to each stage, then an enable script attached to stage 10 plus a disable script attached to a later stage would make sense to me. But you'll need a proper answer from somebody who knows about quest scripting.

Is that the same script we've been talking about, with a new name? Or is it some other script not posted in this thread? What are the characteristics of THEFINNPlayerRefQuest? According to the CK WIki: Perhaps that will give you a clue.

My idea is that when you remove gold from the container, the system does not trigger an event named OnItemAdded, so your disable code is never being executed. Perhaps you need an OnItemRemoved event to handle that part of the job?

If the compile is failing, then the compiler told you what IT thinks is missing or incorrect. Perhaps if you shared what the compiler told you was the problem, and the line number(s) that it didn't like, it would be easier to help. Otherwise we have to run an imaginary compiler in our heads while looking at your script and try to imagine what kind of errors it would find. (Note that the CK Wiki has information about compiler error messages that can often point you in the right direction for solving a compile problem without needing to wait for someone to answer a post.) I don't see any errors in the script as you posted it above that would cause a compile problem. To confirm, I copied your posted code and ran it through the compiler myself. It compiled without error. So if you're getting compiler errors, then you are trying to compile something other than the code you posted. Which means you are basically asking us to diagnose a problem with a script you haven't shown us that has compiler errors we haven't seen. Ummmm.

I agree that documenting "magic numbers" is a really, really good thing to do. FormLists are very nice for that, since you can see the names of all the stuff you added to them, so it's really a shame they won't work for you. If the properties could somehow be made so that you could fill them from a pick-list of names, that would solve the problem, but I can't think of a way to do that offhand. If one occurs to me, I'll sure let you know! OTOH, if you're going to be including a lot of refs to other mods, then your script is going to turn into a real maze of functions and calls to them, and all the code to initialize all the arrays of the things you want to add is going to suck up processor time. Of course, that matters less when your code is of the "run once" variety rather than something that needs to run every time the player speaks to the merchant.

A FormList is basically a pre-defined array of form IDs. Looking more closely at your code, though, I see that won't work for you, since you have to use GetFormFromFile. The other option is to define your robes as array properties, so the information is filled in before the script ever runs. This will make your script a little leaner and more efficient, since you don't need the initialization code at all. Something like: Int[] Property RobesOpulent Auto Int[] Property RobesVanilla Auto <other code> Function OpulentOutfits() debug.Trace("========== Adding Opulent Robes, Hoods and Boots to Inventory.") i = 0 ; set i back to zero to begin. while i < RobesOpulent.Length AddSomeItems("OmageReplacerPack.esp", RobesOpulent[i]) ; Step through the Array. i += 1 endwhile endFunction Function VanillaMageRobes() debug.Trace("========== Adding Vanilla Skyrim Mage Robes to Inventory.") i = 0 ; set i back to zero to begin. while i < RobesVanilla.Length AddSomeItems("OmageReplacerPack.esp", RobesVanilla[i]) ; Step through the Array. i += 1 endwhile endFunction See how much cleaner and easier to read that is? When you add your script to the merchant and edit the properties, the Properties Editor will give you a special dialog for an array property allowing you to fill in as many or as few elements as needed. If Opulent Robes ever adds new robes, you don't need to change your script at all! Just add the new ones to the list in the Property and you're good to go. In fact, you could make it even simpler by combining the two functions into one. The calling program could simply pass in the name of the property containing the proper robe list as an argument, so the script has less redundant code. The main disadvantage, of course, is that you don't have your nice list of comments telling what each integer is referring to. But, if you can live with that, I think this might be the best way to get the job done.

From the CK Wiki: So the first thing to do is to take a look at line 15 and see if something is misspelled or otherwise not correct. This kind of thing can happen because of errors in the lines that come before the line it is complaining about. Because you did not put the Auto keyword on the property above the global variable (PlayerxMarker), the compiler is expecting the next line to be a function for getting or setting the value of PlayerxMarker. It is expecting to see code that looks like the code for a Full Property, but instead it sees another property declaration. This error should go away as soon as you fix the first error.

Everything that you want to happen when the player enters the trigger goes in the OnTriggerEnter event. After you've made sure that the trigger has been activated by the player and not some wandering NPC, then play the sound, set the stage, and do whatever else needs to happen. I believe you will need to "Import Sound" in the trigger script to use the sound script's functions. You will also need to add a property to identify "mySFX" before you can call its Play() function. If this is a one-time thing that the player can never do again once the quest has moved on, then you will also have to ensure that the trigger is deactivated afterwards, and re-activated if the player uses the console to set the quest back to an earlier stage.