A couple of questions from a newbie

[Domino78]

Well, you convinced me So I'm waiting patiently for the upcoming updates

I understand your logic. I "created" two different levels of communication: one on the interlocking level, and an independent higher one on phone/order level (as it is in the real life). But in fact each connection is able to send trains in both directions, only the conditions differ. Sometimes a direction bit is enough to manage both directions, sometimes a more complex negotiation is needed to change the direction for wrong line operation (or back).

In this point of view it could be better to create only one interface which includes the interface for the phone, ZNP801, and for the interlock level for each line. We could distinguish between the different typicals of interfaces (single line, double lines, reversible, non-reversible, etc.; but typicals could include the TMDs, sidings too).

If I think correctly, first the typical has to be determined for each connection point in the area. This interface must be able to connect the area to the neighbours, or, if playing stand-alone, to the AI. The AI should be independent, must have access to the timetable, accept and "drop in" the trains, can have custom rules (as an extreme solution the AI could run even as a standalone program, communicating on localhost:).

Interfaces (number, type of data points, composition of messages) depend on the types of the block system (based on your list), but the interfaces for the different types must be compatible only on a very basic level (to refuse an attempt if incorrect type). In some cases the different typicals are very similar, they could be even "compatible" (e.g. token and RETB: one party gives radio token, the other party gets the physical token). These cases should be avoided during programming (or if we plan to build a modular system with multiple possibilities, by a check).

In this point of view it seems that in case of KMYO-KAND line the two parties (me, managing KAND, and the AI managing KMYO) speak different languages.

In point of view of KAND:

1) normal working: start point can send trains without train reporting;

2) wrong line working: not supported by block system, but possible based on agreement (AI will not send train without agreement, player will be fired if he does so:)

3) switch to reverse direction: end-point is able to initiate negotiation for the wrong line working on ZNP801, start point must accept this; block system will NOT follow the dir. change;

4) switch to normal working: direction can be switched back to normal via conversation with the start point?

In point of view of KMYO:

1) normal working: like KAND

2) wrong line working is supported on block system level on both lines, both parties can take the direction;

3) switch to wrong line working: end-point is able to initiate negotiation for wrong line working on ZNP801 and on phone, start point must accept this and take the direction on block system level;

4) switch to normal working: end point must take the direction, can be asked on phone if needed.

It seems that we need a different AI to KMYO (or direction buttons for KAND:) Currently KAND and the AI of KMYO should not be able to communicate with each other due to the significant differences in their protocols.