User Tools

Site Tools


Minetest Forum
Content Database
Git Repository
Bug Tracker



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.

Automated testing

  • 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.

Timetable system

(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 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: Seeing that there was not really any opposition to the proposal any more, made a 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.

The route_prog_rework branch

(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.

Dispatcher/signalbox view

(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.

Bugtracker, source repository, contributions

(notes by @ywang)

  • 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: is also an option.
  • orwell: the email-based workflow is not particularly integrated.
  • [Some points on and sourcehut were mentioned and not listed here.]
  • This topic may need to be discussed in the future.

(notes by @Blockhead) A few systems were discussed, mostly for what could replace hemiptera, but source control and contribution also inevitably came up.

  • Hemiptera
    • Anonymous by design, but it gets confusing
      • Has a profile picture system, maybe also pseudonyms? Too hard to come up with something
    • Already in place
    • Suggested by Blockhead that it could continue to be worked on.
    • gpcf: If it has to be reworked, do these:
      • Web submission form (current one is totally broken)
      • Admin tools: Delete spam etc.
      • However, he sees this as more like reinventing the wheel.

* SourceHut

  • No login
  • More like a TODO-tracker.
  • Seemed to require manual filing of issues by developers.

* Notabug or self-hosted gitea

  • Can be hooked to run SourceHut CI.
  • Does require an account. However, when polled, most of us said we already had an account at NotABug.
  • Allows PRs which might aid contributions.
  • Does not work inside the 'git via email' workflow that is the preferred method for project maintainers so far.
  • Could have reliability problems given its history.

orwell would like to keep the sourcehut mailing lists in any case as a reliable point of contact.

Among source repositories, although it was clear that there are many mirrors, the consensus was to keep as the authoritative repository, under gpcf's control rather than a third party. No clear consensus emerged on what to do about improving bugtracking or making contributing easier.

gpcf: For push access to, email him. Contributors can be given push access to only specific branches and only a few have access to master.

Development branch

(notes by @ywang)

  • Blockhead suggested and Maverick2797 seconded 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.

(notes by @Blockhead) Proposal from Blockhead to add a 'dev' branch that is ahead of or equal to master where we can merge without worrying about whether something is broken and that broken state has gone into master.

  1. Advantage: Merge patches faster without worrying about breakage.
  2. Advantage: Merge several feature branches before going to master
  3. Disadvantage: Bureaucracy, doesn't fit our existing workflow.

gpcf: Master is not expected to be unbroken. Only releases. Adding this branch would not help us but instead overcomplicate the existing workflow.

ywang: realistically, a dev branch would only be useful for smaller patches. Feature branches are generally stable enough when they are merged, and minor issues in the master branch can be fixed later. The master branch should not be expected to be stable, but it should at least be usable (i.e. without severe bugs).

56independent: would prefer master to be unbroken, but can agree it is not necessary. 56independent said he was running master on his server but could move to stable release.

Blockhead, gpcf: Server owners should not be running master unless they are prepared to beta test advtrains. Linuxforks is the main public test server.

orwell concludes: Probably more work than benefit. The project does not move fast enough to warrant it. Our current methodology works. Feature branches work well for our purposes so far.

Train HUD and controls

(notes by @ywang and @Blockhead)

  • orwell: remap the inventory button?
    • Potentially unify onboard computer with other controls.
      • Blockhead (in retrospect only): The formspec would be getting quite huge, which is not small-screen friendly.
  • ywang thought about changing the controls, but some things may need to be improved.

Livery system

(notes by @ywang)

  • 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

Organizing the Next Meeting

(notes by @Blockhead and @gpcf)

  • gpcf: There should be smaller conferences for those interested in only certain parts of the project, such as livery, timetabling or i18n.
    • Blockhead: Volunteered to lead a livery conference and prepare a presentation for that.
    • dario23: Expressed interest in an Italian localisation. Was asking to also be prepared to maintain it
    • ywang: Merged French translation recently.
  • Blockhead: We should try to use the wiki and engage with proposals more frequently between conferences.

(notes by @dario23)

  • dario23: Exposed the implementation of the current website with various add-ons


(notes by @Blockhead)

  • ywang: Requested people to read and give feedback on his documentation branch, which has gotten quite substantial.
  • Blockhead: Need to start working on the ATC video…
  • Blockhead: Can we really be using MBB's stuff? Most of it isn't licensed. Also he has renamed to mbruchert on GitHub.
    • Various people suggested various licenses from WTFPL to LGPL and CC, but nothing certain.
    • Repositories have no licence statements.
    • orwell: Clearly he doesn't mind us using them because he isn't suing.
      • Blockhead (only in retrospect): Yes, and he also has merged some changes recently.

Jitsi Meeting Chat Log

erstazi sagt:hi Marnack 
Marnack sagt:hi 
Marnack sagt:I've read it 
erstazi sagt:
Ich sage:
Maverick2797 sagt:standard station track and timetable-specific station track 
Maverick2797 sagt:relative times vs absolute times? 
Maverick2797 sagt:how about a scrollable list that opens up into a closeable tab? 
Maverick2797 sagt:
Maverick2797 sagt:this one? 
Marnack sagt:Yes I've tried that formspec tool.  It's  pretty good. 
Maverick2797 sagt:it doesn't have the scroll_container etc, but it's still good for basic formspecs 
Fellow Jitster
Fellow Jitster sagt:gtg good day 
Blockhead sagt:kthxbai 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:ciao 
Fellow Jitster
Fellow Jitster sagt:dario we talk tomorrow 
Fellow Jitster sagt:not now 
Maverick2797 sagt:I've tried to do a through-coach  system wholly in LuaATC, but it'd be very hard to schedule it imo 
Marnack sagt:Could the taimetable simply trigger that Lua once it arrives? 
Maverick2797 sagt:event = {type="timetable", timetable=true, timetable_id="id"} 
Blockhead sagt:now there's two of them 
Maverick2797 sagt:the trouble is that it's easier to stop a train with the E-Brake when there's lag than it is to slow it normally 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:NEW TRACK:


- 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 
Maverick2797 sagt:having a way to edit the route after it's been saved would be good to avoid having to completely delete and redo a route if you miss something 
Maverick2797 sagt:setting waypoints for the route 
Maverick2797 sagt:Signal boxes: would that require a custom trackplan texture per signal box though? 
Y. Wang
Y. Wang sagt:That could be dynamically generated. MT has a function to render PNG afaik. 
Blockhead sagt:Y. Wang is right I think 
Blockhead sagt:
erstazi sagt:gtg 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:maybe just adding like here "insert a name"? 
Y. Wang
Y. Wang sagt:putting the name in the email body makes it easier to impersonate people though 
Maverick2797 sagt:i generally send patches straight from the command line 
Maverick2797 sagt:account creation vs greater contributor reach and easier patch submission 
56i sagt:Sorry i'm late. I should have set an alarm 0_0 
Maverick2797 sagt:a dev branch could be where branches are merged and beta-tested before being merged into master for release 
Maverick2797 sagt:but making sure that different features play well together should also be important 
56i sagt:I personally use bleeding-edge and would like to see it continue being stable. 
56i sagt:But i can migrate to release if needed 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:if i had access to git banananach i could contribute in certain things 
56i sagt:We should have had this 17:00+Z /hj 
56i sagt:shift+o ? 
Maverick2797 sagt:@56i, international community. This was the best match for everyone. It's 0537 for me 
Blockhead sagt:the meeting time was decided by consensus at the poll site 
56i sagt:Ah, forgot pushing Au back was a bad idea 
56i sagt:Just wondering, are you getting an early start or a late sleep? 
Maverick2797 sagt:early 
Y. Wang
Y. Wang sagt:56 
Y. Wang sagt:56i: depends on your timezone. 
56i sagt:For me, here, BST, 22:39. I sleep at 23:00+ (sometime 01:00) 
56i sagt:But i can understand GCPF's pain. 
Blockhead sagt:early start from me 
Maverick2797 sagt:patches on the mailing list is easy for everyone who doesn't need access to the core advtrains git 
Y. Wang
Y. Wang sagt:^ The atcjit branch started as a set of patches. 
56i sagt:Should i make a simple english translation which simplifies technical terms and phrases to make it easier for noobs and non-natives? 
Y. Wang
Y. Wang sagt:No 
Y. Wang sagt:"Simple English" does not have its own language code in MT 
Blockhead sagt:minetest doesn't support such a translation anyway 
Maverick2797 sagt:i didn't think there was much that wasn't already in "simple english" 
56i sagt:As in Wikipedia SE 
Marnack sagt:Is there any interest in eliminating AdvTrains' dependency on MT Game (default, dye, etc.)? 
Y. Wang
Y. Wang sagt:56i: MT doesn't support that. Also we have a manual 
Maverick2797 sagt:👍 
56i sagt:is it good to have diversity in tutorials? My interlocking tutorial is more regimental then others. Does it inspire fracturing or makes Advtrains easier to learn? 
Y. Wang
Y. Wang sagt:56i: I don't oppose that 
56i sagt:I'll make some on LuaATC, ATC, and other aspects 
56i sagt:Maybe even development 
Y. Wang
Y. Wang sagt:56i: patches are welcome 
56i sagt:*On my own server wiki 
56i sagt:Y. Wang: Just wondering, what's your timezone? 
Y. Wang
Y. Wang sagt:56i: UTC+2 
Maverick2797 sagt:@dario23 I'd be willing to help with that if you want 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:ok no problem 
56i sagt:gpcf: I don't oppose that 
W3RQ01 - dario23
W3RQ01 - dario23 sagt:i'll start the site and some skins 
Marnack sagt:bye 
Maverick2797 sagt:time to go for my morning run 😛 
Maverick2797 sagt:the manual is good as a reference but it's probably a bit long for a tutorial 
56i sagt:Time to go for my daily loss of conscious! 😛 
56i sagt:I'll have to record my server's lines
events/conf/2022-04-02.txt · Last modified: 2023-01-17 18:24 by ywang