Towards Intelligent AI Traffic

I've spent a great deal of time trying to manage AI traffic on my single-track mainline. I wanted my player train to enter a passing siding, come to a red signal at the end of the siding, wait there for an oncoming AI train to arrive and pass, and then have the signal clear and allow the player train to proceed.I read everything I could find on AI traffic, and experimented extensively with double reversing points and passing/optional paths, but nothing seemed to work consistently. It seemed almost random. Sometimes the AI train would appear and pass--if I first nudged the player train into reverse, but that seemed a bit gimicky to me, and in any case the signal facing the player train would never go red.I finally found a method that seems to work flawlessly, at least for me, and I offer it here for discussion, for whatever it may be worth. Maybe it's been tried before, but I haven't seen anything on it. I don't know if it will work with other signal systems, but I use Hank's upper quadrant semaphores and they work perfectly on these passes, for both the AI and player. The player gets a red at the end of the passing siding, the oncoming AI train appears and passes, and the signal facing the player train then clears to green.1. First note the signal block in which the player is to stop (call it the reference block).2. Start the AI train's path in the third block out from the reference block. Then just run the path through the siding on whichever track it is to use--no passing path or optional path. End the AI path in the block after the reference block.3. Set the AI start time according to the player train: the AI must appear in its starting block while the player train is in the third block out from the reference block--in the opposite direction. (I just run the sim, note the time when the player train should be in that block, and then use that time for the AI start time.)Again, this may sound a bit weird, it may not work with other signal systems, and it may not meet everyone else's requirements, but it's been working like a charm for me. I was so frustrated with AI passing problems that I was on the verge of abondoning the hobby, and so I hope someone out there may find it helpful.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RE: Towards Intelligent AI Traffic, robertreedy, Jun-14-04, 08:02 PM, (1) RE: Towards Intelligent AI Traffic, kevarc, Jun-14-04, 10:53 PM, (2) RE: Towards Intelligent AI Traffic, JohnR, Jun-14-04, 11:47 PM, (4) RE: Towards Intelligent AI Traffic, JohnR, Jun-14-04, 11:45 PM, (3) RE: Towards Intelligent AI Traffic, robertreedy, Jun-15-04, 11:00 AM, (5) RE: Towards Intelligent AI Traffic, JohnR, Jun-15-04, 11:40 AM, (6) RE: Towards Intelligent AI Traffic, JohnR, Jun-15-04, 07:21 PM, (7) RE: Towards Intelligent AI Traffic, robertreedy, Jun-15-04, 08:24 PM, (8) RE: Towards Intelligent AI Traffic, JohnR, Jun-16-04, 11:21 AM, (9) RE: Towards Intelligent AI Traffic, GaryG, Jun-16-04, 01:48 PM, (10) RE: Towards Intelligent AI Traffic, JohnR, Jun-18-04, 11:28 AM, (12) RE: Towards Intelligent AI Traffic, GaryG, Jun-18-04, 12:07 PM, (13) RE: Towards Intelligent AI Traffic, JohnR, Jun-18-04, 12:51 PM, (14) RE: Towards Intelligent AI Traffic, railfan4ever, Jun-16-04, 04:13 PM, (11) RE: Towards Intelligent AI Traffic, goonybird, Jun-21-04, 05:49 PM, (15) RE: Towards Intelligent AI Traffic, kevarc, Jun-21-04, 09:37 PM, (16) RE: Towards Intelligent AI Traffic, goonybird, Jun-22-04, 01:03 AM, (17) RE: Towards Intelligent AI Traffic, kevarc, Jun-22-04, 08:31 AM, (18) RE: Towards Intelligent AI Traffic, goonybird, Jun-22-04, 11:36 AM, (19) RE: Towards Intelligent AI Traffic, kevarc, Jun-22-04, 11:54 AM, (20) RE: Towards Intelligent AI Traffic, goonybird, Jun-23-04, 05:20 AM, (21) RE: Towards Intelligent AI Traffic, goonybird, Jun-23-04, 06:35 AM, (22) RE: Towards Intelligent AI Traffic, goonybird, Jun-23-04, 07:50 AM, (23) RE: Towards Intelligent AI Traffic, jamesphh, Jul-02-04, 03:43 PM, (24) RE: Towards Intelligent AI Traffic, robertreedy, Jul-02-04, 07:24 PM, (25) RE: Towards Intelligent AI Traffic, goonybird, Jul-03-04, 07:26 PM, (26) RE: Towards Intelligent AI Traffic, goonybird, Jul-05-04, 09:12 AM, (27)

Conferences | Topics | Previous Topic | Next Topic

>Start the AI train's path in the third block out from the reference blockJohn, I think some good advice, but possibly one qualification on the above for others reading this and using it. They need to check in the sig files and see how many signals ahead are being read. I think this may be what determines how many 'blocks' ahead they need to start the AI path. Some of the routes out there are reading 2, 3 or 4 signals ahead, with one in particular reading 6 signals ahead. Not sure, but I think this might also be one of the 'causitive' factors.RobertR .. ADF-M&RM at http://www.adfrr.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

yepKevin Arceneaux
DEFAULT IS FOR DUMMIES
Cry havoc and Let slip the dogs of war.
It's fun being CRAZY!!!!!
Lone Wolf Activities Forum and Activity Packs are on www.3DTrains.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Kevin, your talent for succinctness is both enviable and amazing.JohnR

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RobertR: thanks for the comment. That's kind of what I thought--that it had something to do with how many signals ahead the script is reading, but I'm not really well informed about the script details. But what surprised me is that in all my tests the AI passing procedure only worked properly when both conditions were met: the AI was back three blocks, and the AI start time was matched to the time at which the player train was back three blocks in the other direction. So if number of signals read by the script is the key, would it follow that if the script reads, say, four signals, then the AI start time must be matched to the time the player train is FOUR blocks back in the other direction?Anyway, I seem to be squandering my golden years on AI traffic!JohnR

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-15-04 AT 11:02 AM (EDT)

>So if number of signals read by the script is the key, would it follow that if the script reads, say, four signals, then the AI start time must be matched to the time the player train is FOUR blocks back in the other direction?Maybe Kevin or someone can help with this one. I think what you are saying is true, but can sometimes be shortened depending on whether the previous signals are absolute or permissive. However, I've run into a consistant problem related to this. What happens if you want an AI to pass (either direction) at the beginning of the activity where there is no previous player blocks to use (if you don't want to use double reverse points, but do it manually and logically, if there is any such thing in MSTS)?>Anyway, I seem to be squandering my golden years on AI traffic!Don't feel alone on this. I think I've put more time in trying to get AI traffic to co-operate (not only my route, but others as well) than I did in making the route in the first place. Some of it my own doing of course, but that doesn't make it any better
RobertR .. ADF-M&RM at http://www.adfrr.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Robert, good points. First, I'm only using absolute signals now, and I haven't tried any of this with permissives. They might make a difference, as you suggest.Two: When I want some AI traffic to be passing right at the start of the activity, I've been putting double reverse points right under the train at its starting position. Then, if the player train just sits there initially the AI traffic ignores it and passes as desired.I also find the double reverse points usually work well for passing by an AI train overtaking from behind. I place a pair of RPs very close together where the player train is to stop, usually just before the signal at the end of the double track. The player will get a red signal there, and if it stops and sits, the AI will come from behind and pass and the signals will respond correctly.I might mention that what's helped me more than anything else in this area was building a very short, u-shaped route with lots of short blocks and a couple of passing sidings, for the sole purpose of testing AI traffic and signals. The u shape enabled me to see what the AI was doing--which more often than not was just coming to a stop at the first signal it encountered, and waiting there until I nudged the player train into reverse.Anyway, hope some of this may help someone out there. I've gotten so much invaluable information and generous help from this forum that I'd like to give something back.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Robert, as a postscript: I went into my little test route and changed all the single-track signals (those not protecting an interlocking) from absolutes to permissives.Then I created an activity with an oncoming AI train, using the principles I espoused earlier.Well, the AI train performed as desired, and the signals worked correctly--except that the signal facing the player train at the end of the double track remained red and wouldn't clear.This doesn't bother me personally, since I'm only using absolutes anyway, but the plot just continues to thicken, doesn't it!JohnR

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

.. like cold gravy, the plot thickens very quickly >Two: When I want some AI traffic to be passing right at the start of the activity, I've been putting double reverse points right under the train at its starting position.John, I have run into problems doing this consistantly. It works fine on my machine, but every activity pack that I have uploaded has had at least a couple of people that have the route absolutely refuse to load until they contact me and I change the RP's around to where they are not under the player consist when starting. I have no theories on this at all .. can't seem to find a common denominator except for the fact that everyone of them have been using XP. However, everyone else using XP seems to get them to work, so I am just plain 'confused' >The u shape enabled me to see what the AI was doing--which more often than not was just coming to a stop at the first signal it encountered, and waiting there until I nudged the player train into reverse.You may have thought about this before, but you can actually use almost any route to test things like this to see it happen under different circumstances. Simply put a yard view in at the point where you want to begin your path, change to the 7 key and you can literally float all over the route until you change to a different view. It works wonders when trouble-shooting things and is much easier than almost any other way of getting a good view of what's happening 3 blocks away.RobertR .. ADF-M&RM at http://www.adfrr.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>>...double reverse points right under the train at its starting position...>John, I have run into problems doing this consistantly. Robert, I'm sorry to hear that the DRPs have caused a problem in this type of application. It's one of only two uses of DRPs that have worked for me.>>The u shape (for a small test route) enabled me to see what the AI was doing-->...Re the suggestion of using the yard view: Thanks, Robert, I hadn't used that before but am sure I'll do so a lot from now on. Incidentally, though, the small test route also has the advantages of letting me set up short blocks that save travel time, and also allows me to quickly change things around (including track and switch configurations) without fear of corrupting the data or losing anything that I can't replace again very easily.JohnR WWW.JoRaff@WorldNet.ATT.net

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

HiIf you start the AI after the player train has already set its route beyond the Red, the AI will flip the switch for its route and you're stuck because in most cases once a route is set it won't be reset if something else changes it. This usually won't happen if you follow the next 'rule'.Are your starting the AI far enough away that it has to pass at least one Absoulte signal? If not, you're possibly overriding Signal Interlocks that have already been set up.After the AI passes you, does the F8 Helper show the switch lining up for you? If not, you probably need to start the AI earlier so if sets up its route through that switch first. This way once the AI clears, your route might then get set up properly.A DRP before the problem location should allow the AI's path to get set up through the switch first although not always needed. Placing a DRP delays extending the path beyond the DRP until it has been passed over. As long as the AI has set its route through that switch before you pass the DRP things "should" work properly. I usually only resort to using a DRP if nothing else works.There is no such thing as Intellegent AI Traffic, all the intelligence is determined by the activity developer. In MSTS I'm not sure what the "I" in AI stands for but I'm fairly certain that it isn't Intelligence.GaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi, Gary:>If you start the AI after the player train has already set
>its route beyond the Red, ...I'm not clear on what "red" your're referring to, and I'm not sure which of the individual posts your message is replying to.Anyway, as I said above, I start my AI three blocks out, and I time it to appear when the player train is three blocks out in the other direction. With my signal system (Hank's UQ Semaphores, absolutes only) that work's perfectly and reliably for me.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi JohnI was trying to reply to #7 and did a very poor job didn't I.What I was trying to say is that it appears that once your path has been lined up then some other path changes the switch that was already lined up, it won't always get lined up for the original path again. In the case of #7, and the Permissives, your path had probably been set up beyond the Red you got stopped at but the Permissives allowed the AI path to flip the switch thus blocking you in and leaving the signal Red.Hope this helps clear up a bit of the confusion I caused.GaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Gary: Got it. Thanks very much.JohnR

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Last night I tried what you said (on the FBL v3) and with slight modification it worked. I was able to set up a meet between my train and another train. I had the AI train leave BEFORE my train even came into play. I don't spend much time designing activities.

SD40-2: the best locomotive EMD ever made!

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Has anybody tried manually sorting a traffic pattern into chronological order? I've found doing so makes my AIs -- errr uhmm errr -- intelligent.Upon signallizing an 11-mile stretch of my route, I created an activity wherein I lobbed about 130 AIs to see how well the signalling worked. Simply put, the 11-mile signallized section starts out with a 16-platform station terminus narrowing into ten, then to eight, and spurs into six tracks and four tracks for the remaining two miles; three full interchanges, three partial interchanges and a dual-track mainline spur off; signals scripted to double-absolute (?! -- I don't know how to call this) end up protecting the junctions such that a train can only be paused at the junction ends, because the junctions are long due to there being no X-track used.Well, the activity didn't start out well for I was faced with a stalemate pretty early on.However, I remembered from somebody's posting from more than a year ago advising activity creators to try to keep the AIs they write into a traffic pattern in chronological order per their individual timings at being spawned by the sim. This isn't always readily possible for -- if a creator were like me -- s/he realizes how to enhance the activity as s/he goes about writing/creating it.So faced with the stalemate, I decided early on (thank the cosmos!!) to manually investigate the traffic pattern that I'd dedicated to the activity. Sure enough, from manually opening the traffic file I saw that many trains timed to spawn early on in the 60-minute long activty (of which the player's life lasts only 20 minutes) by the sim were declared toward the end of the whole traffic file. What I mean to say is that the order of declarations of each traffic service did not match the order by which each AI was being spawned.So I manually sorted the declarations by (basically) performing the following steps:
1) Manually made copies of both the activity file and its (dedicated) traffic file.
2) Deleted the corresponding "*.asv" file
3) Manually opened the traffic file.
4) Sorted all its "Service_Definition" parameters (i.e, the declarations) into chronological order by carefully cutting and pasting them into the order by which they were being spawned. The declared timing of the spawning of a service definition is declared in the second of the two values that follow the opening bracket subsequent to "Service_Definition" by a five-digit number (the first value is the filename of the actual service file {i.e., "*.srv" file, but without the ".srv" part}). If the traffic service must call at stations -- or do other things, I guess -- then the whole service definition will be immediately followed by other parameters to account for the whole activity of the service, thus making the service definition a block parameter; therefore, for these complex service definitions I had to be careful at which five-digit number I was taking into account, and also with exactly what I was cutting to paste in elsewhere within the file.
5) Reviewed the whole new order of declared service definitions, and made necessary revisions of those that I had misplaced or overlooked.
6) Closed and saved changes to the traffic file
7) Opened the activity in the AE
8) Assigned it no traffic pattern (i.e., "None")
9) Computed-and-saved the activity, thereby assigning it a fresh "*.asv" file (because I've found the deletion of the asv file {step 2} to be necessary for, e.g., when converting an activity into an ITR) while also gleaning the activity file of its mirrored traffic-definition data -- in fact, I think the activity file is quite sensitive, for resetting its traffic definition seems to have been indeed necessary for solving what had initially struck me as a totally unrelated problem: http://www.train-sim.com/dcforum/DCForumID7/2160.html#2)
10) Re-assigned it the (dedicated) traffic pattern
11) Computed-and-saved the activity
12) Close the editors and tools and played the acitivity in the simI was floored to discover that the whole activity worked to the point that it worked too well for my liking, for I do fancy being held up now and then when driving. So I opened the traffic file again, (i.e., that is after having made another set of back-ups of the revised versions of both the activity and traffic files), spied a couple of seemingly worthwhile adjacent service definitions, and simply switched their order; well, just this simple modification changed the whole play of the activity considerably.I had also strewn yard views at strategic points along the 11-mile stretch, and they became handy by being able to monitor any AI first-hand.However, there are complications:Sorting works fine if the placements of all the spawnings are uniform, i.e., traffic in one direction are all spawned in at one end of the 11-mile section, while opposing traffic all spawned at the other end of the whole section in the above-mentioned activity.I created a couple of other activities subsequent to the above-mentioned one, the last of which involved bringing in even more trains by having approximately six copies of a service spawning on a branchline merging nearby and into the broad mainline come along periodically. The order of each of these copies had to be revised after their being sorted chronologically, for each of them merged with another series of trains that had spawned several miles away plus stalemates were occuring. I guess headways have something to do with the following finding, mine having been four minutes' worth (in all the activities).For the early-occurring branchline copies, I had to advance the chronology of their being declared by three's worth of the corresponding, coinciding copy of the mainline series of AIs; with the latter-occurring branchline copies, about five to six's worth, for I guess traffic by this point of the whole activity had become quite heavy around the point where this merging takes place. The stalemates had been resolved.I've little -- if any -- knack when it comes to the art of pursuasion, for I mentioned this whole sorting matter some while ago and got no response; this thread has given me a context to try again. I'd really fancy knowing what somebody else finds were s/he to try sorting her/his traffic file should s/he have encountered problems with a complex activity of hers/his.Cheers,
goonybirdUpdated March 2004: http://www.geocities.com/BourbonStreet/Bayou/4804/ -- a fictitious network serving London, Weymouth and points in between

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Not really. I think it is a gigantic waste of time. Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Cry havoc and Let slip the dogs of war.
It's fun being CRAZY!!!!!
Lone Wolf Activities Forum and Activity Packs are on www.3DTrains.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Oh, really? because your first sentence belies the conviction of your last one.Why would you share your negation? Are you trying to thwart folks from thinking about how to overcome priority assignment by the overall mechanisms of the sim?And how come you don't rationalize your negation for others to mull over?Cheers,
goonybird

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

No, just what you are doing is a huge waste of time. It is very easy to set up priority for INDIVIDUAL meets. IT is not rocket science, it is a matter of carefull creating paths that will give you the required flexability. It is called PLANNING. A little bit goes a long way. And very little of it is in the service/AI traffic files. 99.99% of it is in the player service.I don't need to reationalize anything, it is a matter of been there, tried that, and it didn't work. You have continually refused to listen when others have told you that ain't going to work Homer. You have trudged ahead for weeks only to find out that what we have told you is fact. Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Cry havoc and Let slip the dogs of war.
It's fun being CRAZY!!!!!
Lone Wolf Activities Forum and Activity Packs are on www.3DTrains.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>It is
>very easy to set up priority for INDIVIDUAL meets.In the N-American context of things, you're aboslutely right. For instance, my sister and I thought we'd be able to soak in plenty of trainspotting picnicing in a Havre-de-Grace playing field beside the Amtrak's Acela line one weekday summertime afternoon -- we became bored, plus we heard only one whistle emanating from a level crossing to the parallel CSX line a little ways to the north. I wouldn't be surprised if this venture of Amtrak's is losing money big time. Then on some weekday lunchtime hour I became real restless waiting forever for a train to appear at the commuter junction station Jamaica Centre on the fringe of NYC.I guess my tweaking stems from simultaneous multiple meets committed to my traffic patterns as opposed to individual meets (I'm not sure what's meant by individual meets).Needless to say, the activities whichfrom I've shared my findings are really complex, there's no falling asleep in them what with something happening every 30 to 45 seconds. So the FPS rate is lousy, what do I care, right; all I'm after is action.>You have
>continually refused to listen when others have told you that
>ain't going to work Homer.It's actually reading, which I've encouraged you on more than one occassion to retry upon your missing my points made in my postings; besides, your assumption about some refusal is dead wrong. Your persistence at taking the accusatory stance with folks has long become too dull for me. For instance, why does your tag promote the killing of people!Cheers,
goonybird

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-22-04 AT 11:56 AM (EST)

Because there are way to many.30 to 45 seconds? While we all add a lot of extra traffic than there should be, that is over the top.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Cry havoc and Let slip the dogs of war.
It's fun being CRAZY!!!!!
Lone Wolf Activities Forum and Activity Packs are on www.3DTrains.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>Because there are way to many. What aspect are you responding to? too many what? steps to perform? I've another recent posting in this forum asking if anybody think it worthwhile creating a utility to circumvent the flippin' tedious, manual cutting and pasting involved at making a traffic file (hence pattern) sorted into an absolute chronological order, i.e., the timings of both:
a) the AI spawnings, plus
b) the AI declarations for the benefit of the activity file
be in chrono order. How can the traffic pattern be an absolute, true pattern if the order of its declarations are all jumbled up?But this last sentence of mine above is too far ahead when I think about it, for I wish you -- and others! -- would re-read my findings spelled out after my 'However-there-are-complications' subtitle. It's very interesting what the sim is doing, and makes utter sense to me. I only hope I've described it clearly enough (I kind of think that I haven't).>that is over the top. Not if the right of way has the tracking to accommodate the volume of traffic. Besides, the sim can handle it, i.e., the volume and simultaneous priority assignments. (I do see, however, what you're getting at by "over the top"! but I love it!)I did discover a solid limitation of the sim, however.Somebody uploaded a route set in China a few seasons ago. The ?Harbin? route offers an end-to-end trajectory of approximately 2000Km. Its signals have been placed at intervals of about 1Km. I bumped up the engine physics to some EMU such that the fastest speed I got it to travel upon that route was 2300 miles/per hour (not Km). I set the EMU in an activity (as opposed to explore mode). Dispatcher couldn't keep up with its speed because of the tight spacing of the signals along the right of way, i.e., I was booted out of the activity both of the two times I had bothered to play it because I had "ignored a red light" when my train was the only existant one in the activity. OK, OK, so there are about a dozen signals in that route that hadn't been linked by its author, but I really do believe that dispatcher couldn't niether suss out the signal script nor yield safe passage for my train quick enough by the time it reached 2300 miles per hour.I would say that this is a definite/solid instance of being over the top, for the sim couldn't fully keep up. Cheers,
goonybird

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

(>Because there are way to many. Cheesh, now I get you. I'd say too many freekazoids, not people; let nature take care of paring down, never task freekazoids with nature's role.Cheers,
goonybird)

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>I think it is a gigantic waste of time. If time is of the essence, then I suggest Everybody try out the following short experiment.Make two paralleling AIs spawn upon a passing siding at the very same time and travel in the same direction. Path them so that they must compete against each other to travel over the single-tracking ahead of them. Ensure that neither one of their paths intersects the player path. Make their respective consists unique-looking so you can readily recognize which one gets the priority at taking the single track ahead of them.I suggest limiting the player train to navigate a nearby depot siding, and equipping that siding with a yard view. Time the dawning of the activity earlier than the spawning of the two AIs such that you'll have enough time to fly over (the 7 key) to where the AIs spawn and must merge into the single-track line thereafter.The AI that is declared at the top of the traffic file will get the priority.By performing all the steps in msg #15 above, flip the order of these two AIs; you will see that the other train will get the priority instead.If you were to even delay the spawning of the top-declared AI against the timing of the spawning of the bottom-declared one, you will observe that top-declared AI will get priority.I mean, how on earth did I get all this to work, right! -- the screenshots are from the last one of my three-mentioned activities in msg# 15, and I assure you that none of the trains shown is motionless: I'm certain all the knowledge shared early on in this thread is indeed valid. It's just that there are indeed other influences that factor into the handling by the sim, for there also appears to be much uncertainty and speculation in what folks share here.My findings friggin' well occurred/happened/took place/became history!! I'd simply like somebody else to try out the full chrono sorting to verify my findings, and overcome all this BS with respect to priority assignments made by the sim -- there's still left so much other ground for us enthusiasts to pour over, no?I also have a hunch that some random factor has been written into the sim by its programmers at point of manufacture. For instance, has any of you ever noticed how the derailed cars fall differently every time you restart a saved activity (my derailments amounted to train meeting end of track 15 seconds after my save)?Cheers,
goonybird

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

This very interesting, but! Dis anyone take in to account the abilities of the driver of the player train? New players to the activity have different timings than ones that have played the activity multiple times. Therefore, assuming that the players train will be at a specified poit at a specified time mau be false.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Actually you can't assume they will be at a specified place at a specified time unless you basically force them to be, by using various artificial means. For example if someone is highballing 5 minutes ahead of where they should be, use a set of events to give them an (artificial) speed restriction for X number of miles to bring them back in line with where they should be timewise. In essence you could have a location event triggering a speed limit (for the faster ones) for a specified distance/time then a matching location event to 'resume speed', which is shut off by a timed event so that it does not affect someone running at a slower speed.Or for switching you could simply not give them permission to re-enter the main until xx:xx time, with a corresponding location event to shut them down if they try that is triggered off at the correct time by a timed event.Granted it is all artificial, but if done correctly can almost be made transparent without the player even realizing it unless they run it multiple times. Hope this makes sense.RobertR .. ADF-M&RM at http://www.adfrr.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

But not interesting enough to try out the basic test/experiment with simply two AIs, right? My suggested test/experiment for folks to try out is not about forecasting when a train will reach a specified point at a specified time; such forecasting comes about by trial and error, and tweaking with a performance rating if so wished. This whole matter about chronologically sorting the service deinition declarations in a traffic is really all about which AI gets to take priority over another/others. The third of my above-mentioned >130-equipped-AIs activities involved isolating the player train to some yard, where no other AI even came near to crossing its path (or vice-versa, right). I used the yard view to fly over to see how the trains were going about at yielding and taking priority, after having watched the traffic flows on the VCR to the AE to ensure all worked well. The 3rd activity involved:
A) one quarter of the mainline trains changing tracks upon, basically, an eight-tracked mainline
B) branchline trains merging into the mainline
C) mainline trains diverging off onto the branchline
D) branchline trains diverging and merging into yet another branchlineWhat I found interesting was Type B above, because the spawning point of those branchline trains was way, way closer to the merge point compared to the spawning point of the mainline AIs that they had to compete against. Because the branchline spawning point was way closer to the merge, this is why I had to manually advance their chronology in the traffic file so that their declarations preceded the corresponding AIs against which they respectively had to compete in play. If I hadn't advanced their individual declarations after having properly sorted the file into chronological order, all following trains would have been held up by the isolated stalemate down the line from them, which altogether had been my problem with that third activity in the first place.My recollection about the stalemate is a little hazy now. However, I seem to remember the stalemate came about from a mainline train being prevented from de-spawning, because the corresponding branchline train that was to merge into its track was behind it, i.e., the branchline train became caught behind the mainline one. It was as though the branchline train was to de-spawn before the corresponding mainline train.Cheers,
goonybird

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Tut tut tut -- I bothered trying out the test myself (on Marias3.0) and found it didn't work.But I guess that this fact of the test not working versus my overcoming the stalemates in the three activities is some kind of clue. I don't know, I find myself wondering about the way the activity file mirrors a traffic pattern, because forcing the AE a few weeks ago to rewrite its mirroring is what cleared up some problem I had with a consist ( http://www.train-sim.com/dcforum/DCForumID7/2160.html#2 ). Anyhow, as far as priority assignment goes, maybe the UIDs to the mirrored service definitions are what must be sequential. Manually sorting the traffic file into chronological order/declarations might have caused the UIDs to become sequential.Cheers,
goonybird

Alert | IP

[ Home | MSTS Forum | MSTS FAQ | How To... | File Library ] Copyright © 2004 by Nels Anderson. All Rights Reserved.