标签归档:Unity3D Editor

如何搞定 UnityEngine.UI.dll is in timestamps but is not known in guidmapper… 错误

在使用 Unity 开发的过程中,不知道什么情况下就会碰到这么两个错误(根据平台和使用的 Unity 版本不同,路径可能不一样,我这边列出的也不是完整的路径):

UnityExtensions/Unity/GUISystem/4.6.9/UnityEngine.UI.dll is in timestamps but is not known in guidmapper…

UnityExtensions/Unity/GUISystem/4.6.9/Editor/UnityEditor.UI.dll is in timestamps but is not known in guidmapper…

有的人建议是直接把我们的 Project 目录下的 Library 目录直接删除掉,不过这样一来,重新再次打开 Unity Editor 的时候,整个工程的资源都需要重新导入,而且通常我们还是在移动平台模式下进行开发,也就是等它把资源导入进来之后,我们还需要做一次 Switch Platform 的操作,真的好慢好慢好慢啊(也许可以通过 Asset Cache Server 来提速,但是我没有用过,所以不敢乱说)。

那么我们有什么办法呢,这里介绍一个比较好的方法,总共分三步:

  1. 进入出错的两个 dll 文件所在目录中,将出错的两个 dll 文件重命名为任意文件名,例如:UnityEngine.UI.dll.backup 和 UnityEditor.UI.dll.backup;
  2. 重启 Unity Editor,等整个工程加载结束之后,我们会看到很多红色的错误日志输出,甭理它就好了,关闭 Unity Editor;
  3. 回到那两个 dll 文件所在的目录,将刚刚重命名的两个 dll 文件分别修改回来,UnityEngine.UI.dll 和 UnityEditor.UI.dll,然后再次启动 Unity Editor,接下来就是见证奇迹的时刻了。

好了,就是这么简单。

使用脚本在 Unity3D Editor 中完全删除 Prefab 中的 ParticleSystem 组件

今天碰到一个小问题需要通过脚本来批量将我们工程中的所有例子特效 Prefab 根节点的粒子发射器给干掉,那么好吧,开始动手吧。

执行一下,发现 ParticleSystem 组件确实木有了,但是留了一个小尾巴,就是我们在 Unity3D Editor 中查看被处理的 Prefab 时,还能在 Inspector 中看到一个 Shader 的小尾巴,如图:

default_particle_shader_tail

这个让我情何以堪啊,你知道的,我有轻微强迫症的,虽然貌似并不会影响程序的功能,但是我要是不知道原因,我岂不是很不爽,好吧,那么就对比一下手动将 ParticleSystem 组件 Remove 和通过我们这个脚本 Destroy 之后的 Prefab 文件之间究竟有甚么区别呢,这个时候就需要借助一下 Unity3D 提供的 binary2text 命令行工具了,Mac OSX 上这个命令还在这个位置 [Unity3D 安装目录]/Unity.app/Contents/Tools/binary2text,通常就是 /Applications/Unity/Unity.app/Contents/Tools/binary2text。使用这个工具将两个 Prefab 文件转成 Text 文件之后我们就可以使用文件对比工具来进行对比了(对比二进制神马的,真的让人很蛋疼啊,幸好 Unity3D 还提供了这么个鬼啊),对比就会发现,这个 Shader 是因为啥而存在的了。

compare_1 compare_2

左侧有红色文本显示的是通过脚本 Destroy ParticleSystem 组件之后生成的 Prefab 的 Text 文件,右侧的是手动通过右键 Remove Component 删除 ParticleSystem 组件之后生成的 Prefab 的 Text 文件,对比之下我们能发现左侧文件中说明了一些问题:

  • 第一处红色文本表示多了一个内部资源的引用,看起来很像是 Shader;
  • 第二处红色文本更是直接说明了问题,左侧表示有两个组件,组件的 Id 是 19935810,刚好与第三处红色文本描述对应;
  • 第三处红色文本描述的是一个 ParticleSystemRender 组件的信息。

这么一看就知道原来还有一个隐藏的 ParticleSystemRender 组件没有被移除掉,因为这个 Render 是依附于 ParticleSystem 才存在的,所以不会在 Inspector 中单独显示,而是作为 ParticleSystem 的子组件 Render 进行显示的。那么我们就再修改一下我们的代码就好了。

也就是需要独立地将这个 ParticleSystemRender 组件也给 DestroyImmediate 一下就好了。搞定,洗洗睡了。

如何在 Unity3D Editor 脚本中使用 Coroutine 进行异步操作

今天在做编辑器中一个功能时,碰到一个这样的需求,Unity3D Editor 脚本中会通过 System.Diagnostics.Process 这个类来调用外部的系统命令来执行一个操作,其实就是调用系统的 Python 命令执行一个 Python 脚本,来将 Excel 文件转换成文本数据。

但是这样执行完 ImportExcel 菜单项之后,可能会出现我们通过外部的脚本修改了 Unity3D 需要使用到的文本文件,但是 Unity3D 未能及时更新 AssetDatabase,导致 Unity3D 中读取到的文本文件还是执行 ImportConfig 菜单项之前的数据。那么我们能否直接在这个外部程序执行完毕的回调中执行 AssetDatabase.Refresh() 方法呢?不行,因为这些函数都只能在主线程里头调用,而这个回调函数是在启动外部程序的线程中执行的,所以在 ConvertProcessExited() 方法中访问 AssetDatabase 对象会抛出异常。这个时候我们可以通过 EditorApplication 的 update 委托来配合 Coroutine 机制来完成我们想要的功能。

关于 EditorApplication 如何支持 Coroutine,这个是在 GitHub 上找到了一个很棒的参考,地址在 这儿 ,链接页面中是一个完整的独立的 EditorCoroutine 的实现,借助于这个漂亮的工具,我们修改了代码,然后就能达成我们的需求了,在执行完外部转化的 Python 程序之后,及时通过 AssetDatabase 刷新 Unity3D 中需要使用到的文本文件,代码如下: