Offense / Operation Dashboard

Operation Dashboard¶

Prepare targets and attacker assignments, solve a timed operation plan, publish it and coordinate each account’s attacks.

At a glance¶

Product route: /workspaces/{workspace_id}/operation-calls/{call_id}, opened from Operation Calls.

Who can open this page: signed-in users in an enabled workspace with verified membership (including owners). Non-owners require active membership and collection; verified owners bypass the individual grant, not entitlement or verification. HTML viewing uses this gate and workspace-scoped call lookup. Dashboard data additionally resolves the current linked Travian account. Navigation visibility is not authorization.

Call ownership means the saved owner account name equals that current account. The call owner and workspace owner may see every participant and Operation Attacks; other accounts see their own signup and personal commands. Only the call owner receives the full plan, target lists and planning controls. Workspace ownership alone never grants these edits.

What you see¶

The header shows title, owner, joined count and Fighting against alliances. Lifecycle controls which tabs and actions are available. Owner controls offer Close sign-up during the actual open window and Delete operation. The six tab labels remain, but availability follows role and lifecycle:

Target cards show account, village/coordinates, alliance and tags with game profile/map/alliance links when identifiers exist. Coordinate real targets may have Manual target/unknown roster labels. Registry options are filtered to the call’s Fighting against alliances; zero configured alliances means no such registry options. The capital-pool count lives in Settings; its generator uses the configured alliances and one-wave candidates. Candidate target waves and per-command waves are different: solved fake commands begin at wave1.

My Attacks columns are target Village, target Account, Timer, Send time, Impact time, Type, Waves, Link and sent confirmation. A rally-point link prepares the source village and troop selection in Travian; it does not send troops. Real links use current captured source troop counts, while fakes use the saved/default eight-slot composition. Missing source village ID or dispatch helper makes Link Unavailable. Eye-artifact classification automatically uses the Eyes composition for a small Eye’s village or a large/unique Eye owner’s villages. Selecting the Default/Eyes mode chooses the composition editor; the target’s classification chooses the actual fake link composition.

Both compositions must contain at least one troop. Default unsaved composition is t1=19,t8=1. Eyes defaults: Romans t3=17,t5=1,t7=1,t8=1; Teutons t1=17,t6=1,t7=1,t8=1; Gauls t2=17,t6=1,t7=1,t8=1. Unsupported tribe falls back to Default. These are link configurations, not troop-availability validation.

Who fills in each field¶

Calculations¶

Operation lifecycle¶

Calculation ID: operation.lifecycle. Five states from signup time and stored publication/start state.

The sequence is Sign-up → Preparation → Ready → In progress → Completed. Join eligibility separately requires the inclusive start/end window; the Sign-up label tests only the end. Publication clears readiness and records published state. All assigned non-owner accounts with real or fake send times form the readiness quorum; the backend starts when all are ready. With none required, publication starts immediately. A not-yet-started published plan stays Ready, even after its scheduled impacts.

now<=signup_ends_at => sign-up; plan_data is None or status draft/finalized => preparation; status published without startedAt => ready; otherwise now>latest impact => completed; otherwise in-progress. Latest impact is max valid lastImpactAt, assignment impactTime and fakeCommands impactTime; absent valid times falls back to end of last operation day.

Output: state label. Precision: Exact ordered state decisions. Rounding: No rounding. Clamp: No output clamp. Timezone: UTC; naive parsed impacts assigned UTC.

Signup boundary equality remains sign-up. Latest-impact equality remains in-progress; completion is strictly later. Unknown/missing plan status is legacy in-progress unless completion time has passed. No operation days and no valid impact yields no completion timestamp.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Overview, Operation Calls, Operation Dashboard.

Wrapped map distance¶

Calculation ID: map.wrapped-distance. Shortest Euclidean distance on a toroidal Travian world.

Choose the shorter direct or map-edge distance on each axis, then the Euclidean length. On the default map, synthetic (−200,0) to (200,0) is one field. Coordinate acceptance does not make this helper a world-bound validator: the calculation assumes coordinates within the configured world.

size=2*radius+1; dx=min(abs(x1-x2),size-abs(x1-x2)); same for dy; hypot(dx,dy). Default radius200 means401coordinates per axis, so -200 and200 are adjacent.

Output: fields. Precision: Floating point hypot. Rounding: No rounding. Clamp: No output clamp. Timezone: not-applicable.

Same coordinate returns zero. Assumes coordinates in the configured world; this helper does not validate/wrap arbitrary out-of-world values. Browser radius null also defaults200; mirrors are separately hashed and not proof of equivalence.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Villages, Def Calls, Counter Scout Plan, Artifacts Registry, Operation Dashboard.

Server troop movement multiplier¶

Calculation ID: server.movement-multiplier. Map hostname speed labels to actual troop movement scaling.

The hostname speed label is not the movement multiplier. .x3. gives movement ×2; .x10. gives ×4; no recognized label gives ×1. The backend supplies this multiplier to browser and extension dispatch. Unsupported tribes use the Roman unit-speed table.

Regex .x(\d+). yields server label (default1); mapping {1:1,2:2,3:2,5:2,10:4}, unknown label=>1. Movement is not linear with server speed.

Output: speed multiplier. Precision: Exact integer. Rounding: No rounding. Clamp: No output clamp. Timezone: not-applicable.

No xN label defaults1. Unknown speed labels fall back1. Browser/extension dispatch consumes the backend multiplier, rather than copying the hostname map.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Def Calls, Counter Scout Plan, Operation Dashboard.

Tournament Square travel¶

Calculation ID: travel.tournament-square. Platform one-way travel seconds using slowest troop speed and TS after20fields.

Let d be wrapped distance, v the slowest positive-count troop’s base fields/hour times the server multiplier, and L the saved signup TS. The first 20 fields use ordinary speed; only the remainder gains 1+0.1L. Multiply hours by 3600. Synthetic distance30, v10, TS10 takes9000 seconds. Planning uses every positive captured troop type, not a manually chosen attack composition. No captured troops means missing travel entries. The planner rounds one-way seconds with Python round (ties to even); browser travel labels round minutes, with at least one minute for positive travel. No hero/artifact movement bonus is applied. The farm-list extension variant uses 20% per TS level and round-trip minutes, so it is not interchangeable.

d=wrapped distance; d==0 =>0 before speed validation; v=base_speedspeed_multiplier; v<=0 raises; d<=20 or TS<=0 =>3600d/v; otherwise3600(20/v+(d-20)/(v(1+0.1TS))). Caller chooses slowest present selected unit. Operation planner rounds one-way seconds to integer. Related extension farm-list variant uses0.2TS, clampsTS0..20, returns round-trip minutes and is not interchangeable with this platform formula.

Output: one-way seconds. Precision: Floating-point seconds; planner uses integer seconds. Rounding: Python round(seconds) in planner; browser display varies: operation travel rounds minutes with minimum1 for positive travel, defense countdown floors absolute seconds. Clamp: No output clamp. Timezone: Travel duration independent of timezone.

Zero distance returns0 even with invalid speed. Unknown/empty speeds: platform raises on nonpositive speed; browser dispatch returns null, operation mirror Infinity. Farm-list mirror is a related divergent20% round-trip variant outside web guide scope; do not describe it as equal. No hero/artifact movement bonus is applied by these formulas.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Def Calls, Counter Scout Plan, Operation Dashboard.

Alliance capital fake pool¶

Calculation ID: operation.fake-pool. Deterministic top-player-capital candidates per configured alliance.

Rank eligible players within each configured alliance by total population across all roster villages, including non-capitals. Require a known capital outside real/manual-fake exclusions. If more than one eligible capital exists, choose greatest capital population, then lowest village ID. Player ties use case-folded name ascending, then player ID ascending. Take at most N per alliance; manual fakes survive replacement. The current web caller emits one wave for generated candidates, preserves manual fakes with N0, and errors when N>0 yields no eligible capitals. Fewer than requested is valid when only some players qualify.

Casefold alliance keys; sum population over all player villages; eligible player needs nonexcluded capital. Multiple capitals choose largest population then smaller village ID. Rank player by descending summed population, casefold name,player ID; take count_per_alliance per alliance, emit capital tags and configured waves. Existing manual fakes survive prior generator replacement.

Output: fake target records. Precision: Exact stable ordering. Rounding: No rounding. Clamp: No output clamp. Timezone: not-applicable.

No eligible capital =>player omitted. Capital pool input default10per alliance, allows0..100. Manual selected and real-target coordinates are excluded by caller; real targets are not silently generated.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Operation Dashboard.

Operation impact grid¶

Calculation ID: operation.impact-grid. Inclusive discrete UTC arrival grid derived from send windows plus travel.

Saved availability is sending time, not arrival time. Each hour label becomes a UTC half-open interval [hour,hour+1h). Floor the earliest send epoch to the configured step; ceil the latest send end plus maximum integer travel to that step. Include aligned endpoints in the integer epoch-second grid. For synthetic bounds0…1200 seconds with step600, slots are0,600,1200. Arrivals may lie on later dates than the selected sending days.

Caller maps saved availability slots into1-hour [start,end) UTC windows; floor earliest send epoch to step and ceil(latest send end+maximum integer travel) to step. build_impact_slots uses int(start.timestamp()),int(end.timestamp()),range(start,end+1,step). Impacts may be on later days than sending availability.

Output: UTC epoch seconds. Precision: Exact integer. Rounding: Caller floor/ceil to step; integer timestamp truncates fractional seconds. Clamp: No output clamp. Timezone: UTC.

End included only when aligned with step. End before start or nonpositive step invalid. Input availability timestamps without timezone are assignedUTC.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Operation Dashboard.

Operation plan feasibility¶

Calculation ID: operation.feasibility. Possible arrivals/commands respecting travel, send windows, fake bounds and cooldown.

For every real target, choose one arrival shared by all assigned offender villages: each needs recorded travel and send=impact−travel inside at least one saved half-open window. Exactly K distinct slots are used. Candidate fake destinations include the explicit fake pool and real targets; an offender cannot fake its own real target. Its selected fake arrives at the same time as its own real command. Apply each village’s min/max fake counts and the group’s common-fake intersection. Reserve each selected real/fake command interval [send,send+cooldown) without overlap per offender village; intervals may touch, cooldown0 disables this constraint. Different villages of the same account are not merged for this check. An unassigned real target still has a grid choice but no village commands.

Real target slot feasible only if every assigned offender has travel and impact-travel in a half-open availability window. Fake for offender must differ from own real target, have travel and share its real arrival slot with available send. Model chooses exactly one slot per real target and exactlyK used slots; per-offender min/max selected fakes; group intersection>=shared_fakes; selected real/fake commands reserve [send,send+cooldown) with no overlap.

Output: feasible combinations and plan status. Precision: Integer second decisions. Rounding: No rounding. Clamp: No output clamp. Timezone: UTC integer epoch seconds.

Missing travel creates no variable; no fabricated0travel. Availability end equality is excluded. Cooldown equality is allowed; zero cooldown disables overlap intervals. Configured real targets without assigned offenders retain target impact selection. Insufficient feasible fakes/shared fakes produce diagnostics, not relaxed successful plans.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Operation Dashboard.

Operation plan optimization¶

Calculation ID: operation.optimization. Smallest feasible impact count followed by lexicographic objectives.

Try K in ascending order up to the minimum of configured max impacts, real-target groups and grid slots. Return the first feasible result. After initial feasibility, minimize arrival span, then the worst village send span, then the sum of village send spans, then total fake commands, fixing each proven optimum before the next stage. Despite internal player labels, spans belong to offender villages, not merged accounts. The web budget is30 seconds per K, default8 workers; initial feasibility gets70% of that budget. Unknown lower K means smallest impact count is unproven. A later UNKNOWN/INFEASIBLE preserves the last feasible solution; FEASIBLE ends optimization without proving the remaining objectives. Minimal-count proof and complete optimization are separate flags. Diagnostics suggest relaxations, but do not change constraints automatically.

Try K=1..min(max_impact_times,real-target groups,grid slots). For eachK reserve max(0.01,70% budget) for initial feasibility; then minimize impact span, worst offender send span, sum offender send spans, total fake count sequentially, fixing each proven optimum before next stage. First feasibleK returned. Unknown lowerK means minimal impact count unproven. Later UNKNOWN/INFEASIBLE preserves last feasible solution; FEASIBLE stops without declaring optimal. Default solver8workers/10seconds; web call overrides budget30seconds perK.

Output: plan, statistics and proof flags. Precision: Integer objectives; time budget floating seconds. Rounding: No rounding. Clamp: No output clamp. Timezone: UTC command/impact timestamps.

Returning FEASIBLE does not prove lexicographic optimum. Unknown lowerK invalidates minimal-count proof. No feasibleK returnsUNKNOWN if any attempt unknown, otherwiseINFEASIBLE. Relaxation order is diagnostic guidance only; solver does not auto-relax constraints. Objectives measure offender-village send spans, not a merged account-wide span.

Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.

Used on: Operation Dashboard.

Freshness and updates¶

Dashboard data loads on entry and after the relevant target, plan, publication, readiness and other actions. Confirmation/configuration handlers also update their local personal view. There is no recurring dashboard-data poll in the current script: one-second timers update the display from browser time, not fresh captures. Reload to see another member’s later changes. Offender cards read current captured troops/tags, saved signup overrides, roster labels and dispatch identifiers; none implies live troop availability in Travian.

Send availability labels are UTC whole hours despite their timezone-free saved strings; legacy date-only entries expand to24 hours. The display of those hours groups strings directly. Computed send/impact instants are UTC and format in the browser’s local timezone with seconds. The declared-impact datetime input is local, then submitted as UTC and normalized to whole seconds. Countdown floors absolute seconds and shows a minus sign when overdue; declared difference is declared−scheduled, rounded to the nearest absolute second and signed. No declaration displays Not declared. The backend receipt timestamp is independent from that claimed impact. Lifecycle completion uses scheduled impacts, not declarations or whether every command is marked sent.

The effective input hash includes sorted assignments, saved availability, signup TS, tribe speeds, captured troop presence (positive/zero, not exact counts), target coordinates, movement multiplier and all advanced settings. Changing wave text or position alone does not change it. An identical hash blocks repeated solving. Target add/remove or fake-pool coordinate/count changes clear a non-draft saved plan; draft state is retained. Editing signup does not automatically invalidate a finalized plan, so recompute after changed inputs before publication. The publish handler does not recheck the input hash.

Actions and permissions¶

Who can perform each action / Who can take action: All writes require the verified collection gate, a current linked account and same-origin request. Call ownership is matching the current Travian account name; workspace ownership does not grant call ownership.

Draft saving and automatic planning use different gates: arrangement can save in Sign-up/Preparation, while solve/hash checking requires Preparation/Ready. Planning accepts a nonempty subset of valid offender villages, one assignment per village, each to a current real target. You need at least one signup and real target. A successful solve finalizes in Preparation; solving in Ready keeps Published and the prior publication time. No required participant may already be ready when regenerating a Ready plan. Publication is owner-only in Preparation with a finalized plan; an already-published request returns idempotently and does not publish again.

Publication resets readiness. Only required assigned non-owner accounts can mark or revert their own readiness while Ready; the final ready account triggers automatic start. There is no manual owner Start action. A required participant’s Ready state blocks ready-state replanning and edits to their fake commands/waves, but the fake-troop configuration endpoint still permits that assigned account to change compositions in Ready or In progress. In progress, owner wave edits remain allowed and the readiness lock no longer applies. Completed state permits viewing but locks these writes.

Manual fake toggles require a Published Ready plan and an affected participant who is not ready. Enabling checks an eligible fake option, available send time and command cooldown; it does not run the full solver again or re-enforce its min/max/shared fake objectives. Removing a fake updates fake-count/shared-group metadata without guaranteeing the original optimization. The matrix uses this narrower local check for unavailable gray cells. Owner wave edits allow real free text and fake integers1–8. My Attacks confirmation is own-account only and needs a declared impact; removing it removes both sent receipt and declaration. Treat confirmation as a member statement.

States and edge cases¶

No visible signup shows an empty Offenders state. No own published assignment shows You do not have an attack assigned in this operation. No shared commands shows No operation attacks are scheduled. No finalized/published plan shows a plan-empty message instead of a matrix. Targets without roster rows keep fallback labels; missing troop presence produces Travel unavailable and prevents feasible real scheduling. A current linked account is required even for privileged owner data. A failed dashboard-data response places its error in the Offenders area; target/fake mutations have inline errors, while plan/publication/readiness failures use a dialog.

Real/fake coordinate overlap is a conflict; selecting a fake requires a workspace registry target. New coordinate real targets need no roster record. Generating a positive capital pool requires at least one configured alliance and an eligible nonexcluded capital; requested count may exceed actual eligible output. Count0 clears generated fakes and preserves manual choices. Create plan first regenerates the pool when its requested count differs from the saved count. That generator is restricted to Sign-up/Preparation: changing the pool count in Ready can therefore fail even though solving with unchanged targets is allowed. The client prechecks minimum/shared fakes against candidate counts; the backend still checks reachability. Planner inputs reject min fakes greater than max, invalid/duplicate/unavailable offender assignments, targets outside the call and missing signups/villages/targets. Each real target’s assigned villages must have a common arrival reachable from saved send windows. Unknown travel, too few reachable fakes, insufficient shared fakes or cooldown overlap can make solving infeasible.

No feasible result returns a planning error with diagnostics; a timeout/UNKNOWN does not prove infeasibility. A feasible result may have unproven minimum impact count or unfinished optimization. Later unproven objective stages retain the last feasible solution. The client dialog shows a main message and up to three non-relaxation diagnostics; it does not expose a guarantee that every objective was proven. Suggested relaxations are guidance; the owner must change inputs explicitly. An unchanged hash asks you to change a setting, assignment, offender, target, availability or travel input. Stale lifecycle, locked readiness, absent commands and unauthorized owners are separately rejected by the endpoints.

Ready can persist beyond scheduled impacts until start is recorded. With no required non-owner attackers, publication starts immediately. At latest-impact equality an already-started operation remains In progress; only later is Completed. Completed disables personal confirmation/composition controls and readiness, removes planning/target tabs according to their gates, and leaves personal/shared history visible. Call deletion remains available to the call owner.

Related pages¶

• Operation Calls for creation and signup.
• Targets for the workspace registry.
• Artifacts Registry for recorded artifact targets.
• Troops Overview for captured village troops and TS.

Source references¶

Stable page ID: offense.operation-dashboard.

Source reviewed: 2026-10-07