AttachRef broken for MovableStatics ?

[niston]

this one does not use platformhelperfree (or any other vanilla elevator thing) at all.

 

the problem is such: https://i.imgur.com/GwTkwXk.png

 

the yellow thing to the right is the "motor". The cart is attached to it, and as such, the motor should be located on the cart's side (cart and Motor being on the same Z level).

 

When the cell is unloaded/reloaded for the first time (and only then), the cart (and everything else that's refattached to the motor) inexplicably gets reset to it's editor location - as shown in the picture.

s***'s still refattached tho, so when the motor moves, the rest moves as well, but now with an offset. Which is not a good thing.

 

Meanwhile, the motor always ends up staying in the position it was on unload (which, on the linked picture, is the floor with the open door) - as it is to be expected.

[SKKmods]

Take a look at the institute helix elevator which has 3 levels in the institute concourse cell. The activator button stalk DN136_ElevatorButton 001a8d03 inside the capsule is separate, placed, and somehow attached so it stays in the right place as the elevator moves and when the cell loads and unloads.

 

When I was rewriting that worldspace a couple of years ago I could not figure out how the button moved with the capsule (so I cheated with 3 fixed position activators which enabled/disabled at the elevator stops)

[niston]

You mean this? https://i.imgur.com/qLxb980.png

[DiodeLadder]

this one does not use platformhelperfree (or any other vanilla elevator thing) at all.

 

the problem is such: https://i.imgur.com/GwTkwXk.png

 

the yellow thing to the right is the "motor". The cart is attached to it, and as such, the motor should be located on the cart's side (cart and Motor being on the same Z level).

 

When the cell is unloaded/reloaded for the first time (and only then), the cart (and everything else that's refattached to the motor) inexplicably gets reset to it's editor location - as shown in the picture.

s***'s still refattached tho, so when the motor moves, the rest moves as well, but now with an offset. Which is not a good thing.

 

Meanwhile, the motor always ends up staying in the position it was on unload (which, on the linked picture, is the floor with the open door) - as it is to be expected.

 

That's strange. I am, for example, doing movable targets here in my shooting range (starting at 2:00 or so) :

 

https://youtu.be/cl6a3Bha9OA?t=122

 

...and things persisting in the last position at the time of the cell getting unloaded always works for me. The hanger (meat hanger = movable static created from an SCOL) is attached to a dummy activator, and I am using translatetoref on this dummy activator to move it to 3 target positions. 3 target positions are marked with xmarkerheadings, and those are the refs used by translatetoref as destinations. (The dummy is a rotatehelperfree. Attaching objects to a "helper" makes their collision to be intact while translating automatically. No set motion type stuff needed in the script.)

 

In this particular case, I was using a single object attached to the dummy helper, but I have attached a whole bunch of stuff to the dummy in some other cases (not using custom nif at all), and I haven't seen issues with them keeping last positions before cells unloading, either. Admittedly, whatever I do would always be more simple than your projects :laugh:, but if there's an issue with the positions of attached refs persisting as you say, I think I should be seeing the same problem you are having even in my cases.

 

By the way, using a "helper" to translate objects like this would not actually require "movable" static, because regular static objects would work as they are. My meat hanger can be a regular static/SCOL and would function fine, but it was already made that way because of experiments I did to get there.

 

I can't tell why you are having such a problem, though. I wonder why the problem only happens once, and the position would persist just fine afterwards? That makes no sense. :ohmy:

[niston]

I think it's an obscure bug in the engine's handling of refattached MovableStatics:

 

- Changed the cart to be a Static instead of a MovableStatic. Cart got no longer moved to editor location.

- New problem became apparent: The buttons on the panel inside the cart would "vanish".

- Turns out buttons wouldn't really vanish but get spawned totally off-location

- Guess what, the button panel is a MovableStatic

- Changed the code to not respawn buttons on each cell load

 

Problem solved.

 

*shrug*

 

Might try changing the panel to a Static as well, just for the lulz.

[DiodeLadder]

Maybe we need to establish what *actually* needs to be movable static...? In the vanilla game :

 

1) Constantly animated objects (steam, waterfall, dust particles, sparks, fans, console panels with blinking lights)

2) Destructible environment objects with "before", "in progress", and "after" states (Sandbags, fire extinguishers, destructible fans, cars)

3) Statics with interactive physics (skeletons, body parts, hanging fluorescent light fixtures)

 

...those are all types I can think of. To be honest I haven't really given a thought to this subject before, but I don't think any platforms or other stuff that getting translated in game actually are movable statics.

[niston]

It seems to me that refattached things better not be movablestatics. If you want to TranslateTo, it's gotta be a movablestatic tho, or it will teleport instead of translate (had this problem with the gates of the forest grove water lock). Some models also additionally require motion type set to keyframed, tho that can be changed in the NIF header.

 

For reference, most (all?) moving platforms in vanilla game use the platformhelper instead of TranslateTo.

[SKKmods]

+ Objects that need scripts attached (but don't want to be activators).

[niston]

If you can't get by adding the script to the reference directly, yes.

[DiodeLadder]

It seems to me that refattached things better not be movablestatics. If you want to TranslateTo, it's gotta be a movablestatic tho, or it will teleport instead of translate (had this problem with the gates of the forest grove water lock). Some models also additionally require motion type set to keyframed, tho that can be changed in the NIF header.

 

As I have said before, if you use the translate to on the helper activator dummy acting as a host for attaching refs to, there's no need to mess around with the set motion types or making movable static. This method is very straight forward, and the attached objects always behave like they would in their natural states while the dummy host is translated.