#Fixing Localization Gather (Primary Assets held text but were not Gathered For Cook)

1 messages · Page 1 of 1 (latest)

tepid hamlet
#

Actually maybe we can thread here so they can discuss ASC @atomic wing

#

No rush!

#

... Maybe? Primary Assets work differently to other assets, though. You can include them in cooks even if they're never directly referenced from a Map or from your main Game Framework classes.

The downside is that you need to configure them to be collected, if they're not strictly referenced.

#

Can you describe your plugin setup? Is it just a regular old Game plugin... is it an Engine plugin?

#

Where is your content (in the Content of the plugin?)

#

Ok! Yeah you wanna configure scan rules in the project settings.

#

Nah

#

Data Assets aren't an editor only thing, innately. Something is fishy here. Might be a localization dashboard bug, though, but it could also be some arcane setup thing

#

I don't wanna lead you on like I have a solve, but I don't mind being a springboard / rubber duck for a bit

#

Yeah it does look nice - if you tick that setting, does it gather ALL your text? Or just the top level testing text?

#

plus that's a nonstarter for teams that have a lot of dev-facing text

#

Well, it isn't going to break your loc gather ChillBar_heh

#

that's gonna take a while. Can you show me the primary asset scan rules you set up?

#

What about the Rules there? I forget what the default is, but if that is set to NeverCook it would be an issue.

#

You might try setting Unkown to AlwaysCook?

#

Do I need to package it after?

I'm unsure. I don't think so, but as I say I haven't worked with the loc dash.

#

Also can I have a plugin that has a runtime module and an editor module?
This is fine, but I think your plugin will need two targets (the editor target will need to include your runtime & editor module, the other target should only have the runtime module)

#

Earlier you were describing that you had one module specific for customizations, that one needs to be editor

#

oh dang

#

#if WITH_EDITOR or #if WITH_EDITORONLY_DATA
https://forums.unrealengine.com/t/with-editor-vs-with-editoronly-data-need-clarification/103182

Epic Developer Community Forums
WITH_EDITOR vs WITH_EDITORONLY_DATA - need clarification

Hi, It’s been few months I didn’t code in C++ with the engine, and I forgot some of the preprocessors stuffs. Can comeone explain me what are the difference between WITH_EDITOR vs WITH_EDITORONLY_DATA? From what I can get in the engine source is that “WITH_EDITOR” is stricly related to the build “*Editor” like “DevelopmentEditor” or “DebugEdi...

#

There are some functions that are only defined if compiling for editor, but it would be ... impractical to structure your code so that those functions are inside the editor only module

#

If you remember, you had the entire plugin Editor

#

Anyway you gotta do

#if WITH_EDITOR
virtual void PostEditChange...(...)
{
   // ...
}
#endif // WITH_EDITOR
#

The function, and the function's declaration, these both need to be compiled out when !WITH_EDITOR

#

It's a little scary at first, but these are only really important in the editor.

#

In fact, it's possible you could end up with your dialog system only containing a single FText at runtime, when its cooked

#

(Practically, you may have other data, like speaker ID, but you wouldn't need all the editorcustomization supporting structs and whatnot)

#

If you want, you can explore the engine and find different classes that are in Runtime modules but which use this technique to have a better editor experience

#

Yeah!

#

If you're unsure, go look at where the function was first declared - like UObject's header

#

Almost all of these are going to be initially declared within a #if WITH_EDITOR block

#

Fixing Localization Gather (Primary Assets held text but were not Gathered For Cook)

#

You could share the source file PDA_DAS_EntityData.h, but I would expect that you're missing either a forward declaration of a class/struct/etc, or you hadn't included the full declaration of whatever type it is choking on

# 

UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\PDA_DAS_EntityData.h(49): error C2061: syntax error: identifier 'UTexture2D'
UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\PDA_DAS_EntityData.h(45): error C2065: 'DefaultTexture': undeclared identifier

So, C++ doesn't understand that UTexture2D is a type, it errors there, and then it tells you that DefaultTexture is an identifier that wasn't declared (becuase technically it wasn't, the previous declaration of UTexture2D* DefaultTexture; was rejected

#

DialogueAssetSystem.h(25): error C2504: 'UDeveloperSettings': base class undefined Seems like a similar thing happening here

#

These aren't the same kind of error

#

These have to do with the translation units your plugin module is made with. Nothing else in the translation unit has included the header for UTexture2D, yet, so the compiler has never seen that type.

#

It's the same reason you had to use

// forward declare for EntityData's pointer, the class is defined just after
class UPDA_DAS_EntityData;
#

Yeah, UTexture2D

#

Happenstance and/or PCH (precompiled headers)

#

Sometimes its easier to catch this sort of thing if you run "non-unity builds"

#

Well, I've been doing this for a long while now

#

I was once in similar shoes to you

#

In your plugin's Build.cs file(s), you can try setting bFasterWithoutUnity to true

#

There's a bunch of other settings related to PCH and "Adaptive Unity" you can try fooling around with

# 

UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\DialogueAssetSystem.h(27): error C3646: 'Super': unknown override specifier
UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\DialogueAssetSystem.h(27): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\DialogueAssetSystem.h(27): error C2440: 'return': cannot convert from 'UDASSettings *' to 'UObject *'
UATHelper: Package Plugin Task (Windows): C:\Users\User\Desktop\DAS 5.5.4\DialogueAssetSystem\DialogueAssetSystem\HostProject\Plugins\DialogueAssetSystem\Source\DialogueAssetSystem\Public\DialogueAssetSystem.h(27): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or parenthesized function-style cast

These errors.... suggest you're putting your functions in the headers. I generally don't do that, because it can mean that your header has to include a bunch of stuff to compile.

DialogueAssetSystem.h(27): error C2440: 'return': cannot convert from 'UDASSettings *' to 'UObject *' Right here, for instance, you need to include the declaration of UDASSettings in order to resolve this error. So now, anything that includes DialogueAssetSystem.h will also have to include DASSettings.h.

#

Although, that may be from generated code

#

Speaking of generated code, any of these errors: DialogueAssetSystem.gen.cpp( will probably go away once you IWYU (Include What You Use)

#

A lot of the time, error walls like these only have a few critical things to address (the UTexture2D thing, for instance), so a ton of them go away once you fix one or two spots.

#

I would expect that you can get away with just using WITH_EDITOR. If you feel better wrapping calls to FText::ChangeKey in #if WITH_EDITORONLY_DATA, that won't hurt anything.

tepid hamlet
#

If you're not Live Coding does that mean that you're Hot Reloading?

#

Oh you've been re-running it, but you want to try to save time

#

For a base class (or any class that your code is writing to or reading from) you need to include that header

#

Ok, so, do you compile the engine from source @atomic wing ?

#

Ah I was going to suggest compiling "UnrealFrontend" and using that standalone to manage your packaging

#

Oh, you know what

#

In Rider, you can change from building Editor to building Shipping (I'm pretty sure)

#

That might show you some of these errors without needing to fully package.

#

Yeah, you got it!

#

Oh. I'm a little surprised that happened. I would have expected it to not appear at all, if it weren't supported. I was worried that it wouldn't be supported. Dang.

#

Oh, ok

tepid hamlet
#

UATHelper: Package Plugin Task (Windows): Missing precompiled manifest for 'Settings', 'S:\GameDev\0 - ENGINES\UE_5.5\Engine\Intermediate\Build\Win64\UnrealGame\Shipping\Settings\Settings.precompiled. This module can not be referenced in a monolithic precompiled build, remove this reference or migrate to a fully compiled source build.

This is for you, but the other line is for Engine programmers (who might be testing their engine plugin or engine module in a promoted build)

#

So, I think your UDASSettings can't be in your runtime module, at least, with the launcher engine

#

It's because UDeveloperSettings isn't precompiled here

#

It's kind of odd, but DeveloperSettings is a Runtime module, so the reason it isn't working here is that they didn't precompile Settings for Shipping

#

Is there any way you can make your settings Editor Only?

#

I think you need to move it to the other module (for now), but I imagine your runtime code uses it?

#

There's a bunch of ways you can invert the dependency between your runtime code and settings class

tepid hamlet
#

Would you mind pastebin sharing your new source header?

#

And your build output in full?

#

Is BPFL_DAS_Utils.cpp in the Runtime module?

#

Ok, so yeah that's not going to work. We're going to need to invert that dependency. Is it the only place that uses your settings?

#

Correct!

#

Ok, then this is going to be pretty easy

#

Within BPFL_DAS_Utils.h, you're going to declare a new delegate type

DECLARE_DELEGATE_OneParam(FOnGetMasterEntityDataAsset, TSoftObjectPtr<UPDA_DAS_EntityData>&);

You're going to want to make this statically accessible. The easiest way to do so would be to declare it as a static member of your UBPFL_DAS_Utils class. Make sure it's public:

public:

   FOnGetMasterEntityDataAsset OnGetMasterEntityDA;

Now, in your code, you gotta change out what you're doing:

 // instead of 
 MyDASSettings->MasterEntityDA.Use();

 // You need to
 TSoftObjectPtr<UPDA_DAS_EntityData> Path;
 OnGetMasterEntityDA.Execute(Path);
 Path.Use();

// Also somewhere in your .cpp file
  FOnGetMasterEntityDataAsset UBPFL_DAS_Utils::OnGetMasterEntityDA;
#

Now, of course, you're going to need to connect this to your UDASSettings.

#

I'd recommend you do this in the constructor, but you also can do it in PostLoad or PostInitProperties or anything like that.

# 
   // Bind an anonymous lambda that can access our own field MasterEntityDA
   UBPFL_DAS_Utils::OnGetMasterEntityDA.BindWeakLambda(this, [this](TSoftObjectPtr<UPDA_DAS_EntityData>& Out ){ Out = MasterEntityDA; });
#

And actually, you may want to check whether the this instance is a CDO first -- although I'm unsure of whether or not DeveloperSettings are instanced. The point being that you don't want to bind to the CDO if you can bind to an instance

#

No! I'm declaring it once, the second time is different, that's a definition

#

Oh! I forgot static! Derp!

#

no I mean in my code example

#

Oh that's actually easy

# 
UPDA_DAS_EntityData* UBPFL_DAS_Utils::GetEntityDataAsset()
{
    TSoftObjectPtr<UPDA_DAS_EntityData> Path;
    OnGetMasterEntityDA.Execute(Path);
    if (!Path.IsNull())
    {
      return Path.LoadSynchronous();
    }

    return nullptr;
}
#

This is probably not how you want to do multiple settings, but it should get you unblocked

#

Nope!

#

I'd recommend you bind to that delegate from within UDASSettings() or UDASSettings::PostInitProperties or UDASSettings::PostLoad

#

And it seems you might be able to ignore what I said about checking for CDO

#

I think that looks right, yea

#

Yeah I forgot if DeveloperSettings were instanced

#

Ah this one is pretty easy

#

UBPFL_DAS_Utils needs to export OnGetMasterEntityDA

#

you can do like class DAS_RUNTIME_API UBPFL_DAS_Utils: public UBlueprintFunctionLibrary