PDA

View Full Version : Simple 3 signal String fails?



boleyx
09-20-2009, 01:35 PM
No new patch. Service 1 is an AI engine with a destination2 the target beyond Service2.

Signals in first picture look good. Go into Play mode and they all turn green which is not correct.

Run the scenario and Service1 will not move despite the all green. AI smarter than signals?

Change target to Destination2 and the same signal appearance - Edit=first picture and play=second. But now AI lets the Service1 run to the destination.

I would expect the signals in Play to be be red, yellow and green in Play moving toward Service1.

Capt_Scarlet
09-20-2009, 02:38 PM
I assume you are exiting to the menu in between the edit and play of the scenario ?

John

sniper297
09-20-2009, 02:55 PM
Gotta keep in mind it's not train - signals, it's train - PATH - signals, you can't see the path but it affects everything. A train starting on the back side of a signal won't make that signal red because the signal don't actually "see" the trains, what it sees is the PATH, and if the train hasn't started running yet the signal don't see anything. AI train follows the path, since the path sees the other path it stops, AI train won't go unless it has a path to follow. Only way to make that work is to start them further apart, preferably starting the AI train on a side track with extra "spacer" signals on it.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20639&stc=1&d=1253472395

Start here, this signal is green over red, should be red over red, it don't see that train.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20640&stc=1&d=1253472410

Move the starting point back before the previous signal, THAT one don't see the train either so it's green.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20641&stc=1&d=1253472422

But once I pass the trip for that signal, this signal now sees the block as occupied and turns red. USUALLY they all work okay after that, of course they're not consistent. Sometimes they don't clear when they should because they didn't see the last car of the train passing the trip for the next signal, or display green when the train comes into the middle of the block (entering or leaving via a crossover for example), but for the most part you need to expect the first signal to be wrong and place your starting points accordingly.

pikehkr
09-20-2009, 03:22 PM
Sorry, but I don't think anyone can explain this to you properly as they do not have enough information.

You have two services in the picture. What is Service 2 doing? Where is it going?

Is this single track? It looks like single track in the picture.

Is only one way signaled? It looks like you only have signals on one side of the track.

All of this comes into play.

Pike

adriansw
09-20-2009, 03:34 PM
What sniper is saying is that Trains are invisible at the very start of a scenario until the trigger a signal by passing it.
The path of the train is known, but the position of the train is not until it passes a signal.
Which, essentialy is correct.

Watching a light board, you know where a train is "supposed" to be. But you cant say for sure until it passes a signal trigger and you see the signal change on the board.

If you want that test to work, you will have to start the locos further appart, and throw some more signals in.

Ill run my feather test and throw that on YT for you to see.
It uses a bunch of CTRL signals in a chain, and some other signals too...

pikehkr
09-20-2009, 04:24 PM
My bad, I was responding to the AI part of his statements. For the lighting part you are correct, until you cross one of the signals the train will not show on the signaling system (occupancy).

Think of the signals as blind and they have their hands (links) place on the track. Until something touches that hand, they don't know it exist. So when you start a scenario the signals don't know where anything is until one of the hands gets touched and then it lets the next signal know it's been touched and that signal tells the next signal. This continues until the message has no affect on the receiving signal and that signal stops passing it on or until there is no signal to recieve the message and the track ends, whichever comes first.

Pike

adriansw
09-20-2009, 06:15 PM
I explained it to someone by compairing it to a routing table.. LOL

landnrailroader
09-20-2009, 07:17 PM
I downloaded a copy of the Tennessee Pass route and I notice the same thing in
it. When you come to the end of a siding, both of the exit signals show green
and this is a definite no-no. If I am holding the main, then the siding exit should
show stop (red), or vice-versa. I would say that there is a flaw in the RW signal
scripts.

However, I have been able to accomplish more toward getting a route together
in a much shorter time than I ever was able to do with MSTS, so now the tear in
my thinking is based on the very generous wealth of freeware material out there
for MSTS versus a relative dirth of it for RW. TZ-2009 is able to use all previous
legacy material, so there is also a lot out there for it.

J. H. Sullivan

pikehkr
09-20-2009, 07:44 PM
I downloaded a copy of the Tennessee Pass route and I notice the same thing in
it. When you come to the end of a siding, both of the exit signals show green
and this is a definite no-no. If I am holding the main, then the siding exit should
show stop (red), or vice-versa. I would say that there is a flaw in the RW signal
scripts.



Not sure that is the correct assumption... Could be the route designer used the wrong signals or placed the links incorrectly.

Pike

sniper297
09-20-2009, 08:13 PM
That's a great route, but he DID use 1H0T signals where he should have used 1H1T, that's why they're displaying wrong. I don't have it installed at the moment cuz when I work on my route I get rid of other routes plus all the assets they depend on to make sure I don't accidentally stick something from 3Djusttrainsstuff or whatever into mine. Also the following are from railsim since I shifted development over there until the newest glitch is fixed, nothing like a little confusion, hey? Anyway they work the same way in both games, I've been adding signals in RS and copying the route over to RW to test run it since the signals are visible from farther away in railworks. Other than that they work the same.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20657&stc=1&d=1253491033

That's the 1H0T which I'm pretty sure is only intended as an interval AKA automatic block signal.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20658&stc=1&d=1253491053

Ingame they both show green, but that's correct since the blocks are both clear, not being linked to the track beyond the base of the switch they don't know anything about which way it's set, "not my job, man!"

http://www.trainsim.com/vbts/attachment.php?attachmentid=20659&stc=1&d=1253491053

Use 1H1T instead with the secondary links beyond the base of the switch, in order to show anything other than red this type needs to be able to trace an uninterrupted path from the link zero to link 1, which it can't if that trace is broken by the switch points being set the wrong way.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20660&stc=1&d=1253491053

In game they alternate red or green depending on which way you throw the switch. Also see this;

http://www.trainsim.com/vbts/showpost.php?p=1527062&postcount=4

Second part of that post a demo of how the paths affect the signals, I can swap back and forth between those two services and change which of the slip switch signals is green or red just by changing which train I'm driving in free roam.

boleyx
09-21-2009, 08:50 AM
The Service2 is static with a driver. I have reloaded a few times due to the the memory zero error. All links point toward Service2.

When you are in EDIT mode the signals display properly so they do not require movement by Service2. Also, I have run (driver mode) Service1 through the signals to allegedly reset them. That did nothing. As per the suggestion I ran Service2 thru the signals and they reset to the proper state in Play mode. So 1H0T are proper signals to be used in a switchless area of track.

Also, tried both San Bars yard and mainline same results.

Then there is the AI train that will not move when all signals show green. It does move when Service2 is removed. Also, the Destination is shown as faulty as soon as you select Destination2 in the destination flyout. SO the AI sees the static engine but ignores the signals.

This seems to lead to the conclusion that a scenario can't be started with static engines in place. To setup that route you would have to emit the "static" engines from portals to go to specific destinations before beginning the intended activity.

RW Signals do not recognize a "pre-placed" static engine.
RW Signals do not recognize ANY rolling stock in place without an engine.
RW AI does recognize both situations.

davveb
09-21-2009, 10:52 AM
The view that RS-RW signals don't "see" initially stationary consists, and only update the signal aspects when one of their links is crossed by a consist is not actually correct. When a scenario is started the core software informs any signal script that has a train "in its block" by using the OnSignalMessage call with a message no 1 - "INITIALISE_TO_BLOCKED". The signal then sets it's own occupancy accordingly and messages the signals arround it so their states can be updated.

Dick - I think your particular example doesn't work because you don't have an enclosed signal network - your two engines are both outside the network, therefore there are no initially occupied signal blocks and the core software sends no blocked messages. You need to add two more single link signals "outside" of your two engines. Signals should then initialise and update as you expect.

You should also be carefull setting up "compressed" test routes. I believe adjacent signal link0s need at least one track node "red triangle" between them. A node is placed automatically at junctions and every 1km when laying track. Although this isn't needed for the signal scripts to display correct aspects, I think it may result in mismatches with the behaviour of the AI trains.

Dave B

boleyx
09-21-2009, 11:27 AM
The view that RS-RW signals don't "see" initially stationary consists, and only update the signal aspects when one of their links is crossed by a consist is not actually correct. When a scenario is started the core software informs any signal script that has a train "in its block" by using the OnSignalMessage call with a message no 1 - "INITIALISE_TO_BLOCKED". The signal then sets it's own occupancy accordingly and messages the signals arround it so their states can be updated.

Dick - I think your particular example doesn't work because you don't have an enclosed signal network - your two engines are both outside the network, therefore there are no initially occupied signal blocks and the core software sends no blocked messages. You need to add two more single link signals "outside" of your two engines. Signals should then initialise and update as you expect.

You should also be carefull setting up "compressed" test routes. I believe adjacent signal link0s need at least one track node "red triangle" between them. A node is placed automatically at junctions and every 1km when laying track. Although this isn't needed for the signal scripts to display correct aspects, I think it may result in mismatches with the behaviour of the AI trains.

Dave B

Added signals beyond the two engines. Result all green when going to Play - first picture. Ran Service 2 toward Service 1 thru the first signal then they displayed correctly. So "trailing" signals do not seem to have an affect.

Reversed the links on the two added signals and no change. Startup all green unless Service2 run thru the first signal it encounters moving toward Service1

There are many anecdotal explanations and/or work arounds for various situations in RW. However, these are lost in the forum over time. Since CEO Jackson forbids making any committments we have no information to say Rail Simulation will fix, or not fix, a problem. I suspect the latter since problem fixes do not bring in cash and the vast majority of customers are interested in only running on existing or addon routes with perhaps some subset doing some mild adjustments.

It is a shame since many of the problems are probably not needing of a "rewrite" but simple code adjustments. Portal train emissions appear to be the best answer for now if multiple AI on track assets are desired.

davveb
09-21-2009, 11:47 AM
Dick

Must confess I'm at a loss as to what is causing this problem. Are all your signals single link? Are all the links pointing in the same direction? What signal type are you using? I can create your setup using UK 3 aspect signals and it works perfectly everytime, so there must be some subtle difference as to why RailWorks is behaving so badly for your case.

Dave B

ps I'm afraid my experience is that using portals can make things worse, not better! However, if we all keep plugging away maybe we can get some results, even if it's just convincing rs.com that some things need changing.

adriansw
09-21-2009, 01:57 PM
Hey,

I realise what your trying to do...

Your setting up a collision between Serv and Serv2 but having the signals prevent it right?. You want serv1 to move to the marker beyond Serv2. Correct?.

It not going to... Ever..
The AI cant find a clear route to Dest1 behind Serv2. So Serv1 "cant" get there. Since it cant get there, its just going to sulk.

Try moving the markers so they are just infront of the two locos at the start. See what happens.

I did a quick demo with some signals and multiple locos. But all the locos are working in the same direction.
http://www.youtube.com/watch?v=W4FZmOdPs_4

pikehkr
09-21-2009, 03:50 PM
Just ran a couple of quick tests.

It appears that the 0T signal does not initialize showing occupancy if there is a train between it and the next signal.

It appears that the 1T signal does initialize showing occupancy if there is a train between it and the next signal as long as there is a track node as you call it (red triangle) between link 0 and link 1. If no triangle it does not show occupancy. There is also a signal further up the track and I didn't test to see if that signal is required for this to work.

I have found this to be the case with junctions as I always break and join each section of track just beyond where the junction forms so there is a break between link 0 and the other links or I have seen them not work correctly. This is new and it looks like using the 0T tracks are not a good idea unless someone can explain where they must be used since the 1T seems to do the same thing.

Here are the pics, 1H0T on left, 1H1T on right. First picture, links 0 and 1 in same section of track (highlighted by yellow). Second picture, links 0 and 1 in different sections of track.

Pike

PS... Removing the driver icon from the train causes 1H1T signal to show clear on startup even if it is set up correctly.

http://www.trainsim.com/vbts/attachment.php?attachmentid=20674&stc=1&d=1253562459

http://www.trainsim.com/vbts/attachment.php?attachmentid=20675&stc=1&d=1253562470

adriansw
09-21-2009, 04:14 PM
Right. You just saw what we mean by the train being invisible until it crosses a link.

pikehkr
09-21-2009, 05:05 PM
Right. You just saw what we mean by the train being invisible until it crosses a link.

If you are referring to what I wrote, only if you use the wrong signal or do not set it up correctly.

I am agreeing with Devveb now. Correct signal and correct set up equals correct signal initialization, including occupancy on startup.

I thought I had seen it working correctly before so I was confused also in my previous statements when testing with the 0T, it did not work.

IGNORE MY PREVIOUS MESSAGE about the signal being blind until it was touched by a train. Not all signals are blind at startup! I WAS WRONG! YAY!!

Pike

adriansw
09-22-2009, 02:46 AM
youll see.
;-)

pikehkr
09-22-2009, 02:47 PM
I have found this to be the case with junctions as I always break and weld each section of track just beyond where the junction forms so there is a break between link 0 and the other links or I have seen them not work correctly.

I just wanted to add to this statement that I also make sure there is a break/weld between the links of one signal and the link of the next signal. I don't think this is documented anywhere and if it is, I never saw it, but without doing this little step I often have trouble with the signals and the AI.

I really hesitate to say anything for sure on here because I do not want to give out bad informaton. I can only say what my experience has been and while long sections of track are great for laying track, when it comes to signaling you need to break that track apart so that your signal links are on different ribbon sections. Link 1 should be on a different ribbon of track than Link 0 of it's own signal and also on a different ribbon section of track than Link 0 of the next signal.

Pike

Here is an example and again, this just ensures that I get the proper signal and also proper AI reaction to those signals and only comes into play when signaling in close proximity to other signals.

Risky...

http://www.trainsim.com/vbts/attachment.php?attachmentid=20707&stc=1&d=1253644719

Less Risky...(Break and Weld the track between the links)

http://www.trainsim.com/vbts/attachment.php?attachmentid=20708&stc=1&d=1253644751

sniper297
09-22-2009, 08:01 PM
I've heard that one about separating links with a red triangle before, but gotta wonder how thoroughly that was checked out. It would APPEAR that you proved the validity of the theory, however;

http://www.trainsim.com/vbts/attachment.php?attachmentid=20715&stc=1&d=1253663834

One red triangle between primary and secondary links there;

http://www.trainsim.com/vbts/attachment.php?attachmentid=20716&stc=1&d=1253663847

Two red triangles there. Same signals from my previous post, if this is the answer wuffo they both show green in my previous post?

pikehkr
09-23-2009, 02:55 AM
It is hard to say. I can say in the second picture it looks like the junction is against you so that signal showing red makes sense.

The first picture...

It almost looks like there is a signal facing the other direction on the same ribbon of track. I do not know where the links are for that signal but it could be interfering. I personally would try breaking/welding the track between link 1 and link 0 of that signal or moving that signal back a little. Like I said the close quarter signaling like this is just a real PITA treat and if I knew the exact answers I'd probably charge money for them! :D

Pike