2021-10-23

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.

A developer conference took place on 2021-10-23 at 20:00 UTC. Only a few people were invited.

• @orwell mentioned the timetable system as one of the current priorities. In the future, when the timetable system is mature, it might be possible to change the signaling system in a way that respects timetables (e.g. to prioritize late trains).
• The summary is that it will allow building a timetable based on recorded timing information on station/stop rails.
• @orwell floated the possibility of a LuaATC interface to the scheduling code

• Imre's pull request to add the “G” command (wait for a green signal as a specific position) needs review.
• A command to change the autoshunt mode was requested.
• The atcjit branch still needs some improvements and currently conflicts with Imre's PR.

• @gpcf: warning devices, station departure boards, should run with nodetimers so they cause 0 CPU usage when not in loaded mapblocks
• Related bug: H#173
• A node that is a LuaATC component but not punchable or interruptable (station departure boards)

(notes by @ywang) @gpcf noted the following points regarding maintenance:

• Sourcehut also has a bugtracker that can be considered as a replacement for Hemiptera.
• PGP-signed patches/tags should be considered as it (to an extent) prevents people from impersonating developers and prominent contributers to send bogus patches. It is also relatively easy to set up.

• Hemiptera was coded by @gpcf in a few hours on the subway. Its level of anonymity is good, but it was put forward by @Blockhead that it is not a good project management tool.
  • @gpcf Would like to try sourcehut's bug tracker, which has project buckets.
  • Kanban boards were discussed. Possibly @gpcf will look into Kanboard or other free software. This will provide a system where we can see where work items are in development and who is working on them.

• Core developers: you should PGP sign your patches when submitting as a core developer to the mailing list. Other patches will still be considered as we don't want a barrier to entry, but they will be vetted.
• It was decided it is more important to sign the patch files that you submit to the mailing list than the actual commits.
• @orwell will sign release tags

• @gpcf may make an order of advtrains stickers like the LinuxWorks stickers that were made for the Chemnitzer Linux-Tage
• A presence at Linux and Free Software events. Giving away the stickers to entice people?
• Our strengths: Best in class automation, signalling, track system, full programmability. Our weaknesses: art, usability

• LinuxForks (formerly LinuxWorks NG) was always considered 'the' advtrains server in the past.
• @orwell even mentioned that he recommends people visit LinuxWorks to learn about advrains.
• Nowadays there are at least 3 other servers that run advtrains: Tunneler's Abyss, SurvivalWorks Urban Edition, and VanessaE's Train Table. This means server admins affected by the project are at least CalebJ/Hume2, Edgy1 and VanessaE. These have had different levels of involvement:
  • Hume2: Authored linetrack, which added the need for the suitable substrate feature to advtrains core. Also authored the lines 11-99 display colours for the Subway Train. Had extensive experience on LinuxWorks before separating.
  • VanessaE: Forgiving collision mode was added at her request.
  • Edgy1: The train copy tool was requested by a moderator/admin on the SurvivalWorks Urban Edition server, which is part of EdgyNet, but not by Edgy1 himself. Edgy1 formerly played as Trump on LinuxWorks NG so had prior experience with advtrains as well.
• Other less notable servers include 56independent's server and C&C City server, the admins of which also both play/played on LinuxForks.
• We also have a (not very quantifiable) number of people who play singleplayer. The number of ContentDB downloads gives some indication of how many people have tried the base game, as well as each of the train packs also available on ContentDB. Some of these people post in the minetest forums.

Currently most parts of advtrains does not come with unit tests. This has led to multiple cases where the introduction of new features unintentionally broke existing setups. However, as advtrains is a large project, it should be expected that unit tests will be added very slowly.

• The question was asked: Should unit tests be written for new or old code? @Blockhead answered:
  • They should be written for old code so that we can be sure we are not introducing regressions
  • They should be written for new code so that we can be sure the new feature works as intended
• Possibility of a 'test world' where after changes to advtrains, it could be run for a while, to see if any issues occur.

(notes by @Blockhead)

• New signs and signals are coming, by @ywang
• Line speed sign: Sets the maximum speed for a section of track. Analogous to what we already have.
• @orwell described Temporary speed / warning speed restriction signs
  • Round yellow sign, to differentiate from existing systems.
  • Takes priority over line speed restriction.
• @ywang added speed indicators for ks signals

(notes by @ywang)

• The Ks signals are changed to (hopefully) be realistic.
• Distant signaling will be removed from the branch.
  • It is far from maturity, and implementing it properly would likely extend the development time by a lot and move the focus away from the signals themselves.
  • The Zs3v signal will be kept.
  • Distant signaling will be implemented as a separate feature.
  • This will affect worlds that already use distant signaling, but it will not affect the actual operation of the train. (It should also be noted that using a WIP branch on a production server is not recommended for obvious reasons)

(notes by @ywang)

The development of the dlxtrains mod led to a discussion on the train livery system, which is currently very limited. The following solutions were discussed during the conference:

• Keeping the current livery mechanism and writing another mod for advanced livery support,
• Using certain standardized fields in the wagon registration table, or
• Using a livery table where information on supported liveries is passed (@Blockhead).

Additionally, @gpcf brought up a few points that should also be taken into consideration:

• Certain wagons are designed to have variable models (such as the gondola wagons in his moretrains fork).
• In real life, changing train liveries is not trivial, and it is handled by multiple tools.

(notes by @Blockhead)

• Livery has become the catch-all term for visual customisations of wagons. At first @Blockhead thought it would cover just texture and colour options, but @gpcf mentioned the moretrains logging wagons (among others) which customise their model as well, based on loads.
• Customisations include textures, colours, models. Maybe in future even sounds. The options are nearly limitless!
• Adding a one-size-fits-all tool into the advtrains core just wouldn't work, we will leave it to mods to allow full customisation of their wagons with the exposed set_livery callback feature.
• The standard tool will be the train painter, but it will only set primary and secondary colours and a company logo. Wagons don't need to support any of these of course.
  • Train painter: You should need to load it up with dyes for survival mode (@BreadBox64)
• Livery table in the wagon data designated to be managed by the wagon mod
  • How will this data be persisted? API.md currently says there is no way to persist custom wagon data.
  • Some members have conventional values
    • livery_colour - the train painter sets this value
    • livery_logo - company logo
  • Or as further discussed by @Blockhead, @BreadBox64 alone:
    • livery = {color1, color2, logo, …(mod fields)}
    • Texture painter like the painting mod where you can make your logo in-game.
    • technictrain: Battery charge value could be stored in this table?
• Some wagons may choose their colour based on their owner, a la Simutrans or OpenTTD. Not discussed: What interface would customise this?

(notes by @ywang)

The following points were briefly discussed:

• A “line speed” signal aspect (the maximum speed at which a train is allowed to pass a line) should be implemented, which should override the max speed restriction if necessary. (Refer to notes on the new-ks branch)
• The trainhud branch is ready for review, although the custom train HUD feature still needs to be tested.
• @orwell: Minetest currently lacks a mechanism for custom auxiliary keys.
• @orwell, @gpcf: IRL, some older trains can also accept data from newer signaling systems, although the controls need to be manually changed. However, this is not a priority, and implementing this feature would break existing setups (@Maverick2797).
• In the LuaATC punch event, it should be possible to send a message to the player who punched the operation panel.

(notes by @Blockhead)

• It has been discussed before, but we need to add crafting recipes for everything, and consider survival mode in new features as well.

The details of the next conference were not discussed yet, but it is considered that more people may be invited next time if possible.