Crawling AI Trains.

[NeutronIC]

Just to throw something in from the other side of the pond... i'm in software development myself... and the major downside of frequent releases is the enormous amount of additional time spent testing - at a bare minimum each release that they put out would need to be tested with all the variants of the main package, plus all of their own add-ons. Ideally it ought to also be tested against a selection of user created content because if an update suddenly breaks a load of user content it might be nice to at least warn of this in advance... all of this takes up *huge* amount of time. If you can get something tested in the same amount of time it took to develop it then you're doing pretty well.

A previous commenter also said that he felt people would be more satisfied if RSDL gave more detail about what was in the patch as soon as it was definitely going to be in the patch. Well, the bad news is that that's exactly what happens - nothing is definitely going to be in the patch until the patch is basically done and tested because you can't always predict how one change will affect another - putting fix A in might work great, then put fix B in and it breaks fix A - but with minimal amount of time left you decide to drop fix A and run with fix B because it is a much more sought after feature... etc. It's just not that predictable. Additionally, every time you put out a "this is what's in now" list, you'll get a guaranteed 20 page thread complaining about what's *not* there, or speculating on how something might be fixed and then complaining that if your speculation is wrong then the world is going to end... and many many other pointless directions that such things can go in.

Speculate all you want, once there are facts available then RSDL will release them and then we can discuss it in the presence of facts rather than continued ranting and rumour.

Incidentally, the sudden slow-to-crawl of AI trains seems to be caused by (or at least one cause of it) the twit of a despatcher trying to change a point underneath the train, this causes the AI train to run very slowly and produces a shed load of output to the logmate logger thing where you can see it trying and failing miserably to change this point rapidly. Just change the timings of your AI for now so that they aren't relying on the despatcher to have a clue what it's doing because frankly it doesn't.

Matt.

[Retro]

Thanks for the advice Matt on why the dispatcher is causing the problem. I was just about to ask that question and find out if a solution is possible at present. So no need now. I am not up to AI trains yet as my route is still in the making but will soon be there. I also agree with Geoff's point about the Romans. I use a method similar to Geoff's with my level crossings and they look fine when passing. From what I can gather a number of the more major issues are being fixed in Upgrade 2. It would be nice to have a fix list but this is usually not possible until the Patch or Upgrade has been released.
EA usually present a webpage with the items fixed in the patch you are about to download. Speculation causes problems so IMHO this is the better way to do it.
So not yet a year since release and I am quite happy with KRS. It is keeping me busy in retirement.
Regards James.

[boleyd]

I would point out that many years of experience and development was the basis for the RS product. It was not started as a totally greenfield inception.

I believe that RS has a set of objectives for each release. Some are garnered from customers and are included with in-house sources. Assuming a 3 month targeted cycle one would think that after the first month of the cycle the highest probability of successful inclusion in the update would be known. As I have said before keeping the customer base "in the loop" is an important element in retention and attraction of customers. You need a dynamic environment not one that for a three month period customers have no idea if their concerns are being recognized and addressed. During this quiet period once again the rumor mill is fueled by speculation. RSDL has then lost control of the market and must hope that the release of the update will recover any customer loss, existing or potential.

Certainly there is an argument about the dynamics of updates where changes to code may unfavorable interact with either other new code sets or be hurtful to older code. If this is a concern then the answer is to provide a list of recognized issues. These lists have historically been the platform from which customers can lobby for their items. It has no commitments. I am familiar with this approach, in the past, from IBM and Oracle as well as other lesser known vendors. The problem with this strategy is that the vendor (RSDL) is no longer dealing with a contained customer base who usually are quite adult and serious with their needs. The Internet lets in to the discussion some who have personality and social issues. You only need a small number of these "dynamic" individuals to discourage a vendor from telling such a group anything.

Thus RSDL is probably going to have to continue on 3 month cycles of updates along with information blackouts as to the content and date for the update. At least we have an informal idea of what we might expect. Hopefully this will satisfy the current customer base. If it does not only are future addon buyers retained, new customers are not discouraged from buying RS due to a large level of negative forum messages.

[mbtech22]

Incidentally, the sudden slow-to-crawl of AI trains seems to be caused by (or at least one cause of it) the twit of a despatcher trying to change a point underneath the train, this causes the AI train to run very slowly and produces a shed load of output to the logmate logger thing where you can see it trying and failing miserably to change this point rapidly. Just change the timings of your AI for now so that they aren't relying on the despatcher to have a clue what it's doing because frankly it doesn't.

Matt.

This would tend to agree with my own testing of signals with AI traffic. Experience suggests that the AI Signaller can try and change the points because the signalling links are not correctly set out, and this causes confusion within the track occupation database. If this is happening to you I suggest that you look very closely at how your signalling is set-out. It may also be worth tweaking a few of the train start times to move the point of potential conflict. Then seeing what difference it makes.

Mark Brinton

[Retro]

Thanks for that additional information Mark. Much appreciated.
Regards James.

[phat2003uk]

Incidentally, the sudden slow-to-crawl of AI trains seems to be caused by (or at least one cause of it) the twit of a despatcher trying to change a point underneath the train, this causes the AI train to run very slowly and produces a shed load of output to the logmate logger thing where you can see it trying and failing miserably to change this point rapidly. Just change the timings of your AI for now so that they aren't relying on the despatcher to have a clue what it's doing because frankly it doesn't.

Matt.

This would tend to agree with my own testing of signals with AI traffic. Experience suggests that the AI Signaller can try and change the points because the signalling links are not correctly set out, and this causes confusion within the track occupation database. If this is happening to you I suggest that you look very closely at how your signalling is set-out. It may also be worth tweaking a few of the train start times to move the point of potential conflict. Then seeing what difference it makes.

Mark Brinton

Just out of interest, how are the signals set up wrongly and how can they be fixed?

[TheTazman]

Hi Derek

Rome was not built in a day and the Roman Empire lasted over 400 years.
You have only been going for 10 months since release, I am sure there is much more to come over the next 399 years and 2 months.

What have the Romans ever done for us?

Aquaducts, Sanitation, Roads, Irrigation, Education, Wine, public baths, medicine, public order..... Rail Simulator.

http://www.youtube.com/watch?v=ExWfh6sGyso

Tazman

[mbtech22]

Just out of interest, how are the signals set up wrongly and how can they be fixed?

Two of the most common errors appear to be:
1) Failure to put links on all routes from a signal. All potential routes from a signal should have route links applied regardless of whether the route is actually used or not. Failure to do this appears to cause problems with the track occupation database as the boundaries of the signal's Link0 section can change depending on the setting of the points ahead of the signal.
2) Placing a signal link on the wrong side of a set of point blades. This usually occurs when a junction signal is located close to the points. The Link0 is set short of the graphically displayed point blades but is actually within the point database area and beyond the split in the "track database". The location of this split appears to be graphically represented by the red triangle or rectangle marker. The means that the Link0 can apply only to either the main or diverging route. Therefore the preceding signal will still apply to the other route.
A third problem that can occur especially in complex signalled areas is the overlapping of links. Route Links should normally not overlap into the Link0 of the next signal.
Lastly another problem sometimes found when reversing direction at a signal. The links are not completely cleared by the rear of the train before changing direction and therefore the signalling sequence can cause some of the signalling to lock on. Route links for a signal controlling a trailing move over the points must be beyond the red point marker, but before the Link0 of the junction signal controlling the facing move.
In the current signalling system you need to think as follows:
The track is split into sections and the boundaries are indicated by the track links of the signals (Link0 and Route Links).
Each section runs from one Link to the next point in the same direction.
When the front of a train passes a Link it changes the status of the section ahead to Occupied (+1).
When the rear of a train passes a Link it changes the status of the section to the rear to Clear (-1).
The front and rear are dependant on the direction of travel, not which end the loco is attached.
One problem is that the "track database" uses a counting system which is interpreted to determine clear or occupied status. Thus each time a train enters a section, its occupation counter number is increased by one and each time a train leaves a section it decreases by one. A section is only clear when the count is 0. If trains do not traverse the links correctly this count can easily get corrupt and can result in signals locking on.
The above is a much simplified explanation of how the signalling works in relation to track occupation and is based on my experience to date with my testing of signals. Further more technical information can be found in the RS Signalling documentation.

Mark Brinton

[phat2003uk]

Thanks for that information, very interesting.

[mearle73]

Mark do you know how log mate works (Script Manager,Signals) with all this as it flags errors on all the standard routes including the IOW route ?

[Retro]

Thanks for all that information Mark. As you say and have advised me when I first started delving into signals is that the correct placement of links is crucial and also avoiding overlaps which in complex junctions can be tricky. When testing my route with a standard test scenario it usually becomes obvious which signals are not working correctly and those that are not are generally caused by a link in the wrong place, A slight adjustment of the link usually puts things right. If it doesn't I find replacing the Signal with the correct links in the right place seems to work also.
Regards James.

[Retro]

Mark do you know how log mate works (Script Manager,Signals) with all this as it flags errors on all the standard routes including the IOW route ?

The Dev Docs mention the Signal Validation Tool which involves adding extra lines to the RS shortcut and it is then supposed to output signal placement errors to Logmate. I have never been able to get it to work though.
Regards James.

[NeutronIC]

Unfortunately the problems i'm experiencing with crawling trains are on the default newcastle route but i'll take a look at its signals and see if I can find anything wrong as you suggest

Thanks very much!

Matt.

[AndiS]

While I agree with all that Mark said about potential errors in signal placement, I must say that I observed the crawling syndrome on a test route that was nothing but a single track with single-link signals on it. Thus, while the theory about changing switches sounds ok, it is certainly not the only reason. I also observed the crawling in light engines quite far from any switch (at least half a mile), but I cannot exclude from memory that some switch was changed in that other case.

Also, I would not make too strong assumptions about the dispatcher and the Lua scripts. I asked often about the role of the occupation tables and never got any answer. And I see often trains waiting for the signal to clear to green, instead starting off when the signal changes from red to yellow. This, again, on clean-cut test routes without chance of some link mess-up.

[NeutronIC]

Agreed Andi, I'm certainly not saying it's the *only* cause, just that in this instance I saw it spamming the heck out of the logmate log trying to change two points that were right next to each other (presumably a cross over) - nothing visible in the sim except that the train was definitely right over it.

Matt.