Jump to content

Desirable features for future Railmaster Software updates


Recommended Posts

Good luck with making any progress with your very reasonable request MMUK.

 

;-)

 

@RAF96.  I think your misunderstanding of my suggestion is also an important point.  If you look at it logically, when you commence a problem report, HRMS ask if you have read the manual and troubleshooting guide.  This would save you and HRMS from wasting each other's time.  However, think of the time you might spend re-checking possible solutions and constructing an in-depth report even though HRMS are fully aware of the bug.  Providing a known bug list may not save HRMS any time but it could save you and me a lot of time, but are HRMS worried about that (perhaps 'should HRMS be worried' is more appropriate) ?  

Are you suggesting that the bug list is provided from within RM itself or on the Forum? 

 

 If the former, then it would have to be only those users who have bought the license and activated it who could access the list. Otherwise (and also if displayed on the Forum) it would probably discourage potential customers from buying it.

Ray

Link to comment
Share on other sites

  • Replies 516
  • Created
  • Last Reply

Top Posters In This Topic

As this link is now 46 pages long I'm afarid I can't remember all the items that have been suggested as 'desirable features", so apologies in advance if this has been mentioned already. I just wondered what we thought about having only the throttles that were needed for any given moment of operation actually displayed on screen. They could parhaps be scalable and floating. Just a thought. R-

Link to comment
Share on other sites

Good luck with making any progress with your very reasonable request MMUK.

 

;-)

 

@RAF96.  I think your misunderstanding of my suggestion is also an important point.  If you look at it logically, when you commence a problem report, HRMS ask if you have read the manual and troubleshooting guide.  This would save you and HRMS from wasting each other's time.  However, think of the time you might spend re-checking possible solutions and constructing an in-depth report even though HRMS are fully aware of the bug.  Providing a known bug list may not save HRMS any time but it could save you and me a lot of time, but are HRMS worried about that (perhaps 'should HRMS be worried' is more appropriate) ?  

Are you suggesting that the bug list is provided from within RM itself or on the Forum? 

 

 If the former, then it would have to be only those users who have bought the license and activated it who could access the list. Otherwise (and also if displayed on the Forum) it would probably discourage potential customers from buying it.

Ray

 

Naturally, displaying your dirty linen in public takes courage but it would be the sign of a company confident in its product.  I hadn't thought about access only through RM but the idea is growing on me.  It would certainly be a good place for HRMS to start just as long as access is via standard means and not via an HRMS in-house designed tool.

 

 

Link to comment
Share on other sites

Naturally, displaying your dirty linen in public takes courage but it would be the sign of a company confident in its product.  I hadn't thought about access only through RM but the idea is growing on me.  It would certainly be a good place for HRMS to start just as long as access is via standard means and not via an HRMS in-house designed tool.

 

Maybe if HRMS allocated a reference number to each bug report, and sent that to the originator via email, how difficult would it be to allow that user to check on the progress of the bug by means of an enquiry facility within RM?

Ray

Link to comment
Share on other sites

Maybe if HRMS allocated a reference number to each bug report, and sent that to the originator via email, how difficult would it be to allow that user to check on the progress of the bug by means of an enquiry facility within RM?

Ray

 

I'm not too concerned about how fixing a bug is progressing but I would like to know if it has already been reported and also acknowledged as a bug by HRMS so that I can avoid unnecessary work.

Link to comment
Share on other sites

I can't find this via a search but has anyone flagged up having the large throttles (that pop up into the main screen when you tap a small throttle) scaleable? Might be useful to have a couple open but scaled down from their current size and out of the way. Or, an idea I saw elsewhere, have one large (scaleable) throttle that had the roster in a drop down menu at the top? If youv'e got hundreds of locos maybe a bit unwieldy but, for a group? Anyway, just a thought. R-

Link to comment
Share on other sites

The ability to call a program when a point is switched is a great facility provided to ProPack users. However, it would be better, in my opinion, if two different programs could be specified, one to run when a point is switched left, and the other when the point is switched right.

Ray

Link to comment
Share on other sites

... if two different programs could be specified, one to run when a point is switched left, and the other when the point is switched right ...

I agree that this would be a great feature

 

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
  • 4 weeks later...

There is aprogram "bug" that I have come across recently which I would like to see fixed in a future update.

 

It is to do with REPEAT and END REPEAT instructions. These are a common type of instruction used in every program language I have ever practiced in but in RM do not behave as expected. At the end of a sequence of instructions the END REPEAT should take you immediatley back to the beginning of the sequence and start again, doing this until the required number of sequence runs is completed. For some reason I cannot fathom, in the RM version there is a substantial delay after the last instruction in the sequence has been performed before the first one is repeated again.

 

When run from the main screen (outside of the editor mode), the lttle program clock appears to run backwards to zero before restarting. So on say, a 30 second sequence there is a 30 second delay in between sequence runs which is very frustrating.

 

 

Link to comment
Share on other sites

  • 4 weeks later...

If others would find it beneficlal could consideration be given to users being able to move the point / signal ID number to a different location as suits their layout? At the moment it always sets itself on the lower right hand corner of the green point icon or to the right of a signal icon (will LD sensors have them?). Also I have noted that the LD sensor icons change from a certain size in the track design window and print out at a different size, at 100% anyway. This is not a hugh problem as they display correctly on the main screen but I thought I would point it out. R-

Link to comment
Share on other sites

  • 1 month later...

The Case for Removing the Railmaster.ini file

 

Judging by the posts on the Forum, several people seem to have trouble in making changes to the Railmaster.ini file. There is a wide range of reasons for this, from not being able to locate the file, to not having Administrator rights to save the file.

I have been looking more closely at the entries in the file, with a view to moving these parameters inside the Railmaster program itself.

Let's start with five of the first six entries, which are to do with the Tipper, Turntable and Conveyor. According to the manual, you are able to have up to ten Conveyors, up to ten Tippers, and any number of Turntables in your layout design. Now I realise that not many layouts will have more than one of each of these items, but if you did have, for example, two tippers, then because the speed and time are defined in the .ini file, they would both be restricted to these values. These three items are inserted into the layout design file and at the moment they can be configured in layout designer to specify their DCC address. Why not have these .ini file values configured there, so that you can have different values for, say, two different tippers.

Consider the possibility of someone using the same computer to run (at different times) two different layouts. Such a person will probably have two different track plans, and will use the current field in System Settings of RM to switch between the two layouts. It could be that some of the entries in the .ini file will be different depending on which layout he wants to operate. For example, Double Pulse=n, Point Button Arrows=n, and Show point indicators=n may have the opposite value on one layout to the other. So these items should really be configured by the Layout Designer and attached to the .pln file.

All of the other parameters in the .ini file could quite easily be changed within new tabs in the System Settings window. Some of these would mean that a change to a particular parameter value could be made "on-the-fly" without the need to reload RM. For example, Classic Buttons=n - changing this value, if it was in System Settings, could be actioned immediately.

A final argument for getting rid of the .ini file is that on each line, the text before the equals sign must be exact - one wrong character or an extra space before the equals sign and RM will ignore the line completely. I don't think it even gives a warning if it finds a line it doesn't understand. If the value after the equals sign is wrong, then I don't know what happens - I shudder to think.

If these items were removed from the .ini file and brought into RM itself, then you remove immediately the possibility of getting the text before the equals sign wrong. Also, it allows RM to validate any parameter value which the user enters, so it can't be given an invalid value. In fact, the majority of these parameters are 0/1 values, i.e. off/on no/yes. If they were inside RM, they could be switched by a checkbox (tickbox) control so they can’t possibly be given any other value than 0/1.

 

Ray

Link to comment
Share on other sites

The RailMaster.ini file is more straightforward to edit, from within the Help/About screen in version 1.62.

Entries are validated for both realistic and completely wrong assignments so it is difficult to get wrong.  Having said that there are also plenty of warnings when editing the file both in the program and in the RailMaster PDF guide.  We shall keep it that way for a while.

Link to comment
Share on other sites

I have just read the comments above by St1ingr4y, to me, they make a lot of sense.

 

To have these settings in layout design, all in one place, seems to me good house keeping, to have each item with a box to add data or tick or untick would be far simpler than the situation now with the .ini file, where there are risks of typing items incorrectly that could be bye passed (I have done this in the past), adding wrong data or spaces, saving incorrectly etc.

 

To me it makes total sense and so long as the table of settings can be saved or returned back to default, it has to be much better than it is now. 

 

I then read the reply from HRMS and must admit I was surprised. But after re-reading it I was a little happier, at least they have not shut the door on St1ingr4y's suggestion above, they have at least said that they will  'keep it that way for a while'. Hopefully when HRMS have more time, they will re-consider the suggestions above and implement them into RM.

 

Link to comment
Share on other sites

I'm sure I mentioned it before in one of these 40-odd pages, that Rocrail has 2 .ini files and both of them are configured by way of dialogue boxes mostly with radio button or drop down selection. It didn't always work that way - early days was using notepad to hand-crank the .ini files.

Link to comment
Share on other sites

The RailMaster.ini file is more straightforward to edit, from within the Help/About screen in version 1.62.

Entries are validated for both realistic and completely wrong assignments so it is difficult to get wrong.  Having said that there are also plenty of warnings when editing the file both in the program and in the RailMaster PDF guide.  We shall keep it that way for a while.

I had noticed over the last few days that my turntable was getting out of sync more regularly than usual. I remembered that I recently changed the .ini file setting Turntable timer=25 

To cut a long story short, on checking the .ini file, I realised that I had inadvertently deleted the 'e' from the word 'timer'. I found that the turntable seemed to be using a timer value of around 20 seconds (which is quite close to the default value mentioned in the manual). As soon as I had corrected the error and restarted RM, the turntable now started to run at the required 25 seconds. On examination of the log.txt file this entry had appeared:-

 

Set turntable inter-road run time to 25 seconds

 

When I examined the log.txt when I was using the incorrectly spelt parameter, there was no entry in the log.txt file. There was no warning message displayed when RM loaded up. So my question is this - where and when are these "Entries are validated for both realistic and completely wrong assignments" ?

 

Ray

Link to comment
Share on other sites

If you miss-spell an entry it will be ignored ...

 

In view of the intention to keep the .ini file, maybe the list of entries should be checked to ensure that they are in the list of correct entries and if not found in the list, highlighted in a different colour.

Link to comment
Share on other sites

If you miss-spell an entry it will be ignored.  Correctly spelled entries are validated for realistic/incorrect value settings.

This is exactly one of the points I was trying to make. Is it too much bother to display a message to the user if it finds a mis-spelt entry, rather than just ignore it. Even an entry in the log.txt file would be better than nothing.

Ray

Link to comment
Share on other sites

Looking back at the suggestion by St1ingr4y, and the messages that follow, I am more convinced than ever that what he proposed is the best option. 

 

The discussions of wrongly typed items in the .ini file, are not new, and as long as there is an .ini file there will always be risk of a typing error. Once saved and RM restarted we may not know immediately there is a problem or why something is not working as it should. Then we have to go to the .ini file again to check everything and correct it. Some people do not know where the .ini file is, let alone edit it and save it correctly.

 

All this messing around, yet a table of contents in the Layout Design section, with tick boxes, and boxes that only accept alpha, numeric, or alpha/numeric entries, that are within range and correct can only be acceptable. Surely this has to be easier for everyone.

 

RailMaster was initially built on the basis of making things easy for the novice.

 

The table of values, in the layout design, I think, would be so much easier, it makes more sense, and there is minimal risk of error, surely this has to be the best option for everyone.

 

But when you add to the table the facility to 'Save as' and 'Return to Default' these options certainly enhances the facility as there would be no chance of saving data that is not suitable for the program; first the data in the table can only be set within the parameters allowed and secondly it wouldn't save the data if it was not acceptable.

 

Link to comment
Share on other sites

If you miss-spell an entry it will be ignored.  Correctly spelled entries are validated for realistic/incorrect value settings.

This is exactly one of the points I was trying to make. Is it too much bother to display a message to the user if it finds a mis-spelt entry, rather than just ignore it. Even an entry in the log.txt file would be better than nothing.

Ray

 

 

Frustrating I think St1ngr4y, 

 

Building in fault finding and replies for .ini file entries, or a table of contents with tick boxes or add data within set parameters. Surely your first suggestion of the table in the layout design section is far simpler, less risky better for all users, particularly the novice. 

 

Wasn't RailMaster designed to make things easy for the novice to run their trains with computers?

 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
  • Create New...