IECC8

Does it actually communicate with the external dispatcher in Run8?

Thanks

Sean

IECC8 does not communicate with the existing external dispatcher by Mr. Balls, and you do not need it installed. IECC8 communicates directly with Run8 and controls Run8’s signals and switches. You turn on the “Enable External DS” switch in Run8 and then run IECC8, and that’s it; no other software is needed. You can see IECC8 as a replacement or substitute for, or competitor to, Mr. Balls’ external dispatcher, or for TSCAD once that comes out.

I initially e-mailed Run8 Studios to ask about the dispatcher protocol. At the time I was told to wait a while as the person with that information was on vacation and would get back to me when they got back. They never did, but I certainly didn’t get the impression that the information was secret, just that nobody had bothered documenting it publicly yet, so I went ahead and investigated on my own. I initially used Wireshark to learn that the protocol was built on top of Windows Communication Foundation. I then used Microsoft’s ILDASM to examine just one DLL file; I carefully chose a file that was not part of Run8 itself nor was identical to any file in the Run8 install directory (it was part of Mr. Balls’ external dispatcher), did not have any copyright notice in the file properties, and was marked as allowed-to-be-disassembled (when building a .NET DLL, you can put a marker in the DLL indicating whether ILDASM is allowed to be used on it or not and ILDASM will respect that marker; in this case, the marker said it was allowed). I certainly didn’t copy any files, not even the file I examined; instead, I merely recorded information about the names of the message structures and their fields and the data types involved, then wrote my own code, 100% from scratch, just using that name-and-type information to build the needed structures. I could have obtained that name-and-type information using Wireshark, not disassembling any files, it just would have taken longer. All information gathering from that point on was totally black-box; for example, I then needed to know the ID number of every switch in a route, and I would get that by just connecting a test program which would print out all messages Run8 sent to it, throw the switch in the F3 screen, and then write down the ID number on the map next to the switch—no reverse engineering of any files here, just observing cause and effect.

I never saw any warnings of any sort, ominous or otherwise. Maybe they were in a file I didn’t even look at.

Worst case, if Run8 Studios doesn’t like IECC8, they can just send me an e-mail and I’ll delete the public repositories. It’s not like I’m making any money from this, nor ever want to.

Well, if you want to look at my code to get an understanding of how the protocol works, and get the layout of the messages and what they mean, then by all means go ahead; I’d love to see more external software talking to Run8 (even though GPL3 means you can’t outright copy any of my code unless you’re also making an open-source program). Maybe eventually someone could use the dispatch protocol to ping a server, find out where all its trains are (although it doesn’t tell you about ones that are in non-CTC territory), and then showing the result on a Web page? Could be really neat to work that in with the registries that public servers (like SWRS) use!

If you want to contribute to IECC8, if you haven’t yet, then please give it a try. Most of my recent work on it has been just gathering data and entering it in XML files which describe all the signals, switches, track circuits, and routes available in the game, then also figuring out the graphical layout to use and building that. That could be done even if you haven’t had much experience with .NET development (not sure if you have or not). It’s… not all that interesting, though. If you want to give it a go, let me know and I can explain how everything fits together.

The controls are pretty simple. Left-click on two consecutive signals to set a route between them. Right-click on a signal to cancel the route. Clicking switches moves them, but generally doesn’t need to be done (they move automatically as part of setting a route). The middle button is used for less-common things, like putting switches in manual mode or showing a flag-by aspect on a signal. This will all be documented somewhere more appropriate when I get around to it, but for now might as well leave it here.