(super:) — The Easiest Call to Get Wrong in Verse

1. The Scene: After an Override, Where Did the Parent's Lines Go?

Lesson 20 taught you: once a subclass overrides a parent method with <override>, calls run the subclass's new version — the parent's implementation is completely stomped. But in practice, the more common need is "adding to the scene" rather than recasting it: the parent's welcome line plays as usual, then the subclass appends a VIP-only line of its own. The classic question on the Epic developer forums is exactly this scenario — the parent's Test() prints Parent, the overriding child prints Child, and the asker wants both lines printed.

If you normally live in node graphs: when you want an Overridden function to keep the parent's original behavior, you right-click and choose "Add Call to Parent Function". Verse has no such right-click menu — instead there's one short piece of syntax: parentheses plus a colon:

using { /UnrealEngine.com/Temporary/Diagnostics }

greeter := class:
    Greet():void =
        Print("Parent: welcome to the arena!")

vip_greeter := class(greeter):

    Greet<override>():void =
        # Run the parent's original implementation first, then append the subclass's new logic
        (super:)Greet()
        Print("Subclass: VIP lane right this way~")

Translating the drawing: vip_greeter is a child blueprint of greeter, and it Overrides the Greet function graph. That (super:)Greet() at the top of the graph is the equivalent of Blueprint's "Add Call to Parent Function" — first run the parent's welcome line, then wire in your own Print String for the VIP line. So at runtime you see two lines: the parent's first, the subclass's second.

Call vip_greeter{}.Greet() and the log prints two lines in order: first the parent's welcome, then the VIP line. (super:)Greet() reads as "go up to the parent's level and dig out the parent's Greet to run" — this is the accepted answer in that forum thread, and the answerer backed it up with the official Subclass in Verse documentation.

2. Why Parentheses Plus a Colon?

Don't let (super:)'s odd look scare you; what it means is humble: "go look at the parent's level." In Verse, "parentheses + name + colon" is a whole family of "which level to look in" spellings (there's also a (local:), meaning "look right here at the local level"). (super:)Greet() in plain words: don't look for Greet inside your own blueprint (you'd only find yourself — the function graph endlessly calling itself, instant lock-up), but go one level up to the parent blueprint and dig out the parent's Greet to run.

Two usage limits to memorize. First, (super:) may only appear inside an overriding method — outside a class, or in a method with no override relationship, it means nothing. Second, it calls the immediate parent's version; you can't use it to "skip a generation" and reach a grandparent's implementation. The most typical everyday use is keeping the parent's behavior when Overriding an engine event (like BeginPlay), then layering your own logic on top — exactly the same idea as Greet here.

While we're at it, defuse these — every one of them turns Compile red in Verse: super.Greet(), Super::Greet(), super:Greet() (those are spellings from other languages/engines). Only (super:)Greet() is right: parentheses, super, colon, immediately followed by the function you're calling — drop any one part and it breaks.

3. Classic Pitfalls: When (super:) Errors, the Root Cause Is Usually the Override

If you've only ever wired nodes in Blueprints, one glance at this "how other languages write it" table is plenty — the only row you actually need is the last one, Verse; the rows above exist to rewire people arriving from code, and you can skip them.

The other high-frequency errors aren't really about (super:) itself but about its prerequisite — the override. Verse demands that overrides be explicitly declared: forget <override> on the subclass method and Compile goes red, complaining the parent already has this member, because it treats your new method as an illegal duplicate name; conversely, hang <override> on a method that doesn't exist in the parent at all and that errors too — there's nothing to override. The function signature must also match the parent exactly — mismatched input or output pins turn Compile red. Only once all three gates are cleared does (super:) have a place to stand: it can only live inside a legal overriding method, pointing at the original implementation you stomped.

4. Pop Quiz ◇

Sources & Further Reading

This article draws on the Epic developer forums and official documentation:

▸ Forum Q&A: How to call parent function from an overridden function ↗

▸ Official docs: Subclass in Verse ↗