The Short Version
Override is not Push Back with new game pieces, and it is not High Stakes with a different field. The rule structure shifted in four places that meaningfully change what designs win. If you build a robot the way you built last year's, you will spend the season fighting your own assumptions.
The four areas where habits fight you most:
- Drivetrain power and PTOs — the rulebook closed off some old patterns.
- Endgame — there is no climb to optimize for.
- Stack-building and possession — you can't hold what you used to hold.
- Scoring priorities — the highest-leverage point source is something neither last season nor the season before had.
Each of the four sections below names the old habit, names what changed in v0.1, and gives a concrete recommendation. The last section is about how to read community claims about Override without getting led astray by speculation.
⚠️
Verified-vs-pending discipline. Where this page cites a specific rule (like R11b), that rule is in the v0.1 manual we've ratified. Where a topic is still open or speculative, the page says so explicitly. If you see a strategy claim that doesn't match the manual, ask a coach before building around it. See section 6 for the verification pattern.
What Changed in v0.1
| Rule | What it Says | Status |
|---|
| R11a |
Drivetrain motor power capped at 55W. Roughly 5 green V5 motors, or 4 green + 2 half-motors, or other equivalent combinations. |
Confirmed |
| R11b |
No power take-off (PTO) from the drivetrain. You cannot share a drive motor with a lift, intake, or any other subsystem. |
Confirmed |
| R10a |
Non-drivetrain motor power capped at 88W. Roughly 8 green V5 motors of equivalent budget for everything that isn't the drive. |
Confirmed |
Habit 1 — The "Just Add a 6-Motor Drive" Reflex
Old habit: 6-motor drive as the default starting point
In High Stakes and earlier, putting six green motors on the drive was a reasonable default. It gave you the speed and pushing force needed for ring-collection cycles and corner battles, and the rule structure allowed it.
What v0.1 says: 55W cap means 5 green motors max (or 4 + 2 halves)
A literal 6-motor drive is now illegal. Practical configurations:
4×11W green (44W, headroom remaining), or
4×11W green + 2×5.5W half-motors (55W, at the cap). See
override-drivetrain-config for the side-by-side and the recommendation.
What to do instead: start from the drivetrain config page. Pick Option A or B based on whether your match-end strategy values pushing power. Don't default to the old number.
Habit 2 — "Borrow a Drive Motor for the Lift"
Old habit: drivetrain PTO to share motors with another subsystem
Several past-season designs used a clutch or pneumatic shifter to redirect drive motor power to a lift, intake, or arm at specific moments — the drive doesn't need full power while you're lifting at a goal, so you borrow a motor.
What v0.1 says: R11b prohibits PTO from the drivetrain
Any mechanism where a drive motor also drives something else is illegal in Override regardless of how clever the shifting is. The rule is about the source, not the cleverness of the implementation.
What to do instead: allocate motors per-subsystem from the start. The 88W non-drive budget (R10a) is generous — an Architecture A manipulator uses 22W (lift + claw), leaving 66W for sensors, secondaries, and reserve. There is no need to scavenge from the drive.
Note on PTOs in general: a PTO between two non-drive subsystems (intake to lift, for example) is a separate question and isn't addressed by R11b. Whether such a PTO is worth building is a different conversation — for a middle-school program with limited fab time, the answer is almost always no, but it is not a rule prohibition.
Habit 3 — Treating "Motor Budget" as a Single Pool
Old habit: "we have N motors total, where do they go"
In some past seasons the drive and non-drive caps were softer or expressed as a single combined number, and teams thought of motor allocation as one budget.
What v0.1 says: two separate caps — 55W drive, 88W non-drive, with no transfer
You cannot move budget from one bucket to the other. A drive that uses only 44W of its 55W cap doesn't free up an extra motor for the lift — the unused drive watts just stay unused.
What to do instead: plan the two budgets independently. Pick the drivetrain config first based on match-end strategy, then allocate the non-drive budget across manipulator, secondaries, and reserve. Engineers should keep a written motor allocation table in their notebook from week one.
What Changed in v0.1
The Glossary defines "Endgame" as the last 10 seconds of the match. SG12 governs midfield rules. Robots inside the midfield boundary at clock-zero, while staying at or below the height limit, score endgame points. The alliance with the most robots inside the boundary at clock-zero claims yellow-pin points scored on the center goal.
⚠️
The opening GDC philosophy letter in v0.1 references "Final 20 Seconds." The Glossary and SG12 consistently use 10 seconds. Glossary plus SG12 are authoritative; the GDC letter appears to be an editorial holdover. We're watching the Q&A for clarification — until then, plan for 10 seconds.
Habit 1 — "Climb Mechanism as the Endgame Plan"
Old habit: dedicating a subsystem to a hang or climb
High Stakes rewarded a hang at match end. The climb mechanism was a real subsystem with real motor budget — a passive ratchet, a deployable hook, or a pneumatic latch that engaged in the last 10-15 seconds.
What v0.1 says: no climb structure exists in Override; the endgame is positional
There is nothing to climb on. The midfield is a flat zone. Points come from being inside the zone, not from elevating off the ground.
What to do instead: if you were planning to spend motor budget on a climb mechanism, don't. Reallocate that motor to the manipulator or to a secondary mechanism (toggle flipper or pin rotator). See
override-secondary-mechanisms.
Habit 2 — "Build for Maximum Reach Height"
Old habit: tall robots that fully extend at match end
In a climbing endgame, you want the robot to be as tall as possible while latched. Extension legality at endgame mattered.
What v0.1 says: robots inside the midfield must be at or below the endgame height limit, or they don't count toward the boundary score
Override flips the requirement. At clock-zero, the parts of your robot that count are the ones that are short enough. A robot stuck in tall configuration when the buzzer sounds doesn't score endgame points even if it's physically inside the boundary.
What to do instead: design your manipulator to be able to collapse reliably in the last few seconds. A 4-bar that can drop to a low rest position is fine. A cascade lift that can't fold down quickly is a planning problem — either retract from full extension to its base height before the buzzer, or accept that this robot is ineligible for endgame points and earn them elsewhere on the alliance.
Habit 3 — "Endgame Is the Lift Subsystem's Problem"
Old habit: endgame is solved by mechanism design alone
If the climb worked, the climb worked. Driver execution was mostly about timing.
What v0.1 says: endgame is a contested positional fight
The alliance with the most robots inside the boundary wins the yellow-pin tiebreak. Opposing alliance robots are also trying to be inside. This means pushing, blocking, and defensive positioning matter in the last 10 seconds — the kind of capability that comes from the drivetrain and the driver, not just the lift.
What to do instead: drivers practice endgame positioning specifically. Strategists plan endgame role assignment in match prep (which robot pushes, which holds, which retreats). The drive Option B (with half-motors for extra push power) becomes more attractive specifically because of this contested endgame.
What Changed in v0.1
SG6 limits each robot to at most 1 pin and 1 cup in possession at any moment. There is no exception, no holding-state-during-transit clause, no "passing through" the limit briefly. If the robot is in possession of 2 pins or 2 cups for any non-trivial duration, it's a foul.
Habit 1 — "Magazine-Feed Accumulator"
Old habit: intake collects N elements into a holding zone, then unloads
Push Back rewarded mechanisms that grabbed several blocks at once and ran them up to the goal in a single cycle. High Stakes rewarded ring stacks of multiple rings on a mobile goal. Both were "do many at once, then deposit" patterns.
What v0.1 says: 1+1 possession means no accumulation
A robot can carry exactly one pin and one cup. Mechanisms designed to hold three pins or four cups at once aren't just inefficient — they're illegal under SG6.
What to do instead: design for cycle speed, not capacity. Each cycle is one pin or one pin-plus-cup. The figure of merit is "seconds from loader to goal" multiplied by "number of cycles per match," not "max stack height per trip."
Habit 2 — "Wide Intake to Sweep Everything"
Old habit: wide passive intake that grabs whatever it touches
A wide front intake was efficient when the robot would later sort or dump everything as a batch. The robot didn't care which element it grabbed first.
What v0.1 says: elements are different and orientation-sensitive
Pins and cups are different shapes with different mass and different scoring rules. Cups have an opaque side and a transparent side — orientation matters. A wide passive intake that grabs whatever it touches will load the wrong element or the wrong orientation more often than not.
What to do instead: use a precise gripper, not a sweep. The V5 horizontal pincer in
mechanism-claw is sized for one element at a time. Loader handoff (where the human player presents the element vertically through a gate) does the sorting for you — the robot just needs to receive accurately.
Habit 3 — "Descore Opponent Goals as Defensive Strategy"
Old habit: a dedicated descoring mechanism aimed at opponent goals
In Push Back the descoring meta was central. A robot that could pull blocks off opponent goals quickly forced the opponent into rebuilding cycles, swinging the score by twice the block value (you didn't score it, they did). Specialized descoring mechanisms were a real subsystem.
What v0.1 says: SG9 + SG10 — opponent-goal removal is illegal
SG9 states that alliance-colored goals are protected: "Robots may not directly or indirectly interact with the opposing Alliance-colored Goals. This includes both Placing and removing Scoring Objects." SG10 extends this: "Robots may not remove Scoring Objects from Goals that do not match their Alliance color."
Combined: a robot can only remove scoring objects from goals matching its own alliance color. Red robots can remove from red goals only. Blue robots from blue goals only. Removing from a neutral goal or an opponent goal is a Major Violation.
What to do instead: the Push Back descoring playbook is dead. Don't build a descoring mechanism for going after opponent goals — you cannot legally use it. Removing from your own alliance goals is legal and occasionally useful (fixing a wrong-orientation cup, for example), but this is a corner case, not a strategy. Plan matches around outscoring opponents directly, and around toggle control to swing yellow-pin economics. Defensive value comes from positioning and toggle defense, not goal interference.
📝
The Push Back habit of "descoring is always good" is now structurally impossible because the rules prohibit it. Defense in Override means toggle control and endgame midfield positioning, not opponent goal interference. See
override-toggle-strategy for the toggle defense angle.
What Changed in v0.1
The yellow-pin and toggle mechanic, governed primarily by SC5, makes a quadrant's toggle into a points multiplier. Toggle in your alliance color: every visible yellow half in that quadrant is +10 points for your alliance. Toggle in the opponent's color: those same yellow halves go to them. Toggle in default (yellow): no points either way.
There's no analog to this in High Stakes or Push Back. Toggles are a new dimension of strategy.
Habit 1 — "Score the Highest-Value Element First"
Old habit: rank elements by base point value, score in that order
If a high block is worth more than a low block, score the high block first. Past-season prioritization was straightforward.
What v0.1 says: point value depends on toggle state
A yellow pin is worth 0 points or +10 points depending on whether your alliance owns the toggle in its quadrant. The same physical pin, in the same physical placement, has different point values depending on something happening at the perimeter wall.
What to do instead: score allocation has to factor in toggle state. If you've secured a toggle in your color, yellow pins in that quadrant become higher priority. If a toggle is contested, the safest scoring is in quadrants where the toggle is locked (yours or opponent's) rather than swinging.
Habit 2 — "Defense Means Blocking Their Goals"
Old habit: defense = stand near opponent goal, prevent placement
In games with point-dense goals, sitting near an opponent's primary scoring location was efficient defense.
What v0.1 says: toggles are the highest-leverage defensive target
Yellow halves are 62% of all pin halves on the field. A toggle in your alliance color, defended for the rest of the match, is worth more than blocking a single goal. Conversely, an opponent toggle that you can flip mid-match swings up to 30 points (3 yellow halves × 10 each, in a busy quadrant) without you ever placing an element.
What to do instead: add toggle defense to your match plan as a real role. The toggle flipper mechanism (
override-secondary-mechanisms) exists for offense, but a robot that can flip can also re-flip an opponent's flip. Strategists should have a plan for which alliance member covers each toggle.
Habit 3 — "AWP Is a Late-Match Optimization"
Old habit: AWP as a touch-up — build any autonomous, you'll clear the threshold
In some past seasons, the AWP threshold was loose enough that any reasonable autonomous routine cleared it. AWP became a late-match optimization rather than a primary autonomous design driver.
What v0.1 says: SC8 — AWP requires three concurrent conditions, no Violations Verified
The Autonomous Win Point is awarded to any Alliance that ends the Autonomous Period with all of the following, plus zero Violations during Auton:
- At least 7 Pins Placed for your Alliance (does not include Pins on the opposing side of the Autonomous Line)
- At least 3 Goals each containing at least 2 Pins for your Alliance (same Auton-Line restriction)
- Neither Robot contacting the Field Perimeter
This is a real autonomous design constraint. 7 pins in 15 seconds is roughly half-second-per-pin pacing — aggressive but achievable for a tuned routine. The 3-goals-with-2-pins constraint forces multi-goal coordination, not just dump-everything-on-one-goal. And the "not touching perimeter" clause means an aggressive auton path that finishes against a wall costs you the AWP.
What to do instead: design auton from the AWP requirements backwards. Plan a routine that hits 7 pins across 3+ goals on your own side of the Autonomous Line, ending in a position not touching the perimeter, with no rule violations. This is the autonomous spec for the season — everything else is an enhancement. See the
manual summary's AWP section for the rule cite.
⚠️
Championship-qualifying events (Event Region Championships, Signature Events, World Championship) may use slightly stricter AWP criteria starting with the Sept 3, 2026 manual update. Modifications will be minor — the manual gives examples like "8 pins instead of 7" or "4 goals instead of 3." Standard event criteria are not changing.
The Pattern
When a YouTube video, Reddit post, Discord message, or other team's notebook cites a rule by number ("Rule R23 says..."), do this before believing it:
- Open the v0.1 manual PDF.
- Search for the rule number ("R23").
- If the rule number doesn't exist in the manual, the citation is wrong — regardless of how confident the source sounded.
- If the rule exists, read what it actually says. Compare against the source's claim.
- If the source paraphrased correctly, integrate the information. If the source overreached or invented, ignore that source going forward and tell your teammates.
This sounds slow. It is fast in practice once you do it a few times. And it's a habit that pays off through inspection day — you'll catch your own assumptions before an inspector does.
Where Bad Information Comes From
Not maliciously, mostly. The pattern is:
- A YouTube creator gets the manual on day 1 and records analysis under deadline pressure.
- They guess at things the manual doesn't fully cover, or extrapolate from past games.
- Their guesses get framed with confident language ("Rule R23 bans..."), because uncertain language doesn't hold viewer attention.
- Viewers repeat the claim as fact.
- By week three, the wrong rule has become "common knowledge" in some Discord servers.
None of this is the creator's bad faith. It's the format. It's why you verify against the source.
Spartan's Running List of Unverified Claims
Things we've heard from community sources that don't match v0.1, or that we haven't confirmed yet:
| Claim We've Heard | Source Type | Status vs v0.1 (verified against manual) |
|---|
| "R23 bans anodizing and dyeing" |
YouTube influencer |
Substantively correct — R23 exists. Headline is "Visual decorations are allowed," but R23a explicitly prohibits anodizing, painting, dyeing, or changing the color of any legal VEX part. The influencer's title for the rule was creative; the substance was right. |
| "AWP requires scoring 7 pins" |
YouTube influencer |
Correct (with caveats) — SC8 requires 7 Pins Placed and 3 Goals with 2+ Pins each and neither Robot touching the Field Perimeter and no Auton Violations. The 7-pin number is right; just don't miss the other three concurrent conditions. |
| "PTO between intake and lift bypasses R11" |
YouTube influencer |
Wrong framing — the mechanism is legal (R11 only governs Subsystem 1, the drivetrain; non-drive PTOs aren't restricted), but it's not "bypassing" anything because R11 doesn't apply to Subsystem 3 in the first place. Practical question for our team: complexity vs. payoff makes this a poor investment under the 1+1 possession limit. |
This list will grow during the season. When you encounter a claim that doesn't match, send it to a coach to add here.
Where to Trust
The reliable sources for Override rules, in priority order:
- The manual PDF itself. v0.1 is the floor. Future versions (v0.2, etc.) supersede.
- The official VEX Q&A. Opens May 14, 2026. Once it's open, Q&A rulings are authoritative.
- Anything else. Verify before believing. Discord, YouTube, other teams, even other coaches — not bad sources, but sources to check.
💡
If you're ever unsure whether a rule applies, ask a coach. If a coach is unsure, the answer is "let's look at the manual together." That's never wasted time.
← Back to Override v0.1 Manual Summary