Trackmark List Not Complete after TS10-TANE conversion

Greetings Trainzers, forgive me for spamming this forum like this, but yet another problem has come up that I would like to enquire of the community about, before I take a hatchet to it and break something really badly.

I recently brought my main route and it's associated basic setup session to TANE from TS2010. I am currently resurrecting it for use in TANE, and I have discovered that at least half of the Trackmarks on the route are failing to appear in the trackmark selection list when invoking the Navigate To, Navigate Via, Drive To or Drive Via driver commands. All trackmarks that start with the letters H - S are showing as normal. 0-G, and T-Z are not showing at all.

The funny thing is, the missing trackmarks are appearing in the CTRL-F find function, and are visible as normal in Surveyor, so it seems that the route itself knows they are there. Their text strings are also present in the route config.txt file. They are all in the route layer and always have been. Also, if I place a new trackmark with a name starting with H - S, it is immediately detected as normal. But a new trackmark name starting with 0-G and T-Z remains invisible to the driver commands.

Any insight offered as to why this potentially route-killing behaviour is occurring would be greatly appreciated indeed !

Why do the driver commands not recognise their presence in the route? Am I missing something obvious here?
 
Have you checked for updates? Tane uses a different way of saving and Tane SP2 is also different than Tane SP1. New commands have been brought out to use the Tane method.
 
Have you checked for updates? Tane uses a different way of saving and Tane SP2 is also different than Tane SP1. New commands have been brought out to use the Tane method.

Thanks for the response, Mr Stagecoach sir.

Yes, checked for updates to these commands. Which are the new commands meant to replace them? Would they not be in TANE SP2 as I purchased it? I can't see any obvious replacements in the Driver Command list in surveyor.

I may not be aware of such changes because I skipped the whole TS2012 debacle.
 
Hi

This was an issue on the ECML route in TANE right from the beginning. The problem is that there are too many trackmarks which cause the list to be curtailed. There is a workaround for it which was the Navigate to/via or Drive to/via commands being modified slightly by p-dehnert and they now list all trackmarks. A link to them is available in post #20 in this thread https://forums.auran.com/trainz/showthread.php?121847-rules&p=1438505#post1438505

They work just fine for me.

Regards

Brian
 
Hi

This was an issue on the ECML route in TANE right from the beginning. The problem is that there are too many trackmarks which cause the list to be curtailed. There is a workaround for it which was the Navigate to/via or Drive to/via commands being modified slightly by p-dehnert and they now list all trackmarks. A link to them is available in post #20 in this thread https://forums.auran.com/trainz/showthread.php?121847-rules&p=1438505#post1438505

They work just fine for me.

Regards

Brian


Thanks so much for this referral and suggestion. I downloaded the four modified driver commands, and they work as you described in my version of ECML, with all trackmarks showing. In my primary personal route however, these modified driver commands fail to be available in Driver or Surveyor for some reason. They are available in the Driver Commands Rule for selection, but beyond that they don't appear to be functional.

I assume that there are too many trackmarks (in excess of 2000 at last count) for even the modified versions to work with. I suppose my only hope now is to wait for N3V to update Navigate To/Via and Drive To/Via to cope with a huge number of trackmarks.

So at this point I have to abandon bringing my best route into service in TANE until a fix to these driver commands becomes makes it possible to use, if it ever happens.

Thanks N3V.
 
The alternative is to use Trackmarks in a way that doesn't cause the lists to become exceedingly long. Let's say we supported 2,000 trackmarks, then someone else wants 10,000 then someone else 100,000. You can see that at some point the concept of "every place on a map requires a trackmark" becomes unworkable.

Once solution would be to place a limited number of trackmarks in the Route layer. For example at each major location (station, yard etc) or perhaps at the entry to each (so N. Station and S. Station etc). This provides quick "access" to any key location on the map with dozens or perhaps hundreds of trackmarks.

Then, in the Session layer, place specific trackmarks required for that particular session.

Remember also that you have Industry locations available for Drive To commands etc.

If this system doesn't work for you for some reason, then I'd be interested in why not.
 
Hi again

I always try to keep trackmarks to a minimum by making use of driver commands such as "AutoDrivePastJunction" and "AutoDriveViaTrigger" by "atilabarut" as well as Drive to/via Trackmark.

The first thing I do with routes that I download from the DLS (or a third party site) is to remove all except essential trackmarks. As Tony advises above I then add other trackmarks to the session layer. I do this by adding them to a new layer called trackmarks added in the session layer.

If I then need to keep most of the session rules, driver commands etc for a new session it means that I can clone the session and just remove the previous session trackmarks by deleting the trackmark layer. I then add another trackmark layer to the cloned session.

Regards

Brian
 
The alternative is to use Trackmarks in a way that doesn't cause the lists to become exceedingly long

Hi Tony, nice to talk to you again. Thanks for your personal response, and congratulations on the advancement Trainz has shown with TANE, it is heading toward fulfilling it's full potential, and is very impressive, at least on my system. The problem at hand is the first really disappointing one I have hit in coming over to TANE.

I know you are busy, but may I briefly offer three points on this matter of upgrading the Navigate/Drive Via/To driver commands?

1. Whatever changed to limit the amount of trackmarks that these driver commands will detect also affected users of the ECML route, as per Kennilworth's posting.

2. All these trackmarks show up properly in TS2010 - although not in alphabetical order (thanks for fixing that btw!)

3. In this case it isn't so much the unnecessary overuse of trackmarks, more the sheer scale of the route. Consider the amount of trackage (most of it doubletrack) between London and Lille in France, including high speed lines, network lines, and a bunch of branchlines. There are maybe 150 AI and user issued schedules to move trains around, all of which require trackmarks on the main and in yards to properly direct them, many have station or intersection stops too. On a route that strives to have realistic trackwork with gradients and curves commonly in stations, fixed-track stations are not really an option. Then there is the operational side of things in all the yards and towns in between....... And with TANE's capabilities, it could get even bigger than that.

Admittedly, someone with a route like this could probably implement the alternative procedures you and Kennilworth speak of, with weeks and months of work. However I submit that anyone else building such a huge route as the ECML or this one would still run into this limitation at some point, as users of the ECML previously discovered.


If this system doesn't work for you for some reason, then I'd be interested in why not.

Well, I am not sure how many others employ a similiar Trainz useage methodology, maybe I am just a lone nutter, but how I use Trainz on this route is to run large scale operations over several game days or a week, with maybe 1500+ individual wagon movements generated by a spreadsheet. Needless to say my AI drivers more than earn their pay moving trains between yards - but they need good trackmarking for their long schedules, and trackmarks in the yard tracks for their arrivals. I as the human user tend to spend my time on shunting/humping/last mile work, and issuing schedules to AI drivers once trains are assembled. All these wagon movements take place among as dense an AI environment as Trainz/my computer will cope with, again requiring adequate trackmarking. (TS2010 could cope with about 15-20 simultaneous AI trains on my route) For a large Trainz route designed for this "operations" style useage, I submit that all the trackmarks need to be already in place and mapped out as well. There are very few trackmarks that never get used with this style of Trainz play.


Indeed, as you suggest, 100 000 trackmarks might be excessive, but 5000 or so would be awesome for very large routes. I am not a scripter, so I don't know how difficult it is to modify driver commands in this way, but if you do deem this impossible, please advise so that I may commence the mourning phase.

Thanks for your time, and keep up the good work.
 
Last edited:
Strange really because i moved ECML KX YORK over to Tane and there is no problem Then I moved KX Newcastle to Taane and the problem is there and if you check KX Edingburgh its there also, So why????
 
Actually guys, if theres too many trackmarkers theres another thing called Navigate to. It will work for going to Portals not sure about trackmarkers.
 
Back
Top