You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have a reference to an object in Python and the object gets garbage collected in game, then trying to access the object in Python again will sometimes cause crashes.
Here is some example code to cause the crash.
importbl2sdkbl2sdk.LoadPackage("GD_Mercenary_Streaming_SF")
GCObj=bl2sdk.FindObject("SkillDefinition", "GD_Mercenary_Skills.Brawn.Incite")
# Use a hook so we can try reference the object laterdefHookMainMenuInput(caller: bl2sdk.UObject, function: bl2sdk.UFunction, params: bl2sdk.FStruct) ->bool:
ifparams.ukey=="F1":
bl2sdk.Log(str(GCObj))
bl2sdk.Log(str(GCObj.SkillName))
returnTruebl2sdk.RemoveHook("WillowGame.FrontendGFxMovie.SharedHandleInputKey", "GCDemo")
bl2sdk.RegisterHook("WillowGame.FrontendGFxMovie.SharedHandleInputKey", "GCDemo", HookMainMenuInput)
To test this code run it on the main menu, then wait for the next GC cycle and press F1. While waiting you can run getall SkillDefinition Name in console to see what objects are loaded. Once the object has been removed pressing F1 might crash the game. The crash is not consistent, but still relatively common. If the game doesn't crash then it will never crash using that reference (so re-execute the file), and the log file will contain the following.
Note that the hook fires on both key press and release, hence the double logging.
Removing the second log line sometimes gives the following output instead. I have never seen it happen with both log calls, but as the crash is inconsistent anyway it might still happen.
I believe making UObject::GetProperty() and UObject::SetProperty() check if the object has been GCed will probably prevent this, though the inconsistent nature of the crash may mean the issue is hidden deeper somewhere.
On a related note, the SDK doesn't have a good way for mods to check if an object has been GCed. Even if this crash gets fixed, mods that are working with objects that may be GCed will need to know this to prevent themselves from causing exceptions.
The text was updated successfully, but these errors were encountered:
If you have a reference to an object in Python and the object gets garbage collected in game, then trying to access the object in Python again will sometimes cause crashes.
Here is some example code to cause the crash.
To test this code run it on the main menu, then wait for the next GC cycle and press F1. While waiting you can run
getall SkillDefinition Name
in console to see what objects are loaded. Once the object has been removed pressing F1 might crash the game. The crash is not consistent, but still relatively common. If the game doesn't crash then it will never crash using that reference (so re-execute the file), and the log file will contain the following.Note that the hook fires on both key press and release, hence the double logging.
Removing the second log line sometimes gives the following output instead. I have never seen it happen with both log calls, but as the crash is inconsistent anyway it might still happen.
I believe making
UObject::GetProperty()
andUObject::SetProperty()
check if the object has been GCed will probably prevent this, though the inconsistent nature of the crash may mean the issue is hidden deeper somewhere.On a related note, the SDK doesn't have a good way for mods to check if an object has been GCed. Even if this crash gets fixed, mods that are working with objects that may be GCed will need to know this to prevent themselves from causing exceptions.
The text was updated successfully, but these errors were encountered: