Same Lesson, Different Teacher: Romero Blueprints on Verse Operators
When you're learning a new language, hearing the same topic taught by two different teachers shrinks your blind spots dramatically. Renowned UE educator Marcos Romero has a systematic walkthrough of Verse operators on his blog, and his conclusions line up closely with Lesson 13 — this page speed-runs his take, and borrows his example to drive the "parentheses cut in line" point home one more time.
1. Who This Teacher Is, and What He Covers
Marcos Romero is one of the most seasoned educators in the UE community; his "Romero Blueprints" blog raised a whole generation of Blueprint learners, and these days he writes systematically about Verse too. His operators piece walks the button map in three big groups: arithmetic (+ - * /), relational (< <= > >= = <>), and logical (or and not) — a grouping nearly identical to Lesson 13's, but with a completely different set of examples and phrasing, which makes it perfect for hunting down gaps.
Most notably, he arrives in his own words at the same two core conclusions as this course: first, the result of a comparison is "goes through" or "doesn't go through", not True / False; second, querying a logic (Boolean) value with ? means that step doesn't go through when the value is false. Two textbooks, two phrasings, one and the same meaning — once you've verified the same rule from independent sources, you can safely commit it to muscle memory. That's exactly the value of reading community material: cross-validation.
2. His Precedence Table Matches Ours
Romero also lays out a high-to-low precedence table in the article: ? and not at the very top, followed in order by * /, + -, the comparison operators, and, or, with assignment ranking lowest. Check it tier by tier against Lesson 13's cheat sheet and the order matches exactly — two independently compiled tables corroborating each other means the one you memorized won't let you down.
That "assignment ranks lowest" line also happens to explain an everyday phenomenon: why set Result = 5 * 2 + 4 always finishes computing the entire right-hand side before dropping the result into the slot — every operator to the right of the equals sign outranks assignment, so by the time assignment gets to move, the right side has long since settled.
The house rule still applies, of course: for the precise order of certain adjacent tiers, defer to the full table in the official Verse Language Quick Reference; and when a real project throws a complex expression at you, just add parentheses and put "what computes first" out in the open.
3. "Parentheses Cut in Line" in Two Lines of Code
Romero uses a minimal pair of contrasting examples to show how parentheses override precedence — worth copying straight into your practice project and running:
using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }
priority_demo_device := class(creative_device):
var Result1:int = 0
var Result2:int = 0
OnBegin<override>()<suspends>:void =
set Result1 = 5 * 2 + 4 # multiply first, then add — gives 14
set Result2 = 5 * (2 + 4) # parentheses cut in line — gives 30
Print("Result1: {Result1}")
Print("Result2: {Result2}")
Graph translation: in BeginPlay, two Set nodes compute Result1 and Result2, then two Print Strings print them out. The only difference is that pair of parentheses: the top line 5 * 2 + 4 has none, while the bottom line wraps "2 + 4" in parentheses so it computes first.
Same three numbers, same two operators — one pair of parentheses swings the result from 14 to 30. * outranks +, so 5 * 2 + 4 is "multiply first, then add"; and ( ) stands at the summit of precedence — whatever it encircles computes first. Whenever you find these "instantly obvious" mini examples in someone else's material, stash them in your own example library — the day you explain precedence to a teammate, one side-by-side line beats ten sentences of explanation.
4. Two Common Pitfalls That Fall Out of the Table
Pitfall one: not only bites the very next thing. In both tables not stands on the top tier, and ranking high means binding tight — not A and B reads as (not A) and B, not not (A and B). To negate the entire combined condition, you have to write not (A and B) yourself. And a quick recap of Lesson 13's warning: whatever sits inside not lives in a "can fail to go through" check, and any changes made in there are always rolled back — a set (Set node) in there leaves no trace whatsoever.
Pitfall two: and and or rank below the comparison operators. This one is actually good news — if (A > 0 and B > 0): reads the way intuition says: each comparison computes on its own first, then hands off to and, no need to wrap every comparison in parentheses the way some languages demand. Flip it around, though: once a condition mixes in three or four ands and ors (remember, and ranks one tier above or), reading that string of conditions off a memorized table starts testing your teammates' patience. Romero and the official docs speak with one voice here: complex conditions get parentheses — don't make whoever reads them look things up for you.
5. Pop Quiz ★
After set Result = 2 + 3 * 4 runs, what is the value of Result?
This page is adapted from Marcos Romero's blog post: UEFN Verse: Operators — Romero Blueprints ↗