CWHISME

# 前言 这是以前制作人还在的时候，发起的一个 Demo，不过由于没有最终定性，因此只是让我在空余时间搞一搞。 游戏背景之类这里就不做介绍了。 这个 Demo 主要实现有： 利用腾讯地图 SDK 结合，实现定位 + 地图手动移动功能: TencentLocationSdk (定位) TencentMapSdk (地图) WebService API (路径信息) 同时整合了汉室复兴的战斗系统逻辑层，并修改为实时操纵移动、战斗，嵌入新的表现层 一套简单的 UI 管理 (由于只是 Demo，因此并未采用平移汉室复兴的 UI 框架，自己实现了一个以栈结构为基础的简单 UI 管理结构) #...

# 前言 注：该问题可能仅适用于项目，或者公司该项目衍生版本 (该是没有了) 在给对面出了新包之后，由于我方测试都只有低端机，连刘海都没有，因此没有测出该问题。 后续由运营同步过来，显示效果如下： 描述的服务器问题可以忽略，那个是因为后台没开外网测试服导致。 然后我就看了下以前上一个项目组出给对面的白包效果： 这旧版本的刘海更大了！所以还是感觉新版如果把刘海也渲染进去，表现效果会更好一点，稍微查了一下，就得知刘海没有被渲染的原因是因为出包工程 Unity2018.4.36 这个版本没勾 『Render outside safe area』选项导致的，于是勾上重新出包。 #...

# 前言 之前不是有写过 『关于汉室复兴升级 Unity2021 的问题记录』 这文章么，当时是为了将项目越南版本从 Unity2017 升级为 Unity2021。 主要考虑有三点： 越南版本拖了一年多不止，新版可以拉开与其它版本差异，除此之外增加了一些越南特有优化，没准有助于提审 越南还未上线，先行升级可以先看相关兼容性 Hybridclr 若可以使用，只要提审成功一次，就可以像纯 xlua 项目一样更新，有助于运营 越南还未上线，升级 Unity2021...

# 前言 之前听到运营那边报我们游戏可能会出现崩溃问题，主要是韩服，三星机器。 于是拿了日志来看，主要信息如下： 2022-07-07 14:58:35.666 10105-11685/? E/Unity: Using memoryadresses from more that 16GB of memory (Filename: Line: 120) 2022-07-07 14:58:36.069 10105-11685/? E/CRASH: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr...

# 一、UGUI # 超链接 已解决，超链接点击返回剔除富文本信息 详细可见另一篇文档：处理 Unity2019 的 UGUI 顶点数据更新后的图文混排问题 # 图文混排 已解决，计算表情绘制下标时剔除表情标签、剔除富文本信息 详细可见另一篇文档：处理 Unity2019 的 UGUI 顶点数据更新后的图文混排问题 # 竖行排版 由于 Unity 本身提供的 UILineInfo 包含了换行符信息、而顶点数据并不包括导致。 已解决，自行通过『\n』 分割文本，并剔除富文本信息再作计算。 详细可见另一篇文档：处理 Unity2019 的 UGUI 顶点数据更新后的图文混排问题 #...

# 前言 最近在思考如何客观对大家的 BUG 率 和 Reopen 率 的评分问题，本来公司有个统计平台的，但是那个统计平台只会统计大单，小的 BUG、任务根本没记录的，而且关于 “最近一周” 之类的信息的时间条件也没啥统计来支持，于是想到利用 JIRA 来统计。 众所周知，在我们的 JIRA 中，我们经常会用到一个问题过滤器，以统计当前任务信息： 但是自带的问题统计比较简单，基本上只支持选择一个自定义的过滤器，以及部分固定的字段设置： 效果如下： 统计类型都是固定的，你选择了哪个类型，在问题统计中，就会以某个类型为准将过滤器中满足条件的任务进行排列。 例如展示当前前台所有的 BUG...

# 前言 Huatuo 是前一阵子就听说过的新的热更框架，其原理基于对 Unity il2cpp 的扩展。可以使我们目前直接打包出来的 纯 "AOT Runtime" 变成 "AOT+Interpreter" 混合 Runtime. 官方即自称为 划时代 的热更新框架，更详细的原理解释可以直接参考官方文档，这里可以简单概括两点让人感觉比较厉害的： 不像 XLua、ILruntime 等由于采用 VM 执行热更代码，导致需要事先做好各种处理，Huatuo 借助 il2cpp 及自己的一套指令集直接解释执行。因此可以随意调用...

# 前言 前文提到过，想要修改一个进程内指定内存地址的数据，首先得取得『基址』。 个人感觉，『基址』可以看做一个应用在内存中某个值的『锚点』，取得锚点之后，只要该应用没有进行大的更新，无论如何更换设备、系统，其地址都能直接通过计算『确定』。 反之若没有基址，采用手动方法获取了某个值的地址，可能关闭应用再打开就没效果了。 最找出来的这个锚点，一般是某个 exe 、或者 dll 结尾的模块名，在 CE 中一般表现为绿色。 根据目前了解，通过 CE 找锚点的方式，主要有两种： 人工搜索，通过找指向地址值的指针，再找指向指针的指针.......

# 前言 之前不是提到最近在玩一个游戏《无限世界》—— 其实是十几年前的游戏了。 然后里面有个副本有比较好的奖励，然后需要花费大量时间去进行操作、跑路，非常累。 另外之前实现的 AHK 自动战斗，在设置不同分辨率后也有写问题，毕竟识图的方式实现逻辑，比较受外部因素影响，于是想找找其它提升精确度和便捷性的方式。 经过观察， 发现这个游戏的移动方式，应当是采用前端本地移动，服务器转发实现。 这样，如果可以修改到本地的移动数据，那么岂不是就可以实现瞬移之类的了？ 于是就研究了几天，其它先不论，本文主要说说，在取得对应数据基址之后，使用 C# 改写值的方式。 # 简介 这里虽说是使用...

# 前言 似乎好久没写东西了，之前一是在公司忙起来了，还有就是感觉 Github 国内变得越来越难用，经常网都连不上的，作为托管 Git 的博客，点个提交十几次都不一定能成功，修改起来也变得实在麻烦。 最近在玩一个游戏，玩起来非常『费手』，于是后面就在找有没有减轻操作的方法，查到了 AHK，然后自己鼓捣起来了。 开始是简单地不断让它自动按键，后面看文档看到 PixelGetColor ，查了用法之后，就加上了更复杂的操作逻辑。 而在这之间，家里的显示器的杂牌 2K，公司电脑显示器是 1080P，取色函数取值出现了差异，一边能够工作一边不行。 于是找寻解决方式。 # 问题 首先，感觉 AHK...