They may have fixed it in a following version since it did look like a bug. Either way, changing it to TArray<TScriptInterface<ITestInterface>> is the right way to declare it.

@@kirby561 Yes, that's what the IDE suggested.

@@benjamingt1787 lmao. hey games need music too right?

Thanks. Your custom asset can be a ACharacter. ACharacter inherits from UObject (The hierarchy is ACharacter->APawn->AActor->UObject).

Well you could add PublicDefinitions.Add("WITH_OPENCV=1"); to your .Build.cs file but you shouldn't have to. I don't have UE5.3 installed but for 5.1 (and I assume it's the same for 5.3): 1) Add the OpenCV plugin to your project in UE editor->Edit->Plugins->Search OpenCV->Enable it 2) Add "OpenCV" and "OpenCVHelper" in your PublicDependencyModuleNames in your .Build.cs file. 3) You can now use it in your code. For example: #include "PreOpenCVHeaders.h" #include "OpenCVHelper.h" #include <ThirdParty/OpenCV/include/opencv2/imgproc.hpp> #include <ThirdParty/OpenCV/include/opencv2/highgui/highgui.hpp> #include <ThirdParty/OpenCV/include/opencv2/core.hpp> #include "PostOpenCVHeaders.h" If you depend on the modules in the plugin, UHT should automatically put the WITH_OPENCV definition in your Definitions.ProjectName.h file as well as other definitions you will need.

@@kirby561 WOW ! Dude if you make an opencv webcam tutorial with UE 5+ , it'd be one of the most watched videos on the topic. Because the other (and Only) one by jordan duncan is 4 years old ! Go for it 🚀 Also, I have done exactly as you have mentioned but VS C++ just wont allow me to include OpenCVHelper.h peacefully . Error C4430 missing type specifier - int assumed. Note: C++ does not support default-int . OpenCVHelper.h line 118 If I exclude the header the project builds and works just fine. But it's frustrating to not know why this is happening. Thanks for the Definitions.ProjectName.h tip. I learned something new today ✨

@@behrampatel4872 Hmm could be a version issue, there have been changes to the OpenCV plugin since 5.1. Thanks for the video idea, I'll add it to the list!

@@kirby561 💯

Thanks for watching! I may do some tutorials on debugging tricks in general at some point. Is there an issue with the runtime graph you're running in to? You could start by writing a function that prints the tree out with an asterisk or something on the current node. Then print it out after each decision in the tree to make sure everything is still correct. You can also set a breakpoint in vs code / visual studio and just step thru line by line and check that everything is what you expect.

@@kirby561 Thanks for replying, Its the only way I can debug what's node is currently running on the graph by breakpoints in VS. But its not visually friendly for non-tech people to figure out what's wrong in the graph (human error).

Hey thanks for the suggestion. I actually looked at these for saving but the issue is they are only called when you explicitly hit the save or save as buttons. If the save occurs for some other reason like if you close the whole editor down using the X and then it prompts you to save a changed asset and you save that way, SaveAsset_Execute will not be called so your graph will not properly be saved. In the followup video to this I explain how to do it properly by overriding PreSave from UObject on the DialogAsset (CustomAsset in this video).

@@kirby561 Yeah. I have done this before by calling a delegate inside that method and biding to It is inside the editor module.

Thanks for watching and for the correction! Yeah FIntPoint is probably better. Structured bindings are nice and this is personal preference but I usually try to be as explicit as possible when referencing things. It makes them easier to search and also SB's depend on the internal order of the structure so if that changes it can cause really subtle bugs. For example, consider this simple program: #include <iostream> struct Point { double y; double x; }; Point GetStartPoint() { return { 1.0, 2.0 }; } int main() { Point p = GetStartPoint(); const auto [x, y] = p; std::cout<<"SB: x = " << x << ", y = " << y << std::endl; std::cout<<"p: x = " << p.x << ", y = " << p.y << std::endl; return 0; } In the above, the structured binding version prints different output because y is declared before x in struct Point. Now it's a bit silly in this example because you would just switch the order but I don't like the idea of depending on the internal layout of a structure if you don't have to as well as not having the explicit .x and .y reference makes it unsearchable. Now maybe since for data structures it's all super standard those aren't really concerns in this case, but that's why I prefer one over the other.

@@kirby561 I know it can get messed up by structure changes; that’s why I only use it for iterating through maps.

@@kirby561 This is why I like to use curly braces to initialise numeric variables and fields so it stops implicit conversions between numeric data types.

That shouldn't be too hard. You can look at FAssetTypeActions_Blueprint::OpenAssetEditor in AssetTypeActions_Blueprint.cpp to see how regular blueprints open up the editor if you just want to use the exact same thing. If you want to reuse that and extend it, you can use WidgetBlueprints as an example since they extend the default blueprint editor. See FAssetTypeActions_WidgetBlueprint::OpenAssetEditor in AssetTypeActions_WidgetBlueprint.cpp for how they launch the extended version and FWidgetBlueprintEditor in WidgetBlueprintEditor.h/cpp for how they extend it as an example.

Thanks. Do you mean like the viewport tab in the Blueprint editor? I've gotten a few questions about this and I may do a video on it in the future. Probably won't be the next one though.

​@@kirby561 Yep, that's what I'm thinking about! Here's what I've found since writing that comment: - The static mesh, material, Niagara, and Chaos cloth asset editors are using the AdvancedPreviewScene module, which looks like a fairly labor-intensive solution with a lot of moving parts, though definitely a step above starting from scratch - Skeletal mesh and related asset editors (skeleton, physics asset, Control Rig, etc.) are using Persona. This is a much more "out of the box" solution but also looks more opinionated and less flexible - not sure if it supports anything other than skeletal meshes. Persona itself looks like a wrapper around AdvancedPreviewScene - The core Blueprint editor doesn't show up in the list of AdvancedPreviewScene referencers (and it's the only one that doesn't have a "Preview Scene Settings" tab in the editor), so I assume it's doing something completely custom. I'm afraid to investigate this one any further, tbh 😂

@@TheDannyMcGee lmao well thanks for the info!

For "Generic Commands" like delete/undo/redo/etc, you can map actions to them in your editor during initialization. There's a built in class FGenericCommands in GenericCommands.h that has these actions already defined. The base class of FWorkflowCentricApplication is FBaseToolkit that has an FUICommandList called ToolkitCommands. Add commands you want to handle to this list during initialization using: ToolkitCommands->MapAction(FGenericCommands::Get().Delete, FExecuteAction::CreateSP(this, &FBlueprintEditor::DeleteGraphAction), FCanExecuteAction::CreateSP(this, &FBlueprintEditor::CanDeleteGraphAction) ); The above will call DeleteGraphAction when delete is pressed. If you want to add new actions you can make a class extending TCommands, override RegisterCommands, and declare your new commands with the UI_COMMAND macro. You can specify the default hotkey in that macro as well. See BlueprintEditorCommands.cpp for an example, also don't forget to call Register on that commands class as part of initialization in your application. I'm not sure I understand the second question. This series covers how to update the UI within a tab to keep it in sync with the graph - are you asking how to update a second tab with information from a different tab? If so you can either sync it up to the currently edited asset when you switch tabs or you can use an interface / callback to update them.

@@kirby561 Thanks for the quick reply. Yea, I realized that the solution to my question was pretty easy, mb. Although I don't really understand how to use MapAction. Is FBlueprintEditor::DeleteGraphAction already declared? Because there isin't a method called DeleteGraphAction Altough I did find DeleteSelectedNodes, however its a protected method, and so is CanDeleteNodes. I'm calling it in InitEditor in CustomAssetEditorApp.cpp I tried implementing my own DeleteNode, however I can't seem to figure out how to get my currently selected nodes

@@kirby561 Thanks! I figured out my second question, it was already explained in the video. Mb But from what I understand, there is not such function as DeleteGraphAction. I tried implementing my own, but I have no idea how to get the selected nodes from _workingGraph

@@aprivatechannel1152 Oh sorry in that above code snippet, you need to implement the DeleteGraphAction and CanDeleteGraphAction methods on your app. I was copy/pasting how FBlueprintEditor (which is a FWorkflowCentricApplication) does it as an example and didn't replace the class name by accident. The equivilent in this tutorial project would be implementing them in DialogAssetEditorApp (aka DialogAssetEditorApp::DeleteGraphAction/CanDeleteGraphAction). You can get the current selection on SGraphEditor with: const FGraphPanelSelectionSet& nodes = _workingGraphUi->GetSelectedNodes(); Note the difference between _workingGraphUi which is an SGraphEditor vs _workingGraph which is a UEdGraph. SGraphEditor is the UI (the "view") that displays a UEdGraph (the "model").

Thanks! Yeah there's a few different ways you could do it. To have the most control you could implement your own custom asset type like shown in this series and for the editor you could extend FBlueprintEditor and add in whatever you want (See Engine/Source/Editor/Kismet/Public/BlueprintEditor.h for that class and AssetTypeActions_Blueprint.cpp / OpenAssetEditor for how to launch/initialize it). A simpler way may be to use some of the hooks that are built in already to extend it. For example, FBlueprintEditorApplicationMode has a delegate you can subscribe to in order to register your own tab factories as well (From BlueprintEditorModes.cpp in the constructor): FBlueprintEditorModule& BlueprintEditorModule = FModuleManager::LoadModuleChecked<FBlueprintEditorModule>("Kismet"); BlueprintEditorModule.OnRegisterTabsForEditor().Broadcast(BlueprintEditorTabFactories, InModeName, InBlueprintEditor); So you could make a tab factory that gets registered when that OnRegisterTabsForEditor delegate fires. I'm sure there's a lot of other ways too - maybe try poking around that Editor/Kismet module to see what else is available for extension.

@@kirby561 Thank you very much for your detailed reply!

Are you missing any includes? I get this error if I don't have #include "DialogAssetEditorApp.h" for example.

😞Thank you. And wow, I totally missed the part where you added the include for CustomAssetEditorApp.h, if I had only bothered to slow down. The IDE tricked me thinking I didn't need to link it too. Sorry for the bother, but thanks for the assist!

Yeah it did seem like there aren't a lot of tutorials in this realm especially on KZbin so I'm trying to add some coverage here. If i can't find any documentation or existing tutorials I learn by reading thru the Unreal source looking at how existing features work and experimenting. I did run into a blog on this particular topic that has some great information as well: easycomplex-tech.com/blog/Unreal-AssetEditor/ Thanks for watching!

Thanks for watching. I believe it will work in UE4 as well although I haven't tried it so there may be some differences you'll run in to. All the major graph/node/pin/property editor classes exist at least.

Yeah you can customize whatever you want. If you want to change how the line between the pins draws you can make your own FConnectionDrawingPolicy or use the existing one and change its parameters. SGraphPanel has a SetNodeFactory method. The FGraphNodeFactory has methods for creating the node widget, the pin widget, and the connection policy: virtual TSharedPtr<SGraphNode> CreateNodeWidget(UEdGraphNode* InNode); virtual TSharedPtr<SGraphPin> CreatePinWidget(UEdGraphPin* InPin); virtual FConnectionDrawingPolicy* CreateConnectionPolicy(const UEdGraphSchema* Schema, int32 InBackLayerID, int32 InFrontLayerID, float ZoomFactor, const FSlateRect& InClippingRect, FSlateWindowElementList& InDrawElements, UEdGraph* InGraphObj); So extend FGraphNodeFactory with your own struct and override CreateConnectionPolicy, then set your factory on the SGraphPanel with the SetNodeFactory method. If you want to completely change how things are drawn you can implement your own drawing methods in that connection policy. If you just want to change the color or thickness or whatever you can use the parent classes' connection policy and just modify some of its parameters before returning it in your overridden CreateConnectionPolicy method. See FConnectionParams in ConnectionDrawingPolicy.h for what you can change on the default version. You can see how the default FConnectionPolicy works in that file (and its corresponding cpp) as well if you want to just create a whole new class and modify the drawing code in it.

Thanks. For pushing the limits of bandwidth, there are a lot of limits to look at. The basic params to adjust this are: DefaultEngine.ini [/Script/Engine.Player] ConfiguredInternetSpeed=100000 ConfiguredLanSpeed=100000 - These set UPlayer::ConfiguredInternetSpeed and UPlayer::ConfiguredLanSpeed in Player.h [/Script/OnlineSubsystemUtils.IpNetDriver] MaxClientRate=100000 MaxInternetClientRate=100000 MaxNetTickRate=99999 DefaultGame.ini [/Script/Engine.GameNetworkManager] TotalNetBandwidth=600000 MaxDynamicBandwidth=25000 MinDynamicBandwidth=12000 Unfortunately at the end of the day the network system is tied in with the tick rate for some reason and this makes it hard to maximize bandwidth in general. If you notice above, MaxNetTickRate (which defaults to 120) limits how many times per second UNetConnection will tick, which ends up being the bottleneck. Even if you change that to 99999 it will still be limited by how fast your game is ticking in general but I was able to get up to 5MB/s by turning that up. It's also probably a bad idea to do that in the config file because you probably don't always want that since a high framerate would flood the network for all the other network related things when you probably only want this to apply to a specific transfer. For my use case this doesn't matter but if you just want to send the file as fast as possible you may need to modify the engine net code to give yourself direct access to a side channel on the same socket from a background thread or something unless there's another method I missed. You could always open a whole separate socket and send data on that but you would need a second open port to the server and then you could always have issues where 1 connection is alive and the other isn't that you would need to handle.

@@kirby561 wow tx a lot for that thorough answer- I will give it a shot^^ yeah I also was playing around with setting up a tcp connection and reading out the ip addresses from the steam session, but I guess I will stick around with your solution for now.. Still have a lot to learn

SAME i hope he make more tutorials like this

Thanks! You can create multiple links to a node by modifying UCustomGraphSchema::CanCreateConnection. In this tutorial it returns CONNECT_RESPONSE_BREAK_OTHERS_AB which enforces one link at a time but if you returned CONNECT_RESPONSE_MAKE there instead it would allow multiple links per pin. The reason I didn't is UCustomRuntimeGraph would have to support multiple links per pin as well, which adds a bit more complexity to the save/load piece so I left that out. It's not difficult to extend it to do that though if you need that functionality.

@@kirby561 Wow thank you so much. I'm looking forward to watching your next video in this series. I also have some problems to ask. May I have your any contact like Discord or email?

No real reason. Sometimes using std equivalents can be preferable if you don't want to tie part of your codebase to UE but in this case I was just more familiar with std::pair than TPair.

Sure. This one shows how to create a basic slate UI and add it to the viewport from C++: kzbin.info/www/bejne/oJauZ3eGd5qqm6M This one goes into a bit more depth about the syntax, macros, and how UMG wraps slate: kzbin.info/www/bejne/Z5-WoHycfpyheK8

@@kirby561 Thanks! I'll look at those if I need a bit more revision, but this tutorial and it's sequel are so good that I'm already feeling quite comfortable with slate!

Thanks for watching! I will address points 1-3 in the next video, looks like you have figured out 4!

@@kirby561 I seem to have already figured out all the points)) but I will be waiting for the lesson, it will be interesting to compare.

Thanks for watching! I think I am going to do a part 3 of this that will show how to use the asset at runtime and include some of the other little things requested in the comments here.

Thanks! I don't think there will be time to include this in the part 3 of this series but I will look into this for a future tutorial.

@@kirby561 OK, I'm very happy to see you release the third set of tutorials. I look forward to your next one. This is really useful. ： ）

Think I can find an example inside of the PCG module. I'll let you know

I can certainly take a look. Thanks for watching!

Thanks! These last 2 videos I did based on requests in the comments of my previous ones. I could show how to use it in the game for something I suppose although once you have the data loaded into a UObject it can be used for all kinds of things so I guess the point of the video would just be for closure showing these things are actually useful for something lol

@@kirby561 That's awesome! Can't wait for that~ Obviously, take your time. My own implementation also roughly did the same, "translating" all the logic laid out in the graph and gathering it as a usable UObject to use in game. I am not sure if it's the best practice, but hey. It works for me and my team at the very least.

I actually only used this for aesthetic purposes in my project so I didn't need collision. UPoseableMeshComponent doesn't work with collision by default so I assume you need to calculate your own primitives. Depending on your needs, you can probably just do a collision box from each bone to the next bone that is the width/height of the road and add that to your construction script. I'm not sure what you mean by "spline doesn't stay fully intact". Can you explain that a bit more?

@@kirby561 Ah.. That makes sense why I couldn't find collision details as usual. Still trying to get familiar with UE5. So not staying fully intact, I'll move out the control points of the spline but when I hit play then only a small segment shows on the map during runtime.

@@itsfreshson Hmm I'm sorry I can't reproduce that. Did you enable Use Attach Parent Bound on the poseable mesh? That's probably not it but the only thing that comes to mind.

@@kirby561 i do have it on but all good.. I appreciate your help and solid videos!

I'd first make a UCustomNodeData UObject to hold the data you want to be editable in the panel and make this a member of both UCustomRuntimeNode and UCustomGraphNode. Then add a new tab (maybe stacked vertically with the other properties editor) that has an IDetailsView like the other one (Or whatever custom slate UI you want). Whenever a node is selected, set the IDetailsView's working asset to the UCustomNodeData on the selected UCustomGraphNode. Note: To know when the selection changes, you can use the OnSelectionChanged delegate in the SGraphEditor we created in the primary tab. If you want to edit multiple node's data at the same time, make an IDetailsView for each node in the selection.

@@kirby561 I want to know where to define TSharePtr<IDetailView> and how to implement the transfer of IDetailView variables between AssetApp, SGraphEditor, and NodeDetailsTabFactory, because I encountered unexpected problems.😂