Welcome to the AFK Mods bug tracker. In order to report an issue, you need to have a VALIDATED account to post one. Once you have followed the link the registration email sent you, please select a project from the drop down menu below. Select “Open New Issue” and fill out the form with as many details as possible.

Please also consider sending your bug report to Bethesda if you are reporting on an issue with Skyrim Special Edition, Fallout 4, or Starfield. Doing so will help everyone on all platforms.

Issue Data
Status: Closed
Issue Type: Bug Report
Project: Unofficial Fallout 4 Patch
Component: Fallout 4: Vanilla
Category: Papyrus
Assigned To: Sclerocephalus
Platform: All
Severity: Low
Votes: 0
Watching: N/A
Opened By Sclerocephalus on Mar 25, 2017 1:45 pm
Last Edited By Sclerocephalus on May 18, 2018 11:16 am
Closed By Sclerocephalus on May 18, 2018 9:55 pm
Resolution: Fixed
Comment: Fixed for UFO4P 2.0.4

Issue #22216: TrapBarnacle - Cannot delete a None object

 
[03/20/2017 - 01:39:13PM] error: Cannot delete a None object
stack:
[None].ObjectReference.Delete() - "<native>" Line ?
[ (0304ACBF)].TrapBarnacle.inactive.OnTimer() - "g:\_F4\Art\Raw\ScriptsMilestone\TrapBarnacle.psc" Line ?
[03/20/2017 - 01:39:50PM] error: Cannot delete a None object
stack:
[None].ObjectReference.Delete() - "<native>" Line ?
[ (0304ACC0)].TrapBarnacle.inactive.OnTimer() - "g:\_F4\Art\Raw\ScriptsMilestone\TrapBarnacle.psc" Line ?


Basically the same issue as with TrapThistle. MyHazard is a gas cloud that is placed in-game and gets probably deleted by the engine as soon as it fades off.

Related Issues: 34044  

Comments

1 comment(s) [Closed]
Sclerocephalus said:
 
Have logged the activity of this one for quite some while now. The sanity check immediately before the hazard is deleted does not always succeed, i.e. in some cases, the hazard has been deleted already (in those cases, there will be no error thrown however, because the script skips the delete call).

In all cases where the reference was not 'none' at this point, it suddenly was 'none when the script tried to delete it on the next line, i.e. the ref repeatably turned into a none immediately afer the sanity check. It's just as if the check would "remind" the engine to have a look at it to check whether it should be deleted, or - which is more likely - whoever conceived this timer event knew how long the engine would keep the hazard alive before deleting it.

To put this short, the engine does a very good job at forcibly deleting any hazard objects, soe there's actually no need to keep the delete call in the script that only spills errors most of the time. The same fix has been applied earlier to TrapThistle.

Showing Comments 1 - 1 of 1