[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