[VicenteIR]

 Serana, on 07 December 2021 - 09:46 PM, said:

Err... what do you mean ?

I would like to define a different logic for some signals when the game is in Multiplayer mode. Is it possible with the c# script by calling IsMultiplayer() function for example? What am I need to add to the code if so?

Regards
Oleg

[Serana]

Could you give me an example of what kind of logic you want to do when in multiplayer mode?

Currently, this information is not available for C# signal script.

[VicenteIR]

I want to hold some kind of Signals at danger when in Multiplayer Mode and only Dispatcher will can give a permission for a Signal to run the regular script.

Regards
Oleg

[VicenteIR]

I did it with the SIGSCR.DAT a year ago. Multiplayer Mode is identified by checking of MSTS enabled() function in opposite Signal Head. If it is TRUE, variable for the Multiplayer logic stored. The problem is that all signals are enabled also in Explorer Mode. And I can see no way to separate Multiplayer from Explorer.
I thinking maybe with c# scripts it will be possible. Especially since those signals anyway will be written in c# because of possibility of communication between a Signal and the following one.

Regards
Oleg

[cesarbl]

Since MPManager.IsMultiPlayer() is a static method, I suppose you can use it in the scripts. However, that function is not part of the API and therefore may cause your code to not compile in the future.

I believe the feature you mention, i.e. that a signal is held at danger until the dispatcher clears it, and once the train passes it is closed again, is standard for non automatic signals, and therefore could be implemented in the internal OR signalling logic, with some way of telling the simulator to enable or not the feature.

Regarding enabled signals, I don't understand why Enabled always return true in multiplayer mode, this causes inconsistent behaviour. Maybe another addition that can be done is that signals only clear in the current train direction, and not backwards.

My recommendation is that signal messages should be used with care, and only where it is strictly necessary (e.g. when the state of a signal depends on the aspect of the previous signal). It should not be used as a replacement of the internal OR signalling logic. The order to clear or to close a signal should come from the interlocking, and then the signal will show the corresponding aspect obeying it.

[Serana]

I am starting to think that exchanging information through strings is a bit expensive in resources, and it gets worse and worse when the route gets bigger.
I have a case where the route is so huge (so it has a huge number of signals) and, on some computers, even with optimizations to create less strings, the garbage collector can sometimes not be quick enough and we get slow memory leaks.

Two solutions I am thinking about:
- Getting direct access to the signal script of another signal through a function that return the reference to the signal script. That means the signal (or maybe the TCS also) can get access to public members of the signal script.
- Or setting values to be exchanged in a custom object that can be then be accessed from another signal, or from a TCS script.

Not having to serialize and unserialize signalling information would help a lot.

What do you think about these solutions?

[cesarbl]

Quote

I am starting to think that exchanging information through strings is a bit expensive in resources, and it gets worse and worse when the route gets bigger.
I have a case where the route is so huge (so it has a huge number of signals) and, on some computers, even with optimizations to create less strings, the garbage collector can sometimes not be quick enough and we get slow memory leaks.

Yes, string manipulation has to be done with care for this scripts. There are a lot of signals being cyclically updated. For my scripts, I tried to minimize heap allocations taking two different approaches:

• For normal signals: I use pre-allocated strings to extend the 8 MSTS aspects to the 16 aspects needed by Spanish signalling. This approach doesn't use heap allocation.
  
• For ETCS balises: the text aspect corresponds to the binary-encoded telegram, which is dynamically constructed. In this case, there's a lot of string manipulations, which I try to reduce by using string builders where possible. Also, telegrams are updated only when there is a relevant change in signalling (this feature is also used to fill the M_MCOUNT balise message counter). Because of this, the performance impact should be negligible.

I don't see any problem in principle for giving access to signal scripts in other signals, as that would be faster than communicating with strings. Depending on the info that you want to transmit, you can also use the shared Dictionary<int,int> containing each signal's local variables.

For communication with TCSs there's a problem: in Multiplayer mode the signalling information is only fully available at the server, so anything that is made available to the TCS has to be serialized and sent through the internet.

I see that you encode data to be used for different TCSs into the same string, using lists to encode and decode. This is very expensive if it has to be executed several times in the same update cycle. Would it serve your purposes if the localStorage Dictionary is made available to the TCS scripts?