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.
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
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,
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
Sim generates all resources (i.e. cities, farms, coal, forest,
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
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 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 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,
Dispatcher display (what the dispatcher sees)
Automated or manual, and ability to switch back and forth at any
Ability to segregate dispatch territories, esp. for manual
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
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/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)
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 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
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,
Yards (coach, hump, flat), with ability to configure all yard
features, (rip tracks, caboose track, engine shops, fuel tracks,
Ability to act as yardmaster, switching back and forth from
automatic to manual as desired.
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.)
Support all types of trains: Passenger, freight, mixed, non-rev;
way freight, local, yard job, transfer run, work train; limited,
express, local; etc.
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
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
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
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)
Along with this would include prototypical display of this
communication, i.e. 13WPM morse readout, with either audible clicks or
tones as appropriate, etc.
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,
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
Per Station: shows trains soon to arrive at the selected station
(in arrival time order).
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
Print any/everything to PDF.
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.
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
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."
What determines mail demand?
Support bulk mail (which can travel in boxcars, or backfill
Support mail and express trains
Support unit trains
Support carload shipments
Support various types/sizes of coal (bituminous, sub-bituminous,
Support various levels of sulphur content, (i.e. make Powder River
coal desirable enough to ship it to FL over eastern sources)
Support RPE-type network, mixing centers, etc. (obviously needs
As part of pax service?
As separate trains? Apparently NYC supported milk trains...
Support raw timber shipments to mill, cut lumber shipments to
Support seasonal shipments at harvest (assuming that's
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
Support all resting and watering rules (see Santa Fe site mentioned
Support shipment of all types of output (see Santa Fe site)
Support all icing requirements