[Fablok]

Works fine now :)

[Csantucci]

Thanks for confirmation.

[Csantucci]

railguy, on 13 February 2019 - 02:01 PM, said:

I've had the same problem with the more recent versions of Monogame. Here is the message that I get:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
SharpDX.SharpDXException: HRESULT: [0x887A0001], Module: [SharpDX.DXGI], ApiCode: [DXGI_ERROR_INVALID_CALL/InvalidCall], Message: Unknown
at SharpDX.Result.CheckError()
...
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


Pressing "continue" in this message box just brings up TrackViewer with a black box. I hope this info helps. Thanks--by the way, Monogame is pretty much great otherwise.

Hi railguy,
were you able to solve this problem?

[avatrain1]

Hi Carlo, I noticed that with the new signal script parser, a new error is reported in the log file when the sigsrc.dat file is read. The error detected is the following:
Warning: sigscr-file: Invalid operator token # in line number 42

This occurs when the following operators are read:
/# =
== #
!= #
<= #
>= #
< #
> #
# =
/ #
which should be:
/#=
==#
!=#
<=#
>=#
<#
>#
#=
/#

In practice, if a space is found before the # character, the error is reported, so i don't know if the parser then correctly translates the operator with the possible malfunctioning of the signaling or is able to correctly translate the operator.

In many routes I use, in the sigsrc.dat files there are operators written with the space before the # character.
It is possible to arrange the parser so that it translates the operator correctly.

I thank you for your interest and I am grateful for your the excellent work you are doing.

Greetings,
Sergio.

[ebnertra000]

I'm pretty sure that error is because there shouldn't be a space in an operator. That's a faulty script writing problem, not an OR problem

[Csantucci]

Hi Sergio,
I already noticed those warnings and asked the code author, which told me that such lines are interpreted correctly, and the warnings point only out a syntax error in the signal script file.

[roeter]

The old parser is more lenient when it comes to the use of white spaces. It processes the lines as if the white spaces were not there, so the code is processed correctly. It is kind of auto-correcting in that sense.
A very important question here (and in quite a few other cases): are such changes really to the benefit of the users?
Is the new code intended to improve OR, or to make more stringent tests on what the users are creating just to get fully perfect input?
If the more lenient old processing could lead to errors or other problems - OK, then there is a case for more stringent processing.
But in this case it does not matter and such script files have been working correctly for years. It may not be fully syntacticly correct, but does that matter? To suddenly start reporting this as errors is only frustrating users.

Regards,
Rob Roeterdink

[Genma Saotome]

Setting aside the specific for the signal script, I'll echo Rob's concern about tightening things up for the sake of tightening. I worked every day for a week to discover white space wasn't allowed before a unit of measure. It's been allowed everywhere else. I'm trying to get some .wags to Peter for his testing... I've wasted two weeks trying to figure out why the software doesn't recognize the presence of an emergency reservoir... to the point of substituting rows of data from a stock MSTS file to no avail. Something changed but I have no idea what it is. And then there is that stupid warning about a missing texture that was implemented by Voldemort when we already had a perfectly good message for finding a diffuse texture.

Please don't change things that don't need to be changed that will cause our files to be broken... or if you really want to, then you really should be obliged to code a utility that will update our files to conform to the new rule.

[cjakeman]

Genma Saotome, on 07 June 2019 - 10:59 PM, said:

Please don't change things that don't need to be changed that will cause our files to be broken... or if you really want to, then you really should be obliged to code a utility that will update our files to conform to the new rule.

Agree with this principle 100%.

[Icik]

Hi Carlo,
I downloaded your latest update OR MG, where the signal management algorithm was changed. Now, OR behaves absolutely strange. Every track is set free and it looks like the script for the signals is in conflict.

What has to be set in sigscr.dat to make it work properly again?

Attached File(s)

•  1.jpg (2.48MB)
  Number of downloads: 20
•  Sigscr.dat.txt (49.7K)
  Number of downloads: 18

[R H Steele]

I have a fundamental preference for precision in files....makes work easier in the long run.... However, I also completely agree with this very sound principle

Quote

Please don't change things that don't need to be changed that will cause our files to be broken... or if you really want to, then you really should be obliged to code a utility that will update our files to conform to the new rule.

[Csantucci]

I would like to give a chance to the new signal script parser, and I am awaiting a revised version by perpetualKid. If after some few iterations problems will continue to arise (I hope not), I might revert to the original parser.
At the moment I make available the preceding release of OR NewYear MG, that is release 22, which hasn't the new parser : http://www.interazio...Year_MG_old.zip , for people that don't want to experiment.

[Csantucci]

Rel. 24 of OR NewYear MG is available as always here http://www.interazio..._NewYear_MG.zip .
It is aligned with rel. x1.3.1-64 of the standard OR; moreover the MG adaptations are aligned with those of perpetualKid, which now is refining the MG adaptations.
Additional features not (yet) available in the standard OR are:
- addition of track sounds in the sound debug window (by dennisat)
- change of the font family and dimension for the digital displays in 2D cabs
- UPDATED: F5 HUD scrolling by mbm_OR (with improvement requested by steamer_ctn)
- checkbox in General Options tab to enable or disable watchdog
- increase of remote horn sound volume level
- enable/disable on screen control confirmations with Ctrl-Alt-F10
- removal of on screen notification of camera change
- improved dynamic management of trough refill, see here http://www.elvastowe...-water-troughs/ , by steamer_ctn
- activity specific options setting, see here http://www.elvastowe...post__p__247247 , by steamer_ctn
- preparation for advanced management of couplers, see here http://www.elvastowe...vanced-coupler/ , by steamer_ctn
- when car is selected through the F9 window, the car's brake line in the extended brake HUD is highlighted in yellow, see here http://www.elvastowe...post__p__248023 (by mbm_or)
- enhanced human dispatching for AI trains, see here http://www.elvastowe...post__p__247752 .
- removed bug in OR MG concerning display of ETCS gauge (by dennisat)
- removed OR-MG specific bug not displaying some icons in TrackViewer (by dennisat)
- improved distance management in roadcar camera
- animation of bell, see here http://www.elvastowe...bell-animation/ (with the support of mrmosky) (now bell animation FPS can be tuned via .sd file)
- signal script parser (by perpetualKid): reduces CPU time needed for signal management
- UPDATED: removed major bug in signal script parser (by perpetualKid)
- UPDATED: second phase of wheel bearing management, see here http://www.elvastowe...earing-impacts/ (by steamer_ctn)

I hope that this release solves Icik's problems. Moreover the warnings where isolated # operators are present in sigscr.dat have been removed.
Release 22, that has the standard parser, is still downloadable, but I'd prefer to have feedbacks on this new version.

[Icik]

Hi Carlo,
unfortunately this does not solve the problem. All rails are still set to green.

Attached File(s)

•  1.jpg (2.26MB)
  Number of downloads: 29

[Csantucci]

Icik,
I have uploaded a slightly improved version. Can you try with that one?
If you still have the problem, can you attach here OpenRailsLog.txt? Where can I download the route, and can you attach the path here?