minordeveloper / mrail Goto Github PK

The current timetable system is an unmanageable mess. I don't have many ideas to fix it yet, but will discuss with myself here.

Specifically without having to restart the computer or use network control. To be built upon the new unified UI system

This is a serious undertaking that will require a custom mod and interfacing with the railcraft API. Low priority but would be fun to work on.

Need a readme that actually explains how to download the software and get started

Simple admin interface using a pocket computer to allow for quick control from anywhere

Top right of the computer terminal should display the current version number. On each restart query if we are up to date (but don't auto update unless set). and display an asterisk next to the version number if this is not the latest.

There's lots of repeated info in there currently

The detection_broadcast command documentation implies that the detector and train ID should be entered as integers but this does not trigger a block entrance signal in the oneway controller. I suspect that there's a string comparison happening by accident in the oneway controller.

This again reiterates the importance of using the identString and identNumber functions provided by the mRail API to perform these comparisons. Eventually I'll learn to use the helper functionality I built for this exact purpose.

This will save from excessive downloading during an update

Warnings for if the network is down or disabled etc.
Make it clear that something is actively not happening.

List of improvements:

• Change colour scheme
• Add logo
• Widen the main body

Need to figure out how to use the github script to selectively download only certain files - no documentation, batch scripts, or Git submodules.

In the code - just use both the primary and secondary colours
In minecraft - not sure yet, maybe have multiple chests? One chest can support up to 29 trains but we want more than that. Possible solutions:

• Multiple ender chests
• Some depots handle different trains - i.e freight depots

The intended effect of "clear" to the block controller is to clear a block and then reallocate that block to any waiting trains. This is in case we have a missed exit detection of the previous train.

Have switches change 2-3 seconds before a release occurs. Not really important but looks cool!

The block controller has no indication of the colour of a train, just the service ID which can be a little hard to identify from. The suggestions is to either have the train colour to the left of the name or under the service ID itself. Do this for waiting trains too.

What it says on the tin. The block controller does so much more than handle oneway blocks now, and is referred to as both blockControl and onewayControl. This needs standardisation.

This is not an active task but will be completed slowly as the system migrates to a new communications protocol for network control. To be ticked off once the old API's functionality has been replaced.

From both the network controller and admin pocket computer you should be able to trigger other/all computers on the network to check for an update.

Implementation

• Have each computer pull the latest release from GitHub
• Network computer checks that it is up to date and instructs all other computers to pull from it

Also want to be able to specify if you want a stable release or the latest from the main branch. Default to stable.

Rather than showing departures/arrivals, show current platform allocations and train colour on one screen and amalgamate arrivals and departures on the other.

This is going to be a pain and will require testing to make sure I don't mess it up

Introduce an API command (and response) to have computers identify themselves if within a certain number of blocks of the computer than initiated the request. Can be useful for quick admin commands and checking IDs or settings.

Separate menu for requesting a given destination at will.
Communicate with dispatch and indicate to the user if the request was successful (or show an error message)

Nuff said

Lots of pictures and gifs and a link to various videos!

A rare event, but it just occurred so I feel as though there is no harm in adding some simple safeguards to protect against this scenario.

In the event that a train is detected at the entrance of a block it is already presumed to be occupying, it should immediately be admitted via a redstone pulse and not allocated to the waiting list.

Before pushing this change to the main branch I should consider if there are any scenarios wherein this might have an adverse affect.

Have LDoc be run on any push to generate documentation which is then pushed to github pages

Unsure if this is a general bug or specifically related to the situation encountered in #45:
It appears as though sometimes when trains are waiting at both ends of a bi-directional block, one train may not be detected or correctly released. Requires further investigation.

camelCase?

Allow you to remotely edit the configuration file of any computer on the network from an admin control or network control

Allows for network configuration files to be transferred from a central network location and be kept up to date

Calculate predicted train travel times through each block and station routing configuration and raise an error if a train takes too long to transit a block. Further extensions could include rerouting if a block is considered as in an error state.

Need a system compatible with both touchscreen monitors and computer screens, capable of handling all mRail's GUI requirements.

Currently each station is entirely isolated from other stations, and the block control system. This upgrade would serve to integrate everything together under one control network