You can also use Google Sheets, OpenOffice, LibreOffice, CSVed or any other spreadsheet application that can save to CSV. You can alter the tables directly in UE4’s table editor, but it is much more flexible to work in a spreadsheet editor.
As for the font, **UMG **doesn’t (as far as I know), support changing the font, font size, or font weight at runtime, so this can’t be directly supported. I can think of a way to do it, but it’s a clumsy task (and not cleanly supported in the current version of the BDS): Create a new UI_DialogueTextItem for **each **font settings you’d like to support and add new options in the inline parser to swap out the text item it spawns.
The only font option we can alter directly is the colour, you can use the inline font tags for this (col/color/colour)
Thank you! It does. I’ll consider making individual UIs for each typeface.
Sorry for being late to reply, but I’m still a bit confused. I managed to export the Speaker Attributes data table as a CSV and alter it in Excel, but I’m not sure how to get it back into UE4. I can’t import it as a CSV, so what sort of file should save it as?
Hi Cinebeast, CSV is the right format to use. You can import it like any other file (drag&drop, with the import button, or by placing it anywhere in the content folder if monitor content option is on). When you try to import it you should get a prompt for which kind of data asset to create, select Dialogue_TableItem (note, UE4 sometimes doesn’t show this data row type, if this happens try opening DT_Dialogue_Main and trying again to make the editor aware of that type)
In the sample project, I placed the CSV files in the “SampleContent/DialogueSampleContent/Data” folder, in my case UE4 automatically detects a change and updates the datatable or prompts to create a new one from the CSV file - I believe this is the ‘monitor content folder’ option in editor settings, I’m not sure if this is on by default.
Sorry to bug you, but I’ve run up against a new hurdle and I hope you can help me. I’m trying to use the Conditions column, but I’m not sure how. Here’s what I’m looking to do: I have a dialogue branch where the player can choose one of three or four outfits. Whichever outfit they pick, they wear. Ideally, whichever outfit they’re currently wearing will be removed from the dialogue branch, and vice versa if they change into another outfit.
It seems clear to me I need to use the Conditions column to make this happen, but I’m not sure how to go about it. I’ve tried updating a variable every time you pick and outfit – something like $Namespace@CostumeName$=“false” and such – but I’ve had no luck so far. Could you give some suggestions?
The condition column expects a value to evaluate to true or false (this follows the same rules as C/C++ where anything other than false or 0 is true).
You have the right idea I believe. When an outfit is selected, set a flag for that costume (either have a variable for each costume: ‘redDress=true;’, or use one variable with a key: ‘currentDress=“RedDress”;’)
In the condition column, test to see if that variable evaluates to true (you can use ‘redDress’ or ‘redDress==true’ or ‘!blueDress’) or the key you’re looking for ('currentDress == “RedDress”). If the value is false, the option won’t be displayed or used in any default way.
Since I’m having the same problems you guys are having regarding packaging, I was wondering if you found a solution, or are waiting for 4.11 to be released?
I’ve been meaning to get around to doing this. I’m not actually sure how to go about it, though? I’ve created a new UI for the text item like you said, and I went ahead and made a whole new UI_Dialogue that uses said text item too, just in case. I don’t know how to call upon these, however.
Looking at BPC_Dialogue (and the children I’ve made), it looks like I just need to swap out the UI there through a Cast To node or a Blueprint Interface, but the option isn’t available to me.
(That one.)
The variable will only accept the UI_Dialogue class, but I’d like to broaden its horizons, so to speak, so it can also accept the custom UI I made. I could be going about this rather poorly. What do you suggest?
UI_Dialogue was intended to be inherited instead of duplicated entirely (mentioned briefly in the documentation), I don’t think it would be straightforward to replace it with a new class entirely.
Another problem you will encounter is that the text and response widgets are “hardcoded” in the base UI_Dialogue file (this has been changed for the next version).
I’m afraid I won’t be much help beyond this though; the implementation that I can figure is far too cumbersome to describe
Okay, thanks. I didn’t know widgets could inherit from other widgets. (I really should have, though, my bad.)
So, I remade the custom UI and parented it to UI_Dialogue, and I’ve overridden only one graph, the Create Dialogue Item graph. Here I run into an issue that I don’t really understand:
In case it’s hard to read, on compile I get an error that says I can’t override the function because it was declared in a parent with a different signature. This is over my head, but maybe you have an idea.
Still, this might be unnecessary. You mentioned the next update will feature an easier way to change these sorts of things, and I’m not really in any rush to get this problem settled. I could just wait for the update. If it’s not too pushy of me, when can we expect it?
When you created that function, did you use the ‘Override’ drop down? I’ve checked that it should work that way.
The changes that are in the newer version are a few fixes and a few built in functions, nothing major - I’ve exposed the UI_Dialogue_TextItem and ResponseItem classes to spawn from, but you can work around it without this change (you’re in the right direction with the Create dialogue item override, I think).
Yes, I did. I just made it again to make sure, and I get the same error. All I’m changing is the Dialogue Item variable so that it references the custom Text Item UI I’ve made instead of the original.
For the record, the custom Text Item UI is not parented to the original Text Item UI – it’s a duplicate using a different font. Could that be a problem?
Hmm, I’m not able to recreate your error without starting a new function without overriding, maybe try creating a new fresh umg widget, reparent from UI_Dialogue, and try overriding it there - see if it happens again?
I can’t say for certain off the top of my head if that will be a problem, but my instincts tell me it will be.
If I understood you correctly, I tried this and got the same error. I made a new, completely blank widget, set UI_Dialogue as its parent, and then overrode the function in question. Even then it compiles fine, but as soon as I remove the call to the parent function and replace the references, the error crops up.
Make sure the return node is called and that it returns a UI_Dialogue_TextItem reference (if you inherit your new text item from UI_Dialogue_TextItem, you can return it)
*There’s * the problem – my custom text item inherited from nothing. So, I want to make a fresh widget and parent it to UI_Dialogue_TextItem, but how would I change the font? I’m not sure which function I need to override, if any.
I know how to change the font on a widget, but I want to change the font for a widget that inherits from UI_Dialogue_TextItem. I’ve tried making a fresh widget and doing so, but I get an error on compile, since the text is already a variable. I want to override that variable, or replace it or something. I’m really not sure.
I’ve also tried duplicating UI_Dialogue_TextItem and changing the font there, then parenting it to the original widget, but I get the same error.
This is where it gets cludgy in the existing marketplace version, I’m afraid. How it WILL work for inheriting UI_Dialogue_TextItem in the next version is similar to inheriting from UI_Dialogue, where you override the ‘GetTextControl’ and provide your own. With what you have now, you will need to change the base UI_Dialogue_TextItem class to have this getter for all references to the txtText widget. (Most, if not all of these references reside in the one widget, so it’s not too damaging).
A small note is that if/when you update to the newer version (once it’s available), you may have to fix your inherited widgets to call the new GetTextControl function.
