Note: this page should be about the discussion that took place during the conference itself. Comments should be written elsewhere, e.g. on the mailing list.

The conference started at 20:00 UTC.

• gpcf pointed out the lack of testing system in advtrains. The lack of testing has, according to gpcf, slowed down the development of advtrains to an extent.

(notes by @ywang)

• The timetable system proposal was brought up again, as in the previous conference.
• dario23 requested a user-friendly API for the timetable system.
• gpcf noted that a timetable system could make it easier to create information systems.
• dario23 suggested creating a new track to inform trains and stations. It was also proposed that trains could address train delays, such as with more intense braking.
• orwell said that a user interface would be appreciated. Blockhead mentioned a formspec editor.
• gpcf suggested implementing timetable “buffers”.
• gpcf suggested a “subtrain system” that allows splitting trains.
• orwell mentioned SimSig, where the resulting trains from shunting can get separate timetables.
• gpcf thinks it may be interesting to see how the timetable system affects shunting.
• There was a discussion between Blockhead, gpcf, and dario23 on the use of timetables for shunting operations. LuaATC may be involved.
• orwell wanted a system of “guaranteed connections”, where a train would wait for another train.
• Some features do not need to be implemented in the first iteration. Implementation details can be discussed later.
• Support for LuaATC (e.g. timetable-specific events) may be added.
• gpcf could start working on the timetable system.

(notes by @blockhead)

dario23: A more noob-friendly timetable system.

• orwell: Is it necessary? Basic ATC should be useable for this purpose.
• dario23: To bring a proposal for additional track type that makes other tasks easier.

orwell: Timetable

• Recording based entirely on relative times. The first train arrives, it sets a time. No need to program a railway time to start the timetable on.
• gpcf: There should be editing features for after the timetable is recorded.
• orwell: GUI with Tabs, one tab per line
  • Blockhead: Instead of headers, maybe a selection list
  • Blockhead: Use luk3yx.gitlab.io/minetest-formspec-editor to help drafting
• gpcf: Provision built in for sub-train/train splitting system
  • orwell: Do it like SimSig where there are 'split train into new timetable id' and 'wait for a train to join' commands.
• gpcf: Fitting regular shunting into a schedule for, for example, through-coaches
  • Maverick2797: Can the timetable simply send a LuaATC interrupt.

(notes by @dario23, via @Blockhead) Dario23 proposed a new track with the following specifications:

• give infos to stations
• give infos to train
• more easy
• more user-friendly interface
• track takes infos from train and give them to stations about traffic, delay ecc…
• make the train find a way to reduce the delay
• track should be before station/stop rail
• this track IS connected to the station stop rail like a tcb
• train does not stop at this track
• if train hasn’t delay can let pass through

(back to notes from @Blockhead) Describing dario's proposal in my own words

• Tracks that go before the station/stop rail. It is connected on a 1-1 basis like a TCB. that give information to the trains such as:
  • Which station is next, how long the stop is for
  • Ways to catch up if timetable is too far behind.
    • For example, do not turn ARS off so the train will not be late departing the station.
    • Brake harder
    • Less time on the doors
    • Accelerate faster
    • orwell: Setting a quite low minimum stop time would naturally have this type of effect in his proposal

orwell: Request for someone to step forward and work on the timetable system because he has not got the time. Some sign of commitment from gpcf but nobody else.

(mixed notes by @ywang and @Blockhead)

• Orwell is working on the route_prog_rework branch. The goal of the branch is to improve the experience of route programming.
• Ideally, the user only needs to specify the starting and ending point of the route.
• The idea is to reduce problems caused by erroneous route programming.
• Blockhead pointed out that pathfinding may become a problem for complicated junctions. The solution suggested by Blockhead and Maverick2797 is to mark a 'waypoint' or point that the route must travel through. This would work like dragging a specific point on the route suggested by Google Maps.
• Maverick2797 (and many others previously) requested for a way to edit routes instead of making them again from scratch.

(notes by @ywang and @Blockhead)

• The advtrains_itrainmap mod could be revived, but orwell would not like to see it return in its previous form.
• itrainmap ran very slowly for larger areas.
• orwell said that it would be interesting to have actual working signalboxes.
  • He proposed that there should be a view like a train dispatcher can see, similar to SimSig or a physical train control board based on relays. The exact method for constructing these was not explained in detail.

• Hemiptera is currently problematic because of spamming. It is also blocked by certain email providers.
• gpcf: continuing the work on Hemiptera is mainly reinventing the wheel.
• gpcf chose sourcehut because of the email-centric workflow (as opposed to requiring everyone to log in).
• gpcf: the issue tracker is mainly internal (i.e. for developers). Discussions take place on the mailing list.
• gpcf: self-hosting could be an option.
• Blockhead: one advantage of Hemiptera is that it is not as easy to accidentally start new threads in cases where it is not desired.
• gpcf: Hemiptera lacks a proper web UI.
• orwell: notabug.org is also an option.
• orwell: the email-based workflow is not particularly integrated.
• [Some points on notabug.org and sourcehut were mentioned and not listed here.]
• This topic may need to be discussed in the future.

• Maverick2797 suggested creating a dev branch for testing and then merging it into the master branch.
• gpcf: more feature branches are needed.
• Blockhead: The dev and master branch differ in that the dev branch cannot be broken. It would be nice to be able to apply patches to the development branch.
• orwell: The dev branch could be tested on (for example) LinuxForks and then merged into the master branch.
• gpcf: People should use the releases for stability.
• [Some discussions follow.]
• orwell: thing could be left this way for now. The dev branch currently does not need to be introduced as there is not much activity.
• Blockhead: there is a lack of tests.

• orwell: remap the inventory button?
• ywang thought about changing the controls, but some things may need to be improved.

• Blockhead: “wagon transition”: similar to “aliases” that convert certain wagons to other types.
• This appears to be implemented by both gpcf and Blockhead.
• gpcf: There could be a conference on the livery system

• gpcf: There should be smaller conferences for those interested in only certain parts of the project.