Jump to content


Unofficial Patch Project
  • Content Count

  • Joined

  • Last visited

1 Follower

About Sclerocephalus

  • Rank
  • Birthday 12/29/1965

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

2167 profile views
  1. Sclerocephalus


    And then it turned out that this bollard is in a pre-comb .... sigh
  2. Sclerocephalus


    Someobody placed a traffic pole inside of this pod - with the result that the protectron never stayed in, even if it was unconscious.
  3. Sclerocephalus

    Diamond City

    Well, you could make an Open Ciities mod.
  4. (1) There is no function to toggle persistence from a script. If an object is unexpectedly persistent, this might be because it is still linked to other objects (or other objects being linked to it). Workshop objects that require an actor are linked from that actor (this link is deleted on unload and restored on load). All crops are linked from their damage helpers but this link is permanent; it is not cleared until the crop is deleted. It also could be that the offending object is in a script property. All crops, for example, keep the reference of their damage helper in a script property and they also have an array on WorkshopObjectScript to keep the references of their furniture markers. (2) Deleted objects are not actually removed until their parent cell unloads. Up to that point, they're only "marked for deletion" (that's why scripts should disable them before they delete them, so they are at least invisible until they are actually deleted). Thus, in order to make sure that you don't look at bogus objects, you should allow the workshop to unload and reload before you start inspecting objects. Better though if you allow it to unload and reload twice because the householding functions that start running when a workshop loads do a lot of cleanup stuff that may result in even more objects being removed when it unloads subsequently.
  5. Sclerocephalus

    [Fallout 4] Known Engine Bugs

    Update: I'm pretty much convinced now that this iis not an F4SE issue. You might want to have a look at this ticket which we fixed almost two yeras ago: https://afktrack.iguanadons.net/index.php?a=issues&i=20640 In this case, an actor array that should actually have been initialized by the OnLoad() event was mysteriously 'none'. At that time, I had no F4SE running (and it did probably not even exist). I also did not spend any time to investigate why the array was none Just added a sanity check and a line to re-initialize the array if necessary, and that did fix it.
  6. Sclerocephalus

    Feedback thread

    In the "Files for Fixes" section, you have to upload a new version first. Only then, there will be delete options for individual files.
  7. A condition check was on the wrong line. Update is on the way.
  8. Good to know. Thanks for the clarification.
  9. Settlement mods may interfere with the new update because WorkshopParentScript got a massive update. Though, it all depends on whether a mod makes modifications to that script (in that case, it will require an update) and how substantial they are. Good mods won't touch the vanilla scripts and try to work around them wherever possible.
  10. Ninja'ed. Please check my edit to the previous post.
  11. That's an as yet overlooked vanilla bug ! If you send an actor to another workshop, or if a new settler is created for a workshop, the workshop scripts run the TryToAutoAssignActor() function on him. This function auto assigns the actor to food or safety (depending on whether he's a guard or a normal settler), by setting a property on his WorkshopNPCScript, and then assigns him to all unassigned objects of that type that already exist at that workshop. If there are no unassigned resource objects, it won't do anything, and also clears the porperty on his WorkshopNPCScript again. The scripts check for brahmins before they call that function, but they forgot to check for Dogmeat. To unassign him, you only have to assign the objects that are currently assigned to him to somebody else. EDIT: there also may be something else wrong, but not on the scripts: Do you, by chance, have a mod installed that removes the LocTypeWorkshopSettlement from some or all workshop locations ? Asking this for a reason: around two years ago, I downloaded a mod that removed the enemy level lock on locations (i.e. made it so the level won't get stuck at the level of your first visit to a location) and then found out that this mod removed that keyword from all workshop locations. Reported this to the mod author but I don't know whether it was ever fixed. Removing that keyword has detrimental effects on the workshops because the workshop scripts check for it and some operations will not run as intended if it's missing. This would in fact explain why TryToAutoAssignActor() runs on Sanctuary while you are at Red Rocket when it actually shouldn't.
  12. Sclerocephalus

    SSE light sources casting no shadows

    There is a very useful lighting tutorial on TESAlliance: http://tesalliance.org/forums/index.php?/topic/6843-ck-basics-lesson-4/
  13. Sclerocephalus

    SSE light sources casting no shadows

    There also is another limit in that no object may be lit by more than x light sources at the same time (where x = 4, as far as I remember). Place more and you will get strange glitches.
  14. Sclerocephalus

    [Fallout 4] Known Engine Bugs

    Good point. Test run was indeed with F4SE installed. If this is really an F4SE issue, they should fix it as soon as possible.

Support us on Patreon!