James,
??? What I have done uses the all of what one might call 'behind the curtain' of JMRI Dispatcher. One interacts with Dispatcher via a dialog box to create a 'new train'. Instead of using that dialog box, I have Jython code to 'determine' all the answers needed for the dialog box, then call the same Java routines that the dialog box would. In other words, I simply replaced the user interface supplied by Dispatcher with my own.? At the time I did most of my work I recall looking at JMRI's NX warrants but decided not to use that. Don't really recall just why, except from the git go I wanted to be able to mix computer controlled trains and manual controlled trains on the same layout, and didn't see how having to 'train' a train for an NX warrant fit my wishes. (By the way, what I have done is and always has been simply to satisfy my own desires with absolutely no thoughts of any commercialization. If anyone can derive any benefit, that is fine, but I see JMRI as a 'erector set' to do stuff to suit my fancy.)
So to directly answer your questions: NX paths - it uses transits, sections, blocks, signal mast logic, and all the code of Dispatcher.? One of the 'tricks' is to determine from the N click and the X click on the layout editor panal which transit to use and what portion of that transit to use. One change I made to JMRI which is now part of the standard distribution was to be able allocate all the way from the start block to the end block. This is necessary for the NX allocation to 'make sense'.
Concerning the timetable - I know you have been talking about a timetable as a database of trains to run.? This is not it.? Indeed, the only place I have any 'mention' of a timetable is in the Employee Timetable rule book I designed for my layout and there it is a work in progress and is totally blank right now.
One note: I have linked JMRI Operations to my Dispatcher version. Thus trains must be built in Operations before they can be run on the layout via Dispatcher.? Operations does have a 'database' of trains including run times, so with more work on the coding side of my Dispatcher, I see how one could make use of that information. Maybe some day, but again, our op sessions (several years now) seem to be doing fine. As I write more, I think you might be referring to what I call the Form 902 as a timetable. If so (because it does have a column for departure time), the Form 902 is the Operations interface I just referred. The Form 902 is more of a 'Clearance' for the train than a timetable of operations.
To what extant is the code layout specific - I don't know - somewhat - maybe more than somewhat.? I set up a friend's layout to operate in much the same manner.? That layout has a few 'differences' the biggest being no use of Operations.? But I did 'copy over' large chunks of code. (And being a retired programmer, could not resist rewriting a few things here and there.)
So, that may or may not answer everything.? I know choosing layout train automation methodology is not easy, and there are more things to consider now than when I went through the process. Even now I would like perhaps to try something else, but I don't have enough time now to do everything that needs to be done on the layout.? So don't fix it if it ain't broke (too bad broke that is).
Jay Janzen
St. Charles, MO
