UE4工具开发和源码使用的正确姿势是什么？

xiaozongpeng

这个问题下面可能有一些问题，感谢知乎社区。
我是一个UE4初级的工具程序，有一点问题不清楚想请教一下，在做工具的时候有常常因为项目需要会去看一看引擎源码里某些Slate组件的使用，之前为了给工具添加预览窗口我用了EditorViewport，并且为了添加一个交互性，给viewport添加了一个点选Actor和拖拽坐标轴的功能，这两个功能主要就是借鉴LevelEditorViewport的代码，这是引擎使用Slate对工具开发的好处，可定制化高，理论上所有的引擎编辑器代码都能被工具使用，但是他也带来了理解成本高，做起来总需要在引擎里到处查阅的问题，这块非常花时间。
综上所述，我觉得UE的工具开发效率有点低，开发难度较高，不知是不是我姿势不对，欢迎指教。
我在想，有没有一个UE工具开发仓库，通过插件的形式提供案例，当我们想要一些功能的时候就快速的去查阅仓库的案例，比如Unity的这个仓库GitHub - XINCGer/UnityToolchainsTrick: 提供一些UnityEditor工具链开发的常用小技巧与示例(Provides some common tips and examples for developing the UnityEditor toolchain)
但是我又想到开源并不是指开发者有随意修改和使用的权利，这个UE私有库也不能直接就把里面的代码public了，我道听途书说好像编辑器拓展依赖引擎模块就不行？网上UE4插件也很多啊，比如腾讯开源的Unlua的Editor模块也引用了挺多引擎模块（UnrealEd）等等。
所以我想确认一下，使用UE的源码界限是什么？怎样才算侵权？
这里有对应的开发者用户协议，太长不看系列（EULA Reference | Creators | Chinese）
有关开源协议，源码剖析之类的的文章是否也算侵权？
如果有人想开一个仓库来提供引擎工具Slate的功能展示（其实就是更易读的文档），这样的行为是否也涉及侵权？
怎么样才能让UE的工具开发对程序更友好一些？

stonstad

uod18有一篇介绍编辑器开发的教程。涵盖了基本api的使用。
但是如你所说，slate的编辑器扩展有诸多不便。
首先那套operator[]重载的操作就很难受。
为了效率有几条路可以走:
1.不想依赖cpp扩展的话 可以用EditorUtilityBlueprintClass和EditorUtilityWidget,可以在UE端用UMG和蓝图完成工具类扩展。
2.slate对于大量物体的渲染存在性能问题，这就是为什么存放foliage的那个AInstancedFoliage Actor在编辑器是隐藏的，因为如果你选中了 光是detail面板绘制instance transform ui可能就会卡好几分钟。所以不妨用UE自带的pythonscriptplugin插件，它利用了UE自带的反射特性，将UProperty和UFunction都导出到python了，那么所有工具的逻辑完全可以在python完成，对于做打包前cook定制工具,commandlet测试等 都很方便 毕竟是解释执行。
3.同样是利用了UE的反射机制，现在也有不少通过第三方扩展比方说react,vue,或者electron这些web技术完成编辑器开发。至少不会卡主线程。效率还高。内置编辑器这块缺点也很明显 slate加载引用的资源释放时，会跑GC，大项目很卡。有可能崩在某个奇怪角落的蓝图空指针。

kirin77

Unreal从4.26开始支持用Python进行编辑器开发，但这目前还是一个实验性的功能，覆盖面和稳定性都无法保障，所以很长一段时间编辑器开发都免不了和Slate打交道，除了硬生生啃下来别无他法。
Unreal理论上属于源代码公开而不是开源，二次发布应该是不允许的，除此之外不受非公开协议限制的引擎代码都可以自由使用或公开，比如用到自己的项目中，引用到文章里，或者用在开源插件上。受非公开协议限制的代码，比如对应主机平台的部分，仅允许有资格的开发者访问和使用，不得向第三方透露。

xiaozongpeng

虽然不能很权威的解答，但是问题很好，角度也比较高，关注了！