Jump to content


Unofficial Patch Project
  • Content Count

  • Joined

  • Last visited

Posts posted by Sclerocephalus

  1. Package records, conditions sub-records: there's a "parameter #3" listed by xEdit in each package of condition data (CTDA):

    It appears that this parameter may have different meanings - or may be totally unused - depending on what target the condition has been specified to run. If that target is a quest alias (i.e. the "RunOn"  line will display "QuestAlias"), parameter #3 is always the ID of that alias on the quest that owns the package (I confirmed this myself by playing around with the aliases).

  2. Which ghouls ? The pre-placed DEAD ones or those that you killed (i.e. the bodies of the pre-placed LIVE actors)

    We only handle pre-placed DEAD ones because they are never cleaned up otherwise. Pre-placed LIVE actors are clened up by the engine eventually after they have been killed. Though, in a very fresh game with few actors loaded so far, this may take a while.

    Side note: altering the time scale won't change anything because scripts need real time to process their tasks. This time won't change, so the only thing gained by altering the time scale is a longer game time span for scripts to finish running.

  3. Since we cannot disable refs when there is a risk that this could happen in plain sight of the player, we have to wait until the area unloads. More specifically, until all refs that need to be disabled have unloaded. This process doesn't start running until the player owns the respective workshop. Therefore, it usually takes place the first time the area unloads after the player gained control of the workshop.

    The Sunshine Tidings cleanup missed two ghoul bodies because they are in cells that do not form part of the workshop location, although they're still within the buildable area (Bug #23763). This has been fixed for UFO4P 2.0.4 but that fix was not retroactive (i.e. they won't be disabled unless you start a new game).

  4. I'm currently using NifSkope 2.0 Dev 7.

    Used this to change the user version numbers from Skyrim to FO3 (?), 12/83 -> 11/34., then saved (Note: the file had previously been stripped of the collision, the BSShaderProperty blocks and the BSX flags). Upon trying to reload it, I got this warning:

    [0] Array Properties invalid

    Pos 376: failed to load block number 0 (BSFadeNode) previous block was NiHeader

    Failed to load F:/Skyrim Mod Projects/Nifs for Blender Import/dwermsmcolumnfixed01_raw_01.nif


    Loaded the stripped file in old NifSkope, changed the user version numbers there and saved. This file loads fine (i.e. without that error) in both old NifSkope and NifSkope 2.0.

  5. (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.

  6. 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:


    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.

  7. 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.

  8. Another papyrus bug:

    Zero length arrays of object references turn into none arrays on reload.

    My script is using two types of arrays that may have zero length at any time, namely script arrays (to be more specific: arrays of workhopObjectScript and arrays of workshopNPCScript) and object reference arrays.  After saving, quitting to desktop, restarting the game and reloading, I started to get errors on the log about failures to call functions on none arrays when everything was fine before saving. Debug sessions showed that this happened when one of the object reference arrays had zero length when saving; after reloading, these arrays had mysteriously turned into none arrays. The debug logs also showed however that this did not occur to the script arrays: they are still zero length arrays after reloading if they had zero length when the save was made.

    I have not tested this with any arrays of forms other than scripts and object references yet, so there may be more forms affected than only object references.

    It might also be worth noting that the script stores the affected arrays in variables, not in properties, although this actually shouldn't make a difference (once things are getting buggy though, one never knows for sure what matters and what not ....).

  9. Considering the fact that the crashes appear to be level-dependent, the first thing that comes to mind is a mod-added armor or weapon with a faulty mesh that is distributed through leveled lists and does not appear in the game below level 10.

    It might be worth having a look at the leveled list sections of your armor and weapon mods (there shouldn't be too many as there are still only a few modders that go the way of properly integrating their items in the game) and check what they add at level 10.

  10. There is a way to let a script recognize a null pointer (and to discern it from a 'normal' none ref), but I don't know whether this will be of much help because it will not prevent the error from being thrown:

    if actorRef != none
    	if actorRef.GetLeveledActorBase() != none
    	  (do your stuff here)
    	(everything that needs to be done if actorRef holds a null pointer should be added here)

    First check for a 'none', as usual. The second check is a bogus check, as you probably don't need to know the leveled actor base. You know however that the check will fail with an error if actorRef holds a null pointer. If that happens, the script will skip the entire if branch. Thus, do anything you need to do on a valid ref in that if branch and move everthing you might want to do if the ref has turned invalid ibelow that check.

  11. 4 hours ago, dAb said:

    And no, they are not properties in my script, they are untouched vanilla references.

    But you run stuff on them, so you likely save the actor on which a script instance runs at least in a variable once the effect starts running, so you don't have to re-evaluate the actor ref each time the script needs to run stuff on it. Or is your script entirely event based and you get the actor ref always from akCaster/akTarget that are passed in by the respective event ?

    See, that could be the problem. Magic effectts are forcibly deleted by the engine as soon as they stop running. If whatever is responsible for an event to fire on your script is happening while a magic effect is still active, your magic effect script will receive that event no matter what - but it may fire after the effect has expired, and if that happens, anything passed in by that event is likely invalid.

    If you store the actor in a variable or property once the effect starts running and use that instead of what an event is passing in, you'll always have a valid actor ref to operate on, and things may still be working if the script continues running after the effect has expired.

  12. According to your log, it is NOT none but a "null pointer". Note the ref 0002A309 that is logged with the null pointer (should be the actor's valid ref) ? "True" none items do not have any ref. This is essentially why this reference passes all checks for 'none': because it actually isn't 'none'. In any other respect though, null pointers will behave like nones: trying to call any functions on them will fail with an error.

    There is evidence that null pointers are deliberately used to block script access to a reference (at least temporarily) or to prevent an item from becoming peristent. There are at least two cases documented where references may turn into null pointers and back into valid references at run time:

    • Script properties referencing an exterior cell: that property will turn into a null pointer once the cell detaches, and turn back into a valid ref once it attaches again.
    • Object references stored in a form list: they turn into null pointers if the cell where they are persistent detaches, and turn back into valid refs if that cell re-attaches.

    In your case, the magic effect has ended at the time you try to call stuff on the actor: this is obvious because the magic effect script is running on 'none'. I further assume that the actor you try to run stuff on is stored in a property on that script. That would explain why the property turned into a null pointer (it presumably did so as soon as the effect stopped running).


  13. Well, ash piles are not actors. If an actor is turned into an ash pile, the actor gets disabled and deleted as soon as the visual effect has been displayed, and an ash pile is created and placed instead. Ash piles are just in-game created objects, and those are cleaned up very slowly (if at all).

    Actors are different and always put a higher workload on the engine, because they have an AI (even if they're dead). Creation of new actors may fail in areas that have too many actors. In FO4, for example, the random encounter triggers that are close to settlements will fail to start encounter quests once the population at that workshop goes beyond a certain limit. Most prominent example is the encounter zone below the bridge just southeast of the Starlight Drive-In. If you recompile REScript in debug mode and have papyrus logging enabled, you'll always get a warning message on the log when that area loads.

Support us on Patreon!

  • Create New...