Closed DarthMDev closed 3 years ago
this is caused by nametags. seems the set_contents() function is creating issues
After my testing, I'm thinking it's actually the get_nametag2d() function specifically. I'm thinking maybe an issue with the destructor behavior or the function generated by interrogate. Edit: I can indeed confirm it occurs in the interrogate function for get_nametag2d() after running tests with Visual Studio. Double edit: The exception seems to be related to a pure virtual function.
And I just discovered it works fine on NPCs. It's only an issue with LocalAvatar instances.
And I just discovered it works fine on NPCs. It's only an issue with LocalAvatar instances.
That would make sense as it works perfectly fine in OpenRTM
Seems to be that for some reason when u initialize it with a LocalAvatar, the Nametag2d gets destructed immediately upon creation and all the other things are just a side effect of it. (Didn't bring it up sooner cuz I thought it was specific to the context when logging into your toon but it happens upon creating any LocalAvatars.)
It is intended that the nametag2d does not exist, only chat bubbles are supposed to exist for localavatars. A side effect of this being removed in servers can be seen in Corporate Clash, where if your character is not visible, you will see your nametag on the margins, which isn't intended
It is intended that the nametag2d does not exist, only chat bubbles are supposed to exist for localavatars. A side effect of this being removed in servers can be seen in Corporate Clash, where if your character is not visible, you will see your nametag on the margins, which isn't intended
Don't think that deletes the nametag. It basically just doesn't show the name by setting the contents flags. It's just one line in LocalAvatar's __init__ that controls that. Not sure when it was removed but I think a bunch of servers are missing that one line.
Edit: Looks like it was removed very early on in TTI.
self.nametag2dNormalContents = Nametag.CSpeech
Tried commenting that out, didnt work. So youre saying it's full on destroying the nametag object? Odd. I haven't looked much into it
Yup you can see it's calling the Nametag2d destructor by setting the notify mode to debug.
Just here confirming @ooowoothevirtualhowler's case that it is indeed of how the code is interrogated and garbage collected by Python.
The majority of the Toontown code has NametagGroup.getNametag2d()
or NameTagGroup.getNametag3d()
calls by themselves without storing them in some sort of variable. So calls like self.nametag.getNametag2d().setContents(self.nametag2dContents & self.nametag2dDist)
from DistributedAvatar
will cause the NametagGroup instance's _nametag2d
to get totally deconstructed, and will crash the program when getNametag2d()
is called expecting the same _nametag2d
instance. Looking at how nametags works in general, I don't think this is supposed to happen, and needs to be fixed. (This doesn't affect just getNametag2d()
, but the exact same issue applies to getNametag3d()
as well.)
Here's a test code I've made which replicates the exact same crash:
from panda3d.core import *
from libotp import *
loadPrcFileData('', 'notify-level-nametag debug')
# Create our own NametagGroup.
nametag = NametagGroup()
# This will just fetches and print out their Nametag2d as normal...
print(nametag.getNametag2d())
# But shortly after that, the NametagGroup's Nametag2d gets deconstructed
# (even though it's not supposed to), so this will just crash.
print(nametag.getNametag2d())
This problem has been fixed by @LittleToonCat as of a006ca4.
Client Gets to initial loading screen then crashes with no traceback This isn't just happening for me too. Got a report from another toontown developer about the same issue.