[Mod] Advanced Trains [advtrains] [2.4.3]

User avatar
Blockhead
Member
Posts: 1622
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
IRC: Blockhead256
In-game: Blockhead Blockhead256
Location: Land Down Under
Contact:

Re: [Mod] Advanced Trains [advtrains] [2.4.1]

by Blockhead » Post

Slightly wrote:
Thu Mar 02, 2023 19:21
Is there a beginner guide to using the trains? I just want to play with them in sp but everytime I try to look through all the mods and supplements, etc., I'm a bit confused. What is the basic set of mods I need to set up some 1800s style trains on sp? Like what would you tell a kid to download and do?
I would tell a kid interested in steam era to fire up ContentDB from the Content Tab in-game and download:
  • advtrains - the core
  • basic_trains - for the steam locomotive and steam-era passenger wagons included in advtrains_train_steam therein.
  • moretrains - for moretrains_steam and you may also be interested in moretrains_basic with 'minecart' like trains included.
then head over to the wiki and look at the (admittedly somewhat outdated) tutorial. If you get stuck on that, please do come and leave specific feedback so we can update the tutorial. That content might be suitable for a video format, let me know if interested.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Re: [Mod] Advanced Trains [advtrains] [2.4.1]

by yw05 » Post

Blockhead wrote:
Fri Mar 03, 2023 02:36
I would tell a kid interested in steam era to fire up ContentDB from the Content Tab in-game and download [...] then head over to the wiki and look at the (admittedly somewhat outdated) tutorial. If you get stuck on that, please do come and leave specific feedback so we can update the tutorial. That content might be suitable for a video format, let me know if interested.
I thought you said you wanted to make more videos on Advtrains at the end of your interlocking tutorial video? That was three years ago ...

W3RQ01
Member
Posts: 157
Joined: Sat Nov 28, 2020 06:33
GitHub: W3RQ01
In-game: Dario23 or W3RQ01
Contact:

Re: [Mod] Advanced Trains [advtrains] [2.4.1]

by W3RQ01 » Post

Slightly wrote:
Thu Mar 02, 2023 19:21
Is there a beginner guide to using the trains? I just want to play with them in sp but everytime I try to look through all the mods and supplements, etc., I'm a bit confused. What is the basic set of mods I need to set up some 1800s style trains on sp? Like what would you tell a kid to download and do?
Moretrains and basic_trains are your choices.
If you want other types of trains (modern, passenger, freight, etc...) take a look at the train catalogue of at the Advtrains Supplemental Organisation. (https://notabug.org/advtrains_supplemental)
OneUnitedPower

Slightly
Member
Posts: 37
Joined: Sun May 15, 2022 22:29
In-game: Slightly

Re: [Mod] Advanced Trains [advtrains] [2.4.1]

by Slightly » Post

Thanks, y'all, I only have internet occasionally so just now seeing these, but I got those and will try them out!

User avatar
orwell
Member
Posts: 958
Joined: Wed Jun 24, 2015 18:45
GitHub: orwell96
IRC: orwell96_mt
In-game: orwell
Location: Raxacoricofallapatorius

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by orwell » Post

Advtrains 2.4.2

Hi all,
I am happy to inform you that I recently completed my degree. In the next few weeks I want to take some time to catch up on the developments in the Minetest community and advance with my plans for advtrains.

As a starting point, I published a new release of advtrains. Since the last release, there have not been many changes, but notable is the introduction of 2-point wagon positioning which will make long wagons look better.

In the next weeks I will work on the improved route programming system, also integrating ywang's work on distant signalling.

Thank you for your ongoing support!

- orwell
Lua is great!
List of my mods
I like singing. I like dancing. I like ... niyummm...

User avatar
MisterE
Member
Posts: 693
Joined: Sun Feb 16, 2020 21:06
GitHub: MisterE123
IRC: MisterE
In-game: MisterE

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by MisterE » Post

orwell wrote:
Wed Mar 15, 2023 19:52
Advtrains 2.4.2

Hi all,
I am happy to inform you that I recently completed my degree. In the next few weeks I want to take some time to catch up on the developments in the Minetest community and advance with my plans for advtrains.

As a starting point, I published a new release of advtrains. Since the last release, there have not been many changes, but notable is the introduction of 2-point wagon positioning which will make long wagons look better.

In the next weeks I will work on the improved route programming system, also integrating ywang's work on distant signalling.

Thank you for your ongoing support!

- orwell
One thing I have always been irked with about Advanced Trains is the positioning and scale of players in the cabin. Usually, they are placed right in the middle of the cabin and they are also too large for the seats. This makes it hard to see out of the windows and breaks the immersion. Consider taking inspiration from Apercy's vehicle mods, especially the blimp and the cars.

Another thing is the lag, which can now be mitigated by doing the extensive calculations on another thread using Minetest 5.6's new Async Api.

Its really exciting that you are back and working on advanced trains again. As you make improvements, don't forget to leave news for minetest's monthly blog post so the rest of the community is aware of your work: github.com/minetest/blog/issues - just create a new issue for new news, the instructions are in the form.

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by yw05 » Post

MisterE wrote:
Wed Mar 15, 2023 20:34
One thing I have always been irked with about Advanced Trains is the positioning and scale of players in the cabin. Usually, they are placed right in the middle of the cabin and they are also too large for the seats. This makes it hard to see out of the windows and breaks the immersion.
I think player positioning is a MT bug where the player appears (to other players) to be attached correctly but has the camera in the center of the attachment. Doxy wrote an auxiliary mod to address this issue.

The cabins are mostly scaled down from their real-life counterparts to fit the ~880mm track gauge. This results in the wagons looking (awkwardly) small. This is (partly) noted in a slightly less related issue. IMO the scaling problem will unfortunately stay this way until someone figures out how to implement mixed-gauge tracks properly, among various considerations.
Another thing is the lag, which can now be mitigated by doing the extensive calculations on another thread using Minetest 5.6's new Async Api.
I am also personally quite skeptical about improving performance from the async environment.

The last time I tested, serialization/saving data seems to take up a somewhat considerable amount of time with certain hardware setups. Passing large amounts of data between the main environment and the async environment will likely do the opposite of improving performance, as (de)serialization would still have to be partially done on the main thread. Therefore, to save time on saving data, most of the internal logic would have to be moved into the async environment to avoid excessive serialization overhead; this would have its own problems though.

In terms of other parts of Advtrains, internal logic (i.e. most of Advtrains) would need to be rewritten to avoid various timing-related problems. This takes a lot of work and is unlikely to finish in the short term, and I am skeptical when it comes to testing the safety of async code.

And what happens if some other mod also causes lag? Then the dtime clipping mechanism still comes in to spoil the fun. IMO that should be the focus instead of moving things to the async environment.

User avatar
Blockhead
Member
Posts: 1622
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
IRC: Blockhead256
In-game: Blockhead Blockhead256
Location: Land Down Under
Contact:

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by Blockhead » Post

MisterE wrote:
Wed Mar 15, 2023 20:34
One thing I have always been irked with about Advanced Trains is the positioning and scale of players in the cabin. Usually, they are placed right in the middle of the cabin and they are also too large for the seats. This makes it hard to see out of the windows and breaks the immersion.
Designing a wagon for AdvTrains is harder than one might think. You have to fit it it the track gauge but also the loading gauge of 3x3 metres in a plane perpendicular to the track, and the standard platform profile which has actually been slightly moved back from where it used to be, but still restricts the horizontal width quite a bit. Wagons like the linetrack boat don't really function very well unless you use hacks like the invisible platform nodes, because AdvTrains doesn't support widths >3 properly. So you can't make your trains too wide, but this flows on to how you can't make them too tall either, or they will be out of proportion.

You can definitely design a wagon that is easier to see out of than a number of them that we have, but it does mean blowing up the proportion of the windows, and usually refraining from applying streak/shine to the glass area of the texture helps too. But as yw05 mentioned, the camera experience is greatly improved if you install doxy's attachment offset patch. This means you can align the first person camera to the windows properly. Now I know that results in exacerbating foot-through-floor, but that's basically unavoidable.

Larger track gauge has its own problems, and would be so divergent as to basically be its own mod fork/rework. And trust me, if you think the current trains take too much space compared to carts, you're going to be annoyed with how much space normal standard gauge (1435 mm) trains would take. AdvTrains gameplay (public transport and cargo hauling) is still important to consider, not just AdvTrains eye candy.
yw05 wrote:
Wed Mar 15, 2023 21:24
MisterE wrote:
Wed Mar 15, 2023 20:34
Another thing is the lag, which can now be mitigated by doing the extensive calculations on another thread using Minetest 5.6's new Async Api.
I am also personally quite skeptical about improving performance from the async environment. ...
We can't really know until someone actually tries. The performance hit from saving the files is real and already in the order of tens of milliseconds for my poor VPS with only a negligible train network; that's running on an SSD and 2 vCPUs. That's only once per minute though. If the simulation can run in a separate thread then from a CPU standpoint it's great to have all that pathfinding suddenly have a lot more CPU available.

One important question is: can you use a reference to the nodedb (or the whole advtrains table) or do you need a copy? How long it takes to copy the nodedb memory into a runner? That's not really a small amount of memory. And second: what potential race conditions would that create? Trains off the tracks because someone broke them in the meantime? The job would have to be short-running. Anyway I remain hopeful; most people simply don't know enough about the async environment to pass judgement either way. Multiprocessing is important to adopt if one can, because of the huge potential gains.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

User avatar
MisterE
Member
Posts: 693
Joined: Sun Feb 16, 2020 21:06
GitHub: MisterE123
IRC: MisterE
In-game: MisterE

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by MisterE » Post

so instead of writing to the database constantly, could you keep the database in memory, and then use an async environment to update the database?

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by yw05 » Post

Blockhead wrote:
Thu Mar 16, 2023 02:05
yw05 wrote:
Wed Mar 15, 2023 21:24
MisterE wrote:
Wed Mar 15, 2023 20:34
Another thing is the lag, which can now be mitigated by doing the extensive calculations on another thread using Minetest 5.6's new Async Api.
I am also personally quite skeptical about improving performance from the async environment. ...
We can't really know until someone actually tries. The performance hit from saving the files is real and already in the order of tens of milliseconds for my poor VPS with only a negligible train network; that's running on an SSD and 2 vCPUs. That's only once per minute though. If the simulation can run in a separate thread then from a CPU standpoint it's great to have all that pathfinding suddenly have a lot more CPU available.

One important question is: can you use a reference to the nodedb (or the whole advtrains table) or do you need a copy? How long it takes to copy the nodedb memory into a runner? That's not really a small amount of memory. And second: what potential race conditions would that create? Trains off the tracks because someone broke them in the meantime? The job would have to be short-running. Anyway I remain hopeful; most people simply don't know enough about the async environment to pass judgement either way. Multiprocessing is important to adopt if one can, because of the huge potential gains.
On a second thought, IMO it might make sense to do the serialization and then pass the data to the async environment to be written, as the serialization overhead is there anyway, and it would improve performance on (in particular) slower hardware.

I recall reading that the data needs to be copied over to the async environment. IMO it would also make sense to do so anyway to avoid timing issues (e.g. the database being modified by the main thread during the process of saving).
MisterE wrote:
Thu Mar 16, 2023 02:09
so instead of writing to the database constantly, could you keep the database in memory, and then use an async environment to update the database?
Currently the database is kept in memory and saved every 30 seconds, if I recall correctly.

User avatar
LMD
Member
Posts: 1386
Joined: Sat Apr 08, 2017 08:16
GitHub: appgurueu
IRC: appguru[eu]
In-game: LMD
Location: Germany
Contact:

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by LMD » Post

Since we have no cheap shared memory between the main & async environment, the async environment currently usually only makes sense to speed up things which take more than linear time. Anything taking linear time is likely to be dominated by the (de)serialization overhead. Since there are no channels, you can't incur this overhead only once, keeping the async env updated over channel communication.

One exception to this is indeed writing to disk. This is linear time, but has a massive constant factor vs. doing CPU work / writing to memory. You should be able to get a cheap performance boost by simply doing

Code: Select all

local function callback() minetest.after(save_interval, save_db) end
local function save_db()
    minetest.handle_async(minetest.safe_file_write, callback, path, minetest.serialize(data))
end
callback()
The most expensive part of this operation - the I/O - will be done asynchronously. I remember checking with sfan a while ago: even on shutdown Minetest will wait for the I/O operation to complete.

That said, I think it is a design mistake to implement persistence as a full database dump rather than incrementally keeping a proper database updated; outsourcing this inefficient persistence implementation to the async env is just a crutch.
My stuff: Projects - Mods - Website

User avatar
mbb
Member
Posts: 256
Joined: Sat Jan 17, 2015 17:47
GitHub: mbruchert
IRC: mBb
In-game: MBB

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by mbb » Post

I rebuilt the signals to look more minetesty:

Image
Attachments
Screenshot_20230316_213556.png
Screenshot_20230316_213556.png (762.22 KiB) Viewed 4422 times
cdb_2fcfab1b41f9

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by yw05 » Post

mbb wrote:
Thu Mar 16, 2023 20:41
I rebuilt the signals to look more minetesty:

Image
The antialiasing (?) around the circle in the retro signal looks a bit awkward, especially the slight yellow color.

Regardless, I like the texture. I hope you are fine if I use the pole texture for the Ks(-related) signals as well?

User avatar
mbb
Member
Posts: 256
Joined: Sat Jan 17, 2015 17:47
GitHub: mbruchert
IRC: mBb
In-game: MBB

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by mbb » Post

yw05 wrote:
Thu Mar 16, 2023 21:16
mbb wrote:
Thu Mar 16, 2023 20:41
I rebuilt the signals to look more minetesty:

Image
The antialiasing (?) around the circle in the retro signal looks a bit awkward, especially the slight yellow color.

Regardless, I like the texture. I hope you are fine if I use the pole texture for the Ks(-related) signals as well?
yes of course.

i will look into the texture thing
cdb_2fcfab1b41f9

User avatar
apercy
Member
Posts: 640
Joined: Wed Mar 25, 2020 16:31
GitHub: APercy
In-game: APercy
Location: Pinheiral - RJ - Brazil

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by apercy » Post

yw05 wrote:
Wed Mar 15, 2023 21:24
MisterE wrote:
Wed Mar 15, 2023 20:34
One thing I have always been irked with about Advanced Trains is the positioning and scale of players in the cabin. Usually, they are placed right in the middle of the cabin and they are also too large for the seats. This makes it hard to see out of the windows and breaks the immersion.
I think player positioning is a MT bug where the player appears (to other players) to be attached correctly but has the camera in the center of the attachment. Doxy wrote an auxiliary mod to address this issue.

The cabins are mostly scaled down from their real-life counterparts to fit the ~880mm track gauge. This results in the wagons looking (awkwardly) small. This is (partly) noted in a slightly less related issue. IMO the scaling problem will unfortunately stay this way until someone figures out how to implement mixed-gauge tracks properly, among various considerations.
Another thing is the lag, which can now be mitigated by doing the extensive calculations on another thread using Minetest 5.6's new Async Api.
I am also personally quite skeptical about improving performance from the async environment.

The last time I tested, serialization/saving data seems to take up a somewhat considerable amount of time with certain hardware setups. Passing large amounts of data between the main environment and the async environment will likely do the opposite of improving performance, as (de)serialization would still have to be partially done on the main thread. Therefore, to save time on saving data, most of the internal logic would have to be moved into the async environment to avoid excessive serialization overhead; this would have its own problems though.

In terms of other parts of Advtrains, internal logic (i.e. most of Advtrains) would need to be rewritten to avoid various timing-related problems. This takes a lot of work and is unlikely to finish in the short term, and I am skeptical when it comes to testing the safety of async code.

And what happens if some other mod also causes lag? Then the dtime clipping mechanism still comes in to spoil the fun. IMO that should be the focus instead of moving things to the async environment.
I would like to walk inside the train wagon like I can walk on my airship
viewtopic.php?f=9&t=29247

Maverick2797
Member
Posts: 128
Joined: Sun Aug 05, 2018 12:37
In-game: Maverick2797
Location: Poking about here and there...

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by Maverick2797 » Post

Not sure how well this would work (at least at the moment) due to the scale. Most of the existing wagons are barely taller than the player, including running gear under the wagon.
The number you have called is not available during a solar eclipse. This message will self destruct in ten seconds in protest... [BEEP]

User avatar
apercy
Member
Posts: 640
Joined: Wed Mar 25, 2020 16:31
GitHub: APercy
In-game: APercy
Location: Pinheiral - RJ - Brazil

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by apercy » Post

Maverick2797 wrote:
Sat Mar 18, 2023 00:11
Not sure how well this would work (at least at the moment) due to the scale. Most of the existing wagons are barely taller than the player, including running gear under the wagon.
screenshot_20230312_164650.png
screenshot_20230312_164650.png (274.94 KiB) Viewed 4343 times
so set the player scale when attached. And if you want your camera at the character center, you need to attach the player to an invisible object, so the camera will be centered to the zero position of this parent object, not the zero position of the vehicle. Of course, this middle invisible object must be attached to the vehicle

User avatar
Blockhead
Member
Posts: 1622
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
IRC: Blockhead256
In-game: Blockhead Blockhead256
Location: Land Down Under
Contact:

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by Blockhead » Post

apercy wrote:
Sat Mar 18, 2023 00:23
so set the player scale when attached.
Didn't know that was an option, but it sounds like a good idea, thanks.
apercy wrote:
Sat Mar 18, 2023 00:23
And if you want your camera at the character center, you need to attach the player to an invisible object ...
This is precisely what attachment offset patch does, hopefully we can integrate that into master.
Last edited by Blockhead on Sun Mar 19, 2023 02:02, edited 1 time in total.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

User avatar
apercy
Member
Posts: 640
Joined: Wed Mar 25, 2020 16:31
GitHub: APercy
In-game: APercy
Location: Pinheiral - RJ - Brazil

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by apercy » Post

Blockhead wrote:
Sat Mar 18, 2023 01:28
apercy wrote:
Sat Mar 18, 2023 00:23
screenshot_20230312_164650.png
so set the player scale when attached.
Didn't know that was an option, but it sounds like a good idea, thanks.

And if you want your camera at the character center, you need to attach the player to an invisible object ...

This is precisely what attachment offset patch does, hopefully we can integrate that into master.
Interesting! I use this little "hack" since 2021, started it on my ultralight trike mod :)

User avatar
orwell
Member
Posts: 958
Joined: Wed Jun 24, 2015 18:45
GitHub: orwell96
IRC: orwell96_mt
In-game: orwell
Location: Raxacoricofallapatorius

Re: [Mod] Advanced Trains [advtrains] [2.4.2]

by orwell » Post

I've also already looked at the async API. As it is now, it will only be of limited value to advtrains. There cannot be any shared state between main thread and worker thread, and the state copies would probably induce even more overhead.

One thing I didn't think about yet is the saving, which I must admit takes considerable time. Moving that to the background could indeed make the situation better. But I can also imagine that serialize_lib is part of the culprit - in its current implementation it calls file:write() once per line which is probably not very efficient. Rather, strings should be collected in memory and written in bulk once the buffer reaches a certain size. There's certainly room for improvement.

In the long run, I think we cannot get around a dedicated "advtrains daemon" that runs as a separate process. It would communicate with "glue code" in Minetest via an RPC system. However, I want to highlight that I still want advtrains to function as a pure minetest mod. The daemon solution is an option for larger servers which struggle with lag, but for the ordinary Minetest player they should be able to just install advtrains and it works.


BTW, I thought of that attachment hack already in 2017. The result was this issue. By the time it got fixed however, I didn't pick it up again. But I'd welcome a patch to the mailing list to integrate this attachment hack into master for the time being.
Lua is great!
List of my mods
I like singing. I like dancing. I like ... niyummm...

User avatar
orwell
Member
Posts: 958
Joined: Wed Jun 24, 2015 18:45
GitHub: orwell96
IRC: orwell96_mt
In-game: orwell
Location: Raxacoricofallapatorius

Questionaire regarding breaking change of internal track connection handling

by orwell » Post

Hi,

this is directed to everyone maintaining mods on top of advtrains core. Everyone who is not acquainted with the inner workings of advtrains may skip this.

To get forward with implementing a better interlocking route programming system, I'd need to make a breaking change in the way track connections of switches (aka turnouts) are handled. Currently it is like this:
  • When train approaches a turnout, it will always go from conn 1->2. The two switch nodes that represent the two states (straight and curve) will have conns 2 and 3 swapped accordingly.
  • On which connection a train will go out is decided entirely on the number of conns a track has.
  • 3-way turnouts use a so-called "ugly hack", where there are 5 connections and "5th entry is a stub".
  • There's another hack for "split points" that only covers that specific case and defies generality
There is currently no defined way to determine to what states a turnout can be switched to. It may be guessed, but this will certainly break somehow and would only add to the list of "ugly hacks" above. For the new routing system, I need to answer "coming from here, to which directions can I switch this turnout and continue?"

I'd therefore like to change the system as follows:
  • There will no longer be a fixed in-out mapping of connids.
  • All tracks that have >2 conns will need to add an additional definition table, detailing the turnout/crossing layout
  • The function advtrains.get_matching_conn() will be replaced incompatibly.
I will take care of porting advtrains_train_track accordingly, this includes the crossing nodes. I will try to keep the preset-based track registration intact. Also, LUA ATC getstate/setstate will remain compatible.

Do you see any issues in this regard with your current mods?
Lua is great!
List of my mods
I like singing. I like dancing. I like ... niyummm...

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Re: Questionaire regarding breaking change of internal track connection handling

by yw05 » Post

orwell wrote:
Mon Apr 10, 2023 18:43
There is currently no defined way to determine to what states a turnout can be switched to. It may be guessed, but this will certainly break somehow and would only add to the list of "ugly hacks" above. For the new routing system, I need to answer "coming from here, to which directions can I switch this turnout and continue?"

I'd therefore like to change the system as follows:
  • There will no longer be a fixed in-out mapping of connids.
  • All tracks that have >2 conns will need to add an additional definition table, detailing the turnout/crossing layout
  • The function advtrains.get_matching_conn() will be replaced incompatibly.
I will take care of porting advtrains_train_track accordingly, this includes the crossing nodes. I will try to keep the preset-based track registration intact. Also, LUA ATC getstate/setstate will remain compatible.

Do you see any issues in this regard with your current mods?
The proposed changes (mostly) sound nice, although I would appreciate more details. I wrote a simple debugging mod somewhere (which started with a "print conns table of a piece of track" feature mainly for sanity check), and had to split the printing code into multiple parts based on the length of the conns table. I will change that mod accordingly to match the changes.

That said, I hope there will be a way to check whether the old system is used, and some heads-up-time would definitely be helpful.

On a less related note, a tostring metamethod on such a table could help debugging, if you would not mind writing it.

User avatar
Blockhead
Member
Posts: 1622
Joined: Wed Jul 17, 2019 10:14
GitHub: Montandalar
IRC: Blockhead256
In-game: Blockhead Blockhead256
Location: Land Down Under
Contact:

Re: Questionaire regarding breaking change of internal track connection handling

by Blockhead » Post

orwell wrote:
Mon Apr 10, 2023 18:43
3-way turnouts use a so-called "ugly hack", where there are 5 connections and "5th entry is a stub".
You can thank me for that hack.. Yes it is definitely more of a case of working around limitations than good design, but it got the job done. Refactoring is good when done right though.
orwell wrote:
Mon Apr 10, 2023 18:43
There is currently no defined way to determine to what states a turnout can be switched to.
Correct, doing so automatically would basically involve running Lua callbacks. It would be easy enough to use the switch alternate state info if we only had 2-way switches but we have 3-way switches.
orwell wrote:
Mon Apr 10, 2023 18:43
I'd therefore like to change the system as follows:
  • There will no longer be a fixed in-out mapping of connids.
Good, although it adds dynamic lookup, but it's still really just a single table lookup just like the existing global connid table, so I foresee no overhead at a quick guess. Caching/memoisation helps regardless of the implementation.
orwell wrote:
Mon Apr 10, 2023 18:43
  • All tracks that have >2 conns will need to add an additional definition table, detailing the turnout/crossing layout
It would be nice to provide templates in the core that Train Track will use, just like the templates that were added for the crossing shapes when I did that work. That way only odd shapes need to be written out in full.
orwell wrote:
Mon Apr 10, 2023 18:43
I will take care of porting advtrains_train_track accordingly, this includes the crossing nodes. I will try to keep the preset-based track registration intact. Also, LUA ATC getstate/setstate will remain compatible.

Do you see any issues in this regard with your current mods?
Mods that are forks of AdvTrains Train Track will need updating, so that is at least linetrack and tieless tracks. They may continue to work in-place but if not, it would be good to PR it.

Of course, having mentioned linetrack, this brings up a thorny issue: Tunneler's Abyss have a forked AdvTtrains. I think that AdvTrains master has moved too slow which encourages forks, but I also think TA just likes to live in a world of its own. Their fork predates the move to Basic Trains so it still includes versions of their mods. There is also movement to fix deprecation warnings.

I think that AdvTrains needs to make some moves to fix some quick easy things that have been sitting stagnant in the mailing list, which has a chilling effect on contribution. new-ks, route programming rework and so on are good projects for the future but they take a long time. Part of good project leadership is taking contributions and merging them quickly enough to keep people interested. Look, I am here to help, and I could take it upon myself to go and merge a heap of patches into a personal fork today. But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

User avatar
56independent_actual
Member
Posts: 452
Joined: Sun May 23, 2021 16:10
IRC: independent56
In-game: 56independent
Location: Girona Province
Contact:

A dangerous but potentially functional answer to Blockhead's dilemma.

by 56independent_actual » Post

Blockhead wrote:
Tue Apr 11, 2023 02:25
But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
There is a solution, but i'm not sure if you or the community will like it. I, myself, have taken it up myself due to circumstances surrounding me and the project.

You could open your own fork of Advtrains.

By making tons of patches, improvements, and other things, you can then manage the "upstream" and make a better Advtrains. Using this fork, you can then compete against Advtrains and maybe win over the userbase and fix the problems yourself.

I'm taking this approach myself but i do not wish to publish it until it reaches a suitably advanced state. Due to ADHD and motivation troubles, this might not be for years. This means you have the perfect gap to jump into. And the feeling of competition might push myself forwads with the fork.

If we have three seperate forks of Advtrains fighting each other, the main advtrains can then get to a competitive level. If all three forks merge together later on, all three communities combine into one and the total power may be extrodanary, nothing ever seen before in Minetest. Maybe Advtrains can then become the definitive transport mod and brand. We already have boats and buses on seperate forks. If we assimilate these, we can then move onto planes and teleportation and sci-fi devices.

The future looks grim with the stagnation of Advtrains to a halt (there were only four commits to master in 2022! FOUR! Even my fork has already made more then that in the first week alone!), just like a ghost train does to the trains on my server (I am planning to add ghost train checking to routesetting logic. Some of the code is already written; avoid reduplicating it please!).

But, even if the forks stay seperate, there is still hope. By co-ordinating efforts and preventing feature duplication and agreeing on some middle ground fork which merges all three features, we can achieve a simialr effect, but in a more human-conflict-based way, the way that works for humans.

Let us all hope for a less grim future. Let us all hope for the removal of that annoying ghost train and the speedy movement of Advtrains, at a nice 30 m/s insted of the 20 it was always at (I'm still amazed i got my fork up to that speed). If this happens and Advtrains enters rapid development, i may wish to rejoin the community, remove the restrictive legal statement in readme, and assimilate my changes. Maybe i might open my own branch for processing of the changes. If i am unable to, i will attempt to amass my own group of followers to assist my fork to compete.

However, should worst come to worst, this thread should be designated to organisation of this messy battlefield of forks.


Note: I do believe my behaviour at the time of the ban was wrong and unreasonable, but due to many personal and intrapersonal factors, i do not feel i am able to remain a net positive influence. I can potentially push advtrains kilometers forwards given more time and acceptance from the community.

Part of that is accepting patches after heavy modification to make them "safe", and another part is accepting trail and error in social interactions. This contributes to my sense of what's right and wrong in society's eyes. For example, i no longer feel my actions regarding LF after the Trisiston Uranium ban and before my departure from the forum topic were correct, appropiate, nor helpful in any way shape or form, but that was only because i performed them. I understand that LF does not want me anymore, and that's the price i am fine with paying nowdays.

Hopefully, the same thing does not happen to Advtrains leading to my very own Final-Minetest-type fork for Advtrains, which would be terrible for both of us.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

yw05
Member
Posts: 366
Joined: Tue May 07, 2019 12:59
GitHub: y5nw
IRC: y5nw
In-game: ywang
Location: Germany

Advtrains maintenance work

by yw05 » Post

Blockhead wrote:
Tue Apr 11, 2023 02:25
orwell wrote:
Mon Apr 10, 2023 18:43
  • All tracks that have >2 conns will need to add an additional definition table, detailing the turnout/crossing layout
It would be nice to provide templates in the core that Train Track will use, just like the templates that were added for the crossing shapes when I did that work. That way only odd shapes need to be written out in full.
orwell wrote:
Mon Apr 10, 2023 18:43
I will take care of porting advtrains_train_track accordingly, this includes the crossing nodes. I will try to keep the preset-based track registration intact. Also, LUA ATC getstate/setstate will remain compatible.

Do you see any issues in this regard with your current mods?
Mods that are forks of AdvTrains Train Track will need updating, so that is at least linetrack and tieless tracks. They may continue to work in-place but if not, it would be good to PR it.
I think it should be possible to change the conns definition in the way orwell described while allowing other mods to continue using the template.

I think that AdvTrains master has moved too slow which encourages forks, [...]

I think that AdvTrains needs to make some moves to fix some quick easy things that have been sitting stagnant in the mailing list, which has a chilling effect on contribution.
+1. The patches on the mailing list is piling up. I spent some time looking at some of them, but ultimately these need to be merged upstream to be useful.

On the topic of mailing lists, we are still not performing CI on patches.
new-ks, route programming rework and so on are good projects for the future but they take a long time. Part of good project leadership is taking contributions and merging them quickly enough to keep people interested.
Well, I started new-ks mainly to improve Ks/German signals. That turns out to be the part of new-ks that takes the least amount of time, as certain.

The main thing that kept me back from working on other parts of Advtrains is that there are enough times for me where small patches became worthy of a dedicated branch, and (especially recently) I do not have much time to work on all these ideas myself.

Then there are the l10n and doc branches where something is always missing and have (even for me) lower priority. These also happen to be things that more or less need to be updated constantly. Even with less changes recently, there is a lot of work based on what we already have, and things on these branches are only further complicated by new-ks and the route programming rework.
Look, I am here to help, and I could take it upon myself to go and merge a heap of patches into a personal fork today. But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
Have you consider asking orwell whether you can become a maintainer? IMO you would do very well, considering your existing experience in both Advtrains and Supplemental projects.
56independent_actual wrote:
Tue Apr 11, 2023 11:18
Blockhead wrote:
Tue Apr 11, 2023 02:25
But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
There is a solution, but i'm not sure if you or the community will like it. I, myself, have taken it up myself due to circumstances surrounding me and the project.

You could open your own fork of Advtrains.

By making tons of patches, improvements, and other things, you can then manage the "upstream" and make a better Advtrains. Using this fork, you can then compete against Advtrains and maybe win over the userbase and fix the problems yourself.
I do not think Blockhead or orwell have anything against forking, especially considering that Blockhead forked many of mbb's mods himself to work on them during mbb's absence.

IMO the main thing to consider when forking mods is maintenance. It does not take much effort to merge patches: this can easily be done with git am. However, maintaining a fork requires dedication, and things can get relatively messy if you want to sync it with upstream and the latter is focused on introducing large changes. I have had a few merge conflicts a few times during my time working on the HUD and new-ks, and that involves only a small part of the Advrains codebase.
If we have three seperate forks of Advtrains fighting each other, the main advtrains can then get to a competitive level. If all three forks merge together later on, all three communities combine into one and the total power may be extrodanary, nothing ever seen before in Minetest. [...]

The future looks grim with the stagnation of Advtrains to a halt [...]
The stagnation of Advtrains itself does not necessarily make the community around it stagnant. DlxTrains, Doxy's Minitram, and Supplemental show this quite well IMO.

I do not see competition as a way of making upstream Advtrains more competitive. The reason that the development of Advtrains stagnates is that it is limited by the free time of its developers, and more people forking Advtrains will not make them have 26 hours a day.
[...] (there were only four commits to master in 2022! FOUR! Even my fork has already made more then that in the first week alone!)
It is the changes that matter. The number of commits itself is irrelevant - sometimes I (during the process) mark some minor commits as "fixups" when rebasing, which reduces the number of commits that end up in the master branch.

The other thing is that this ignores the work put into feature branches. The commits are not pushed directly to master because a lot of work is involved.

That said, the development of Advtrains was not in its best state, as you mentioned earlier.
But, even if the forks stay seperate, there is still hope. By co-ordinating efforts and preventing feature duplication and agreeing on some middle ground fork which merges all three features, we can achieve a simialr effect, but in a more human-conflict-based way, the way that works for humans.
... in which case separate forks are not seriously needed long-term as the middle ground becomes the de facto upstream; or let's hope the best for the poor guy that tries to merge everything together.

Post Reply

Who is online

Users browsing this forum: No registered users and 21 guests