当前位置：首页 > news >正文

虚幻引擎TSubclassOf：类型安全的动态类管理核心机制详解

news 2026/8/5 12:57:45

1. 项目概述：为什么TSubclassOf是UE开发者的“瑞士军刀”

在虚幻引擎（UE）的开发日常里，我们经常面临一个经典难题：如何在C++代码中安全、灵活地引用一个蓝图类，并能在运行时动态地创建它？比如，你设计了一个“武器生成器”系统，希望策划或设计师能在编辑器中，通过下拉菜单轻松指定生成“火箭筒”蓝图还是“激光枪”蓝图，而你的C++代码无需知道具体是哪个类，却能稳定地把它实例化出来。直接使用UClass*指针？你很快会陷入类型安全缺失和空指针的泥潭。这时，TSubclassOf模板类就该登场了。

简单说，TSubclassOf是UE类型系统提供的一把“安全锁”和“导航仪”。它本质上是一个模板类，用于存储对特定UClass类型或其派生类的引用。它的核心价值在于编译期类型安全检查和编辑器友好集成。当你声明一个TSubclassOf<AWeapon>变量时，它只能被赋值为AWeapon类或其任何子类（包括蓝图类）的UClass。这从根源上杜绝了将AEnemy的类错误赋值给武器变量的可能，编译器会在你犯错时直接报错。同时，在UE编辑器的属性细节面板中，TSubclassOf属性会自动渲染成一个美观的类选择器下拉框，极大方便了非程序人员的数据配置。

结合网络热词来看，无论是处理“UE Subsystem”中的服务类管理，还是在“UE实现手势识别”时动态切换不同的识别算法类，亦或是管理不同“UE半透明材质”对应的后期处理类，TSubclassOf都是实现动态、可配置类管理的基石。它无缝连接了C++的严谨与蓝图的灵活，是赋能动态类管理与蓝图交互不可或缺的核心工具。

2. TSubclassOf核心机制深度解析

2.1 类型安全：编译时与运行时的双重保障

TSubclassOf的类型安全机制是其最核心的优势，它分别在编译时和运行时两个层面为开发者保驾护航。

在编译时，TSubclassOf是一个模板类，其模板参数T指定了基类。这意味着TSubclassOf<AWeapon>和TSubclassOf<ACharacter>是两种完全不同的类型。如果你尝试将一个TSubclassOf<ACharacter>赋值给一个TSubclassOf<AWeapon>类型的变量，C++编译器会直接抛出类型不匹配的错误。这比使用原始的UClass*指针安全得多，因为UClass*本身不携带基类信息，编译器无法阻止你将一个ACharacter的类引用赋值给一个期望武器类引用的变量，这类错误往往要到运行时崩溃时才会被发现。

在运行时，TSubclassOf内部存储的UClass*指针，在赋值时会进行有效性检查。当你通过UObject的StaticClass()方法或蓝图编辑器赋值时，UE会确保赋值的类确实是模板参数T的派生类。例如：

// 假设有以下类继承关系：AItem <- AWeapon <- ARifle (蓝图) TSubclassOf<AWeapon> WeaponClassToSpawn; // 正确：ARifle是AWeapon的派生类 WeaponClassToSpawn = ARifle::StaticClass(); // 错误：AItem是AWeapon的父类，编译失败 // WeaponClassToSpawn = AItem::StaticClass(); // 错误：ACharacter与AWeapon无关，编译失败 // WeaponClassToSpawn = ACharacter::StaticClass();

这种机制确保了从数据配置到代码执行的整个链路中，类引用的有效性，避免了“张冠李戴”的严重逻辑错误。

2.2 与UClass*的本质区别及选用场景

很多新手会困惑，已经有了UClass*，为什么还需要TSubclassOf？理解它们的区别是正确选用的关键。

UClass*是一个纯粹的运行时类信息指针。它就像一张没有标签的空白名片，你可以写上任何类的信息。它非常灵活，但也非常危险。你可以用LoadClass函数动态加载任何一个类，或者接收一个来自不确定源的UClass*参数。问题在于，你无法在编译时保证这个指针指向的类是你期望的类型。你需要在代码中手动进行Cast检查，这不仅繁琐，而且容易遗漏，导致崩溃。

TSubclassOf<T>则是一张印有“仅限T及其子类”标签的名片。它在UClass*的基础上，增加了编译期的类型约束。它牺牲了一点点灵活性（你不能用它指向一个完全无关的类），换来了巨大的安全性和开发便利性。

选用场景指南：

始终优先使用TSubclassOf：当你在C++中声明一个属性、函数参数或返回值，其目的是为了后续动态创建（Spawn）某个特定基类的对象，或进行类型检查时，应无条件使用TSubclassOf。这是UE社区的最佳实践。
不得已才使用UClass*：只有在处理极度动态、类型完全未知的反射操作时，才考虑使用UClass*。例如，编写一个通用的对象序列化工具，需要处理引擎中所有可能的UObject类。

注意：在函数参数中，如果使用const TSubclassOf<T>&形式，可以避免不必要的拷贝。因为TSubclassOf本身是个小对象，但以引用传递是更清晰的习惯。

2.3 在UE属性系统与编辑器中的集成表现

TSubclassOf的强大不仅体现在代码安全上，更体现在其与虚幻编辑器属性系统的深度集成上。这是实现C++与蓝图高效协作的关键桥梁。

当你在C++类中将一个TSubclassOf变量标记为UPROPERTY，并设置适当的元数据（如EditAnywhere,BlueprintReadWrite）后，魔法就发生了：

UCLASS() class AMyGameMode : public AGameModeBase { GENERATED_BODY() public: UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Classes") TSubclassOf<ACharacter> DefaultPlayerClass; UPROPERTY(EditDefaultsOnly, Category = "Weapons") TSubclassOf<AWeapon> StarterWeaponClass; };

在编辑器中，DefaultPlayerClass和StarterWeaponClass这两个属性不会显示为枯燥的文本输入框，而是会变成带搜索功能的类选择下拉菜单。编辑器会自动扫描项目中所有继承自ACharacter和AWeapon的类（包括原生C++类和所有蓝图类），并将其罗列在菜单中。策划或美术人员可以轻松点击选择，无需手动输入容易出错的类路径字符串。

此外，通过元数据Meta = (AllowAbstract = "false")，你可以限制选择器不能选择抽象类；通过Meta = (BlueprintBaseOnly = "true")，可以限制只显示蓝图类。这些细粒度控制使得数据配置既直观又精准。

3. 动态类管理实战应用

3.1 场景一：可配置的对象生成器（Spawner）

这是TSubclassOf最经典的应用场景。我们构建一个通用的敌人或道具生成器。

// SpawnerActor.h UCLASS() class ASpawnerActor : public AActor { GENERATED_BODY() public: UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Spawning") TSubclassOf<AActor> ActorClassToSpawn; // 配置要生成的Actor类 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Spawning") float SpawnInterval = 5.0f; void BeginPlay() override; void SpawnActor(); private: FTimerHandle SpawnTimerHandle; }; // SpawnerActor.cpp void ASpawnerActor::BeginPlay() { Super::BeginPlay(); // 验证类是否已配置且有效 if (ActorClassToSpawn) { GetWorldTimerManager().SetTimer(SpawnTimerHandle, this, &ASpawnerActor::SpawnActor, SpawnInterval, true); } else { UE_LOG(LogTemp, Warning, TEXT("Spawner %s has no ActorClassToSpawn set!"), *GetName()); } } void ASpawnerActor::SpawnActor() { if (!ActorClassToSpawn) return; FActorSpawnParameters SpawnParams; SpawnParams.SpawnCollisionHandlingOverride = ESpawnActorCollisionHandlingMethod::AdjustIfPossibleButDontSpawnIfColliding; FVector SpawnLocation = GetActorLocation() + FVector(0, 0, 50); FRotator SpawnRotation = GetActorRotation(); AActor* SpawnedActor = GetWorld()->SpawnActor<AActor>(ActorClassToSpawn, SpawnLocation, SpawnRotation, SpawnParams); if (SpawnedActor) { UE_LOG(LogTemp, Log, TEXT("Spawned actor: %s"), *SpawnedActor->GetName()); } }

在这个例子中，ActorClassToSpawn可以在编辑器中配置为任何AActor的派生类。同一段代码，通过配置不同的TSubclassOf，就能生成敌人、宝箱、特效载体等任何Actor，实现了极高的复用性和灵活性。

实操心得：

空值检查至关重要：在使用TSubclassOf变量进行SpawnActor或NewObject之前，务必检查其是否有效（if (MyClass)）。编辑器配置可能为空，直接使用会导致崩溃。
合理使用Spawn参数：FActorSpawnParameters中的SpawnCollisionHandlingOverride非常重要，它决定了当生成点被阻挡时的行为。对于地面生成器，AdjustIfPossibleButDontSpawnIfColliding是个安全的选择；对于空中生成，则可以考虑AlwaysSpawn。

3.2 场景二：游戏子系统中的服务类动态注册

参考网络热词中的“UE Subsystem”，子系统常需要管理多种服务。例如，一个音频管理系统可能需要根据场景动态切换不同的混响算法服务。

// 基础服务接口 UCLASS(Abstract) class UAudioService : public UObject { GENERATED_BODY() public: virtual void ApplyReverb(AActor* Listener) = 0; }; // 具体的服务实现类 UCLASS() class UCaveReverbService : public UAudioService {...}; UCLASS() class UHallReverbService : public UAudioService {...}; // 音频管理子系统 UCLASS() class UAudioManagerSubsystem : public UGameInstanceSubsystem { GENERATED_BODY() public: // 注册服务类的映射 UPROPERTY() TMap<FName, TSubclassOf<UAudioService>> ServiceClassRegistry; // 根据场景名称获取并创建服务实例 UAudioService* CreateAndGetService(FName SceneType) { if (TSubclassOf<UAudioService>* ServiceClassPtr = ServiceClassRegistry.Find(SceneType)) { TSubclassOf<UAudioService> ServiceClass = *ServiceClassPtr; if (ServiceClass) { return NewObject<UAudioService>(this, ServiceClass); } } return nullptr; // 或返回一个默认服务 } void InitializeServiceRegistry() { // 可以硬编码，也可以从数据资产、配置文件加载 ServiceClassRegistry.Add(TEXT("Cave"), UCaveReverbService::StaticClass()); ServiceClassRegistry.Add(TEXT("GreatHall"), UHallReverbService::StaticClass()); // 蓝图实现的服务类也可以通过SoftClassPath动态加载后加入 } };

这里，TSubclassOf<UAudioService>确保了ServiceClassRegistry这个映射表中，每个键对应的值都一定是UAudioService的派生类。当场景从“洞穴”切换到“大厅”时，系统可以安全地创建对应的混响服务实例，无需修改C++代码，只需扩展这个注册表。

3.3 场景三：技能或武器系统的数据资产集成

在复杂的技能或武器系统中，我们通常使用数据资产（DataAsset）或数据表（DataTable）来配置数值和引用。TSubclassOf在这里可以优雅地定义技能效果类、投射物类等。

// 技能数据资产 UCLASS() class USkillDataAsset : public UDataAsset { GENERATED_BODY() public: UPROPERTY(EditDefaultsOnly, BlueprintReadOnly) FText SkillName; UPROPERTY(EditDefaultsOnly, BlueprintReadOnly) TSubclassOf<UGameplayEffect> DamageEffectClass; // 应用的效果 UPROPERTY(EditDefaultsOnly, BlueprintReadOnly) TSubclassOf<AActor> ProjectileClass; // 产生的投射物 UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, meta=(AllowAbstract=“false”)) TSubclassOf<UCameraShakeBase> HitCameraShakeClass; // 命中相机震动 }; // 在角色技能组件中使用 void UCharacterSkillComponent::ActivateSkill(USkillDataAsset* SkillData) { if (!SkillData || !SkillData->ProjectileClass) return; // 安全地生成投射物 FActorSpawnParameters Params; Params.Instigator = GetOwner(); Params.Owner = GetOwner(); GetWorld()->SpawnActor<AActor>(SkillData->ProjectileClass, SpawnTransform, Params); // 应用游戏效果 if (SkillData->DamageEffectClass) { // ... 使用AbilitySystemComponent应用GameplayEffect } }

通过将TSubclassOf嵌入数据资产，设计人员可以在一个集中的、非代码的界面里配置整个技能链所涉及的所有动态类。这实现了内容与逻辑的彻底分离，是大型项目必备的架构模式。

4. 与蓝图的高效交互全流程

4.1 向蓝图暴露TSubclassOf属性与函数

让蓝图能够读取和设置TSubclassOf属性，是赋能策划和设计师的关键。这主要通过UPROPERTY宏的BlueprintReadWrite或BlueprintReadOnly说明符实现。

// 在C++中声明 UCLASS() class AMyWeaponManager : public AActor { GENERATED_BODY() public: // 蓝图可读写，用于配置 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Weapon") TSubclassOf<AWeapon> PrimaryWeaponClass; // 蓝图可调用，传入一个武器类进行设置 UFUNCTION(BlueprintCallable, Category = "Weapon") void SetSecondaryWeaponClass(TSubclassOf<AWeapon> NewWeaponClass) { SecondaryWeaponClass = NewWeaponClass; } // 蓝图可调用，返回当前武器类 UFUNCTION(BlueprintCallable, Category = "Weapon") TSubclassOf<AWeapon> GetPrimaryWeaponClass() const { return PrimaryWeaponClass; } private: UPROPERTY() TSubclassOf<AWeapon> SecondaryWeaponClass; };

在蓝图中，PrimaryWeaponClass会显示为一个类选择器。SetSecondaryWeaponClass函数的输入引脚也会是一个类选择器。而GetPrimaryWeaponClass的返回值可以连接到其他需要类输入的节点上。

4.2 在蓝图中获取、判断与使用TSubclassOf

蓝图提供了丰富的节点来操作TSubclassOf变量。

获取类的默认对象：有时你需要访问类的默认属性（CDO）。使用“Get Class Defaults”节点，输入一个TSubclassOf，输出是该类的默认对象（CDO），你可以从中读取默认的数值、引用等配置。
类判断与转换：
- Equal (Class)：判断两个TSubclassOf变量是否指向同一个UClass。
- Is Child Of：判断一个TSubclassOf变量代表的类是否是另一个指定类的子类。这在处理类层次结构时非常有用。
- Cast To：虽然TSubclassOf本身不用于对象转换，但你可以用它生成的对象进行Cast。例如，先Spawn Actor from Class，然后将生成的Actor对象Cast To某个特定接口或父类，以调用特定方法。
动态加载：如果类路径存储在字符串或数据表中，可以使用Load Class节点。该节点的返回值类型就是TSubclassOf（你需要指定一个基类）。这是一个连接动态配置（如JSON、CSV）和类型安全代码的桥梁。

// 一个蓝图逻辑示例： // 1. 从数据表读取一个类路径字符串（FString）。 // 2. 使用“Load Class”节点（基类设为AWeapon），加载这个类，得到一个TSubclassOf<AWeapon>。 // 3. 使用“Is Valid”检查加载是否成功。 // 4. 如果成功，使用“Spawn Actor from Class”节点生成武器。

4.3 处理蓝图原生事件与动态委托中的类参数

TSubclassOf也可以作为蓝图动态多播委托（DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam）的参数，实现更解耦的通信。

// C++端声明委托 DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnWeaponUnlocked, TSubclassOf<AWeapon>, UnlockedWeaponClass); UCLASS() class AMyPlayerState : public APlayerState { GENERATED_BODY() public: UPROPERTY(BlueprintAssignable, Category = "Events") FOnWeaponUnlocked OnWeaponUnlocked; void UnlockWeapon(TSubclassOf<AWeapon> WeaponClass) { // ... 解锁逻辑 OnWeaponUnlocked.Broadcast(WeaponClass); // 广播事件，传递解锁的武器类 } };

在蓝图中，任何Actor都可以绑定到这个OnWeaponUnlocked事件。当事件触发时，传递过来的UnlockedWeaponClass参数可以直接用于生成武器、更新UI图标等。这种方式将“解锁”这个逻辑事件与具体的响应处理解耦，系统扩展性极强。

5. 高级技巧与性能优化

5.1 结合SoftClassPath实现异步加载与热更新

TSubclassOf虽然安全，但它通常指向一个已加载到内存中的UClass。对于大型项目，所有可能用到的类都在启动时加载是不现实的。这时就需要FSoftClassPath或TSoftClassPtr。

FSoftClassPath是一个存储类引用路径的字符串结构（如”/Game/Blueprints/Weapons/BP_SniperRifle.BP_SniperRifle_C“）。它本身不是TSubclassOf，但可以异步转换为TSubclassOf。

UPROPERTY(EditAnywhere, Category = "Weapons") FSoftClassPath WeaponSoftClassPath; // 在编辑器中显示为资产选择器，但选择的是蓝图类资产 // 异步加载 void LoadWeaponClassAsync() { TSoftClassPtr<AWeapon> SoftClassPtr = TSoftClassPtr<AWeapon>(WeaponSoftClassPath); if (SoftClassPtr.IsPending()) { // 启动异步加载 SoftClassPtr.LoadAsync(); // 通常通过一个回调或委托在加载完成后处理 } else if (SoftClassPtr.IsValid()) { // 已经加载，可以直接获取TSubclassOf TSubclassOf<AWeapon> LoadedClass = SoftClassPtr.Get(); SpawnWeapon(LoadedClass); } }

最佳实践：在数据资产或长期配置中，使用FSoftClassPath或TSoftClassPtr来引用类，以实现按需加载和内存控制。在需要立刻使用该类进行生成或判断的代码逻辑中，再将其解析或同步加载为TSubclassOf。

5.2 使用模板元编程增强泛型类工厂

对于需要根据TSubclassOf创建对象并执行某些通用初始化的场景，可以利用C++模板编写一个类型安全的工厂函数。

template <typename T> T* CreateManagedObject(UObject* Outer, TSubclassOf<T> Class, FName Name = NAME_None) { if (!Class) { UE_LOG(LogTemp, Error, TEXT("CreateManagedObject: Invalid class provided.")); return nullptr; } // 确保传入的类确实是T或其派生类（TSubclassOf已保证，此处是双重检查） if (!Class->IsChildOf(T::StaticClass())) { UE_LOG(LogTemp, Error, TEXT("CreateManagedObject: Class %s is not derived from %s."), *Class->GetName(), *T::StaticClass()->GetName()); return nullptr; } T* NewObj = NewObject<T>(Outer, Class, Name); if (NewObj) { // 这里可以添加所有T类型对象创建后都需要执行的通用初始化逻辑 // 例如，注册到某个管理器、设置默认标签等。 PostCreateInitialization(NewObj); } return NewObj; } // 使用示例 TSubclassOf<AWeapon> WeaponClass = ...; AWeapon* MyWeapon = CreateManagedObject<AWeapon>(GetTransientPackage(), WeaponClass);

这种模式将类型检查、空值校验和通用初始化逻辑封装在一起，避免了在业务代码中重复这些“样板代码”，提高了代码的健壮性和可维护性。

5.3 避免常见的内存与生命周期陷阱

悬挂指针：TSubclassOf内部持有的是UClass*指针。虽然UClass对象通常是常驻内存的，但在热重载（Live Coding）或模块动态卸载时，旧的UClass可能失效。确保持有TSubclassOf的对象生命周期合理，或在必要时使用TSoftClassPtr来软引用。
循环引用：如果在一个UObject类A中，持有一个TSubclassOf<A>（即自身的类），这本身没有问题。但如果A的实例大量存在，且这个TSubclassOf成员被标记为UPROPERTY并序列化，可能会产生不必要的引用关系，但通常不会导致垃圾回收(GC)问题，因为UClass是根对象。更需警惕的是在复杂的数据资产网络中，通过TSubclassOf间接形成的对象引用环。
与UObject默认序列化的配合：TSubclassOf完美支持UE的序列化系统。这意味着它可以被保存到磁盘（如.uasset文件），在游戏存档中保存和加载。但请记住，它保存的是类的路径引用。如果对应的蓝图类被移动或重命名，这个引用就会断裂。在项目开发中，对已广泛使用的蓝图类进行重命名操作需格外谨慎。

6. 疑难排查与实战调试记录

6.1 编译错误：“Cannot convert from ‘UClass*‘ to ‘TSubclassOf<...>‘”

这是最常见的编译错误。原因是你试图将一个UClass*赋值给一个类型不匹配的TSubclassOf。

错误示例：

TSubclassOf<AWeapon> WeaponClass; UClass* SomeClass = UStaticMeshComponent::StaticClass(); WeaponClass = SomeClass; // 编译错误！

解决方案：

检查赋值来源：确保你赋值的类（或UClass指针）确实是TSubclassOf模板参数指定的基类的派生类。
使用正确的静态类获取方式：对于已知的具体C++类，应使用::StaticClass()。
```
WeaponClass = ARocketLauncher::StaticClass(); // 正确，如果ARocketLauncher继承自AWeapon
```
如果是动态加载的类，确保使用TSubclassOf兼容的加载方式，如LoadClass<T>()或TSoftClassPtr<T>::Get()。

6.2 运行时错误：“Invalid TSubclassOf was specified“

这个错误通常发生在调用SpawnActor或NewObject时，传入的TSubclassOf变量是空的（nullptr）或者其内部UClass指针无效。

排查步骤：

检查编辑器配置：首先去编辑器中查看暴露为UPROPERTY(EditAnywhere)的TSubclassOf变量是否被正确设置。这是最常见的原因。

添加空值检查：在使用TSubclassOf变量前，务必进行有效性判断。

if (WeaponClassToSpawn) { GetWorld()->SpawnActor<AWeapon>(WeaponClassToSpawn, ...); } else { UE_LOG(LogTemp, Error, TEXT("WeaponClassToSpawn is not set!")); }

检查动态加载路径：如果TSubclassOf来自动态加载（如LoadClass），请检查提供的类路径字符串是否正确，以及对应的资产是否存在。

6.3 编辑器下拉框中找不到预期的蓝图类

你明明创建了一个继承自AWeapon的蓝图BP_SuperGun，但在TSubclassOf<AWeapon>属性的下拉菜单里却找不到它。

可能原因与解决：

蓝图未编译：新创建的或修改过的蓝图必须编译成功，其生成的类才会被纳入编辑器类列表。尝试编译该蓝图或编译整个项目。
基类不匹配：确认你的蓝图父类确实是你期望的基类。在蓝图编辑器中，查看“Class Settings”，检查“Parent Class”是否设置正确。
类被标记为抽象（Abstract）或临时（Transient）：在蓝图的“Class Settings”中，如果勾选了“Abstract”，它不会出现在下拉列表中。确保它是可实例化的。
元数据限制：检查C++中UPROPERTY的元数据。Meta = (BlueprintBaseOnly = “true”)会过滤掉原生C++类；Meta = (AllowAbstract = “false”)（默认）会过滤掉抽象类。
模块依赖：如果蓝图所在的模块（Module）没有被你的游戏目标（Target）所依赖，其类可能不会被加载。检查.Build.cs文件中的依赖关系。

6.4 在数据表（DataTable）或结构体中使用TSubclassOf的序列化问题

TSubclassOf可以直接作为USTRUCT的成员，并用于数据表。但需要注意：

数据表列头格式：在CSV文件中，TSubclassOf对应的列，其值应填写类的完整引用路径，例如：”/Game/Blueprints/Weapons/BP_Rifle.BP_Rifle_C“。注意末尾的_C，它代表蓝图生成的类。
引用有效性：数据表是纯文本配置，引擎在加载时会根据路径查找类。如果路径错误或资产被删除，该字段会加载为nullptr。在代码中读取数据表后，使用前必须检查TSubclassOf成员是否有效。
使用FSoftClassPath作为替代：对于更健壮、支持异步加载的配置，可以考虑在数据表中使用FSoftClassPath类型。在运行时，再通过TSoftClassPtr::LoadSynchronous()或异步加载方式转换为TSubclassOf。这提供了更好的错误容忍度和热更新能力。

一个实用的调试技巧：当你怀疑一个TSubclassOf变量为何为空时，可以在代码中临时打印其内部信息。虽然不能直接打印TSubclassOf，但可以打印其Get()返回的UClass*的路径：

if (WeaponClass.IsValid()) // 或者 if (WeaponClass) { UClass* ClassPtr = WeaponClass.Get(); UE_LOG(LogTemp, Display, TEXT("Class Path: %s"), *ClassPtr->GetPathName()); } else { UE_LOG(LogTemp, Warning, TEXT("WeaponClass is NULL or invalid.")); }

这能帮你快速定位是配置没加载，还是路径不对。

查看全文

http://www.jsqmd.com/news/1333186/