Hey all, currently diving into the CommonConversation plugin, I’ve created a conversation graph with an entry and a bunch of tasks, the entry has a gameplay tag and all the other required items to run, though when I save the DataAsset, I get the following errors:
[AssetLog] E:.…[Path here]…\TestConversation.uasset: Missing from DefaultEngine.ini, +CookedTagsWhitelist=(Class=ConversationDatabase,Tag=EntryTags)
[AssetLog] E:.…[Path here]…\TestConversation.uasset: Missing from DefaultEngine.ini, +CookedTagsWhitelist=(Class=ConversationDatabase,Tag=ExitTags)
[AssetLog] E:.…[Path here]…\TestConversation.uasset: Missing from DefaultEngine.ini, +CookedTagsWhitelist=(Class=ConversationDatabase,Tag=InternalNodeIds)
[AssetLog] E:.…[Path here]…\TestConversation.uasset: Missing from DefaultEngine.ini, +CookedTagsWhitelist=(Class=ConversationDatabase,Tag=LinkedToNodeIds)
This is despite those tags being added to CookedTagsWhitelist in the DefaultEngine.ini…
And then consequently, if I try calling StartConversation to call my test conversation, I get an error Entry point Test.Entry did not exist or had no destination entires; conversation aborted, though I suspect this part will likely be fixed once I figure out what’s going on with the CookedTagsWhitelist…
So question is, can anyone tell me what I’m missing / doing wrong?
Update, I saw Fortnite is also using the CommonConversation plugin from the looks of it, and found this in their DefaultEngine.ini - which when copied over, removes the error:
[AssetRegistry]
bSerializeDependencies=false
bUseAssetRegistryTagsWhitelistInsteadOfBlacklist=true
bFilterAssetDataWithNoTags=true
bFilterDependenciesWithNoTags=true
+CookedTagsWhitelist=(Class=DataRegistry,Tag=RegistryType)
+CookedTagsWhitelist=(Class=ConversationDatabase,Tag=EntryTags)
+CookedTagsWhitelist=(Class=ConversationDatabase,Tag=ExitTags)
+CookedTagsWhitelist=(Class=ConversationDatabase,Tag=InternalNodeIds)
+CookedTagsWhitelist=(Class=ConversationDatabase,Tag=LinkedToNodeIds)
Next issue to figure out, it still fails to find the entry point tag…
2 Likes
I figured I should bump this one with an update as still trying to figure out CommonConversation, the current issue with the Entry point %s did not exist or had no destination entries; conversation aborted log appears to be down to the ConversationInstance.cpp, when it’s retrieving the UConversationRegistry from the UWorld, it then calls ConversationRegistry->GetOutputLinkGUIDs(EntryPoint);, which returns an empty array…
There must be some way to register the conversation with the UConversationRegistry that I’m missing?
I ran into the same issue. Currently there is an imperfection in that the Common Conversation Database asset MUST be loaded on a GameFeature (extra Plugin).
Additionally, its very tricky because in the Game Feature needs to be set Initial State = Installed, and in C++ to Enabled by Default = true, and Explicitly Loaded = false.
Not only that, but you must also configure to look for Databases with your Asset Manager. This only works in the AM of the GameFeature btw… Type ConversationDatabase as a new entry, look for the type, and in the advanced details mark it Always cook.
Also, set it back to Installed, sometimes it glitches out and doesn’t load the databases properly.
Check this example: GitHub - pafuhana1213/UE5_CommonConversationSample: Sample for UE5's CommonConversation Feature
In the readme, you will see that the creator mentions :
- This is a C++ project because it cannot be implemented using only BP due to the specification of Common Conversation. Also, due to the same specification, the GameFeature feature is utilized.
(PS1: This might actually not be an imperfection and rather a way to manage the memory usage of the dialog data for large game, as GameFeature can be loaded only when needed and allow potentially considerable savings in RAM. They are essentially asynchronously handled by the Asset Manager and thus I assume without “loading through” a game feature, the database doesn’t get registered properly.)
(PS2: Now, in Lyra I have for a fact loaded dialogs from the primary runtime module, not a GameFeature, but it must be because of how Lyra is hooked up or it has to do with me having used an early access branch (5.5) when I did that in the past. Maybe that requirement has been dropped ?)
