Playtest: 727 variants and fleet compatibility need clearer explanation

Sandbox 1, Season 1 — Atlas Globe Airways (AG), ORD.

While setting up a 727 operation, I bought two 727-200s and scheduled ORD–JFK and ORD–ATL. The overview correctly warned that the B722 fleet had no spare. I then bought a 727-100 at ORD, expecting another aircraft in the same 727 family to provide cover.

Actual: the purchase sheet says the pilots already fly this family, but the 727-100 must join a new fleet (B721), while the scheduled routes belong to the B722 fleet. The 727-100 does not appear as a spare in the B722 fleet/planner.

Expected: either the variants could cover each other where operationally compatible, or the purchase sheet should clearly warn before purchase that a different type/variant cannot join the existing fleet or provide cover for its routes, even when pilots share a family. The current wording about pilots sharing a family made me expect the aircraft to be interchangeable.

This is a UX expectation issue, not a claim that the fleet restriction itself is a bug. I have not tested whether a manual reassignment or recovery option can substitute the aircraft after disruption.

Second UX observation — inconsistent aircraft availability wording in the planner.

Reproduction: buy a used 707-320B for ORD, then immediately open the ORD–LAX planner and select that fleet while the aircraft is still in handover. The selector showed “1 in handover, first available 13 Mar 1970” alongside “no aircraft, 0 usable, none spare.” After selecting it, the planner said the route was ready to plan from 16 Mar and would use 1 of 1 aircraft; it accepted the route.

The route planning itself worked, but seeing “no aircraft” and “0 usable” alongside “1 in handover” and “uses 1 of 1” was confusing. Consider distinguishing usable now from available by the route start date, and explaining that the handover aircraft is counted in the planned schedule.

Maintenance UX: overdue checks and the “Send for a check early” sheet.

In Sandbox 1 on 13 Mar 1970, open aircraft N103AG (727-100) while it is in handover. Its Checks section shows an A-check overdue since 8 Jan and a B-check overdue since 11 Jan; the next check is B. Press “Send for check.” The sheet is titled “Send for a check early” and preselects C-check, even though C is not due until June. It then says the aircraft already has work planned and disables scheduling.

I expected the dialog to highlight the overdue check and explain when it can be scheduled (or whether it will happen automatically after handover). The “early” title and default C selection make it hard to tell how to address the urgent checks. This is a wording/default-selection observation; I have not yet verified the automatic maintenance outcome after handover.

Follow-up: after handover completed at about 13 Mar 10:24, N103AG displayed “Ready” while the A and B checks still showed overdue. I manually selected B in Send for check; its preview explained that lighter checks would count as done, and scheduling immediately changed the aircraft to “In check,” due back 14 Mar 12:22. I cannot tell whether an automatic check would have started later; the Ready label did not make that distinction clear.

Route planning and overdue checks: a used 707-320B (N105AG) was purchased with an overdue C check; the purchase preview said the check was needed as soon as it arrived. While it was in handover, the ORD–LAX planner nevertheless offered a “Ready to plan” start on 16 Mar and let me put the route on sale. After handover, the aircraft was labelled Ready even though its C check remained overdue. I manually scheduled that check on 13 Mar; the preview and confirmed status put it out of service until 28 Mar.

Expected: make the required check and its likely effect on the start date obvious when planning against a pending delivery. If the check will be performed automatically, show its scheduled window; if it requires manual action, say so. I have not yet observed whether flights would actually be cancelled or whether another aircraft will cover them.

Another maintenance visibility issue: in Sandbox 1, Atlas Globe Airways, aircraft N112AG (727-200) is in handover. Its aircraft page and the fleet list show “Next check: C, about 25 May 1970,” while the Checks section on the aircraft page shows A overdue since 14 Jan and B overdue since 20 Feb 1970. The lease preview also said both were needed as soon as it arrived.

The next-check tooltip says it is based on recent flying, but the headline and fleet column can still suggest no urgent work is due. Please consider prioritizing overdue calendar-based checks in that summary, or showing a prominent overdue warning alongside the flying-based estimate.

A related date inconsistency: on 2 Apr 1970 after N154AG’s A-check, its aircraft headline said “B overdue since 2 Apr 1970,” but the detailed B-check row said it was overdue since 19 Feb 1970. Please make the summary show the actual overdue date or label the date as an estimate so it does not understate how long the check has been overdue.

Follow-up on automatic maintenance: N101AG (727-200) completed handover on 15 Mar. Without my scheduling a check for it, its aircraft page showed an A-check in progress from 15 Mar 02:00 to 11:36. At 05:33 the B-check was still shown as overdue; I have not yet observed what happens after the A-check finishes. So automatic checks do occur in at least this case, correcting the uncertainty in my earlier observations. A visible indication of pending automatic work and its expected timing would still help players understand readiness while planning.

Maintenance preview UX: on 15 Mar at about 17:05, N112AG was Ready and assigned to AG100 ORD–JFK at 14:00 UTC on 16 Mar, with A and B checks overdue. Selecting B in Send for check showed “out of service until about 16 Mar” and “about 1 day,” but no time or indication of the scheduled flight’s potential conflict. With departure less than 21 hours away, the date alone does not show whether the check will finish before the flight or whether another aircraft would cover it. I cancelled the preview and did not test the outcome.

On 27 Mar, N139AG’s C-check choice said “about 11 days,” but its contractor preview said out of service until about 12 Apr, and the booked window was 27 Mar 18:45–12 Apr 21:23 (about 16 days). The end date was shown before booking, but the duration label suggested a much shorter check. Please make the duration reflect the selected provider, or distinguish nominal duration from contractor time.

On 29 Mar, N145AG had an automatic A-check in progress and the HS748 fleet’s first routes were scheduled to begin the following week. Opening Send for check showed “the timetable needs 0 of its 0 aircraft this week” but also said taking it out leaves the fleet “1 aircraft short” and flights would be cancelled. The check itself could not be scheduled because work was already planned. Please calculate the warning against the affected check window and actual scheduled flights, and avoid asserting a shortage when this week needs zero.

Please show predicted start/end times and flag affected assigned flights or explain coverage before scheduling.

Automatic maintenance and route planning: in Sandbox 1, Atlas Globe Airways, N111AG’s purchase preview said an overdue A-check was needed on arrival, but the ORD–JFK planner allowed a round trip without showing a maintenance window. On 16 Mar, AG100 arrived at JFK; the page then showed an automatic A-check at JFK from 16:35 UTC until 03:37 on 17 Mar. The full return AG101, scheduled for 17:00, was cancelled with “no aircraft available.” The check overlapped the return, though I cannot independently prove the cancellation engine’s exact cause.

A second case suggests a location conflict: on 2 Apr, N155AG flew AG118 from ORD to HNL, arriving at HNL at about 05:48 UTC on 3 Apr. While it was airborne, its page showed a B-check scheduled at ORD from 3 Apr 06:14 to 4 Apr 09:11. The HNL–ORD return AG119, scheduled for 20:40 HNL time (06:40 UTC on 3 Apr) with 150 booked passengers, was subsequently cancelled. Afterward, N155AG’s page showed the B-check in progress at ORD, although its last recorded flight arrived at HNL and no return or positioning flight was recorded. The timing and location are observed; the exact cancellation cause is not independently verified.

Please ensure automatic checks respect aircraft location and return flights, and show likely check windows and their impact on planned flights before they go on sale.

Maintenance status wording: at 02:26 UTC on 18 Mar 1970, N111AG’s page showed a B-check at ORD scheduled from 19 Mar 02:00 until 20 Mar 02:52, while the A and B rows both said “In work at ORD, 0% done” and “ready Fri 20 Mar 02:52.” The aircraft itself was Ready and had flights scheduled on 18 Mar. Calling a future check “In work” makes it look as if it has already begun. Please distinguish scheduled checks from checks actually underway and show the start as well as the finish in the check rows.

Overview overdue warning: on 20 Apr 1970, Atlas Globe Airways overview says “1 aircraft overdue for a check, since 17 Apr 1970” and warns that overdue aircraft may break down or be grounded. Maintenance shows that aircraft as N124AG, already in its C-check until 28 Apr. The warning does not say the overdue check is being addressed, making it look like action is still needed. Please distinguish overdue checks already in progress from outstanding checks, and link to the affected aircraft or its work.

Flight board default columns obscure first-class bookings: in Sandbox 1, Atlas Globe Airways, open Flights for 24 Mar 1970. AG142 ORD–JFK shows Economy 165/165 and 173 passengers, while the default premium column is Business (C), shown as a dash, despite the aircraft having 8 first-class seats. The F column is available under Columns and export; enabling it shows 8/8 and explains the total. Please consider showing the cabin classes actually used by the fleet by default, or making the hidden class more apparent, so a player can reconcile the passenger total without discovering the column selector.

Overnight return flights show the wrong date in two views: Sandbox 1, Atlas Globe Airways, ORD–LHR route 71, first rotation. Route details list AG116 ORD–LHR on 29 Mar at 17:40 local, arriving 08:00, and AG117 LHR–ORD also on 29 Mar at 08:55 local. The Flights page, described as grouped by local departure date, likewise shows AG117 under 29 Mar. But assigned aircraft N131AG’s flight timeline shows AG116 departing Sun 29 Mar 23:40 UTC and AG117 departing Mon 30 Mar 07:55 UTC (08:55 local), which is consistent with the overnight outbound. At 13:00 UTC on 29 Mar, the supposedly 29 Mar 08:55 return was still Scheduled. Please show the actual local departure date on the route and flight board, or label a rotation/service date explicitly, so the return does not appear to depart before the outbound arrives. I have not yet verified whether the actual flight operates correctly.

Pricing visibility: in Sandbox 1, Atlas Globe Airways, I saved an economy rule for Detroit–Chicago at 110% of reference, with daily application. The market list was open before the daily review and continued to show $27 / 100% and “default” at 02:53 UTC on 5 Apr 1970, while the game clock advanced. Navigating away and reopening Fares & pricing immediately showed $30 / 110% and “rules.” The rule itself applied; the open list did not reflect the update.

A manual fare save also left the list stale: on 6 Apr, I set San Francisco–Chicago first and economy fares to 110% of reference. After the dialog closed, the market row still showed economy $98 / 100% and “default”; reopening the page showed $108 / 110% and “you.” Please update the list after saving and automatic rule runs, or show its update time and offer a clear refresh.

Pricing rule default: on 9 Apr, add a new rule (initially “A share of the reference,” 100%) and switch to “Below the cheapest rival.” The input becomes “100% below the cheapest rival,” apparently carrying the previous mode’s value across even though its meaning changed. That is surprising and could imply a zero fare. Please initialize a modest undercut or require an explicit value when switching modes. I changed it to 5% and added a 70% floor before saving; I did not test the effect of saving 100%.

Boundary test on 19 Apr: I entered 150% below the cheapest rival in a temporary Dallas economy rule. The field accepted 150 and Save reported success, but the saved rule displayed 100%, with no explanation that the value was changed. I removed the rule immediately, before observing a daily application; I have not tested the resulting fare. Please show the permitted range and reject or clearly announce any clamping before saving.

Route launch date wording: Sandbox 1, Atlas Globe Airways, ORD–YVR route 109. I planned three weekly departures on Friday–Sunday with a start date of Tuesday 21 Apr 1970. After saving, the route page says “Its first flights are on 21 Apr 1970,” but its flight list starts with AG276/277 on Friday 24 Apr. The start date appears to be the timetable effective date, not the actual first departure. Please label it as the effective date and show the first scheduled flight date separately.

Another case points in the opposite direction: JFK–YYZ route 121 was labelled “From 21 Apr” and “Its first flights are on 21 Apr,” but the route list included AG316 departing JFK on 20 Apr local. The outbound local time corresponds to 21 Apr UTC, which may explain the boundary, but the UI does not say which time zone governs the effective date. After operation, the route lists AG316 at 21:30 and AG317 at 06:05 both under 20 Apr, both Arrived. N104AG’s flight timeline confirms AG316 departed 21 Apr 02:30 UTC and AG317 departed 21 Apr 11:05 UTC (06:05 local), so the return actually departed on 21 Apr local. Please clarify the effective date and time zone and show each leg’s actual local departure date.

Flight number mismatch: on 15 Apr 1970, open JFK–CVG route 177. Its header identifies “flight 268”, but its flight list shows AG270 outbound and AG271 return on 4 May. The mismatch persisted after reopening the page. Please make the header and scheduled flights agree, or explain if the header number refers to something different. I have not checked which number will be used at departure.

Route planner hides a future fleet shortage behind “Ready to plan”: Sandbox 1, Atlas Globe Airways, on 8 Apr 1970, copy route 115 and select JFK–DTW, HS748 ORD, seven departures weekly, starting 21 Apr. The main preview says “All 7 in its free time” and “Ready to plan,” even though it also says “Uses 9 of 8 aircraft.” Expanding “What it asks of the fleet” reveals that the week of 27 Apr needs 9 of 8 and says flights without an aircraft are cancelled; the start week needs 8 of 9. Please surface the later shortage and likely cancellations prominently before the route is put on sale, and distinguish readiness in the first week from ongoing coverage. I did not commit this route or verify actual cancellations.

Partial-fit economics: on 10 Apr, copying route 127 and selecting BOS–DTW, HS748 ORD, with 7 departures requested and First available, the fit offered only 4 a week (Mon–Thu), but the completed preview still showed 364 seats per week each way, corresponding to 7 × 52. Changing the requested frequency to 4 updated the capacity to 208 and the 80%-full contribution from $19,789 to $10,575.

A second case on 10 Apr: BOS–TPA with 7 requested offered only 1 weekly flight, yet the preview showed 350/364 seats and $33,714 weekly contribution at 80% full. Saving without changing the request created route 143 at 1 × weekly, confirming that the economics describe the requested seven rather than the saved schedule. Please calculate the economics from the fitted frequency, or explicitly label them as estimates for the requested frequency.

Fit inconsistency: on 18 Apr, copy LAX–PDX route 189, select LAX–SFO on B703B ORD, starting 4 May. Requesting 7 weekly offered 5 (Mon–Fri at 15:00); changing the request to 5 offered only 3 (Mon, Thu, Fri at 15:00). Changing back to 7 again offered 5, and saving created route 190 at 5 weekly. Please preserve the feasible five-flight fit when fewer flights are requested, or explain why the chosen fit changes. The 7-flight preview also showed 1,316 seats, again counting requested rather than fitted flights.

Batch validation visibility: on 22 Apr, plan JFK–MKE on B703B ORD at one weekly departure with First available. The route preview says it needs 12 aircraft and the fleet has 11, so Plan the route is disabled. Add to batch nevertheless queues the draft, clears the destination and shows “Submit 1 plan” disabled, but the batch row shows only JFK–MKE and 1×, with no explanation of the shortage. A “Get another Boeing 707-320B” link remains below the now-empty planner. Please show each queued plan’s validation error and a way to edit it, or prevent adding an invalid plan. I removed the draft; I did not submit it.

Historical airport search ambiguity: in Sandbox 1 on 17 Apr 1970, search for DEN in the route planner. The results include both Denver Stapleton International Airport (the airline has a gate there) and Denver International Airport under the same DEN code. Selecting Denver International and planning DEN–OMA for 4 May only later reports “DEN is not open to airlines then”; the selected field and route heading show only “DEN Denver,” so the identity and reason are easy to miss. The active Stapleton airport is also labelled DEN in existing routes. Please make the full airport name and opening/closure status visible in the result and selected field, and flag unavailable historical airports before selection.