Quindi vuoi dire che nel tratto tra Bussoleno e Salbertrand, nonostante sia molto in salita (infatti il GdF in senso inverso è VIII come scrivevi), ci sono alcuni tratti in discesa con GdF III?

esatto, dovrebbe essere cosi' in base alla definizione propria di gdf.

E il SSB calcola la riduzione di velocità solo nei tratti in discesa, mentre in salita no?

il ssb opera ad ogni cambio di gdf comunicato dai pi di tipo fv o f. in caso di variazione di gdf in aumento, attuera' una curva di riduzione velocita'. in caso di gdf in diminuzione, la velocita' massima verra' innalzata. per dettagli puoi leggere la sezione "2.3.2.3 Velocità massima PGOS (controllo rispetto al GdF della linea)"

salve a tutti, nuova versione v6 disponibile - per dettagli come sempre: https://worcestergeorge.altervista.org/wip
se avete domande sono qui
enjoy :)

ciao, allora riguardo:

- 180 a monte del V: e' un problema di segnalamento, in particolare dei segnali di blocco. ho ritrovato tra l'altro tra le mie vecchie note un appunto riguardo malfunzionamenti dei segnali di blocco relativamente a trasmissione codici rsc ed anche aspetto segnali (verificabili eventualmente sempre nelle 5 terre in uno scenario se non erro e' chiamato "lavori sulla linea"). per fixare queste problematiche e' necessario rivedere gli script dei segnali di blocco, dunque nuovo aggiornamento del segnalamento

- vril attiva molti metri prima del segnale a via impedita: in pratica e' la marmotta presente dopo la protezione di la spezia, di preciso quella marmotta posizionata proprio all'uscita del tunnel, a creare problemi. in particolare, e' la presenza del limite di velocita' delle marmotte impostato in editor che causa una errata generazione della curva di riduzione del CMT. una risoluzione applicabile lato script del DLC SCMT risulta al momento impraticabile causa assenza di metodi per discernere segnali da marmotte nella attuale versione del segnalamento simulato. la risoluzione del problema e' tuttavia possibile operando direttamente in editor sulle marmotte cancellando i limiti velocita' inseriti. tale cancellazione non comporta alcun effetto indesiderato in quanto ho verificato che il limite di velocita' inserito in editor e' del tutto inutilizzato negli script delle marmotte. se provi a cancellare ad esempio i limiti della marmotta a fine tunnel, vedrai che la situazione si risolve. ho pubblicato su https://worcestergeorge.altervista.org/wip, nell'ultimo post, uno script in powershell che rimuove in automatico i limiti in pochi secondi. grazie mille della segnalazione, roberto. sta cosa delle marmotte non ci avevo mai fatto caso :)

---

off-topic:

stavo facendo un paio di giri sulla SFM attrezzata con SCMT per alcuni test vari e mi e' capitato di notare:
- lat: 45.08096, long: 6.70909 (a bardonecchia direzione confine francia), i due pi L hanno le velocita' di rango errate (dovrebbero essere -75-80-85-85 invece di -100-110-110-110)
- lat: 45.17156, long: 6.67440 (nel tunnel che parte da bardonecchia, sempre direzione confine francia, superato confine, binario sx) c'e' un pi V in asse alla tabella avente velocita 70|75|75, che ha il link sul binario di dx (invece che sul sx)

nel caso ti sono sfuggiti

devi reinstallare il pack originario. lo script funziona sul pack originario.

ho dato una occhio. i bin della mod impostano come script carrozze lo script della 464, che e' errato.

ora che ricordo, gli ultimi commenti presenti su https://worcestergeorge.altervista.org/wip di 3.5 mesi fa circa trattano la questione mdvc/mdve. in breve gli script originali delle mdvc/mdve presentano la funzione richiesta per la trasmissione messaggi nel convoglio (che permette dunque tlc e parking) ma non sono usati, ovvero i bin hanno la sezione script non compilata. si ovvia compilandola. nei commenti vi e' anche uno script in powershell che in automatico compila il campo script in tutti i bin delle mdvc/mdve che lo hanno vuoto.

il binario 2 dove capti 120 dovrebbe essere un binario di precedenza (vedi presenza mutanda) quindi teoricamente la rsc non dovrebbe esserci, dunque si sarebbe dovuto continuare ad avere AC sino al segnale di partenza.

ma al momento il segnalamento simulato invia codici rsc sempre, indistintamente dalla tipologia di binario (se di corsa rsc presente, se di precedenza rsc non presente).

in questo caso ricevi 120 in quanto la configurazione "segnale a 1 vela V con mutanda a 30 kmh su binario di precedenza senza rsc" risulta (causa questa limitazione nel segnalamento) pari a un "segnale R/V con conferma di riduzione a 30 kmh su binario di corsa avente rsc".

la questione e' simile a questa che avevi evidenziato tempo fa' tu qui: http://www.rotabili-italiani.org/index.php?topic=280.msg30619#msg30619

da quel che ricordo la route e' stata rilasciata prima dell'ultimo aggiornamento dei segnali (v2.3). scarica e installa Pack segnali RI FS Rel. 2.3 (http://www.rotabili-italiani.org/sito/segnali,-pali,-tralicci.html). vediamo se risolve.

ciao, grazie del video. allora, frenatura e errore 9.00 sono corretti in quanto si ha ricezione di una sequenza illogica 270 -> AC (vedi manuale tabella 2 pagina 9). la limitazione a 60 a seguito del cambio illogico e' anche corretta (vedi manuale, sottosezione 2.3.3.1 a pagina 19, citazione alla "Tabella 2-5 – Gestione Segnali Fissi in M.O. RSC" dell'allegato RFI[17]). ora il punto e' capire perche' i segnali inviano AC all'SCMT. ho provato a creare uno scenario freeroam con loco da binario 3 in CT proprio come da video, ma non ricevo AC dopo il 270... magari puoi provare a creare un veloce freeroam anche tu e vedere il problema si presenta. se riesci/vuoi condividere lo scenario in questione mostrato in video che da' problemi, potrei eventualmente darci un'occhio