niston

F4MS Factory was written to do this. There is a demo mod showing how to use it.

Can confirm what LarannKiar said about the WorkshopObjectBuilt event. I will add that it might not work properly if the cell you build in is not tagged for workshop location. Re WS+: WS+ keeps objectreference arrays around for the undo, forcing things to become persistent. Imho, the feature creates way more problems than it solves. For example, Actor Values on an object are lost after store/undo - The code to recover them AVs simply does not work. This means that an object that was removed from the game world and then placed back via UNDO will often not work properly. If you must absolutely, positively use it, set the UNDO feature to exclude powered objects at least, as forcing persistency on powered objects has many unintended side effects. As such, the UNDO feature is probably the reason for a whole bunch of very weird bug reports. There is another feature "Keep Workshop Objects Persistent" or whatever, which will also force persistency, even on powered objects. Turn this feature OFF unless you play on console.

It's the texture smear bug and I hate this particular bug very much. It apparently is caused by an obscure fault in the game engine's MipMap handling, and it only triggers if there is lots of geometry to render on screen - like, going downtown with disabled precombines for example. If you remove MipMaps from all your DDS texture files, the bug will go away, as South8028 (IIRC) found out. But I can not recommended to remove the mipmaps. Another way to get rid of it is to precombine geometry, but that's not possible for stuff built in workshop.

Trivial scripts using vanilla functions only: Very low probability of being affected, except for maybe Beth introducing new bugs (which is a possibility that probably cannot be discounted entirely). Complex scripts using vanilla functions only: Low probability of being affected. Potential problems could be 1) subtle and undocumented changes in behavior of certain aspects of the engine, 2) unintended side effects of fixes and changes made or 3 ) newly introduced bugs. Scripts using F4SE provided functions: Guaranteed to be affected by the immediate unavailability of a F4SE update. Will probably work fine after (possibly multiple) F4SE updates, Caveats above do apply. Scripts using F4SE Plugin provided functions: Guaranteed to be affected by the immediate unavailability of a F4SE update AND of a F4SE Plugin update. May possibly continue to work fine after both F4SE and all F4SE Plugins used have received sufficient updates. Caveats still apply. If a script uses many functions from a Script Extender Plugin (SUP F4SE, Lighthouse, Garden of Eden and others) , and if the Plugin in question provides 200, 300 or more functions to Papyrus (some do), it might take a bit of a while before everything works as it did pre update. The new EXE will have to be reverse engineered, before Plugin authors can update offsets and possibly refactor or rewrite some code, before mod authors can have working stuff again and update their scripts where it may be required. I can assure you that most of my mods will break hard, because my scripts make really extensive use of some Script Extender Plugins and there is not even a remote grasp of hope of getting those scripts to work without all the Script Extender and Plugin magic being perfectly in place. The RE folks really are the unsung heroes in all this madness. None of this Script Extender business would be possible without them good folks. Don't forget to say thanks should you ever meet one of 'em, some day.

Huh, anyone can post to F4MS comments afaik? IIRC, the skill calculator script needs to be attached to a miscobject (I used a synth component) and the property on the script can then be set to that miscobject. Creating new instances of a script/class is not really straight forward in Papyrus, hence the complication. That said, the base implementation of the skill calculator totally sucks as it was just meant as a cheap example, and you'd definitely need to extend the script (create a derived class) to write your own, better suited version. F4MS was the very first mod I uploaded. I'd do a whole bunch of things different, esp. with regards to the player mining scripts, if I'd (re)write it today. Truth is, I never finished that mining mod I initially made the scripts for and sort of lost interest in them, as the only things I consistently found use for in F4MS are the scheduler and the menu system. Also nobody except Zorkaz showed any interest in using F4MS, literally for years. The NPC mining/factory scripts work fine, but I'd recommend not using the power connector supplicant. It's not broken, but also does not use the optimal approach for placing the connector. Someone else asked me about the mining mod a while ago, and if making mods wouldn't take the insanely stupid amounts of time it actually does, I'd probably finish that mod by redoing it from scratch, including the scripts. However, if you need specific support, you can find me on the collective modding discord. I have a channel there, nistonmakemod. Replies may take a while as IRL keeps me quite busy these days.

This is great!

Max interior cell dimensions are -32767 to 32768 on every axis.

I suggest converting one of the downtown towers into a SCOL for testing? The big downside of all this precombining business (SCOL Generator and Precombiner use same code and suffer from the same inability of dealing with full precision meshes) is the loss of modability, ofc. If Beth had made Trinity Tower a single object instead of insisting on their worldbuilding kit approach, I would not be able to "easily" repair and/or modify it without any 3d modelling skills and tools. Otoh, their choice of occlusion culling tech (Umbra) cannot efficiently operate on large collections of small objects, hence the precombines.

Re texture smear bug: 1) Turn off previs and precombines system wide, through fallout ini file. 2) Go to the library downtown and look towards trinity tower, panning and tilting the camera a bit - you'll notice it looks like this. 3) Travel on foot to Goodneighbor - You'll notice it numerous times more (until you CTD, see below). 4) It also happens when u go to Bunker Hill and look towards the Boston skyline. 5) Another spot is in the parking lot behind Diamond City, looking towards the towers or the stadium 6) Yet another spot is in Lexington at the Mystic Pines location, looking towards the corvega plant. 7) It's mostly dependent on viewing angle, with the bug vanishing and reappearing as you pan and tilt the camera around. If you're adventurous (highly NOT recommended): * Reprocess all your textures to contain NO mipmaps * Retry the above steps and notice the bug is gone Re havok CTDs: Ever had the Basketball or some other random vanilla physics object being listed in a Buffout crashlog near the top of the stack? And when you remove the object in question from the cell, another random object causes a CTD? It happens all the time in downtown, when precombines are disabled for the entire game. Pretty sure in both cases the issues are caused by data corruption from engine bugs that become apparent only when there is a sufficiently large number of references in the scenery. In case of havok, the corruption causes a CTD. In case of the textures, the corruption causes wrong parts of the wrong textures being selected and getting drawn in a wrong way with a wrong mipmap level onto wrong geometry. As precombining reduces the amount of references (probably quite drastically in some cases), the faults are masked by the previsibines system and Beth therefore didn't give any f*#@s about saw no immediate commercial incentive to fix them. But perhaps both issues could be rectified with some f4se dll black magic.

One of the issues is, Beth used previsibines not only to paper over shortcuts in worldbuilding but also to mask away bugs in the engine. 2 examples: - Havok object CTD in very densely populated areas - Texture smear bug in very densely populated areas So if u turn precomb/previs off, these hidden but lingering issues are then going to become problems again. I also suspect this strategy of tryna sweep tech debt under the rug has come back to bite Beth in the ass more than once already.

Sounds like they're ragdolling. Try this: https://falloutck.uesp.net/wiki/ForceRemoveRagdollFromWorld_-_ObjectReference

Uh... U got some settlers-turned-synths sabotaging ur operation and destroying your equipment. Power grid issues do not cause equipment to break and needing repair. But if all ur generators get sabotaged by synth infiltrators, u obviously wont have power.

Why clear the roombounds/portals tho? Set them up properly instead, and they'll work fine.

Sounds like Scrap Crash, tbh. I've also seen such CTD happen after building a CWSS shower station in Sanctuary. The reason there was a specific texture with invalid dimensions (2000x2000 IIRC).

Texture block compression is only tangentially related to BGS Creation Engine: In case of BC7*, it is supported by Direct3D 11, which is a subsystem of DirectX 11 and relies on implementation in Direct3D Feature Level 11.0 compatible GPU hardware**. Creation Engine then "merely" uses Direct3D for rendering. *BC1-3 otoh were supported already by D3D 9. Later, D3D 10 added BC4/BC5. **Yes, there is -and must be, for performance reasons- hardware support for texture block compression: Texture block compression works by clustering Texels into 4x4 blocks (hence block compression) and compressing these blocks individually, reducing the effective bit count needed to (approximately) represent every Texel block while still allowing random access to individual blocks. It was initially designed by S3 company as S3TC, to reduce VRAM needs of "large" (by 1999ish standards) textures. As a consequence of this requirement, block compressed texture is loaded into VRAM with block compression still applied. It is only decompressed by GPU itself, at the block level and on the fly, as needed. This is in stark contrast to BA2 compression, which is always decompressed entirely by the CPU when loading texture or other file from compressed archive on disk.