niston

Bool Function WaitForHavokInit(ObjectReference refWaitFor, Int waitLimit = 30) If (refWaitFor == none || refWaitFor.GetFormID() == 0 || !refWaitFor.IsBoundGameObjectAvailable() || refWaitFor.IsDisabled() || refWaitFor.IsDeleted()) Return False EndIf Float weight = refWaitFor.GetWeight() While ((weight == 0.0) && (waitLimit > 0)) Utility.Wait(0.1) waitLimit -= 1 weight = refWaitFor.GetWeight() EndWhile Return (weight > 0.0) EndFunction Might be useful then

I usually set weight to 5 on my static collisions as I've seen stuff moving on its own in-game, when it's set to zero.

What I can tell with absolute certainity about this is, uGridsToLoad=7 fixes the electrical problems one can experience on Spectacle Island. My speculation is that the ugrids number is straight line in each direction, but centered on the player. Makes sense, because then you'd always need odd numbers. If this is the case, ugrids=5 should have the game load 25 cells, while 7 would make that 49 cells, and so on.

Interesting; Especially re rain blocking glass.

Well, the issue with settlers is that they are not normally persistent. If an actor is not persistent and leaves the loaded area, teh actor will unload. Unloaded actors will not be able to be resolved by reflinks. So if workshop update (or reset, I keep forgetting which) runs, the workshop is loaded but the actor is unloaded, that will cause all kinds of trouble such as the actor vanishing from the workshop. Obviously, this is not a problem for non-settler NPCs in this context.

How'd the player assign settlers to the beds outside? And how did you solve the unloaded location problem?

Pra is working on an AutoDoc I think

Sending settlers from an exterior to work or sleep in a non-settlement interior is impossible. Or... is it? https://www.nexusmods.com/fallout4/images/262512 https://www.nexusmods.com/fallout4/images/261232 https://www.nexusmods.com/fallout4/images/261871

Eff me... It was a version management problem, plain and simple. Classic PEBKAC. D-oh!

I have a script A on an objectreference in an exterior cell. And a workshop in an interior cell. Script A has an objectreference property auto const, which is filled in CK to point to said workshop. The workshop has MustPersist keyword and it is listed in the cell's Persistent section in xEdit / record has Persistent flag. So the workshop is persistent for multiple reasons (has persistent flag, has mustpersist keyword, is in a script property). Accordingly, I can prid the workshop in console from the exterior, and the dppi command confirms the workshop is persistent. Yet, when I am not inside the interior and try to access the objectreference property on Script A... it doesn't point to the workshop, but is none instead. How is such a thing even possible? Huge WTF moment.

Very neat! Thanks a lot South8028!

Thanks. Yes and yes.

Excellent! Thank you so much! May I request two more anims, for simple idles? 1) scale actor to 0.001 (make actor invisible) 2) scale actor to 1 (make actor visible) FInally, are you OK with me using and distributing these anims as part of F4MS?

Thank you! I am building anim info and testing in game now. Tests were mostly successful! Character can still be observed shrinking/growing, but other then that it works perfect. Thank you again South8028. Is it difficult to create a variant? where the character moves to +256 instead of 128.

Yes, 3 anims - good idea! The vanilla door open anim is Meshes\Actors\Character\Animations\MT\Neutral\DoorOpen.hkx Vanilla door open anim (was used as entry animation) is not looped I think. Im not sure if kziitd's idle was looped. Their custom exit anim wasn't. The actual furniture I am going to use this with, is an invisible marker furniture. So if the enter anim plays at 0,0,0 that is perfect. For clarity: There will be no actual door that opens. The character should just vanish (move forward and scale to 0.001) once the open door anim has played. Open door anim should more appropriately be called "push door handle" anim, btw )) So, entry anim: Actor pushes door handle, then vanishes into forward position, scale 0.001 Idle anim: Actor is invisible. Exit anim: Actor scales back to 1 and returns to 0,0,0 position.

Forget I said anything about timers. CallFunctionNoWait() will work as well.

EventTicker() calls TickSender() which calls EventTicker() which calls TickSender() which... ..nets you a stack overflow sooner than later. Even more so, as Papyrus is very bad at recursion due to it's shallow stack depth. But this outcome can be completely avoided by raising an event or using a timer (that raises an event), to invoke one of the calls. Because doing so will let the current thread end, while running the call on a new thread. The upside is, you already have an event you can use: SendTick.

Yep. I see. Can you import existing anims? Perhaps the entry animation should be a modified version of the door opening anim, where after the last existing frame the movement and some more frames later the scaling is added. Then the idle would simply do nothing, or just keep scale at 0.001. And the exit scales and moves back.

The goal is to make it appear as if actor opens a door and then vanishes, when it actually enters the furniture. When it exits the furniture, it shall reappear, just as if it had emerged from a door. I use the vanilla door open animation as entry anim. For idle animation, the actor starts at 0,0,0 in standing position, and should instantly zap to forward position (+128 units). then scale to 0.001. When idle gets played multiple times by engine, actor will probably move back to 0,0,0 and zap to +128 again. But it should not matter because its scale is 0.001 and it can't even be seen. For exit animation, actor scale shall return to 1 and zap back to standing at 0,0,0 position. then exit animation ends. By zapping I mean instantly, with no visible walking or anything.

Kziitd made some anims for me, and in our testing we found that scaling is well possible. Especially, scaling to 0 in 1 Frame was instant and the actor completely vanishes. The issue with that was however that the actor gets kind of locked at scale 0. Sometimes, moving them brings them back to 1, but I found that only disable/enable does so reliably. So we instead scaled to 0.001 in 1 Frame and that works. However, the scaling process is clearly observable with 0.001 (you can see the actor shrink or grow back), even though its just one Frame. Also, scaling and moving at the same time seems to confuse the absolute heck out of the engine: The actor just stays in place and kind of shrinks and tries to grow at the same time. It looks very funny. I was looking for furniture anims (idle/exit) that move an actor to +128 in x axis and scale it to 0.001 (idle anim), respectively scale it back to 1 and move it back to 0 on x axis (exit anim). The movement must be instant and scaling should be instant, but can be sequenced. ie: movement first, then scale / scale, then move. Was wondering if you could give it a try?

South8028 welcome back :smile: Can you find a way to scale actor to zero in animation, and then scale them back to 1 in another anim? It seems that once scale has been set to zero, the only reliable way to get the actor back is to disable/enable it.

When a "Marker Keyword" is set for an interact point, only actors with that keyword on them can interact with that particular interact point. But anyway. You can create/remove/adjust interact points. They'll use the furniture animation. Where the actual entry point then is, depends on the position of the interact point, and the animation. Like, if you char did a forward somersault and moves +128 units in X direction during the furniture enter animation, the entry point would be at interact point -128 units on the X axis. I guess CK generates all the data needed for this when you generate animation information (a whole bunch of random looking text files) after adding stuff to a subgraph. The marker model is only visual help afaik. There are no nodes in the NIF involved in this whole process. The "P-WS-Connect" is not a node, but a connect point (CPA extradata, if Im not mistaken now). The workshop system uses them for placement and snapping. "P-WS-Snap" is another one.

Utility.Wait(0.5)

Also, there's this: https://www.nexusmods.com/fallout76/mods/1487 Works with FO4, too.

The "yellow marker" placement in CK depends on 1) "interact point(s)" on the furniture and 2) the animations used. You can add/remove "interact points" in CK. This will determine where the furniture enter animation ends, ie where a NPC will sit/stand/etc once they have entered the furniture. The animation entry point to each interact point then depends on the furniture enter animation. Furniture animations usually have at least 3 hkx associated: EnterFromStand.hkx - The animation to enter the furniture from stand. PoseA_Idle1.hkx - The furniture animation idle, such as sitting, praying, whatever. ExitToStand.hkx - Animation to exit furniture to stand. The association of these is done via human subgraph. You can use additive subgraphs to add more furniture anims to the human subgraph. This video will be helpful: https://www.youtube.com/watch?v=NgjkbMfD2G0