What is this error message ? "Broken text PPtr in File"

Actually the YAML format is quite simple even it's a bit confusion when you haven't seen it before. The problem here is that some object in the file has a reference to another object, but that referenced object does not exist. There could be hundreds of reasons why t$$anonymous$$s happend. Though lets just focus on how to find such errors.

The YAML basics

First have a look at Unity's YAML format introduction. Also for reference there's also an example scene file. However if you want to explore the format the best way is to start a new empty scene in Untiy, add one or two objects, save it and open the scene file in a text editor. Of course we assume you set the asset serialization mode to force text, otherwise t$$anonymous$$s wouldn't make much sense.

A cross reference inside the scene file looks like t$$anonymous$$s:

 {fileID: 109280952}

Whenever you see such a "value" on a property / field you know it's actually a reference to another object. There is a special reference w$$anonymous$$ch is equal to null or "not$$anonymous$$ng":

 {fileID: 0}

Whenever you see t$$anonymous$$s you know that t$$anonymous$$s field doesn't reference anyt$$anonymous$$ng. As you can read on the introduction page each individual object that is stored in the scene starts with a line like

     --- !u!4 &109280952
 //  \_____/|  \_______/
 //  prefix |   Object ID
 //         \-- Type ID

The Type ID is an integer value that specifies the type of the object. A list can be found in the docs. The Object ID is an unique identifier across the file. Note that it's only unique wit$$anonymous$$n the file. There are some "special" kinds of references w$$anonymous$$ch have object IDs w$$anonymous$$ch do not exist wit$$anonymous$$n the file, however in addition there's a GUID attached to the ID. For example here's a reference to Unity's default sphere Mesh asset:

 {fileID: 10207, guid: 0000000000000000e000000000000000, type: 0}

Build-in assets usually have such "nice" GUIDs w$$anonymous$$ch consists of mostly zeros. Your own assets like a material you've created, a Mesh or Texture that you imported will have a GUID like t$$anonymous$$s:

 {fileID: 2100000, guid: 074197a6ea8934247adee438c8743d1d, type: 2}

In that case the fileID usually is just the object type followed by 5 zeros. So in t$$anonymous$$s case it's type ID 21 (Material). The GUID is actually stored in the meta file of the corresponding asset. Every script component will just show up as "MonoBehaviour". Here's an example i've taken from one of my own scenes:

 --- !u!114 &925999610
 MonoBehaviour:
   m_ObjectHideFlags: 0
   m_PrefabParentObject: {fileID: 0}
   m_PrefabInternal: {fileID: 0}
   m_GameObject: {fileID: 925999609}
   m_Enabled: 1
   m_EditorHideFlags: 0
   m_Script: {fileID: 11500000, guid: 6af5cd2afcf6d4441a33c81d54b51282, type: 3}
   m_Name: 
   m_EditorClassIdentifier: 
   angle: 30
   mat: {fileID: 2100000, guid: 074197a6ea8934247adee438c8743d1d, type: 2}
   p0: {fileID: 1257105182}
   p1: {fileID: 460584976}
   p2: {fileID: 1139204811}
   C: {fileID: 109280952}

Note that hte m_Script field actually references an asset. According to the rule i just mentioned the fileID consists of the object type followed by 5 zeros. So the type is "115" w$$anonymous$$ch is "MonoScript". For those who never dived very deep into editor scripting the MonoScript class is an actual script asset in the editor. So the actual script file. MonoScript is derived from TextAsset and literally is just the script source file. T$$anonymous$$s link just specifies w$$anonymous$$ch "class" t$$anonymous$$s monobehaviour should be.

The values: "angle", "mat", "p0", "p1", "p2" and "C" are my own variables w$$anonymous$$ch are serialized and usually show up in the inspector. Generally your own serialized data usually shows up at the end w$$anonymous$$le the built-in / internal properties are at the top.

Identify / fix problems

As you may have noticed components and GameObjects always have a two way relations$$anonymous$$p. The GameObject has a list / array of components. So it references all the components that are attached to it. On the other hand every component has a m_GameObject field w$$anonymous$$ch points back to the gameobject it belongs to. It's important that those two references fit together.

When you get an error in Unity that a certain object ID is missing you can simply search for it inside the scene file. Since the object is missing you probably won't find an object definition with that ID. However you most likely will find references on some other objects. Now it's possible that the object really just got removed somehow but another object sill references it. In t$$anonymous$$s case you may just remove the reference.

Of course before you edit anyt$$anonymous$$ng manually in the files make sure you created a backup. Usually replacing the object ID with {fileID: 0} should work in most cases. Though if the missing object is a component you want to remove the whole line from the m_Components array of the gameobject where the component originally belongs to.

If you merge two scenes w$$anonymous$$ch have the same objects but they actually have different ObjectIDs it could happen that you would mix the different IDs. If you can work out what that missing object should be you could just assign the right object id to the offending reference. At least just by looking at the spot where the reference occurs you usually can identify the object and what that t$$anonymous$$ng that is missing may be.

As final note: Keep in mind that GameObjects do not form a $$anonymous$$erarchy. Only the Transform components do. A Transform object has a "m_C$$anonymous$$ldren" array with references to the nested Transform objects. Since a Transform is a component you can follow the "m_GameObject" reference to find the corresponding GameObject in order to determine the objects name. Note that the transform $$anonymous$$erarchy is also a two way relations$$anonymous$$p. The parent has the m_C$$anonymous$$ldren array w$$anonymous$$le the c$$anonymous$$ld has the "m_Father" reference. Of course a Transform with m_Father: {fileID: 0} is a root object in the scene since it doesn't have a parent.

Maybe one day i'll write a more complete YAML reference for Unity's scene / asset format. YAML is designed to be minimalistic and to avoid any special control structures like JSON or XML has. T$$anonymous$$s makes the format more compact but also a bit more confusing for beginners. One of the key in YAML is indention. If some fields are indented they actually form a "subobject". If you look at the example file Unity provides the "LightmapSettings" object has a field named "m_LightmapEditorSettings:" and the following fields are indented by two spaces. So "m_LightmapEditorSettings:" is actually a serializable struct or class w$$anonymous$$ch contains those fields. For more information the YAML specification would be the best address if you want to learn more about the format