NECv4 Strange Signal Problem

[smmille1]

You've probably exceeded the number of lights that the sim will draw. Not sure why you see it when you start on one tile, but not the other. Just for a test, try it with a loco with lots of lights, and try it with one that has none.

[Signalmaster]

Vince,

I'm not sure what the 'interal' structure of a sim light is, but I've speculated to myself that, in the case of signals, it's a 2 poly object created by the sim on the fly. One poly textures itself with the lamp color the script is calling for, the other poly is a holder for the lamp lens texture called 'ltex' or 'BNSF ltex'. Since we've found so many 'unannounced' limits, I'm sure there's a limit here somewhere, also. It could be the light limit or with my light object theory, the poly/tile object limit.

Hank

[Vince]

Thanks for your input Hank. It sure is "some" kind of a limit. Did some testing this morning. Made up a geep with no lights defined and using that as a test vehicle vs. the stock geep was able to observe a marked change with what signal heads failed to show lights and their location. If it's a tile poly limit I may be able to fix the problem by removing buildings with high poly count and replacing them with lower poly objects. Now that begs the question as to what the poly count of the various objects are.

We discussed previously the poly count of the switchstands.I notice the red/green stands have a pretty much square support for the head and the red/yellow have a round support with a much higher poly count.
Is there an easy way for you to cook up a shape file with a minium of poly's? Say putting the square base shape for both types? The square base looks very nice and would go a long way reducing the count in the Washington area as the majority of the switchstands are the red/yellow type in the yards.
I say "easy" because I don't want you to go through a lot of time and effort to do something like this. I can live with a few dark signals in the Washington DC area which is the only location on the route where the failure is seen.

[bobs]

Vince, I'd be interested in seeing what a trace of one of the offending signals would show. You probably don't have any trace code in your signal scripts. I left the code in the Marias Pass signals so that other people could see how it works. The sim will write a trace file that outputs whatever you want it to when the signal state changes, plus some other times I never did quite figure out. In any event, it might help show you what the signal code "sees" when it is dark vs. lit. I don't know that it will solve anything, but it might eliminate something!

If you want to try this and need some help getting the trace stuff in, let me know.

Bob Siederer
Co-author of Marias Pass 3.1

[Vince]

Bob,
I don't think the trace would help as the signal is working correctly.
It's just that it does not light. How do I know this?
It shows the correct aspect in the F4 track monitor and if I use the
Acela, also on the cab signal monitor.

I placed a static consist at various locations beyond the stubborn
signal and the signal did show the correct aspect on the F4 monitor
for all conditions, clear,approach or stop.

The failure is be affected by:
1) Which tile the players path starts on. ie: strart on a crowded tile...fails, start on a less crowded tile...works.
All I have to do is move the start point 20 feet across the tile boundry to make it fail so it is definitly a "You-have-reached-the-maximun-sim-drawlight-limit-you're-screwed" problem.
Jeez, didn't the yahoos who coded this sim ever hear of yards...with signals in them?

The screen pic shows that it's basically a very crowded tile problem. There must be a hundred of Hank's switchstands in the 2 yards and the Washington terminal area. I'm surprised it works as well as it does!
If there was only a way to have those beautiful switchstands display without using the drawlight function....sigh...

Hook me up with the trace code and I'll give it a shot. Never can tell
something interesting could show up.
Thanks.

[bobs]

If the track monitor is showing the correct thing, then you are probably right, it is a graphic display problem, not a signal problem per se.

The trace facility is primitive, to say the least, yet without it, I could never have gotten the GCOR signals debugged. The signal scripts allow you to write out a real number, but not text or integers, so you have to make a code out of things.

I used one of the USER flags to turn the code on or off for a particular signal. Since the code is in the signal script, if you don't control it somehow like this, it will trace every signal head that uses the script on the route without any way to distinguish traces from signal A from any other signal. Like I said, primitive.

I'll mark up a script and send it to you.

Bob Siederer
Co-author of Marias Pass 3.1

[Vince]

The signal problem has been solved.
The clues were;
1) Player tile start position,
2)The loco released some time back that had so many lights it made signals go dark.

The Washington area, where the problem occurred has a LOT of signals.
Running an engine with no lights(I modified a stock geep engine file)affected the problem.
So I started deleting, one at a time, an "eye candy" signal, one that was not really needed and then running the test activity.
One delete/test...no change; second delete/test...one of the bad heads lit up...Ahhh.. third delete/test...another dark head lit....and so on until I had deleted 6 of the eye candy signals and the absolutly required absolute signals at an important interlocking were all working.
I wish to thank all who helped me solve this problem, the last major one on the NEC. I was really down in the dumps for the last few days trying to figure out what was wrong and all of you hauled me out of the deep dark mire of the Sim code.
I can now concentrate on getting activities written so the route goes out for beta testing next week.
I am truly grateful for your support.

(Edit add)
I would love to see some input from KUJU on this, just a snippit on what is the actual drawlight limit is. This would be most helpful in planning for a routes signal design. V

[chucksc]

Hey Vince you really think that Kuju "knows" what that limit is...
If I had to guess I would guess that particular code (along with most of the detail code) was probably written by a contract programmer who was let go after RTM (probably when his code was only 90% complete)... He's probably back in India or over here working on Oracle scripts by now...
:-)

Chuck Schneider
(Virtual) CEO
North American (Virtual) Locomotive Works
http://www.trainsim.com/dcforum/User_files/3d27c65e12399724.jpg

[Vince]

I have what seems to be an unsolvable problem.
If I start an activity on say Tile 1 running north to tile 3 crossing a small piece of tile 2 the first (and only the first) set of signals on tile 3 fail to light. This is the only place this happenes on the route so I can't blame the signals or their control files.
The only thing that may have some bearing on this is the tile that causes the failure is the most crowded tile on the route.

Now if I start the activity on tile 2 everything works fine and all signale light up. I have tried evrything I could think of like going into the sigcfg.dat file and changing the SignalNumberClearAhead parameter from 2,3,4,5,6 with no affect, running with the train lights on or off, using a different engine, different consist. Nothing I do with the engines or the signal files does anything. The only thing that changes whether the signals are illumunated or dark is the start point being on an adjacent tile (they light) or two tiles away (they are dark)
Are you confused yet? Here are three screen grabs to help illustrate what I have been trying to say.

If ANYBODY has ANY idea or suggestions I would be grateful.

[Vince]

Weird, isn't it. I've tried no lights on a loco and got the same result. There are a LOT of lighted switchstands in that yard that don't show up well in the screenshot. Every black dot indicating a switch has one. PLUS there are about 30 or so MORE switches with switchstands that are not visible that are off the edge of the frame but on the same tile.
I'm going to have to leave it as an open problem (for now anyway) as I'm trying to get the route ready to send to the beta testers.
Like I said it is only affecting 4 signals at a single interlocking and the F4 track monitor does display correctly.

(EDIT):
Speculation Alert!
Just thought of something while I was making o pot of coffee;
The Sim uses a file "ltex" to use to draw the lights. Here is a snippit of the sigcfg file;

SignalType ( "USSwitchLamp"
SignalFnType ( DISTANCE )
SignalLightTex ( "ltex" ) <---Texture for the light.
SemaphoreInfo ( 0.5 )
SignalFlags ( SEMAPHORE )

Now my question is, is the limitation on the number of lights the Sim can draw based on the number of actual lights OR is it based on the number of, in this case, the number of "ltex" it uses at a time?

IOW, say I used a copy of the "ltex" file named something else, say "Mtex" and changed the sigcfg accordingly so the Sim would be using two identical but different named files for the light textures. Would that possibly 'fool' the Sim code into thinking that it has not passed the drawlight limit?
Anyone have any comments on this? Thanks.
EDIT to add illustration below:
As you can see the ace file for the light ( SigLight.ace) is a template for the signal lens, color added by the sigcfg file. What I am speculating here is a copy of sigLight.ace named sigLight2.ace and that being referred to in the sigcfg.dat file as "Mtex".
Here I used the texture select window in the route editor to display the ace file for the signal head lens.