Release Notes for JMRI 1.5.5 test release
Date: November 29, 2004
From: Bob Jacobsen
Subject: Test version 1.5.5 of JMRI/DecoderPro is available for download.
This is a test release. Please post a note if you encounter any new or old bugs! And please back up your JMRI files before installing this, in case you want to go back to an earlier version.
This test release is part of a series that will eventually lead up to a production release called version 1.6; no date has been set for when that will happen.
There was no public 1.5.1 test version; it was used for internal testing.
New warnings for this test version:
Older warnings for the 1.5 series of test versions:
The method for configuring the C/MRI protocol has changed since version 1.4. If you use the C/MRI protocol, you will have to reconfigure your preferences the first time you run this version.
Please use these links for downloading, including the "?download" at the end. That adds to SourceForge's advertising statistics, which makes them happy to host our stuff.
MacOS 8/9 "Classic": http://prdownloads.sourceforge.net/jmri/JMRI.1.5.5.Classic.hqx?download
Changes since test version 1.5.4:
Fix some minor Javadoc problems
Fix problem introduced in 1.5.4 that prevented SPROG from functioning
Update on US&S lamp (yellow) that had wrong background
Updates to consisting code by Paul Bender
Update to consist tool to handle case when no consist selected; may be correcting a change to the way Java 1.5 works - Paul Bender
Update the XPressNet monitor to display additional messages in English - Paul Bender
Dennis Miller improved the Throttle panel layout so various parts display completely
Improve Digitrax ops-mode readback so that it works with Intellibox and other devices.
Fix a problem with SPROG where code listening to replies would get a second copy after sending a message. This only effected people writing code within JMRI itself.
Turn off DirectX acceleration of Java3D on Windows. This prevents a rare fault during startup. RFE 989410
Change DecoderPro code so that only variables coded red ("Unknown/Error", generally caused by a read or write that failed) or orange ("edited", due to manual changing of the value) will be read or written when you click the various "read/write changes" buttons. This is a significant change to behavior; please try it and less us know whether it's an improvement!
Alex Shepherd: Improve key-mapping for the Throttle.
Convert the NCE support to use "binary" commands instead of "ASCII" commands when talking to the command station. This is intended to make JMRI simultaneously compatible with the existing and next versions of the NCE command station PROMs.
The internal fastclock mechanism was updated so that various clocks would stay synchronized when the minute changes.
Dennis Miller updated the Nixie clock so that it can be resized. He also greatly improved the graphics.
Dennis Miller improved decoder printout by adding the CV number in the "All" version.
Improvements to support for one DecoderPro variable split across two CVs: Mask now works on both upper and lower bytes for both read and write to CVs. Previously, this was only used in a special case for AD4 decoders, and hopefully that special case still works.
Paul Bender: Internal changes to consist tool to add hooks for system specific consist restrictions and error propagation.
Paul Bender: New XPressNet Specific Consist Manager. Allows use of Lenz "Double Headers" and Decoder Assisted consisting through the use of Lenz's "Smart Consisting" facilities.
Joe Salemi contributed a decoder definition for the Atlas 345 decoder and updated the TCS Tx definition.
Michael Greene contributed new definitions for the E-Z Command and Zimo MX61_N decoders, and updated the Soundtraxx SHS F3 and F7 Diesel decoders.
Fix bug where a Roster selection box would have entries out of order after adding a new locomotive.
Alex Shepherd added some additional decoding to the LocoNet monitor in the fast clock area.
Alex Shepherd added the capability to synchronize the LocoNet fast clock to an internal clock.
Macintosh "Classic" build process rebuilt _again_. The MacOS Classic JVM will lock up if certain synchronized constructs are compiled with a "modern" compiler, so the build process has been redone to ensure classes containing that are compiled with the "oldjavac" compiler. This is a stopgap, however, as other constructs (local variables in anonymous inner classes) _require_ the newer compiler; eventually, we'll get a conflict between these.
The problem with "out of memory" when requesting certain DecoderPro programmer formats while running on MacOS ("Classic") has probably been fixed.