My ship mod uses persistent refs for the statics, collision, and an activator. I plan to change this to an alias-based system eventually; but I'd still like to know how to do this....

When activated, my boat switches a certain static for another (the sail)... then Player sails off to wherever. When the boat is anchored, the sail should switch out with the other static (a stowed version of it)... but if Player isn't in the vicinity of where the boat was 'launched', that static doesn't appear. Papyrus log shows that it's because it's in a cell that has no parent... which I understand.

But how does one either ASSIGN a parent cell, or somehow workaround this issue? Would sending the object(s) to an interior cell work, or does it give the same error? I believe I tried sending stuff to an interior, with my mannequin mod, but was unsuccessful (probably for the same non-parent reason). I'd rather not have that 'hidden' static inside the movement functions (to keep it in the vicinity as Player)... as that may slow down the script-timing.

Any help or suggestions are appreciated. [It actually took a lot for me to ask for help in a new thread... but I couldn't find anything about this anywhere.]

I tried sending an object to an interior and it doesnt work. Do I need to use location aliases? I haven't used aliases yet so I have no idea if this is what has to be done. In the meantime, I wound up having my object being moved along with Player like the other objects; but I'd rather do away with this as it may affect performance on lesser systems.

Also, does anyone know how to get rid of 'cannot open store for class' errors in Papyrus? I'm fairly certain they're linked to fragment scripts, but haven't looked into it yet.

I'm not sure I understand your issue with MoveTo. I have no problems moving things from unloaded cells to loaded cells.

You can check the http://www.creationkit.com/Papyrus_Runtime_Errors#.22Overridden_function_X_in_object_Y_does_not_have_the_same_signature_as_in_parent_object_Z..22 page for your other problem.

I figured the class errors had to do with deleting old scripts.

But the moveto (or translateTo.. doesn't matter): any time I've tried to do that, the object nevers shows up and the Papyrus log says it's because the object has no/diff parent cell or something to that effect). This is trying to move something that is a property assigned directly to a reference. This may be what's causing the problem. Do I need to place it in an alias instead of an objectRef property? Or is it maybe the way I'm decalring the property? I just do it the basic way, but I've seen scripts with "as actor" and such things tacked to the end of certain commands or lines. I haven't gotten far enough into this yet to have come across a need to know... but it seems that time is nigh.

The script I use is attached to an activator, which moves with Player to elsewhere in the world. When first activated, it sends an object underground and disables it. Now if Player moves far enough away (so the original cell is unloaded and/or unattached), the underground object can't be 'retrieved' when I end the script. I also cannot send things to and from an interior cell (like the old Oblivion trick to get around certain issues)... for the same parent-related reasons.

I appreciate your help!

I made and tested this script for someone's Mark and Recall spell:

Scriptname Example extends ActiveMagicEffectGlobalVariable Property MyGlobal AutoObjectReference Property Marker01 AutoObjectReference Property Marker02 AutoActivator Property Portal AutoEvent OnEffectStart(Actor akTarget, Actor akCaster)    if (akTarget.IsInInterior())	    Debug.MessageBox("You cannot use this spell inside an interior cell.")	    Return    endif    ObjectReference PortalRef = akTarget.PlaceAtMe(Portal)    Utility.Wait(2)    if (MyGlobal.Value)	    MyGlobal.SetValue(0.0)	    Marker01.MoveTo(akTarget)	    akTarget.MoveTo(Marker02)    else	    MyGlobal.SetValue(1.0)	    Marker02.MoveTo(akTarget)	    akTarget.MoveTo(Marker01)    endif    PortalRef.MoveTo(akTarget)    Utility.Wait(3.5)    PortalRef.Disable()    PortalRef.Delete()EndEvent

The markers I used were XmarkerHeading objects. I was able to move them to and from whatever cell they were in, whether or not they were loaded, with no problems.

Amethyst Deceiver suggested using a location (in another thread), which I know precious little about as well. But I've tried doing something not unlike the above... I'm not sure where your marker1 & 2 go and where they come from; but I doubt that matters. That's about as straight-forward a moveto setup as you can get... heheheh; which is why this drives me crazy when it doesn't work. It'll probably be something ridiculously mundane that I'm overlooking.

But I have an interior cell with an xHeadMark... I've tried to moveto the static to it, and I get the parent error. Same thing if I try to move something FROM the interior to another xHeadMark in Tamriel. Again, I think this may be solved by using a location (which may parent/attach/whatever the cell to get it working)... but it doesn't really help if talking strictly about Tamriel worldspace and distant objects. All this works perfect if the statics, Player, & the markers are in the same vicinity. I'll reinstate the code and run it so I can get the exact errors it shows... it's been like a week since I messed with this.

error: Failed to setup moving reference because it has no parent cell or no 3D
stack: [ (06560586)].ObjectReference.TranslateTo() - "" Line ?

This is the error it gives me. I transTo the troublesome static underground (out of visibility); then Player sails away several cells. When the script stops it's supposed to transTo that static to the boat & Player (and transTo a diff static underground, which it does fine).

are you using stats as property refs for your moveto targets?

if LOD kicks in, that stat no longer has any 3D data to reference (LODs are an entirely separate object that is "baked" with no ref ID, and thus non-callable). you should target markers instead.

if you dont have any luck with the purgatory trick, you can always place a single xmarker underground in tamriel. markers make edits as REFs in the tamriel parent world cell, not any of its children (i believe this allows them to be persistent forever, and probably quicker for a script to access, since it only need look in the root parent). it will still create an empty dirty edit in the local cell's GRUP, but you can safely delete that in tessnip, and just leave the actual REF in the tamriel parent cell. all REFS in the parent tamriel cell are stackable, so there is no risk of mod overwrite

they dont even count as vanilla edits in Esm's (i havent had problems with them). all of my mods only connect to tamriel through the parent tamriel cell using these type of REFs (markers, activators and doors). i never allow any edits to cell children, and all these are kept in my esm with no problems

Do you mean to create a dedicated xMarker to link to the static? I know the above error is from a translateTo, but I get the same thing with moveto - when trying to send the distant object to a non-linked xMark (which remains near Player the whole time). I've tried sending it to another static too, doesn't work. SetPos doesn't work either; I assume because it's basically a precision moveto.

The static I'm trying to move is specifically assigned/pre-filled to it's own property in the script. I know this isn't the preferred method, and I plan to change it when I get everything working nicely. But the point is, that by doing filling a property with an actual ref, the reference should be perma-persistent.... yet it still has no 3D/parent and cannot be moved when distant.

[EDIT: Right now, I've resorted to moving the static underground, then moving it along with Player and all the other objects... which works as expected. But I'm sure you can see the value in not having to do that.]

I want to apply this in a slightly different manner as well... if Player somehow trashes the boat and it gets stuck somewhere or whatever, I want them to be able to pull a lever back at the original location; and the ship, no matter where in Tamriel it is, would be auto-teleported back instantly. This works when close-by, by distance from the lever gives me the same errors as above. I just mention it because at one point I thought it may have to do with the static being called in the script; which still runs, then called again after the 3D is unloaded... my theory was that the script somehow 'tagged' the static, but even in a 'fresh' script calling the commands it doesn't work. I have the vague notion this may still be a possibility somehow..

have you fiddled with disable/enable during the moveto process at all?

is your sail high-poly? you may need to check it off as is full LOD, maybe the no 3d is referring to the sail itself (as it disappears after distance, but i believe this can be bypassed if the object is disabled in waiting). but first i would try the purgatory method with the location data

yup.. same thing. This is what I do... so maybe I'm overlooking something simple. There's an onUpdate for the actual sailing stuff, but that static isn't touched during that (well.. the current version does out of necessity, but the buggy version doesn't). The function is called at the very end, and everything else inside it works fine.

objectReference property GokSailStowed1 auto
onActiv
GokSailStowed1.translateTo(underground)
endEv
function toEndTheScript
GokSailStowed1.translateTo(player in a new area)
end


[EDIT: as you can see... there's not much there to go wrong, so it HAS to be something simple heheheh. Those lines are the only time that static gets called in the script, if that matters. Again, it works while Player is still close-by; and it doesn't matter if it's a moveto or WHAT it's being moved to]

error: (06560586): cannot be moved.
stack: [ (06560586)].ObjectReference.MoveTo() - "" Line ?

This is actually the error I get when I try to move it into an interior cell (to an xHeadMark in a pre-filled-w-ref property). Slightly different as it doesn't say anything about 3D or parenting... and the static just stays where it is.

I think that whether or not an object can be moved depends on the BSX flags in the nif file. I'm surprised that SetPosition and TranslateTo works on it when MoveTo doesn't.

As for the other error, I believe it's as Amethyst Deceiver says. The problem isn't that the cell is not parented, but rather that your sails have no 3D (because of the LOD). I don't know how you're going to fix it except by turning off LOD for them.

are you ok with using placeatme instead of the ball and chain moveto method?

placeatme kill-and-respawn method is potentially much more dangerous as there is more room for error and pollution, but i think it can be controlled with good conditions, and at least there is no issue with 3d data

Moveto DOES work... if used in the same area; all the commands work. But none of em do when distant. I suppose it's possible that it's because of the actual NIF structure; none of my NIFs have a BSX node... I don't use them because I don't use collision (which I understand the primary function of those nodes to be). But I think, as you inferred, that the static wouldn't move at ALL if that was the case... whereas mine moves, just not while far away. I'll add a BSX in there and see if it makes a diff.

[EDIT: added a bsxFlags of 130, no difference]

I just tried several things: linking the static to an xHeadMark (which moves with Player, nope. Tried linking it to the interior cell's xHeadMark, nope. I tried using a movetoMyEditorLocation() (which is supposed to send it back to wherever it was orig placed in the CK), nope. I tried it with the 'isFullLOD' checked, nope (it usually isn't checked). All the same errors and the same failed results.

I agree that it's because the 3D not loading, but I think THAT'S because the cell it's in is no longer parented/attached... hence the errors' ambiguity.

[EDIT: I'd rather just stick with moving the static underground with Player... to keep it in a parented cell/3D loaded. I just wanted to minimize all the moving parts during an intense script - maybe I'll only tell it to move every couple of iterations; that'll probably be a LITTLE better. PlaceAtMe that many times sounds like a saveGame data nightmare unless done with rocket surgery...]

yeah i suppose. placeatme would be easily controllable, in theory but we all know how papyrus loves to go on strike during crunch time. all it takes is one lunch break too long to throw a wrench in the placeatme system to throw it off sync and cause a "dupe bug"

otherwise, the carrot-on-a-stick method would at least be better than moving it in real time

Do you guys think these ideas you're talking about would work to move a player and the horse he's riding from Tamriel to an interior cell?

(Just a thought....carry on

Fragginborn: Moving Player should work no problem.. I actually do that in a separate script in my ship mod. I wanted to use an activator instead of a door object, to better prevent others from following you into the 'safe-home'. I haven't checked into it too far to see if this causes problems upon return, but I doubt it does. I didn't see any in my early testing, but it wasn't something that concerned me at the time (certain objects not having their 3D loaded).

As for the Horse... I'm not sure. I think I tried to move mannequins into another interior when I was working on them in another mod, but I seem to remember it didn't work well. Since mannequins are actors just like horses (only a different shape and animations/etc), my initial guess would be no. I'll try it when I do some work on this stuff later today or tomorrow.

Amethyst: I dunno why but I thought you meant using placeAtMe inside the onUpdate loop.. which would be ludicrous. NOW I realize that you probably meant only doing one at the end of the script (when the static would be moved back into place/visibility. That would work, and I'd be comfortable doing it except it would require a more code in the onActivate event... to search the vicinity for a certain baseObject's reference (since it would be dynamic). I'm not familiar enough with that kind of thing yet to try.

I anticipate this issue not being one after I switch to an alias-driven system. From what I understand, this uses markers then spawns instances of Forms (not unlike placeAtMe), which can be deleted much easier than the above brute-force method. I just wanted to get the formulas and timing of the script down, and iron out the control issues, before incorporating something I know close to nothing about. I think I'm pretty close to that point now, so hopefully I'll have a solution soon.

I found some more out about scripting, the CK, and whatnot. I'll post it to the other thread about impact of performance.

While I need to test this some more, it seems attaching the script to a ref (actor, static, activator.. doesn't matter), then having that script call the movement functions will work; BUT that ref has to be moveto'd the unparented/unattached cell FIRST. I assume since the script is still running, that ref causes the new cell to attach.. allowing other items to follow; and since Player is still in the original cell - it remains attached as well.

I discovered this by looking at my own damn mannequin scripting. I worked on that like a month or more ago, so didn't really remember I had used it successfully. Now that I'm about to update that mod (spodum), I noticed this little trick... but as I said, I want to test this more to say if it definitely works or not. If it does, I would only have to moveto my 'reset lever' to wherever my boat is, moveto those ship pieces back to the dock, then moveto the lever back again. Hopefully this will work, I'll let ya's know... I'm sure at least SOMEONE is interested in doing this kind of thing besides me.

definitely let me know if it works.

i'm working on a "hot air ballon" type sky-ride (non controllable) and could definitely use this info

Weeellll... good news and bad news.

Good news: I got it to work. Refs with a script running can be anywhere you want them to be without causing errors; even non-parented/unattached cells. BUUUUUT...
Bad news: Moving the ref with a running script doesn't actually attach/parent that cell... to "get it to work" you have to moveto Player to whatever location (which attaches that cell of course), move your other stuff anywhere you want, then moveto Player back to wherever again. If there are a lot of commands to be had while Player is away, like me having over a dozen objects which need moving, you need a wait() in there before moveto'ing back or they don't all finish before Player leaves the cell again..

For what I want it to do, this is just fine.... it would only be needed if User completed effed up the boat by driving into the ground or some mountainside (and not know how to use tcl to get it back out). Really just a convenience/courtesy, as there already is a fast-trav mapMarker which follows the boat anywhere. I still think converting to an alias-based system, and creating/deleting the objects as-needed would be best though. The time may have finally arrived that I can dodge learning that stuff no longer.

Something peculiar I took away from this though... it's strange that some commands seem to take more time than others, and also seem to "sub-stack". If Player is moved out-of-cell AFTER the commands for moving everything else, why do some of them not move (and caused no3D errors again) unless Player is delayed? I actually use the translateTo for my statics (moveto doesn't work on them for whatever reason); moveto is only used on collision boxes, actors, and activators.

Is it possible that translateTo uses some kind of controller or module that can only be executed so many times at once? (or whatever the programmer jargon for this kind of thing would be) ..as opposed to other commands which seem to happen instantly. TransTo and moveto both use objectReference as a 'base' script... so it isn't THAT. I dunno. I DO know that if an identical translateTo is called on two different objects, sending them both from the same point to another point (at the same speed/etc), and it's done on consecutive lines of code in the script - only THREE lines will have semi-synched movement... This is to say that of five items moving, the first item will be visibly ahead of item four and even further from item five. 'Stacking' more than three transTo doesn't work unless the discrepency is somehow compensated for in the movement formula.