Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Feedback Format of Included PDBs

Discussion in '2020.1 Beta' started by TheZombieKiller, Mar 27, 2020.

  1. TheZombieKiller


    Feb 8, 2013
    I would like to preface this by saying that this is an incredibly niche request for an incredibly unsupported scenario, however its resolution would be invaluable for several projects I am prototyping.

    At some point in the Unity 5.x life cycle, the included PDB files began to lack structure and enumeration information. The last version I was able to track down with a full PDB was 5.6.7f1, and it only included a full PDB for the standalone player (the data attached to the installer contained two PDBs with the same file name, one of which was a full PDB that could be manually extracted).

    In some of the aforementioned prototypes, I make use of some internal C++ APIs in the engine (such as the type tree, which can otherwise be accessed through the SerializedObject API, albeit with restrictions) to create asset bundles at runtime for the purpose of modding (this enables me to, for example, load a .ttf/.otf as a Font object at runtime now, rather than waiting for such a feature to land in the engine proper, if at all). The PDB is incredibly useful for this, as I can obtain addresses of functions regardless of the version and whether the code is in the editor or the player (provided the PDBs are present).

    Lacking a PDB with structure & enumeration information complicates this process, as I can no longer generate C# structures that I can guarantee will be compatible with the internal APIs I'm accessing (at present I have mostly extrapolated changes from the last full PDB).

    I would like to inquire as to whether the trimming down of information within the PDB files was intentional, or perhaps the unintentional result of a compiler toolchain change. If unintentional, would it be possible for the engine to be compiled with full PDBs being generated again in the future?
  2. Tautvydas-Zilys


    Unity Technologies

    Jul 25, 2013
    That was intentional. It reduced our installer sizes by 60-80%.
  3. TheZombieKiller


    Feb 8, 2013
    Would it be possible for full PDBs to be provided separately from the main installer? Perhaps as an optional component through Unity Hub?
  4. Hyp-X


    Jun 24, 2015
    Oh, my god the amount of hack people try to (have to) do to make modding work in Unity is incredible.
    We tried this with our previous project, I don't want to touch this ever again.

    I could talk for hours just about our experience about loading AssetBundles in edit mode (because you don't want to distribute the source assets to modders)
  5. Peter77


    QA Jesus

    Jun 12, 2013
    I would be interested to hear/learn some "Creating a moddable game with Unity" stories. The stage is yours.
    Hyp-X likes this.
  6. Hyp-X


    Jun 24, 2015
    Well this was in Unity 5.5 so there were no assembly definitions yet.
    We didn't want to include our C# source code and our source assets.

    So we had to put our code in a .dll.
    But when you have a reference to a MonoBehaviour or a ScriptableObject the reference guid is the guid of the .cs file.
    If you use a dll the reference is the guid of the dll and a fileid is a checksum of the class name.
    Thankfully someone already reverse engineered the checksum generator so we found that part on the net.
    We still had to convert all the references in all our assets to point to the dll's which IIRC was a multi stage conversion process.
    Thinking about it assembly definitions won't help you much here, because you still have to jump tru the same hoops when you replace your assembly definition with the compiled dll...

    Next thing is that you want to be able to use assets in the mod tool, without shipping them in source form.
    So you load them from AssetBundles in edit mode. This works until you want to reference your assets in the scene you are building. References to assets loaded from bundles cannot persist when the scene is serialized. So we had to build
    proxy assets for all our assets that we want to use in the mod tool. These assets shipped outside of bundles and contain a reference to the real asset and load them from the AssetBundles.
    Which sounds simple until you run into Unity issues...
    Say you want to load the assets in OnEnable (as most editor scripts do)
    Well when you EXIT play mode this is what happens:
    - Unity calls OnDisable on your play mode scene objects and destroys the scene
    - Builds the editor scene calling OnValidate, Awake...
    - Unity calls OnEnable on all the scene objects
    - Then Unity nukes all AssetBundles currently loaded along with all the assets loaded from them.
    I see this pattern in Unity with other systems as well, not just AssetBundles.
    So we tried to load assets in delayedCalls... (Which I now know that is not 100% reliable either.)

    So at this point you can make a scene in your mod tool.
    But how will the game load this scene?
    You have to build an AssetBundle.
    But this AssetBundle cannot reference the game's AssetBundles because Unity (unlike all the other engines I ever worked with) specifically engineered AssetBundles so you cannot build them one-by-one, only all at once.
    Proxy objects help at this stage too, those will be in your mod AssetBundle (pulled in as references)

    At some point we considered C# scripting in mods, but getting this far was a nightmare already so we just gave that up.

    It was some years ago so I'm pretty sure I'm missing details here.
    If you have a specific question I might be able to answer it.
    Peter77 likes this.