BrettM

The compiler thinks you are attempting to use "disable" and "enable" as properties because you didn't put in the parens to tell it that you want to use the disable/enable functions. Try EE_GoldPile01REF.disable()

Unlike Willie, I have found several excuses to use arrays, but Papyrus is not really very array-friendly even though it has the basic capability. I would give a pretty penny for a one-line assignment myself, but it just isn't there, any more than arrays that can be dimensioned at runtime are there, or array properties that can be given an initial list of values, or ... Just quickly off the top of my head, can't you pre-define the robes as an FLST and then just cast that to Int when you assign it to your Robes array? You wouldn't be able to comment the individual values that way, but I don't see why that is really necessary. You'll know what they are when you populate the FLST.

A State is not like a variable that you put off in some corner and set and test to decide what to do. A State is like an Event or a Function. It has a beginning and an end, with code in between. Events and Functions are boxes that surround code. So are States. The main difference is that an Event or Function surrounds ordinary code. A State, however, surrounds Events and Functions. It is a like a big carton that holds several small boxes of candy. So the structure of a script that uses States should look something like: State Active Event OnTriggerEnter <code> EndEvent Event OnTriggerLeave <code> EndEvent EndState State Inactive Event OnTriggerEnter <code> EndEvent Event OnTriggerLeave <code> EndEvent EndState Each State has its own copy of each event, and the system knows which State the script is in. So, when a player enters the trigger, the system will call the copy of the Event that is in the State that is currently in effect. The Events can do completely different things in different States, so you write the Active version of OnTriggerEnter to move the player and the Inactive version to do nothing. Trying to explain things and pointing you to tutorials is about all the help I can give. I don't know what else I can do short of writing your scripts for you, and I just don't have the time for that. Also, I have never written any magic spell scripts, so I would have to study how that is done before I could do it. I still don't understand why you can't just use the script that Willie generously offered from his Leveler's Tower mod, and just put your fancy portal doors in place of his Riften load doors. That script is guaranteed to work, since Willie is an expert scripter.

To begin with, you don't want to try setting the position on the BaseID, you want to set the position of the copy that you just spawned using PlaceAtMe. What if you had five fires? The BaseID refers to a form that has no existence. SetPosition is a function of an ObjectReference, not a Form. Lucky for you, the PlaceAtMe will give you the ObjectReference ID of the item it made. ObjectReference MyLitLogs MyLitLogs = PlayerRef.PlaceAtMe(LitLogsBase, 1, false, true) ; Keep the logs disabled (invisible) until they're in position MyLitLogs.MoveTo(PlayerRef, 0.0, 0.0, PlayerRef.GetHeight() - 35.0) ; Put the logs on the ground where the player is standing MyLitLogs.Enable() ; Use Enable(true) if you want the fire to fade in instead of popping in. If the player will always be standing on level ground, you might want to give the fire a little X and Y offset instead of 0.0, so he doesn't get a hotfoot. If you like, you can use MyLitLogs.SetPosition(X, Y, ModZ), but using MoveTo means you don't need all the variables and function calls to GetPosition. MoveTo will do the calculations for you. You know, all of this information is in the Papyrus reference material on the CK Wiki, which gives examples and comments on every script and function available. I would recommend that you bookmark this reference. If the compiler doesn't like a function, it may be quicker to look at the function description there and see what you may be overlooking than it is to post a question and wait for an answer.

I just went into the game, open the console, and entered player.placeatme 35f47. I got a campfire01landburning right at my feet. The console uses the same functions used in scripts, compiling them on the fly, so I guarantee there is a way to do it with a script if I can do it with the console. Since you already have an ObjectReference property pointing to the campfire, all you need is to get the BaseID for it as a type that PlaceAtMe will accept as an argument. Form CampfireBase ; Variable for the ID of the object CampfireBase = Campfire01LandBurning.GetBaseObject() ; Should return 35f47 as the base form ID PlayerRef.PlaceAtMe(CampfireBase) ; Function should be happy with a Form argument I think that will do the trick for you.

The code you posted first looks to me as if it would almost work. 1. You are moving the player to the second portal before you block it from activating. If the block doesn't get there until after the player does, then why wouldn't it still send him back? It seems to me that those two statements should be reversed, so you block portal 2 before sending the player into it. 2. Is your "OnTriggerLeave" event in the code for portal 1? After the player arrives at portal 2, he will be leaving that trigger, not the portal 1 trigger that he entered. So portal 1 won't unblock portal 2 until after the player returns and leaves the portal 1 trigger. Except that he can't return through portal 2, because it's still blocked. It seems to me that the OnTriggerLeave event in each script needs to use Self.BlockActivation(false), instead of sending the message to the other portal. 3. As far as I know, blocking activation only prevents the OnActivate event from doing anything. But your teleporting is being done by the OnTriggerEnter event. If that isn't affected by BlockActivation, then blocking activation doesn't seem like it would solve your problem. But, I don't know much about trigger volumes, since I've only written one of them, which was mostly borrowed from another script. All of the triggers I used in the FPI Gallery mod are player-activated, other than the example I gave you of code with states. So, the logic would be: 1. Player enters trigger of portal 1. 2. Portal 1 somehow disables the teleport function of portal 2 so that it can't teleport the player right back. 3. Portal 1 sends the player to portal 2. 4. Player leaves the portal 2 trigger. 5. Portal 2 makes its own teleport function active again so it is ready when the player enters that trigger the next time. Since I haven't studied your scripts and have never written any spells, perhaps I am misunderstanding the logic of what you're trying to do and the above is all wrong. If it matches your idea, though, then it seems there are two states for the trigger to be in: Sending (or Active) state, where it only cares about players entering the trigger, and Receiving (or Inactive) state, where it only cares about players leaving the trigger. The sending trigger must somehow tell the target trigger that a player is about to come there and it should prepare itself to receive him. It would have to involve some kind of function call between the two trigger scripts, like a "PrepareToReceive()" function in each script that is only called by the other. If you already have a valid reference to the other script so that you can call functions on it, then you don't need to set up a reference variable like LookupRef. I had to do it in the code I showed you because the only reference I had was in the linked list of the activator. If you have some other way of getting the reference, then you don't need a linked list or a way to get references out of it.

The function named "GoToState" is part of every script that another script can call. So script01 can call, say, GoToState("Receive") on script02 to put it into "Receive" mode. When the player exits the receiving portal, it can put itself back into "Send" mode, ready for the player to re-enter to go back to portal01. You will need to have a variable in each script to identify the other, and then cast that reference to the script type when calling a function in it. For example, I have a script called "fpiGalleryItem" with only one function, named "GetGalleryString" that I can attach to any static object. The function does nothing but return a string related to that object. To call that function from another script, I have: ObjectReference LookupRef ; Variable used to point to item with the script attached Event OnActivate(ObjectReference akActionRef) <bunch of code> LookupRef = Self.GetLinkedRef() ; I have the other object as a linked ref in my activator String ItemText = (LookupRef as fpiGalleryItem).GetGalleryString() <bunch more code> EndEvent Hope this helps. I think using states is a better way to handle the logic here than creating a boolean variable as DaMage suggested. His suggestion would work, of course, but states are a classier way to go because they make it very clear what behavior to expect from a script under what circumstances. What will the script do when it is receiving a player? Just look at the code in the Receive state and you know whether or not it's doing everything necessary and not doing what you don't want it to do. With boolean variables you have to pick through the code to see which statements are accepted or included for a given value of the variable. Edit: You might also want to look at the CK tutorial on scripting a lever, in which a lever activator calls functions on other activators: Function DisableDoors() Door01.BlockActivation() Door02.BlockActivation() Door03.BlockActivation() EndFunction If you think of one trigger as the lever and the doors as the other triggers, you can see how this would work. The BlockActivation function is a built-in part of ObjectReference.

You could probably use states very effectively to control this. Below is an example script that detects whether a player is within the trigger volume and switches states as he enters or leaves. Trigger volumes are a little odd to work with, since I understand that the OnTriggerLeave event can actually fire before the OnTriggerEnter. So you need to watch the count of objects in the volume. I guess you would probably need a state for "portal is in use" and one for "portal is ready to go," so the "in use" state doesn't perform a teleport. The portal would switch to the "ready" state only after you leave the volume.

I actually have been putting only one or two kinds in at a time for getting screenshots. There isn't one of them that stands out as a problem. It seems to affect any fish or mix that I put in the list. (Since they're all salmon01 or salmon02 with different textures, I'm not sure that a blue salmon01 would be any more or less likely to have a problem than a red salmon01 anyway. In fact, salmon01 and salmon02 are actually the same fish with the UV maps rotated to opposite ends of the same texture file.) All of the fish have alpha transparency on their fins. I don't believe I've ever seen any of them turn invisible as they turn and move about the tank. Perhaps it does happen, but they certainly don't stay that way long enough that I notice any reduction in the population while I'm watching. The missing fish are simply not there when I reach the tank, and never appear, though they report that they are moving around just like the visible ones. The difference between my alpha and Bethesda's is that they used a simple B&W mask for the fin edges, while I'm using blending to get transparency in the fin itself. I'm not sure where I would put in waits. The spawner creates fish one at a time and does not create the next one until the previous one has received and processed parameters sent to it by the spawner. When the fish is ready to begin moving, it registers for a single update that's intercepted by a function in a special "kick off" state, releasing the spawner. The whole process is so danged slow that you can stand there watching fish pop into existence if you get to the tank quickly enough after entering the cell. I'm not quite sure what you mean by "not really spawned". All of the fish that are supposed to be there will send messages to the log reporting their current activities, like "I spawned at location <x/y/z>" or "I arrived at target <x/y/z> at speed <afSpeed>." How can an object that is "not really spawned" report its position?

You don't need the "elseif". If the actor is not the player, then the script just does nothing the way I gave it. The "PlayerREF" only works if you have assigned Game.GetPlayer() to a variable named PlayerREF or set up a property named PlayerREF that already contains the reference to the player. (Actor Property PlayerREF auto -- which is a property that can be autofilled. It's an efficient way to refer to the Player without any calls to the GetPlayer() function.) Otherwise you would have to use: if akActionRef == Game.GetPlayer()

How is your trigger set up? Did you put in a debug statement to see if the script is actually being executed? If the script is being executed, then it's a problem with the script. If the script isn't being executed, then it's a problem with the trigger setup. Also, what happens if an NPC walks into your portal? The script would be called with akActionRef pointing to the NPC, but the script would grab the player and move him. It's generally a good idea to check the akActionRef and make sure it is the player who is activating the trigger before doing anything, if only the player is supposed to use it. For example, my teleport objects use code like: Event OnActivate(ObjectReference akActionRef) if akActionRef == PlayerREF <do stuff> endif EndEvent so that nothing is done unless it is the player who did the activation. Of course, if you have some other means of preventing NPCs from activating your trigger, then the precaution is not needed. But I think it may be a good thing to do anyway, just to make it a habit.

What did you do? Add debug statements? If you didn't get any messages in the log, then your script isn't being called for some reason, so worrying about what kind of references you need internally won't help. However, the BaseID is used when you need to create a new copy of an object. It's like dragging something from the Object Window (where the base objects live) over to the Render Window (where reference objects live): a copy is created and given its own FormID in the cell. The BaseID is also used to refer to things such as FormLists, which don't have any physical existence. So, normally you will be referring to objects by reference ID.

From the CK Wiki: "Note: the akFormToPlace can be things such as MiscItem, Actor, ActorBase, etcetera, but it cannot be an ObjectReference." You need to cast the ObjectReference as a MiscItem before giving it to PlaceAtMe. Edit: Also, I see you're making a lot of calls to Game.GetPlayer(). I think the script would be more efficient and faster if you made it a property that you can autofill and used that instead of repeated function calls. E.g.: Actor Property PlayerREF Auto Or make a variable and do one call to Game.GetPlayer() to fill it, then use the variable.

I seem to be having a problem with some of my fishies being invisible. The spawner reports that it spawned eight fish. The eight fish each report that they are moving around to locations that are definitely within the boundaries of the tank, so they must be enabled and 3d-loaded or the movement events would not be triggered. Yet I rarely see all eight, but usually only around 5-6. How do I go about solving this one? I've seen some postings on large objects with LOD being invisible, but that doesn't seem relevant to my problem. I've also seen some reports on actors being invisible, which may apply, but I see no way for a script to determine which fish are bugged and apply the steps needed to solve the actor problem. Is there a way to invisi-proof my fishies?

One thing that can help you find out where things are going wrong in a script is to insert Debug.Trace calls at certain key points in the code. Turn on Papyrus logging in your Skyrim.ini, run your test, then look for your traces in the log. For example, in your OnEffectStart event, you could put a statement at the top that reads something like Debug.Trace(Self + " is being cast by " + akCaster) If that statement shows up in the Papyrus log, then you know that the script at least recognized that you were casting the spell. If the statement does not show up, then you know that your spell is not being activated for some reason. Either way, you have a better idea of where to begin looking for a solution. In your functions you can put statements such as: Debug.Trace (Self + " is summoning Portal Door 1") So you know that the function that was supposed to be called was actually called. Even without the Debug statements, you should check the log to see if any mention of your script is there. If your script is doing something that the system doesn't like, such as trying to call a function on an object that does not exist, then there will be an error message there. Once you've solved your problems, you can then comment out the Debug statements by putting a ";" in front of them and recompile before release. The reason to leave them in as comments is that you might want to add or change something for the next version, so the debug statements are already there when you want to test that version and you don't have to rewrite them from scratch. Just change them from comments back into statements. By the way, it is very, very good practice to comment your code well and put tooltip comments on your parameters, or at least the most important ones. Edit: I would also recommend taking a look at FAQ: My Script Doesn't Work.