-
Creating a console command is super easy.
FAutoConsoleCommand MyCommand(TEXT(“Doit”),
TEXT(“This command makes awesome happen”),
FConsoleCommandWithArgsDelegate::CreateStatic(&MyCommandExecuted));
static void MyCommandExecuted(const TArray< FString >& params)
{
}
For parsing the parameters I found FParse::Value. It might be worth adding a comment to the comment for the FAutoConsoleCommand class letting you know the unreal method of parsing strings.
-
The current method of adding to the context menu of the viewports is good. A similar paradigm for all context menus would work fine I think.
-
It would be nice if the widget created by a MenuBuilder when calling AddMenuEntry were returned by the call, that way I could tweak things like text color. I know I could construct an entirely custom widget, but that seems like a big hammer for a small nail.
-
I had the opportunity while working on my plugin to mess around with the reflection system a bit. One FUNC_* flag I would love to see added is FUNC_BlueprintCompilerGenerated. Any function not explicitly created by the user in their blueprints would have this flag. FUNC_BlueprintCallable is very close to this but things the compiler generates like the UserConstructionScript would have the above flag as well.
-
Speaking of the reflection system, I’m sure it’s one of the more power-user portions of the engine, but I think if it were well documented you’d see a ton of tools use it.
-
I made a plugin that in SIE mode allows you to just click on objects and trigger any built-in C++ event, like OnActorTouched, for any that don’t currently exist in the engine, would need to be handled by another plugin extending my plugin’s extension point. You can also call any parameterless event added by the blueprint system.
I thought it would improve blueprint scripting workflow to be able to test them out faster. Instead of jumping in and out of the game an event can now be triggered directly.
Here’s a screenshot and I’ve attached a video (in a zip file) of the plugin in action. I wish I could embed a video directly.
[Download Video Here][2]
Stuff I’m planning to try next:
A) Creating custom asset types.
B) Dockable Windows (probably super easy)
C) Creating a custom properties control to appear in the Details tab.
D) Can custom SCC plugin be created (I cursory look says, yes, but unfortunately there’s no way to select which one will be used by the editor by the user).
RE: (4). The absence of FUNC_Native is a pretty good indicator, but will include events declared in C++ as BlueprintImplementableEvent, even if they haven’t been implemented in the derived class (still safe to call though). Alternatively, Function->GetOuterUClass()->ClassGeneratedBy != NULL indicates that it was implemented in a blueprint.
RE: (6) Very cool! This is something we’ve been planning on adding but haven’t had the chance to yet.
Cheers,
Michael Noland
Nice, function->GetOuterUClass()->ClassGeneratedBy == NULL filters out K2_DestroyActor and EndControl. When combined with also requiring it have the flag, FUNC_BlueprintCallable, filters out things like generated functions for Timeline events. With those two filters, I catch everything except for UserConstructionScript. A “BlueprintInternal” flag would certainly be clearer, though to be fair that “internal” flag pretty much only services my plugin or something like it.
As a heads up, there is a list of keywords and common metadata in ObjectBase.h. UserConstructionScript() and other similar internal machinery will have a metadata tag ‘BlueprintInternalUseOnly’.
Usage:
bInternalUseOnly = Function->GetBoolMetaData(FBlueprintMetadata::MD_BlueprintInternalUseOnly);
However, you probably want to use UEdGraphSchema_K2::CanUserKismetCallFunction() instead, which wraps up several checks together (not internal use, blueprint callable, not deprecated, etc…)
Re: 2) Good to know! Currently in progress.
Re: 3) We do not allow custom colors/fonts/etc. in the menus to keep all menus throughout the editor consistent and simple. If we truly do need custom styling, then we require use of an entirely custom widget, because it is such an edge case. What exactly was the issue that you were trying to solve?
Well, it is mostly an issue of attention. I’m not looking to corrupt Rocket’s beautiful emo style’n 
but when it comes to displaying a list of items I like being able to draw attention to items that are more important…within reason.
Specifically - functions that have been overridden in the object, or have listeners which was the case for the builtin events. I thought it would be better to bold/or make slightly brighter the text color of the methods who have been specifically implemented on the object or in it’s blueprint graph. Similar to how VAX / VS do it for intellisense.
The idea being, if I’m just clicking around the level trying things out, wouldn’t I want to know what events are supposed actually have an effect on the object?
Generally, when some items in a menu are more important than others, we usually keep them at the top, in their own section, or in their own subsection. For your specific use case, one of these solutions sounds like it would solve your problem just fine. We prefer to keep a simple UI framework, and to allow complexity in the form of custom widgets only, rather than overloading every control with custom controls and stylings. In this way, the editor stays consistent, and only one off cases need custom styling.
That is really awesome! Actually quite a useful tool, too. Nice work! And thanks for the valuable feedback.
I forwarded your video along to some of our team members.
The next Rocket beta will have initial support for “plugins”. You’ll be able to create plugins that you can drop into a Rocket project or alongside the engine itself, and they will be discovered and loaded automatically. It’s still early days with the feature, but it should be functional enough that you can try it out with your editor extensions.
–Mike
Sounds good Mike, I will certainly post my plugin after the next beta for people to try out. It’s certain to have even more goodness in it by then.
