This is the wishlist. It's partially a list of intended features, and partially just a place to put things that pop into my head. Or yours. Suggest away, and I'll see to it that it gets added here. (My apologies if this isn't completely coherent, as it's probably been written off the top of my head in the midst of coding...)

Coming up next

RLs need ability to lay multi-track and/or sidings

Flexible junction configuration: configure # of tracks to be connected to each other leg of junction, from each direction.

Collision detection/avoidance, use of multi-track.

Application

On/off toggle for place names, station names on map

Have status messages disappear on real-time timer; have collection of n-previous status messages

Let user select application colors (skinning? way down the road...)

Status bar message history window would be displayed when user clicks on status bar. Menu-generated help messages, obviously, would not go there.

Proper icon for various operating systems (esp Windows, check Mac OSX, KDE, Gnome, Fluxbox, others, as supported by wxPython)

Consider allowing networked connection to allow one user to dispatch while another user is yardmaster, a third is stationmaster, a fourth is running a local, etc.

Allow other machines to share processing of background tasks, but have tasks queued up as per prototype, i.e. have limited RR employees to perform "research" tasks, but as these tasks require more CPU time than other "sim" tasks, they could stack up. Outsource them to other boxes when created & hold results until "completed" by RR emp.

Defaults page for edit values (i.e. default siding length)

Defaults page for units for display (i.e. metric or imperial)

I18N support for text (8-bit charsets, at least, and full Unicode at some point) in menus, etc.

Unless you are selecting something by its location (i.e a RL), you should be able to do everything via the keyboard OTOH, when you see something on-screen, you should be able to command it with the mouse These two things should be complete enough to allow a mouse-less user to use drose, and to allow a user to use the kbd only for entering text (i.e. controlling trains, running a yard or station, dispatching, etc.)

Persistence

Investigate SQL-based file I/O. I would require single-file database (copyable, renamable); it must not require separate server process, must be maintainable solely via the application. PySQLite (IIRC) is the top candidate. Others include bindings for gdbm, dbm, metakit (and mksql), xsdb, mxBeeBase, Firebird, KirbyBase. Gadfly is in-memory, so not appropriate.

Second choice may be ZoDB, although it doesn't have query capabilities that I seem to be needing. Can data structures help here? Can it support persisting a prio-queue?

Sim should be continuously persisted. This would prevent "undo" and "revert" capability, perhaps, unless we saved a copy when we started, but a crash shouldn't leave things in a munged state or lose where things are. Perhaps have a separate thread to act as a persistance queue.

Simulation

Sim generates all resources (i.e. cities, farms, coal, forest, etc).

Sim generates terrain (i.e. elevation, rivers, oceans, etc.) (initial version only has flat terrain, no water). Terrain & resources govern city placement and size.

Randomness of events (i.e. "chance cards") which affect all operations aspects.

Economy: delivery of goods provides income, operation causes expenses, boom times vs bust.

Game calendar increases as game progresses, i.e. to days of week (with varying traffic flows), months (complete with national holidays) and years (and hence technologies) (initial version is locked into 1950's era, and a single generic weekday).

Map

Map should be zoomable to varying degrees. Map may be zoomed by dragging a rectangle; the map centerpoint will be set to the rect's centerpoint, with the scale set to display the largest dimension of the rect (width or height). Zooming out will double the scale, until completely zoomed out.

When display zooming of the map is added, better display of RLs at lower scales will be necessary.

Include option dialog to toggle various map features on/off. Should include place names, station names, short RLs (i.e. "shortlines", either as indicated by the user, or automatically determined), etc., as well as geographic features (topographic display (ain't that ambitious of me!), coal fields, land use, etc.)

Rail Editor

Rail editor should have proportional display.

When adding a RL that doesn't connect to the rest of the system, verify that this is what the user really wants to do.

Allow navigation from RL to Junct to other RL via RL display.

display will be able to indicate segment speed limits (system-wide, segment-specific and temporary), location/length of station platforms, etc.

Dispatching/Signalling

Dispatcher display (what the dispatcher sees)

Automated or manual, and ability to switch back and forth at any time

Ability to segregate dispatch territories, esp. for manual dispatching.

Historically accurate displays (what a dispatcher in each time period would have had to deal with, including pure manual). This should include representations of armstrong devices, switch panels (as seen in PA RR Museum), O/S sheets (automated and manual), etc.

Historically accurate dispatch methods and their corresponding signalling hardware: TT&TO, DTC, track warrants, CTC, pure timetable (?), etc. (What about European methods?)

Proper display of signals: upper- and lower-quadrant semaphores, color searchlight, PRR-style, etc. (Again, what about Euro-styles?)

Cities

More realistic determination of city placement (i.e. relative to geographic features, hydrologic features, industry/natural resources, etc.) Placement should follow a settler's algorithm, i.e. why were those locations settled historically.

Population variation. Smaller cities should be more numerous than larger cities. Also, population should change realistically over time, and should be affected by such things as migration. This, of course, implies that migration should be simulated as well, for prototypically accurate reasons.

The same applies to population density; when an area experiences emigration, its area might not change, meaning that its density would decrease to allow for a decreased population to cover the same area. Conversely, more people moving into a city bounded by a geographical restriction, (i.e. NYC), may have its area remain constant while its density would increase to account for an increased population.

Working table for city data should turn into a working database for all persistable data. The only data that would remain in memory would be that required for running the sim, (i.e. train data, but not necessary consist data; if needed, that data could be retrieved from disk and displayed).

Should be able to rename cities, (and stations within that city at the same time).

Rail/Tracks

Rail/track construction shouldn't be instant; should require track gangs and equipment, and transport of needed commodities (via rail) to site. Work site should have slow orders, etc.

Double-crossovers (i.e. parallel ladder tracks)

Crossovers that have actual length; have that length vary with the speed of the crossover (and/or vice versa); partial crossovers (i.e. 3 tracks, but only connect first two; or, only go left-to-right, not vice versa; etc)

Allow removal of specific track (i.e. track 2 of 4); allow removal of inside track to be cheaper if spurs exist on outside track

Allow for definition of a division or subdivision, made up of multiple RLs, and allow that to be edited in RL display (and dispatched as well).

Turntables (for steam, especially), wyes (i.e. stub-end for turning engines), loops (i.e. on Marias Pass)

Rerouting: when accident closes line, be able to reroute (automatically and/or with user assistance) affected trains over secondary, temporary route

Narrow gauge, logging railroads, etc. Also, gauge differences between multiple RRs, (once we have more than 1).

Carfloats (once we have water and geography)

Stations

How do Mac users create a station? Ctrl-click? Fix this.

User right-clicks on a station, selects "Add departure" option. Gets dialog with departure station already selected, gets to select arrival station (combobox) and intermediate stations (once arrival station is selected) (defaulted to stop at all intermediate stations).

Stations should have limited track/platform capacity. Should have ability to do construction to add platforms, etc. Station itself should have limited passenger-handling capacity, ticket agent capacity, etc. Penalty should be provided if number of pax at station at one time exceeds capacity, (i.e. folks were standing outside in the rain, or missed their train due to crowds, and are complaining to the press.)

Ability to act as stationmaster, switching back and forth from automatic to manual as desired.

Commuter stations, light rail, trolleys, interurban (?), etc. (which requires more detailed city modelling, probably).

Station naming should include name of RR, once there are more than one that can run into a city.

Should be able to rename station, (not just at creation time).

Currently, we have a fixed dwell time at each station. This should vary based on actual tasks to be performed at the station (loading/unloading of passengers, luggage, mail, express packages, etc.)

Yards

Yards (coach, hump, flat), with ability to configure all yard features, (rip tracks, caboose track, engine shops, fuel tracks, etc.)

Ability to act as yardmaster, switching back and forth from automatic to manual as desired.

Schedules

Schedules have flagstop capability (inital version actually stops at all scheduled stations).

Automatic yet overrideable scheduling of intermediate station arrival and departure, and expected arrival time at final station. Train schedule display includes scheduled times. Actual train display includes on-time status.

Include day-of-week, (i.e. "MWF", or "Daily xSun"; display might be as shown here, while entry would probably be via checkbox)

Include classes of trains, i.e. First class has rights over 2nd and 3rd class trains; north and east-bound trains of same class have rights over south and west-bound, etc. Consider that when delaying a train, "if you're going to offend folks, pick one person and offend them the most. then, don't pick the same person every time", per Steve Stepp; translation: don't make everyone late the same amount, but hold one guy back until there's room. (Then apologise to the pax on that one train.)

Trains

Support all types of trains: Passenger, freight, mixed, non-rev; way freight, local, yard job, transfer run, work train; limited, express, local; etc.

Engines

Prototypical power characteristics (how much tonnage can it haul how fast on what grades) and accel/decel characteristics (based on power available on the train)

Fuel limitations (including water for steam trains)

Steam train support (including coal/water, directional differences)

Rolling Stock

Rolling stock is limited in availability and placement (i.e. requiring resource allocation and empty handling) (initial version creates rolling stock as needed, dispenses of it upon train termination).

Rolling stock of varying types, which influences pax ridership (i.e. Pullman cars) & other shipping (i.e. boxcars, tank cars, etc). Commodities require certain types of rolling stock (i.e. oil in tank cars, grain in hoppers, etc.) (initial version has only 40-pax basic passenger cars).

Communications

Prototype efficiency is greatly affected by being able to comminucate with the trains to coordinate movements. To this end, we'll be able to simulate period communication technology:

Telegraph (morse code)

Telephone

Fax/teletype

Computer

Along with this would include prototypical display of this communication, i.e. 13WPM morse readout, with either audible clicks or tones as appropriate, etc.

Displays/Reports

Scheduled Trains

Per Station: shows trains (sorted by arrival time) that serve that station (does not include trains that merely pass by). Make it look like a period display (i.e. chalkboard for old, small stations, digital for new, big ones, those flip-digit displays for the 70's, etc.)

Per Path: shows trains that pass along selected path. Path is selected by start and end station, and disambiguated like schedule makeup. Display is wide, (like printed schedules) and scrolls side-to-side and up-and-down. Train numbers are across the top, stations down the side, and arrival times in the grid.

String diagrams: line that shows train's position on track segment at a given time. Different class of train has different color. See Chubb book or Mike Dodd's Virginian website for examples. For multi-track, allow display to show all tracks in one diagram, or split into two sections for easier viewing. Be able to zoom in and out according to user desire, to accommodate varying levels of detail on the diagram.

Actual Trains

Per Station: shows trains soon to arrive at the selected station (in arrival time order).

Printing

All reports, of course.

Multi-page map, i.e. print map on a MxN grid of pages that can then be assembled (taped together) into a wall poster.

Public and employee timetables.

Switchlists (and/or waybills), to allow "local crew" to have more prototypical feel.

Print any/everything to PDF.

Commodities

Complete commodity handling, including network handling for pax, LCL, etc., as historically accurate.

Handle all commodities that prototype RRs handle; take them on one at a time and get them right.

Commodity volume will be demand-driven; people buy packages that would be shipped LCL, which drives how many LCL packages are actually shipped. People demand milk, which would determine both how much milk is shipped and how many dairy farms exist. People demand cars (which requires steel, which requires coal), electricity (which is generated by burning coal), etc., which determines how much coal is mined and shipped to meet those demands. Etc.

Passengers

Why do people travel? What determines travel demand?

Be able to specify consists as part of schedule

Support various car types

Support thru cars and car routing

Support commuter demand (will require better simulation of cities)

The number of pax leaving a city in a given day is proportional to the city's size. The number of pax going to a given destination is inversely proportional to the distance between the source and destination. The number of pax going from src to dest is somewhat proportional to the speed of transit. The number of pax is related to the economy, and to the proximity to a major holiday (or a weekend, to some extent).

Loading/Unloading: Passengers load at a rate of one per 5 seconds per door per car (1/sec/door/car for commuter trains). Baggage is loaded at a similar rate.

Passengers require ticketing. As far as the sim goes, this impacts what we know about pax loads prior to the day of travel, and can impact rolling stock utilization (i.e. a large group is leaving Townsville today, add another coach, sleeper, etc., as per prototype). This can also impact station requirements (i.e. # of ticket windows and ticket agents to support pax buying tickets on the day of travel, trains sold out, etc.)

Rob Dunn said: "Something to add to your wish list is demand indicators and peaktimes (in align with 9-5 jobs) and the ability to report on how many people at using the trains on each route and at what times. This could also link in with rail demand from industry and ports so you can schedule the trains at the right time."

"Also to add to your rolling stock is heritage trains and not sure if this is there but the ability to make a daily or recurring schedule (like daily timetables) and the ability to one [off] schedule a train for day a charter."

Mail

What determines mail demand?

Support bulk mail (which can travel in boxcars, or backfill reefers)

Support mail and express trains

Coal

Support unit trains

Support carload shipments

Support various types/sizes of coal (bituminous, sub-bituminous, anthracite)

Support various levels of sulphur content, (i.e. make Powder River coal desirable enough to ship it to FL over eastern sources)

LCL

Support RPE-type network, mixing centers, etc. (obviously needs more research)

Milk

As part of pax service?

As separate trains? Apparently NYC supported milk trains...

Lumber

Support raw timber shipments to mill, cut lumber shipments to lumber yards

Grain

Support seasonal shipments at harvest (assuming that's prototypical)

Chemicals (be more specific)

Support petrochemical cycle

Support historical crude-oil shipments (don't forget tank-train ran fairly recently, while most crude shipment happens via pipeline nowadays)

Livestock

Support all resting and watering rules (see Santa Fe site mentioned on RyOps)

Reefers

Support shipment of all types of output (see Santa Fe site)

Support all icing requirements