DevLog 20250507 Bringing Smart Suggestions and Smarter Search to Divooka’s Visual Coding

Question

Learning from Unreal Engine Blueprints

I’ve always admired Unreal Engine’s Blueprints - particularly its subtle yet powerful connection suggestion feature. When you drag a wire out from a pin, the system intuitively suggests compatible nodes based on the pin’s data type.

This kind of context-awareness accelerates creation and keeps workflow fluid by making things just work - no guesswork needed.

The Challenge: Missing Type Labels in C# Instance Methods

Divooka, built atop C#, posed a snag: instance methods don’t include the object’s type in their signature. So if a method like Rotate() belongs to a Transform object, the type isn’t explicitly declared in the method signature - making automatic suggestion tricky.

To match Unreal’s intuitiveness, I needed a way to tell Divooka - not just "Rotate()", but Rotate() on Transform.

Explicit Type Filter in Search Syntax

The first step is to allow users to filter the toolbox explicitly in their search query.

For example: [Pixel Image] Save would filter for methods in the Pixel Image toolbox (category). The symmetry of this syntax remains intuitive even in localized languages like Chinese - because only the type would be translated, not the syntax design itself.

Building the Pipeline: Filtering and Highlighting

Next, I leveled up the search experience by crafting a multi-stage pipeline:

• Category names (like [AI Service], [Pixel Image]) now at the front, so users can scope their search by purpose.
• Then we optionally parse <TypeName> syntax, which is used to filter input parameters.
• Finally, full-text search for other keywords.

So a query might look like:

[Pixel Image] <String> Save

In which case we will search only for functions containing the word "Save" and expects a String parameter. Visually, I emphasized that first category tag with syntax highlighting to help the eye quickly scan.

The Result: It Just Works (Mostly)

Here’s how it currently looks:

1. Type [Pixel Image] Save.
2. The search autocomplete suggests all instance methods named Save...() defined in Pixel Image toolbox (mostly operating on the PixelImage object type) (e.g., PixelImage.Save, PixelImage.Load, etc.).
3. Everything lights up in palette instantly - users can find what they need fast.

What’s Missing: Auto-Connecting Suggestions

This solves the searching half of the problem beautifully - but it doesn’t yet auto-connect. In Unreal, dragging from a Vector pin might instantly suggest Normalize() - and connect it for you if you click that suggestion.

Right now, Divooka still requires a manual drag-and-click - our intention was only searching and filtering, not full drag-and-drop automation.

Next Steps: Toward Full Contextual Suggestions

I’m plotting the future:

• Pin-aware suggestion: When dragging a wire from a pin, immediately filter down to matching methods—and optionally even pre-wire the node when hitting “Enter” or double-clicking.
• Type inference: Avoid requiring <Type> if the context is obvious - since the system already knows the pin’s type.
• Better localization: Make sure category tags and type filters localize cleanly, without mangling grammar in languages like Chinese, Japanese, etc.
• Enhanced UX hints: Perhaps grey-out non-matching nodes live, or provide quick tooltips (e.g. “only shows methods on Transform”, like Unreal Blueprint's node search interface).

Summary

Previously, instance-based methods don’t expose their object type; this hampers auto-suggestion. We solved this by introducing explicit <Type> filters and category tags in our search syntax. The result is now the users can quickly locate relevant methods with filtered search - instant clarity. Up next, we want to add full context-aware, auto-connecting suggestion - move from “search” to “smart connection.”

Conclusion

Unreal Blueprints’ delightful node suggestions inspired us to refine Divooka’s search. By introducing syntax like [Category] <Type> Keywords..., Divooka now lets you filter instance-based methods explicitly - greatly improving discoverability. Coming up: auto-connection and smarter, context-aware wiring.

Let me know if you are interesting in learning more specific implementation details - like the regex matching, indexing logic, or localization strategy!

Happy visual coding!

Comments

Really cool update! The explicit type filters and category syntax sound super useful for speeding up workflow. How close are you to implementing the auto-connecting suggestions like Unreal Blueprints?

---

Hi James, thanks for the comment!

We are half-way through auto-connecting suggestions in that once a suggestion is selected, we already know its signature and parameter types. This is a low-priority feature since with filtered search is handy enough for practical use and we have other more important language-level things to work on first. On the other hand, the auto-connecting part just needs some convention to automatically tries to connect the new node’s most relevant input/output to the pin you dragged from, and we have some pretty good idea on what it should be.

To implement this, in general:

• If the user drag from an output pin into empty graph space and search, Divooka should assume the user want to connect that output into the next node’s input.
• Conversely, dragging from an input pin into space makes Divooka should assume the user is looking for an upstream node that will produce a compatible output.

There could be several special cases to this, as below.

Execution Pins

In procedural context,

• If the user drag from an execution output pin (white arrow), the newly placed node’s (first) execution input pin should be auto-connected.
• If the user drag from an execution input pin, the new node’s (first) execution output pin will connect instead.

Data Pins

In both dataflow and procedural contexts,

• If the user drag from a typed data pin (like Float, Vector, Object):
  • The search menu is filtered to show only nodes that accept that type.
  • When the user select a node, Divooka should auto-connects the pin the user dragged from to the “best matching” input pin on the node (usually the first input of that type).
• If the types don’t directly match but can be implicitly converted (e.g. Int → Float, or Actor → Object), Divooka should will auto-insert a conversion node (like Int to Float or Cast To) between them.

Auto-Casting

Divooka already automatically handles marshalling of compatible data types but sometimes we may wish to make such conversions explicit on the graph:

• If the user drag from an Object Reference pin and place a node requiring a more specific type, Divooka should probably insert a Cast node automatically.
• For primitive types, simple implicit conversions are automatic on the input pin itself (like Byte → Int).

In summary: auto-connection is contextual - it connects execution to execution, data to the best matching input/output, and inserts conversion nodes when necessary. With above rules we have some good convention as starting point, the next step is just to implement it!