Consulta sobre alcance de señales

[damontej]

Luego de haber buscado exhaustiva e infructuosamente sobre el asunto, me atrevo a plantear la siguiente problemática que he observado, especialmente en rutas de vía única con eventuales vías secundarias de paso en estaciones intermedias.
En algunas rutas la influencia de una formación que viene de frente se limita a una distancia de un par de señales por delante de la posición de la formación, mientras que en otras las señales anticipan excesivamente la prioridad de paso, de forma que un tramo queda bloqueado aunque esté muy por delante del camino por recorrer.
El efecto es evidentemente igual para con la formación del jugador, lo que hace que una formación AI que uno espera quede detenida en determinado lugar, en realidad lo haga mucho más allá, cuando no en el primero de los semáforos que se encuentra en su recorrido.
Esto hace que las actividades con tráfico sean muy difíciles de hacer entretenidas si (como yo) el autor pretende insertar tráfico AI "realista", es decir que recorran la ruta asignada en toda su extensión. Al respecto, la alternativa que es más pobre en resultado visual, es que los servicios AI definidos, aparezcan poco tiempo antes del paso de nuestro tren y desaparezcan a poco de haber pasado.
Esta alternativa obliga a llenar de servicios el Patrón de Tráfico y en mi caso trato de no usarla, excepto por algún eventual servicio que quiero ver en determinado tiempo y lugar muy específicos.

La pregunta concreta sería:
¿Saben si existe alguna forma de setear en los archivos de configuración de señales (o en otros) el alcance de la influencia de una formación en las señales que se encuentran por delante de su recorrido?
Por ejemplo, definir que una formación, a medida que va avanzando, actúa solamente sobre la inmediata siguiente o sobre las dos señales siguientes y no más allá.
He observado que en algunas rutas esto ocurre varias señales más allá de la posición actual de una formación con prioridad, como que el MSTS le libera, si no totalmente, buena parte del camino a recorrer.
En rutas de doble vía, es un problema menor (pero igualmente molesto), pero en rutas de vía sencilla con apartaderos, hace muy dificultoso componer patrones de tráfico entretenidos y que se comporten de acuerdo a lo esperado.
Bueno, espero ansiosamente vuestros comentarios al respecto.

[Repo]

Hola Jorge, yo dejé el MSTS hace ya tiempo, pero si recuerdo ese pequeño gran problema de la señalización, lamentablemente creo que se trata de un problema estructural que no depende de una determinada configuración.

En RS hemos abierto todo un tremendo hilo en Uktrainsim debido a que el nuevo simulador presenta problemas muy parecidos a los del MSTS en rutas con vía única. Por suerte hemos sido oídos por los desarrolladores del simulador y este incoveniente vendrá arreglado en la siguiente actualización que esta por salir en estos días.

De estas discusiones se ha desprendido que este problema de las señales tiene más que ver con el código del simulador que con alguna opción de configuración por el lado del usuario. Esto me lleva a pensar que en MSTS el origen del asunto debe ser el mismo.

Creo que es algo que podría corregirse con el uso de futuros parches no oficiales del tipo bin.

Saludos.

[damontej]

Estuve chateando con Andrés Blaho y me pasó un dato que creo es más que relevante:
Hay un parámetro "SignalNumClearAhead" en el archivo sigcfg.dat cuyo valor entre paréntesis define la cantidad de señales a "limpiar" por delante, del que debo profundizar acerca de los valores permitidos y su consecuencia.
Me parece que por ahí está el asunto.
Ampliaremos...

[edsolis]

Quizá te interese este enlace, si no lo conoces ya:
http://www.agrupament.net/msts/TutSignal/

En él se describe, entre otros temas de sumo interés, los ficheros sigcfg.dat y sigscr.dat.

[Sankito]

en mis pinitos como creador de actividades comprobe una cosa ya comentada por alguno de los maestros creadores: que los trenes tienden a terminar saltandose algun semaforo en rojo. Por ello es conveniente no hacerles recorrer la ruta entera unos detras de otros.

[damontej]

Quizá te interese este enlace, si no lo conoces ya:
http://www.agrupament.net/msts/TutSignal/

En él se describe, entre otros temas de sumo interés, los ficheros sigcfg.dat y sigscr.dat.

Lo tenía visitado. Es excelente y muy instructivo. Gracias EDSOLIS!!!
El problema que verifico es que el parámetro "SignalNumClearAhead" que menciono en mi posteo anterior y que estuve verificando con Andrés, tiene puesto un valor de 1 y trato de verificar los valores permitidos y las consecuencias de cada uno... por ejemplo qué pasa si el valor es cero.
Esto lo hago porque veo que en el archivo correspondiente tiene valor "1" y aún así se liberan más señales que sólo una delante de las formaciones.

[damontej]

Bueno... acaban de poner en Train-sim ( http://forums.flightsim.com/vbts/showth ... ClearAhead ) un post que dice textualmente:

I setup a test track with 7 signals of type JP3Light which have 3 indications: STOP, APPROACH_3, and CLEAR2. These were placed close enough so that the aspect of 5 signals could be observed but not too close. If the signals were too close they had odd behaviour.

The default SignalNumClearAhead is 2 and I tested with values of 1, 2, and 3.

With the value of 2 the signals were
R R Y G train
R Y G train

With the value of 3 the signals were
R Y G G train
Y G G train
Y G train

With the value of 4 the signals were
Y G train
Y G G train
Y G G G train
R Y G G G train

With the value of 1 the signals were
Y train
R Y train
R R Y train

With the value of 0 the signals were
R R R train

I believe what is happening is that to calculate the signal before the train, the value of SignalNumClearAhead is read, the signal that distance ahead on the path is set to SIGASP_STOP and then the signals are calculated backwards toward the train.

This would explain why for 3 there would be two consecutive G and why for 1 there would be no green. This could also explain the odd behaviour with traffic trains if a signal in the distance was being set to SIGASP_STOP.

Another interpretation is not that it is changing the signal SignalNumClearAhead to SIGASP_STOP, but instead is using that as the value for calculating the previous signal. It appears that all signals are initially set to SIGASP_STOP when the simulation starts.

Sin importar demasiado la traducción, pero teniendo en cuenta que G es verde, Y amarillo y R rojo, puede verse en las sentencias en negritas que resalté qué pasa con los valores del parámetro mencionado...
Habrá que ver qué pasa con ese parámetro para señales de brazo, pero creo que acá está la respuesta.
Saludos a todos!!!

[Shadow]

El problema que verifico es que el parámetro "SignalNumClearAhead" que menciono en mi posteo anterior y que estuve verificando con Andrés, tiene puesto un valor de 1 y trato de verificar los valores permitidos y las consecuencias de cada uno... por ejemplo qué pasa si el valor es cero.
Esto lo hago porque veo que en el archivo correspondiente tiene valor "1" y aún así se liberan más señales que sólo una delante de las formaciones.

el parametro "SignalNumClearAhead" determina la cantidad de semaforos en Verde tenemos q tener "delante nuestro" para q nuestro semaforo este en Verde tambien ... esto depende de la cantidad de estados posibles q tenga nuestro semaforo


y vamos con los ejemplos =)


1 (senal mecanica normal / señal de maniobras) nuestro semaforo tiene solo 2 estados "STOP" y alguno mas q podria ser "CLEAR" / " APROACH " STOP & PROCEDED" etc



2 (señal de 3 estados ) este es la mas comun q encontramos ... la de 3 colores

STOP , APROACH Y CLEAR


3 ( señal de 4 estados .. de avanzada) esta señal es como la anterior solo q nos agrega un estado intermedio mas


STOP , APROACH 1 , APROACH 2 y CLEAR


4 (señal de 5 estados... solo la vi en pocos lados) incluye otro valor intermedio mas ... puede ser una amarilla mas o la "verde condicional"



STOP, APROCH 1 , APROCH 2 , CLEAR 1 Y CLEAR 2



los valores q puse son los mas comunes...en si los estados q tendra depende de cada semaforo en si ... puse lo q serian semaforos "standarts" a mi entender


espero q sirba de alguna ayuda





editado a posteriori

tanto tarde en escribir q postearon algo mas util jajajajaja

[josepablo]

Buenas.
Haciendo múltiples pruebas, poniendo muchas señales consecutivas para poderlas ver todas a la vez, he podido determinar las siguientes curiosidades, sin que ello no pueda ser rebatido o modificado por más pruebas hechas por otras personas. Las señales estaban relativamente juntas, por lo que no sé si el comportamiento se modificará al separarlas más distancia.
- Como se dice absolutamente en todos los documentos al respecto, sólo es aplicable a las señales definidas como NORMAL. Cualquier otro tipo de señal no entra dentro de los cálculos con el parámetro indicado.
- El parámetro "SignalNumClearAhead" define el número de señales verdes que se ponen por delante del tren, si se pueden poner porque no hay otro tráfico, como una especie de ola verde anticipándose al tren. Esto evidentemente influye también en la señalización del sentido contrario, supongo que a través del parámetro "enabled" que se consulta en todos los scripts de señalización.
- El parámetro "SignalNumClearAhead" es único por ruta, y es el máximo de todas las señales que se usan en la ruta. Esto lo he comprobado muchas veces, y significa que cada señal no tiene su propio parámetro, sino que para todas las señales se utiliza el valor más alto de todas las señales realmente usadas en la ruta, no el de cualquiera de las señales definidas en los ficheros sigcfg.dat sin uso en la ruta. Creo que este posible bug del MSTS puede explicar muchos comportamientos anómalos de algunas actividades, en función de que tráfico se queda con los cantones pillados en verde, según quién llegue antes.

Repito que estas cosas son las que he podido probar personalmente, pero que puedo equivocarme perfectamente y admito cualquier aporte distinto a estos temas que he enumerado.

[Francesc SV]

en mis pinitos como creador de actividades comprobe una cosa ya comentada por alguno de los maestros creadores: que los trenes tienden a terminar saltandose algun semaforo en rojo. Por ello es conveniente no hacerles recorrer la ruta entera unos detras de otros.

Esto sólo sucede en rutas que tienen señales de bloqueo permisivas, o sea que pueden ser rebasadas después de detenerse ante ellas y obligan al maquinista a circular con marcha a la vista hasta la siguiente señal. Esto es así según el RGC y sucede en la vida real; el problema está que los tráficos IA de MSTS no llevan un "maquinista" que se conozca al dedillo el RGC y, por lo tanto, ni se detiene ante las señales permisivas en rojo, ni circula con marcha a la vista, ni frena cuando se encuentra un obstáculo (otro tren) delante

Lo que plantea Jorge en este hilo es muy interesante y debería ser un parámetro consensuado con los creadores de rutas, ya que si un activitero, particularmente, modifica los parámetos de las señales de una ruta en su ordenador, al publicar la actividad estos parámetros no se exportan con la misma, ya que son inherentes a los archivos de la ruta, no de la actividad. Lo realmente útil sería conseguir un acuerdo o unas "normas" a seguir por los creadores de rutas, en el número de señales "abiertas" delante de un tren, dependiendo de si la ruta es en vía única o doble, y de si se simula un bloqueo automático o un BEM o bloqueo telefónico, ya que la disposición de las señales en estos casos es diferente en función del tipo de bloqueo (como en la vida real, también...).

Ciertamente, este aspecto influye mucho en la creación de tráficos IA en las actividades, muy especialmente, como apunta Jorge, en las rutas de vía única. Yo, al igual que él, prefiero los tráficos IA que recorren toda la ruta, ya que así se pueden confeccionar "mallas" de trenes y cruces. Pero, claro, sobre gustos no hay nada escrito...