Is it possible to conjoin different activators into a single NIF ?

[deadbeeftffn]

It's just to be on the safe side.

 

Actually no, the attachments do not become disconnected on unload, but i experienced it once anyway. Though it seems to happen only for objectes which are snapped to the ceiling. As long as your objects are placed on the ground, you should be safe without the handlers. On the opther hand, i don't notice any problems when the handlers are present and get called.

[niston]

I just stumbled upon this link on my desktop. The information contained is mostly accurate and certainly useful.

Yet, after having invested a lot of time into the particular topic of refattaching in creation engine, I would like to dispense some additional advice.

 

First, Refattaching is broken AF: Literally every aspect of it is bugged in some way or another, on the engine level.

 

The most pressing issue is that the engine quite often fails to restore correct 3d position of movable, refattached objects on (game) load. Affected objects will either revert to their editor location (if placed in CK), or mysteriously get offset from the correct position in random directions. They will however still be refattached, so if the root object to which they are attached to moves about, they will still move with it.

 

The simplest solution to this problem is to delete any refattached objects on unload, and respawn/attach them on load.

At least for objects spawned by script.

 

If this is not possible because the objects were placed/attached in CK, the obvious method of repositioning the refattached objects on load will only work if the object to be repositioned has been disabled. However, Disable/Move/Enable leads to flicker and may cause other, unforeseen headaches related to script onload events. Sadly, you can't use MoveToNode() for repositioning, as it won't work reliably.

 

One would think that a script could instead simply check the 3d coordinates of refattached objects and compare them to expected values, so as to disable/move to coords/reenable them only when needed. However, the engine also fails to even properly report 3d position of refattached objects (result being 0,0,0 or some such useless values), which means a script will not be able to reliably read the 3d coordinates of refattached objects.

 

As you can see, things then get really complicated if you have an object refattached to a movable platform. The most well known manifestation of these problems probably can be found with the vault workshop elevators, where -without a correcting mod- the buttons sometimes "disappear" on load. The reality is that the engine effs up restoring their correct position and places them somewhere else instead.

 

So, in such a situation, whenever you can, respawn the reattached objects on (game) load. And when you can't do that, disable/move/enable.

And if that's not possible either, then you're in for an entire world of hurt, trying to work around these issues. Congrats & enjoy!

 

Next, avoid long refattaching chains. Ideally, refattach everything to the same "root" object. This is especially true for moving platforms.

 

And re moving platforms and TranslateTo(), here's a little nugget:

 

Set the "Use as Platform" flag (or whatever it's called) on the object that is intended to be the platform. But then, do NOT use TranslateTo() on the platform. Doing so would cause janky movement for player in first person mode, as they use the moving platform. Instead, create another object with a REF_ATTACH_NODE in it, which I like to call the "drive object". Refattach the platform to that drive object; The platform will then move with the drive object. Now, use TranslateTo() on the drive object. Resulting in totally butter smooth motion for player standing on the platform.

Caveats due to buggy refattach handling by engine do apply, as outlined above.

 

Avoid saving while the platform is moving. Stop a running TranslateTo() on cell detach, before unload.

 

Finally, to reliably obtain 3d coords of refattached objects without SUP F4SE, you can use a proxy object and PlaceAtNode(): Spawn the proxy on the root node of the refattached object, without refattaching the proxy. Then you can reliably read the 3d coords of the proxy object (which will correspond to the object it has been placed on), and discard the proxy after you're done. The proxy can be invisible of course, it doesn't even need any mesh. An otherwise empty NIF with just a root node (at 0,0,0) and the BSXFlags in it will do. Just be sure you don't forget to Delete() the proxies you create.

 

HTH

[lee3310]

I just stumbled upon this link on my desktop. The information contained is mostly accurate and certainly useful.

Yet, after having invested a lot of time into the particular topic of refattaching in creation engine, I would like to dispense some additional advice.

 

First, Refattaching is broken AF: Literally every aspect of it is bugged in some way or another, on the engine level.

 

The most pressing issue is that the engine quite often fails to restore correct 3d position of movable, refattached objects on (game) load. Affected objects will either revert to their editor location (if placed in CK), or mysteriously get offset from the correct position in random directions. They will however still be refattached, so if the root object to which they are attached to moves about, they will still move with it.

 

The simplest solution to this problem is to delete any refattached objects on unload, and respawn/attach them on load.

At least for objects spawned by script.

 

If this is not possible because the objects were placed/attached in CK, the obvious method of repositioning the refattached objects on load will only work if the object to be repositioned has been disabled. However, Disable/Move/Enable leads to flicker and may cause other, unforeseen headaches related to script onload events. Sadly, you can't use MoveToNode() for repositioning, as it won't work reliably.

 

One would think that a script could instead simply check the 3d coordinates of refattached objects and compare them to expected values, so as to disable/move to coords/reenable them only when needed. However, the engine also fails to even properly report 3d position of refattached objects (result being 0,0,0 or some such useless values), which means a script will not be able to reliably read the 3d coordinates of refattached objects.

 

As you can see, things then get really complicated if you have an object refattached to a movable platform. The most well known manifestation of these problems probably can be found with the vault workshop elevators, where -without a correcting mod- the buttons sometimes "disappear" on load. The reality is that the engine effs up restoring their correct position and places them somewhere else instead.

 

So, in such a situation, whenever you can, respawn the reattached objects on (game) load. And when you can't do that, disable/move/enable.

And if that's not possible either, then you're in for an entire world of hurt, trying to work around these issues. Congrats & enjoy!

 

Next, avoid long refattaching chains. Ideally, refattach everything to the same "root" object. This is especially true for moving platforms.

 

And re moving platforms and TranslateTo(), here's a little nugget:

 

Set the "Use as Platform" flag (or whatever it's called) on the object that is intended to be the platform. But then, do NOT use TranslateTo() on the platform. Doing so would cause janky movement for player in first person mode, as they use the moving platform. Instead, create another object with a REF_ATTACH_NODE in it, which I like to call the "drive object". Refattach the platform to that drive object; The platform will then move with the drive object. Now, use TranslateTo() on the drive object. Resulting in totally butter smooth motion for player standing on the platform.

Caveats due to buggy refattach handling by engine do apply, as outlined above.

 

Avoid saving while the platform is moving. Stop a running TranslateTo() on cell detach, before unload.

 

Finally, to reliably obtain 3d coords of refattached objects without SUP F4SE, you can use a proxy object and PlaceAtNode(): Spawn the proxy on the root node of the refattached object, without refattaching the proxy. Then you can reliably read the 3d coords of the proxy object (which will correspond to the object it has been placed on), and discard the proxy after you're done. The proxy can be invisible of course, it doesn't even need any mesh. An otherwise empty NIF with just a root node (at 0,0,0) and the BSXFlags in it will do. Just be sure you don't forget to Delete() the proxies you create.

 

HTH

Well damn, it's never easy with this game is it.