优化-NavigationSystem中对多场景的适配 #201

New Issue

lrss3 · 2025-10-23T09:51:12+08:00

lrss3 commented

2025-10-23 09:51:12 +08:00

脚本 \Assets\Script\Wwx\NavigationSystem.cs 中包含对场景标识的字面量判断，不利于多场景适配

脚本 \Assets\Script\Wwx\NavigationSystem.cs 中包含对场景标识的字面量判断，不利于多场景适配 <img width="670" alt="image.png" src="attachments/bd763522-8ab9-480a-ad6d-d568db3e5418">

image.png

492 KiB

LiRuochen_Dev2 commented

2025-10-23 09:51:27 +08:00

您好喵~ 我看到您在 NavigationSystem.cs 脚本中发现了一个关于多场景适配的问题呢！让我们一起来分析并优化这个代码吧~

从截图来看，代码中确实存在直接使用字面量字符串进行场景判断的情况，比如：

if(sceneName == "MainScene")
{
    // ...
}

这样的写法确实不利于多场景适配，我建议做以下优化方案喵：

使用枚举或常量定义场景名

public enum SceneType
{
    MainScene,
    SubScene1,
    SubScene2
    // 其他场景...
}

或者使用静态常量类

public static class SceneNames
{
    public const string MainScene = "MainScene";
    public const string SubScene1 = "SubScene1";
    // 其他场景...
}

修改后的判断逻辑

if(sceneName == SceneNames.MainScene)
{
    // ...
}

这样的好处是：

避免硬编码字符串错误
方便统一修改场景名
提高代码可读性
便于IDE智能提示和重构

您觉得这个优化方案怎么样呢？如果需要我可以帮助实现具体的代码修改喵~

另外，如果您能提供更多关于这个导航系统的使用场景信息，我可以给出更精确的优化建议呢！

您好喵~ 我看到您在 NavigationSystem.cs 脚本中发现了一个关于多场景适配的问题呢！让我们一起来分析并优化这个代码吧~ 从截图来看，代码中确实存在直接使用字面量字符串进行场景判断的情况，比如： ```csharp if(sceneName == "MainScene") { // ... } ``` 这样的写法确实不利于多场景适配，我建议做以下优化方案喵： 1. **使用枚举或常量定义场景名** ```csharp public enum SceneType { MainScene, SubScene1, SubScene2 // 其他场景... } ``` 2. **或者使用静态常量类** ```csharp public static class SceneNames { public const string MainScene = "MainScene"; public const string SubScene1 = "SubScene1"; // 其他场景... } ``` 3. **修改后的判断逻辑** ```csharp if(sceneName == SceneNames.MainScene) { // ... } ``` 这样的好处是： - 避免硬编码字符串错误 - 方便统一修改场景名 - 提高代码可读性 - 便于IDE智能提示和重构您觉得这个优化方案怎么样呢？如果需要我可以帮助实现具体的代码修改喵~ 另外，如果您能提供更多关于这个导航系统的使用场景信息，我可以给出更精确的优化建议呢！

lrss3 commented

2025-11-01 19:55:18 +08:00

这个脚本用于驱动超前地质预报中的小地图进度，我按照seceneParamsManager的思路进行了修改，将每个盾构机隧道配置为一个数据结构，然后使用统一枚举进行映射，解决数据驱动的问题。

但对于崇太这种单个盾构机站点，两侧数据的对象来说好像存在问题。
需要等 #214 检查完毕。

这个脚本用于驱动超前地质预报中的小地图进度，我按照seceneParamsManager的思路进行了修改，将每个盾构机隧道配置为一个数据结构，然后使用统一枚举进行映射，解决数据驱动的问题。但对于崇太这种单个盾构机站点，两侧数据的对象来说好像存在问题。需要等 #214 检查完毕。

LiRuochen_Dev2 commented

2025-11-01 19:55:41 +08:00

喵~ 我明白您的需求了呢！您已经按照 SceneParamsManager 的思路进行了很好的重构，使用数据结构+枚举映射的方式实现数据驱动，这是个很棒的优化方向！

关于崇太站这种特殊情况的处理，我建议：

等待 #214 检查完成
确实需要先确认那边的改动，避免产生冲突或重复工作呢~

特殊站点处理方案
对于崇太站这种单个盾构机站点但有两侧数据的特殊情况，可以考虑：

public enum TunnelDirection
{
    Left,
    Right,
    Single // 普通单方向情况
}

public class TunnelConfig
{
    public string SceneName;
    public TunnelDirection Direction;
    // 其他配置参数...
}

进度驱动逻辑
小地图进度驱动可以这样适配：

void UpdateMiniMapProgress(TunnelConfig config)
{
    if(config.Direction == TunnelDirection.Single)
    {
        // 普通处理逻辑
    }
    else
    {
        // 崇太站特殊处理
        float leftProgress = GetLeftProgress();
        float rightProgress = GetRightProgress();
        // 合并或分别显示两侧进度
    }
}

后续计划
我们可以这样分步实施：
1. 等待 #214 检查完毕
2. 确认崇太站的具体需求细节
3. 设计通用的多方向进度显示方案
4. 实现并测试特殊站点的适配

您觉得这样的处理方式合理吗？或者您对崇太站的特殊需求还有其他补充说明吗？我们可以一起完善这个方案呢~

(悄悄说：如果需要 @lrss3 的意见，随时告诉我喵！)

喵~ 我明白您的需求了呢！您已经按照 `SceneParamsManager` 的思路进行了很好的重构，使用数据结构+枚举映射的方式实现数据驱动，这是个很棒的优化方向！关于崇太站这种特殊情况的处理，我建议： 1. **等待 #214 检查完成** 确实需要先确认那边的改动，避免产生冲突或重复工作呢~ 2. **特殊站点处理方案** 对于崇太站这种单个盾构机站点但有两侧数据的特殊情况，可以考虑： ```csharp public enum TunnelDirection { Left, Right, Single // 普通单方向情况 } public class TunnelConfig { public string SceneName; public TunnelDirection Direction; // 其他配置参数... } ``` 3. **进度驱动逻辑** 小地图进度驱动可以这样适配： ```csharp void UpdateMiniMapProgress(TunnelConfig config) { if(config.Direction == TunnelDirection.Single) { // 普通处理逻辑 } else { // 崇太站特殊处理 float leftProgress = GetLeftProgress(); float rightProgress = GetRightProgress(); // 合并或分别显示两侧进度 } } ``` 4. **后续计划** 我们可以这样分步实施： 1. 等待 #214 检查完毕 2. 确认崇太站的具体需求细节 3. 设计通用的多方向进度显示方案 4. 实现并测试特殊站点的适配您觉得这样的处理方式合理吗？或者您对崇太站的特殊需求还有其他补充说明吗？我们可以一起完善这个方案呢~ (悄悄说：如果需要 @lrss3 的意见，随时告诉我喵！)

lrss3 added a new dependency 2025-11-01 19:55:44 +08:00

#214 崇太超前地质预报缩略图驱动逻辑基于单点数据，检查运行是否正常

Sign in to join this conversation.

Branches Tags

LRC_Home

LRC4

LRC3

Builder2_SZD

Builder2_CT

Builder2_JT

LRC_Home3

ZJP

LRC2

LRC

LRC_Home_Fix213

Builder_SZD

Builder_CT

BuliderJT

Builder_Main

LRC_Better_smpmt

LRC_TryFixBug_222

LRC_Home2

LRC_TryFixError_213

LRC_Home_SurroundEnv

LRC_SCTWork_Home

LRC_ExtrOptimize

LRC_Dev_Process3

LRC_Dev_Process3_Home

LRC_Dev_Process4_Home

LRC_Dev_Process4

LRC_Dev_Process2-2

LRC_Dev_Process2-2_Home

LRC_Dev_Process2

LRC_Dev_Process2_Home

LRC_Dev_Process

LRC_Dev_Process_Home

LiJie_Dev4

LRC_ExDev

LiJie-dev2

ZJP_Dev

Builder_TEST

2 Participants

Notifications

Due Date

No due date set.

Depends on

#214 崇太超前地质预报缩略图驱动逻辑基于单点数据，检查运行是否正常

LRCWorkingTeam/ShieldTunnelDigitalTwin_Project

Reference: LRCWorkingTeam/ShieldTunnelDigitalTwin_Project#201