ellanjiang / unitygameframework Goto Github PK

The Git tag format hints it's the version string vyear.month.day (e.g. v2020.07.30), but since a recent update, the version of package.json has been reset to 1.0.0 and no longer updated.

To fix: either sync the version from the Git tag (like before) or sync the version to the Git tag (v1.0.1)

Suggested reading:

• Managing release with CLI https://medium.com/openupm/how-to-maintain-upm-package-part-4-managing-package-release-with-cli-972ff5311163

The issue is detected by OpenUPM build-pipelines: https://openupm.com/packages/com.jiangyin.gameframework/nes: https://openupm.com/packages/com.jiangyin.gameframework/

UnityGameFramework是不是依赖GameFramework？

当前字典解析完成无法注册回调函数，我只能用协程不断测试当前字典是否接包含特定键来判断是否解析完成

protected override void OnEnter(IFsm<IProcedureManager> procedureOwner)
    {
        base.OnEnter(procedureOwner);
        localizationComponent = GameEntry.GetComponent<LocalizationComponent>();

        localizationComponent.LoadDictionary("Localization", TablesIndex.Localization_ZH);
        GameObectReference.Instance.StartCoroutine(CheckLocalization());
    }

    IEnumerator CheckLocalization()
    {
        while (!localizationComponent.HasRawString("1"))
        {
            yield return 0;
        }

       Log.Info(“Compelete！！！”);
    }

ab打包 full 资源采用crc32后缀实现增量更新 会不会有冲突的风险? 冲突后cdn 不能及时追溯新的文件? 能不能提供md5的校验方式?

正常流程：例如文件大小为100, SendWebRequest请求文件数据=>ReceiveData写入接收到的数据=>发送下载成功事件
/// BUG流程：例如文件大小为100，SendWebRequest请求文件数据=>ReceiveData写入接收到的数据=>例如写入到50的时候程序发生堵塞导致进程下载超时=>发送超时失败事件，下载失败=>堵塞恢复后会继续把剩下的50写入到文件，这时候文件写入成功100，正常应该发送事件下载完成，但是由于导致超时重新下载，SendWebRequest请求文件数据，由于本地已经存在了100，断点续传的起始位置为100，但是这时候仍然接收到了ReceiveData的数据，比如这时候收到20，实际文件就会有120比源文件大20.
这种情况是因为设置超时时间太短导致的吗？恳请大佬帮忙解惑，不胜感激。

是否可以改变注册Entity加载相关事件的方式和加载Resource相同

• 当前通过Event组件注册Entity加载相关事件会导致同一时刻加载的无关联的Entity共用一组回调函数
• 使用类似Resource加载可以确保每个Entity的加载回调是独立的
• 使用类似Resource加载无需考虑Entity事件解绑时机

您好，雖然目前可能沒有計畫開放下載並手動import以外的方式，但想告知E大，我嘗試用UnityPackageManager來導入這個專案時發現目前的版號格式"2021.05.31"會導致導入失敗，原因是PackageManager只接受SemVer的版號，而SemVer的版號不支持數字前面補0(意思是"05"造成了這次錯誤)，若之後考慮走PackageManager的話可能需要注意~