Movable Bridge Rule

Hi all. Is there, or is it possible to have a rule that triggers all or selective movable bridges to a close position. As far as i know all bridges that move are in the open position by default, this make is difficult to issue commands to a driver to navigate, as an open bridge effectively breaks the route for the AI.

Is there such a rule or possible alternative to this problem.

Regards

NO rule that I know of but look into the ATLS system. It can control bridges also not just grade crossings.

barryg said:

as an open bridge effectively breaks the route for the AI.

Click to expand...

Hello Barry,

I fail to see how an animated bascule or other kind of bridge would affect AI schedule. The train actually rides on an invisible track in the bridge. The track you see and the part that moves is just a mesh and the train does not actually interact with it.

You can drive a train over a bridge while it is open or while it closes since it will only follow the invisible track.

As such, I do not see how it could affect the AI itself. Maybe there is another factor here?

Kieran.

Hi. I'll have a look at the ATLS system

@captainkman... In the case of trainz 2012 a 'Navigate To' command does work, But in Trainz 2004 there is the 'Drive To' command which does not work. The AI cannot see past the end of the track when the bridge is open.

Regards

That's very strange since there is no "end of track". Different KUID's of track (invisible on the bridge and whatever you use off the bridge) but its permanently connected and should look continuous to AI.

All moveable bridges are done as mocrossings and their operation is controlled by code in Trainz so a separate script file is not needed. If what you are saying is true then you should have the same problem on mocrossings.. Do you?

I've made several hundred moveable bridges over the years and this is the first time I've seen anything about AI not working on them (and I'm not the only maker of animated bridges. lol).

Ben

Hi Ben. Hmmm, i have never been able to get the AI to go anywhere past a Bascule or other movable bridges. I always get an error (off the top of my head), - unable to reach destination - or a similar message. If i were to replace the movable bridge with a static bridge the problem doesn't exist, thus i always assumed that an open bridge breaks the track connection. Perhaps it's my install of 2004, and 2006 that has always had this problem, but it has always been the same.

Thanks for all your replies.

Regards

Well, since your talking about it I'll add my 0.02 cents.

RE: Bendorsey's bridges, Mocrossing or otherwise.

I've found that issuing a drive to/via, Navigate to/via for an AI driver either for a trackmark close to or far away from the otherside of said bridge, results in the AI driver driving to/via the trackmark on his side of the bridge, slowing and stopping and then being unable to plot a path to the trackmark on the other side unless in the process of stopping he completely crossed the bridge in question. (Hope that makes sense to you.)

I've found that using the Autodrive driver command removes the above issue.

RE: getting advanced control over any mocrossing bridge from any author can be done by using vincentrh's crossing control triggers (http://forums.auran.com/trainz/show...manage-your-rail-crossing&highlight=vincentrh) - with the advanced mode setup(not hard) even multitrack Lift/roll/bascule/swing/etc bridges can be setup for high speeds/low speeds/any combination of high speed and low speed you want.

Check that you have the track connected at each end at the correct points. Some bridges have more than one connection depending on how they placed track on the bridge.

Interesting that this has (as far as I know) never been mentioned on forums before.

The reason most moveable bridges have more then 2 track attachment points is a function of kind mocrossing. They are of course where a road crosses the tracks and the code in Trainz is set up for them to trigger (gates close and so on) at about 80 meters from the track attachment points. This is fine for a real mocrossing which is never going to be 160 meters long.

Moveable bridges on the other hand are almost always longer then that so if only 2 track attachment points are used at some point towards the center of the bridge the train might run out of the 80 meter trigger radii of the track attachment points. The longer the bridge the worse this will be. It won't "bomb" your session since the train itself is running on the invisible track but the bridge will start to open back up and your train will be magically floating in mid air. Looks pretty darn silly, lol. The solution is to add more track attachment points so a train consisting of a single loco will never run out of any of the track attachment points 80 meter radii. I usually space them 200 feet apart. Is there a limit? I don't know but one of my bridges has at least 70 of them.

BTW - this radii is fixed in Trainz. You can't change it but there are ways of making the bridge trigger sooner then 80 meters away with markers and so on.

Ben

which is why I suggested using vincentrh triggers for controlling the multitrack Lift/roll/bascule/swing/etc bridges.

I have a test bed layout that I'm working on which has:

a wide canal with portals at each end - one end producing ships every so often, sending the ships to the other end which consumes them.

a double track lift bridge with short approach spans on both sides carrying a dogbone loop of track with length, signalling and trackmarks to permit the operation of a fast passenger train and a slow freight train with enough distance between each train to permit close to full speed movement.

a pair of trigger multiple signals rules

a) one set to prevent trains from passing a certain point when a vessel is in a number of spots(Multiple triggers to account for the length of vessels/tugboat and barges).

b) another set to prevent vessels from moving past invisible signals(a pair for each direction to catch SPAD's/multiple vessels)

vincentrh's level crossing triggers

so far this has been a success but there are a few more little issues to work out - when that's done I might try and record a video of this in operation.