Talk:OnCellAttach - ObjectReference
Meaning of AttachedEdit
I'm not sure what the concept of "Attached" means in this context. --Gr3y 09:34, 9 February 2012 (EST)
- The only "behavior" I can isolate pertaining specifically to this "attach" term, is that the event gets triggered every time the player enters the cell from another cell, unlike the OnLoad event which happens only once in a while (whenever the cell needs to be loaded into memory). Now, is this "attachment" different from the other event OnAttachedToCell (triggered when an object is attached to an attached cell)? What constitutes an "attachment" is also an unknown for me : the 3D (what about a trigger box objects, or roombounds, or cell attachment itself which could contain nothing)? Havok? Both? Something else like some bunch of pointers, or some allowed "action area" available for the engine to process?...? --HawkFest (talk) 2013-07-04T17:35:39 (EDT)
- "Attached" means the cell is part of the block of currently "live" cells that connect outward in all directions from the player's current cell (e.g. no load doors between them). This is primarily based on the uGridsToLoad setting, which defaults to 5, meaning that in the wilderness, the 5x5 square of cells centered on the player (25 in total) will all be "attached"--they are full generated, loaded, animating, filled with NPCs, etc; acting like a "normal" cell that the player might be in, for all intensive purposes. As the player moves forward one cell, the 5 cells in the furthest row behind them would be "detached" while the 5 cells in the row in front of them would become "attached".
The game loads 3D data for cells before they become attached, and also retains 3D data for some cells that have been detached; the amount is unpredictable though and depends on virtual memory, the movement path of the player, etc, etc.
In interior spaces or other places where load doors are present, the cells behind the load doors will not be considered "attached" until they are actually entered. However, it may be important to point out that cells behind load doors can be loaded, even though they are not considered attached. (thanks to Inki over at the Beth forums for much of this info, which I have subsequently tested myself: see the thread here) --Egocarib (talk) 2013-09-07T14:49:27 (EDT)
- "Attached" means the cell is part of the block of currently "live" cells that connect outward in all directions from the player's current cell (e.g. no load doors between them). This is primarily based on the uGridsToLoad setting, which defaults to 5, meaning that in the wilderness, the 5x5 square of cells centered on the player (25 in total) will all be "attached"--they are full generated, loaded, animating, filled with NPCs, etc; acting like a "normal" cell that the player might be in, for all intensive purposes. As the player moves forward one cell, the 5 cells in the furthest row behind them would be "detached" while the 5 cells in the row in front of them would become "attached".
This cannot be the total answer. In tests on the main road South from Solitude, I get OnCellAttach walking out from Solitude (goes live) to the edge of Dragonbridge and back again. There was no OnCellDetach, so the cell never stopped being "live". They are not 5 cells apart.
Also, I instrumented OnCellLoad, and OnCellAttach is very reliably called before OnCellLoad. But OnCellLoad isn't always called, so the cell must remain loaded. I had to add a wait loop for 3d to be loaded. So the game doesn't load 3d before it is attached! --DayDreamer (talk) 2013-09-23T18:51:33 (EDT)
Thanks for the helpful testing DayDreamer. The fact that OnCellAttach fires before OnCellLoad is especially useful to know. Can you clarify what you meant about the OnCellDetach() issue, though? I'm not sure I understood that - if the cells you were testing were not 5 cells apart, it would seem normal for them to stay attached an not trigger an OnCellDetach event. Also, I found the added warning on the page "This event may be called multiple times without any intervening OnCellDetach - ObjectReference" to be confusing - I don't think it's true that OnCellAttached could be called multiple times on an object before OnCellDetach is called. You are talking about a single object with that event in its script, right? I tried testing but couldnt make an object fire an OnCellAttach() event while it was still attached (before OnCellDetach() fired). Maybe that's not what you meant exactly? Egocarib 2013-11-11T11:31:18 (EST)
- I have arrived from the future to explain what I know about this event. I set up some engine-level tests (i.e. hooking directly into the event subsystem that Papyrus relies on, rather than going through Papyrus itself) to basically log every single attach/detach event regardless of whether any Papyrus scripts actually existed on the references involved. Testing indicates that the event fires per ObjectReference, and that it fires when the ObjectReference's parent cell attaches (with the detach event behaving similarly). The event does not fire as a result of an object changing cells. Internally, the only data that is sent through the event subsystem (and therefore the only data that Papyrus could ever act on) is the ObjectReference itself and a bool indicating whether it's an attach event or a detach event.
- I don't know the exact testing methodology that DayDreamer used, and after seven years, I doubt they know either. If they had placed a script on a single object, and if that object had traveled with them as they moved around, then it never would have been inside of a cell at the time that that cell detached, and so OnCellDetach never would've fired. DavidJCobb (talk) 2020-07-24T22:44:57 (EDT)
- On that OnCellDetach bit - It will still fire and at the same time as OnAttachedToCell, if both the reference and the player move to the same cell. I've tested that scenario multiple times now and I get the same result each time. Here's my analysis: https://www.creationkit.com/index.php?title=Cell_Attachment_Analysis