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