[Mod] Advanced Trains [advtrains] [2.4.3]

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

Re: Advtrains maintenance work

by 56independent_actual » Post

yw05 wrote:
Tue Apr 11, 2023 15:17
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 was referring to the codebase. The community is perfectly fine, but i feel that if they became more powerful then their core, we could see some dangerous divergence from the more well-defined main, as people develop forks for their own featuress and seperate patches for what Advtrains does not add.
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 develop ers, and more people forking Advtrains will not make them have 26 hours a day.
An error on my part; however, my point still stands that competition can work for the better, especially if some form of co-ordination is established. By having the motivation of "the enemy" working hard, you end up working harder then them, leading to a cycle of development which can bear ripe fruits if the features to be implemented are implemented in a way that allows easy merging.

It actually benifits both parties if the feature sets are different from one another; that way there is an element of choice in fork selection, once again making sure both parties will end up working hard to try to win users and potential contributors.

Some content i added in an edit in the middle of the text, which makes it easy to miss: When my fork is published, i will publish it's nice long todo list. This will ensure that feature re-duplication can be avoided; if i am working on a complicated feature and you are doing it at the same time without knowing about each other doing it, barely any progress is made.

However, if we worked on different features in wildly different parts of the core (like how you're placing more stuff in advtrains_interlocking whilst i'm working all over the core and other places to help refine Advtrains and make intresting new features (i've already made the speed bar porpotional to max speed (but i forgot about the arrows) and added a new speed digit; support for 50 m/s has already been made, with KS signs up to 50 having been added alongside a new 50 m/s edit of the mesejet).
It is the changes that matter. The number of commits itself is irrelevant
Some repositories have 100 commits during one year from tons of people. Maybe they're small or a little useless. However, what they indicate is a living, breathing community of developers. Even if the 4 commits were massive and made Advtrains tons better, what does it say about the attitude of the developers that there were only 4 commits, with a maximumm of 4 different people working on it?
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.
The feature branches do not matter to the end user. They are discouraged from server use (you told me not to use new-ks on my server), and as such cannot be seen as indicators of willingness to develop on Advtrains directly. Even if new-ks made one of the best interlocking systems in the world, even better then IRL ones, it does not matter to the end user until it is merged into main.
... 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.
I was thinking about a situation where everyone is at odds with each other so do not want to co-operate on the same fork; instead middle ground is established for the sake of the users just like how main is a stagnant branch and the feature branches are where the innovation really comes.

Maybe this is the unfortunate fate that awaits future Advtrains; fragmented beyone usability across many forks, branches, and other places, the maintainers busy doing something else and the users fustrated at the lack of change. Maybe the death of advtrains will arrive and the branches will all become seperate forks, forced to become further and further apart, pushed by the dark energy of the developers and the dark energy of the universe expanding.

Hopefully, this does not happen and i can get some competition against my fork from the powerful main branch. I can then backport the Advtrains features, saving me effort, and maybe even vice-versa! Contributing to Advtrains via backporting by the main devs does seem to evade the ban by a wide enough margin it should not matter. This might just happen if Blockhead were to take the effort of maintenence and patch merging, as well as backporting my changes.
Last edited by 56independent_actual on Wed Apr 12, 2023 07:25, edited 1 time in total.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

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

Re: Advtrains maintenance work

by 56independent_actual » Post

Removed post due to misclick on edit button to quote button
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

Re: Advtrains maintenance work

by yw05 » Post

56independent_actual wrote:
Tue Apr 11, 2023 17:06
yw05 wrote:
Tue Apr 11, 2023 15:17
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 was referring to the codebase. The community is perfectly fine, but i feel that if they became more powerful then their core, we could see some dangerous divergence from the more well-defined main, as people develop forks for their own featuress and seperate patches for what Advtrains does not add.
There are currently quite some mods that add features to Advtrains, including, well, more than enough livery systems.

Using the livery system as an example, while the situation is not optimal for someone new, these systems allow the creators of the corresponding mods to provide train packs with unique features, which benefits the community overall.

I do not see how a powerful community is a problem to a stagnant codebase, especially large ones. As I have stated earlier, forks (like the upstream codebase) take a significant amount of effort to maintain, leave alone making these more significant than upstream.
By having the motivation of "the enemy" working hard, you end up working harder then them, leading to a cycle of development which can bear ripe fruits if the features to be implemented are implemented in a way that allows easy merging.
However, what they indicate is a living, breathing community of developers. Even if the 4 commits were massive and made Advtrains tons better, what does it say about the attitude of the developers that there were only 4 commits, with a maximumm of 4 different people working on it?
I do not see how there is a lack of interest in working on Advtrains, considering that orwell himself is also working on route programming. Competition will not make developers have more time to work on projects.

Also, Advtrains itself does not have many developers to start with, and combine that with the limited amount of time: gpcf and orwell are/were busy with university work; Blockhead, Maverick, and I are not developers and can not push directly to the master branch (and at least I do not want to, considering how some things broke when my changes got merged to master in 2.4.0).
It actually benifits both parties if the feature sets are different from one another; that way there is an element of choice in fork selection, once again making sure both parties will end up working hard to try to win users and potential contributors.
Other than creating competition that does not actually benefit anyone (as I wrote earlier), it does not improve the situation for the users either, as they have to choose between two sets of features.
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.
The feature branches do not matter to the end user. They are discouraged from server use (you told me not to use new-ks on my server), and as such cannot be seen as indicators of willingness to develop on Advtrains directly. Even if new-ks made one of the best interlocking systems in the world, even better then IRL ones, it does not matter to the end user until it is merged into main.
Which (unfortunately) leads to what Blockhead wrote earlier:
Blockhead wrote:
Tue Apr 11, 2023 02:25
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.
Advtrains has (from what I have seen) mainly focused on large changes in the past years.
I was thnking about a situation where everyone is at odds with each other so do not want to co-operate on the same fork; instead middle ground is established for the sake of the users just like how main is a stagnant branch and the feature branches are where the innovation really comes.
I do not see a stagnant master branch as a problem as long as development takes place on branches with the intention of being merged into master. IMO this is actually sensible as the commit log is left relatively clean (with commits from a branch/patchset being put together) and the master branch is not left in a unstable/unusable state while development continues. By the way, the latter is the reason I advise people not to use feature branches unless they know what they are doing.

The same can be said for forks, especially considering that the Advtrains repo itself is not open for people to write to (for obvious reasons). In fact, Blockhead's work on track crossings started as a fork on Github.

That said, if people are unwilling to cooperate, then, instead of having a middle ground, we will likely end up with the same sort of drama that took place on IRC recently (and no, please do not bring that drama here).

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

Re: Advtrains maintenance work

by 56independent_actual » Post

Just before i begin, i would like to state that the facts are opinions are so far apart can mean two different things:
  • One of us is wrong (probably me lol).
  • It is a good idea to stay seperate and work how we (as groups) would like to work seperately before we waste more time splitting hairs over what was already set in stone
So, as such, i invite you to review the fork post-publication, its develpoment practices, and see what little is applicable to the real Advtrains.

I would also like to spend more time ignoring forum posts to allow me to focus on 56i-trains development, such as figuring out where in the codebase would be a good place to place "a" and "d" keybinds to change the player's position in the wagon. Help is appreciated, but currently i think that in some function in wagons.lua (which is way too long to allow me to send it to ChatGPT to give an outline of (i'm glad i don't have to bother you with silly questions like "comprehensive guide to the doors API" anymore yay); i would like to split each function into a seperate file for easier thinking and manegement, but that would break compatibality (should i do it?)) would be a good place to put it.
yw05 wrote:
Wed Apr 12, 2023 07:30
There are currently quite some mods that add features to Advtrains.
This can be good or bad depending on how you think of it. Advtrains is a series of related mods connected together. It's a modpack! That's why we have advtrains_interlocking and advtrains_signal_ks as seperate mods which add functionality to advtrains but are not part of the core, yet are still added to advtrains due to their high functionality..

What we are seeing now is a divergence from this concept; by adding new features in seperate mods, like advtrains_attachment_offset_patch being a seperate mod, we are giving the user more choice but forcing them to know more about the code then before.

Where i can see a problem is patches which are small enough that they should be part of Advtrains, but due to stagnation, they have been made seperate mods. This way, stagnation becomes dangerous and fractutres the community. More choice, less usability.

The truth i can see is that the community, due to stagnation, is shying away from non-maintenence core dev, moving innovation to external mods, where they have confidence it will be able to go public and seen by people, rather then part of some small branch. This is damaging to the core in the long-term as people are getting less experience with the core and more with the API, so maintenence becomes more difficult.

Take, for example, commits 3a6b1ca8500cad74f95b925b191582c0aa739116 and 78e0c650e3a3d92facef11ddbf3a58a9dc22bae8. If they had been implemented in the same way advtrains_attachment_offset_patch had been, they would be part of a seperate mod called "Advtrains Freight Code Patches", focused on making freight codes easier to use. Luckily, they were part of the core as they were far enough apart to be non-related chronologically.
Competition will not make developers have more time to work on projects.
Time, at least in my case, is often obscured by wasteful things being performed. For example, i used to be unable to pull away from Youtube until i installed a time-limiter. I suddenly became more aware of the time i was spending and how it was eating into my meager time-limits, resulting in more time staring at 56i-trains and how tiny it was at the times.
gpcf and orwell are/were busy with university work;
I have a lot of iGCSE revision and housework to do as my father is off in the UK managing our buisness and we live in Spain. As such, i have a tiny amount of time left for things. Yesterday, i only had a small pocket between 21:30 and 22:00 to do any free time things and it was so short i couldn't even finish rewriting and organising todo list entirely before i had to go to bed, giving me no time for maths revision for ensuring i can still get into university (luckily Haskell always exists and might just be able to bribe them into letting me in (/hj)).

Time struggles are a universial problem in this community.
Blockhead and Maverick can not push directly to the master branch, which (unfortunately) leads to what Blockhead wrote earlier:
This is a management issue. Should a admin spend the 1 hour-in-a-lifetime needed (including giving permission, communications, and responses) to give permissions to a single developer, they can then sit back and watch instead of become involved.
Advtrains has (from what I have seen) mainly focused on large changes in the past years.
In my eyes, this is a big problem. Small refinemenets are just as important as large changes. What's the point of a big fancy driver HUD if it can't support speeds higher then 20 m/s just because big changes are the norm?

In fact, i will show you the relevant code for this change, which you may freely take with NO GUARANTEE OF WARRANTY WHATSOEVER:

Code: Select all

    -- speed indication(s)
    sevenseg(math.floor(vel/100), 320, 10, 30, 10, "[colorize\\:red\\:255")
    sevenseg(math.floor(vel/10), 380, 10, 30, 10, "[colorize\\:red\\:255")
    sevenseg(vel%10, 440, 10, 30, 10, "[colorize\\:red\\:255")

    -- Seems to be the speedbar thing
    local speed = train.max_speed
    local speedPerBar = speed/20
    for i = 1, vel/speedPerBar, 1 do
        ht[#ht+1] = sformat("%d,/65=(advtrains_hud_bg.png^[resize\\:8x20^[colorize\\:white)", i*11-1)
    end
    for i = max+1/speedPerBar, 20, 1 do
        ht[#ht+1] = sformat("%d,65=(advtrains_hud_bg.png^[resize\\:8x20^[colorize\\:darkslategray)", i*11-1)
    end
    if res and res > 0 then
        local resPerBar = res/speedPerBar
        ht[#ht+1] = sformat("%d,60=(advtrains_hud_bg.png^[resize\\:3x30^[colorize\\:red\\:255)", 7+resPerBar*11)
    end
This might just look like "shitty code contributions" to you, but to me, it looks like a good base to build features upon, even if my variable names are not as cryptic as yours (i understand the need to put less stress on your poor abused keypads (probably, just based off extrapolation from my amount of development on Advtrains and how shiny and dirty my main keypads are (because the dirt has been polished into the keycaps ew)), but my need not to think too much goes above my need not to hit tab in the code editor so often). Feel free to implement it. Beware: the arrow indicators are not porpotional yet.

It's a relatively small and easy change; the main difficulty comes with coming up with the bother to get it done and past all 3 git commands (git add *; git commit -m "porpotional speed bars"; git push --force origin master (yes, --force was a joke).
I do not see a stagnant master branch as a problem as long as development takes place on branches with the intention of being merged into master.
This is the philosophy i am taking with my 56i-trains repository; each related set of changes has their own branch of which i can abandon without consequences should my development skill below that of which past actions of both the community and me have put the situation into, and this means that development can push forwards like some kurbenetes cluster. However, as soon as a branch reaches a "nice good state", i will merge them and either remove the branch due to satisfaction of goals or continue pursuing development.
The same can be said for forks, especially considering that the Advtrains repo itself is not open for people to write to (for obvious reasons). In fact, Blockhead's work on track crossings started as a fork on Github.
I have one phrase which dictates my reaction to this perfectly: "слава богу". If you ever feel 56i-trains is getting better then Advtrains, remember that advtrains has the viral license and my readme note is probably not legally binding.
That said, if people are unwilling to cooperate, then, instead of having a middle ground, we will likely end up with the same sort of drama that took place on IRC recently (and no, please do not bring that drama here).
I hate to request this, but please give me a summary of the relevant elements so i have at least a basic idea of what you mean. At least the date and channel on a publicly-logged channel will be enough to tell what happened.

If people are unwilling enough to co-operate, i have already exhausted my probably-deccenial supply (or maybe, as always, my mental conditions continue to shift; the death of the histomic disorder part and the rise of the noise and smell sensitivity seem to be occuring, as well as a lengthening of the hobby cycle alongside (probably wrong) perfectonism in writing (which means i keep on editing posts, like i'm doing now)) of wishing to cause drama in the earlier 2020s, so i'll just quietly take features from the other forks.

Anyways, besides this, should my work on 56i-trains ever meet your strict quality standards for Advtrains, feel free to either remove the ban (in which case i still refuse to use the email patch system over what i'm already used to; however, i might figure it out should main become rolling again), backport changes (as legally as possible), or move yourself over to the fork should Advtrains ever have some form of pernament damage inflicted to it.
Last edited by 56independent_actual on Wed Apr 12, 2023 10:48, edited 3 times in total.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

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

Re: Advtrains maintenance work

by Maverick2797 » Post

56independent_actual wrote:
Wed Apr 12, 2023 09:12
Take, for example, commits 3a6b1ca8500cad74f95b925b191582c0aa739116 and 78e0c650e3a3d92facef11ddbf3a58a9dc22bae8. If they had been implemented in the same way advtrains_attachment_offset_patch had been, they would be part of a seperate mod called "Advtrains Freight Code Patches", focused on making freight codes easier to use. Luckily, they were part of the core as they were far enough apart to be non-related chronologically.
These specific patches would never be pushed to a separate mod due to how they intergrate with advtrains. The fact that they were spaced so far apart has nothing to with how related they are, instead being due to me seeing a feature that could be expanded on, writing working code for it and submitting the patch to allow others to play test it as well. If I had a dollar for every time this has happened... well I'd have a few bucks, and it's entirely reasonable for it to happen repeatedly for similar features or portions of the code.
Blockhead and Maverick can not push directly to the master branch, which (unfortunately) leads to what Blockhead wrote earlier:
This is a management issue. Should a admin spend the 1 hour-in-a-lifetime needed (including giving permission, communications, and responses) to give permissions to a single developer, they can then sit back and watch instead of become involved.
I beg to disagree. Just because advtrains is a large mod with multiple contributors of various size does not mean that the original author is required to delegate anything. We are very fortunate that orwell has delegated a bit. Not everyone needs write access to the master branch. There's nothing wrong with forking off your own branch and making a patch contribution when your feature is ready for release. I have no need for anything more than read access (which everyone has via https) and a path through which to submit my patches. I agree that the email patch system is not straightforward to everyone, but I learned from scratch how to use git-send-email, along with enough of the basics of git, in the last 2 years to be able to meaningfully contribute to the codebase of the mod I like. It's not that hard to follow a tutorial when it's literally written in front of you: https://git-send-email.io

Edit: typo
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
56independent_actual
Member
Posts: 452
Joined: Sun May 23, 2021 16:10
IRC: independent56
In-game: 56independent
Location: Girona Province
Contact:

Re: Advtrains maintenance work

by 56independent_actual » Post

Maverick2797 wrote:
Wed Apr 12, 2023 10:18
It's not that hard to follow a tutorial when it's literally written in front of you: https://git-send-email.io
It's not that it's difficult to switch to email git, just that it changes my workflow. It might be the simplest thing in the world, but i still have to go to the bother of finding information about my email addresses and SMTP and so many things. Change is difficult for humans a lot of the time.

In any case, i would like to quote what has already been said, just in this context:
Blockhead wrote:
Tue Apr 11, 2023 02:25
But unless I could guarantee that upstream would accept [my changes], it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
Blockhead: If i accidentally sent a quote notification, sorry; i thought removing the user ID would be enough and i wanted that little up arrow for context reasons due to my little abridgment with the square brackets.

In any case, i don't think i wish to contribute to master for the forseeable future anyways due to:
yw05 wrote:
Sun Jan 15, 2023 18:39
shitty code contributions. [...] So fuck off.
Oh, and also:
yw05 wrote:
Sun Jan 15, 2023 19:15
I would be more than glad that you leave [...] Advtrains.
Ywang/yw05: If i accidentally sent a quote notification, sorry; i thought removing the user ID would be enough and i wanted that little up arrow for context reasons due to my little abridgment with the square brackets.
Anyways, i love how ChatGPT helps me decode the codebase. I just paste in a function and it will come up with some form of explanation about it. Here is its first response about the wagon:on_rightlick function.
ChatGPT wrote: This function is called when a player right-clicks on a wagon object. The function first checks if the wagon has been initialized and if the clicker is a player. It then retrieves data about the wagon and the player who clicked it. The function then checks if the player is already seated in the wagon, and if so, displays a list of possible actions the player can take, such as accessing the wagon's inventory or onboard computer. If the player is not seated, the function checks if the wagon has any available seats and if the player has permission to access them. If there are available seats, the function allows the player to sit down in one of them. If there are no available seats, the function informs the player and does not allow them to board the wagon.
It was enough to help me understand and edit it. I suggest you also use it when code gets too confusing for your poor overworked brains to handle.

Oh and also, you can ask it questions about where to best place code and what to do!

You must take it with a grain of salt; i'm pretty sure this function does not exist:
chatGPT wrote: You can move a player to the next wagon by calling the move_to_next_wagon() function on the current wagon object. Here is an example:
Last edited by 56independent_actual on Wed Apr 12, 2023 11:18, edited 3 times in total.
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

Re: Advtrains maintenance work

by yw05 » Post

56independent_actual wrote:
Wed Apr 12, 2023 09:12
yw05 wrote:
Wed Apr 12, 2023 07:30
There are currently quite some mods that add features to Advtrains.
This can be good or bad depending on how you think of it. Advtrains is a series of related mods connected together. It's a modpack! That's why we have advtrains_interlocking and advtrains_signal_ks as seperate mods which add functionality to advtrains but are not part of the core, yet are still added to advtrains due to their high functionality..

What we are seeing now is a divergence from this concept; by adding new features in seperate mods, like advtrains_attachment_offset_patch being a seperate mod, we are giving the user more choice but forcing them to know more about the code then before.

Where i can see a problem is patches which are small enough that they should be part of Advtrains, but due to stagnation, they have been made seperate mods. This way, stagnation becomes dangerous and fractutres the community. More choice, less usability.

The truth i can see is that the community, due to stagnation, is shying away from non-maintenence core dev, moving innovation to external mods, where they have confidence it will be able to go public and seen by people, rather then part of some small branch. This is damaging to the core in the long-term as people are getting less experience with the core and more with the API, so maintenence becomes more difficult.
I do not see why people moving away from core development is a problem, and how this makes maintenance (of what?) more difficult.

Instead, we have seen how this brings innovation, as people are not bounded by the rate of patches being accepted. The alternative would be having Advtrains do everything while not doing anything well as core development becomes the bottleneck.

In fact, if anything, I would argue that Advtrains should make its API more open to make Advtrains-related modding easier (and encourage such development), as people only need to learn its API without being forced to read the source code and figure out the internals. IMO the developers should not be (and, currently, are not) in the position of deciding what is acceptable and what is not.

That said, Advtrains itself also has to move on to allow more features, and I do agree that smaller (workaround) mods should belong in the Advtrains source code.

Time struggles are a universial problem in this community.
And what you propose is to add pressure to people with competition while burnout is a (problematic) reality we face here.
Blockhead and Maverick can not push directly to the master branch, which (unfortunately) leads to what Blockhead wrote earlier:
This is a management issue. Should a admin spend the 1 hour-in-a-lifetime needed (including giving permission, communications, and responses) to give permissions to a single developer, they can then sit back and watch instead of become involved.
For reference, this is what I wrote:
yw05 wrote:
Wed Apr 12, 2023 07:30
Advtrains itself does not have many developers to start with, and combine that with the limited amount of time: gpcf and orwell are/were busy with university work; Blockhead, Maverick, and I are not developers and can not push directly to the master branch (and at least I do not want to, considering how some things broke when my changes got merged to master in 2.4.0).
The feature branches do not matter to the end user. They are discouraged from server use (you told me not to use new-ks on my server), and as such cannot be seen as indicators of willingness to develop on Advtrains directly. Even if new-ks made one of the best interlocking systems in the world, even better then IRL ones, it does not matter to the end user until it is merged into main.
Which (unfortunately) leads to what Blockhead wrote earlier:
Blockhead wrote:
Tue Apr 11, 2023 02:25
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.
Advtrains has (from what I have seen) mainly focused on large changes in the past years.
Anyway, I do not see how this is a management issue, as I do not know whether Maverick or Blockhead asked for write access to the repo in the first place. I only asked for write access to work on specific branches, so gpcf set my permission to allow writing to branches that are not the master branch, and this has worked well for me.

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

Re: Advtrains maintenance work

by 56independent_actual » Post

yw05 wrote:
Wed Apr 12, 2023 11:17
Instead, we have seen how this brings innovation, as people are not bounded by the rate of patches being accepted. The alternative would be having Advtrains do everything while not doing anything well as core development becomes the bottleneck.
That does actually make sense! I guess, if we were to use some metaphor you should ignore if its wrong, it's like an innovative country; they could choose to put almost all innovation in the innovation capital (somewhere like hypothetical silicon valley) to keep people close together and allow for faster innovation, or spread innovation over a wide area, like what's happening now with Advtrains; people in this hypothetical country can then innovate at their own pace as they live far away in places like hypothetical Alaska and cannot hypothetically travel to the hypothetical meetings so don't need to, just that travel here is replaced by time waiting for merging, and meetings are the individual patches...?
In fact, if anything, I would argue that Advtrains should make its API more open to make Advtrains-related modding easier (and encourage such development), as people only need to learn its API without being forced to read the source code and figure out the internals. IMO the developers should not be (and, currently, are not) in the position of deciding what is acceptable and what is not.
56i-trains has already taken this approach; it treats the offset patch as part of the modpack, along with DLXtrains. This approach mixes both the innovation of being seperate with the user-friendlyness of only needing to press one download button to access all this innovation.
And what you propose is to add pressure to people with competition while burnout is a (problematic) reality we face here.
Just thinking about that has helped me remember the brutal final week of school before the easter break, which was (luckily) one week long. At that time, most of the students had significant sleep debt, burnout, and as such the school calendar cut off Friday to make it easier for us.

Hopefully, we never reach the situation that happened to MPlayer, where 56i-trains is the MPV (which i use daily) and Advtrains becomes Mplayer. In fact, i dare to say this is already happening; 56i-trains does have a focus on being friendly to the new user, and Advtrains main branch has stagnated with only a small stream leaving the swamp.

Maybe feature branches and new developers, as previously discussed, are the saving grace for Advtrains-main and as soon as New-ks is merged and code reviews are delegated to Blockhead we will end up finally having some form of movement on Advtrains, encouraging development, allowing the swamp to drain and make a much nicer river running through a forest of development and creation.

I guess, as a conclusion, I'll continue working on my project until it surpasses Advtrains; hopefully, I won't lose momentum and give Advtrains an opportunity to catch up. Advtrains might be able to benefit from its many changes and new features with a night dedicated to the terminal and git should a time come that the core developers have enough time to do it.

For time-booking reasons, my exams begin on 2023-05-14 (see the countdown), and won't end until 2023-06-16. Most of the exams during this week will be exams i don't take, meaning i have time to revise and work hard to cram in the weeks leading up to an exam... leaving absolutely no time for 56i-trains development. This is the prime time for Advtrains to take my features and try to advance past my fork, if you're willing to do such a task.

Afterwards come the lengthy summer holidays and i will be able to spend a lot of time working on 56i-trains, should the hobby cycle permit it.
One example from FOSS history where the original fork died due to lack of activity but a new fork is living on quite well is the case of the MPlayer media player.

MPlayer was a popular media player for Unix-like systems, including Linux. However, development of MPlayer stalled for several years, with no new releases or updates being made. This led to a decline in its popularity and users began to look for alternatives.

A group of developers then decided to create a new fork of MPlayer, called mpv, which aimed to improve upon the original software and address some of the issues that had led to its decline. Unlike MPlayer, mpv was designed to be easy to use, with a simple and intuitive interface.

The new fork gained popularity quickly, and today it is widely used as a media player on Unix-like systems. Despite the decline of the original MPlayer, the new fork has continued to thrive and is actively developed and maintained by a dedicated community of developers.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

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

I would like to remind everyone in this thread to stop feeding the trolls. The more that is said in response, the more everyone's time is wasted.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ 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:

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

by 56independent_actual » Post

Blockhead wrote:
Wed Apr 12, 2023 12:00
the trolls.
Which trolls? The ones which i publicly denounced (i still hate that reply and the tone, but i hate those guys even more)? Or are you talking about me, mistaking my opinions as fake ones designed to sow discord?

If you are talking about me, i will leave temporarily to put more time into 56i-trains for its eventual publishment, under the condition that any member of this topic, when responding to me, assume that giving no reply implies nothing and that what can be attributed to stupidity may not ever be attributed to malice, including my posts.

If you fail to state wether the troll is me or not, i will continue posting regardless of what you think internally.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

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

Blockhead wrote:
Wed Apr 12, 2023 12:00
I would like to remind everyone in this thread to stop feeding the trolls. The more that is said in response, the more everyone's time is wasted.
Agree.

A few weeks ago I took some time to look over the mailing list posts, but from what I've seen, most, if not all of the patches there are in fact already merged. (this does not apply to the new patches that came in over the last 2 weeks, I still need to check these out). The issue is that I can't get Thunderbird to include a custom header into mails I send, and I have not gotten around to set up a terminal mail client that would allow this kind of thing - so I can't close the threads on the mailing list.

If that's not the case and one of you is waiting for a certain patch/contribution to be applied, please give me a heads-up.

EDIT: just noticed that apart from MBB's new signal models - which I'll need to try out again - all advtrains mail was going towards the supplemental mods - which I am not responsible for (less work for me :) )

EDIT2: There are in fact a few things that haven't been merged yet. My memory somehow played tricks on me. Let me review the patches again.

EDIT3: I replied to some threads.
Last edited by orwell on Wed Apr 12, 2023 20:30, edited 1 time in total.
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: [Mod] Advanced Trains [advtrains] [2.4.2]

by yw05 » Post

orwell wrote:
Wed Apr 12, 2023 19:08
A few weeks ago I took some time to look over the mailing list posts, but from what I've seen, most, if not all of the patches there are in fact already merged. (this does not apply to the new patches that came in over the last 2 weeks, I still need to check these out). The issue is that I can't get Thunderbird to include a custom header into mails I send, and I have not gotten around to set up a terminal mail client that would allow this kind of thing - so I can't close the threads on the mailing list.
You can change the mail.compose.other.header setting in Thunderbird's config editor. I did that a while ago but forgot where I read about it.
If that's not the case and one of you is waiting for a certain patch/contribution to be applied, please give me a heads-up.

EDIT: just noticed that apart from MBB's new signal models - which I'll need to try out again - all advtrains mail was going towards the supplemental mods - which I am not responsible for (less work for me :) )
Seems like a few patches are still open:
  • Make selection boxes of track nodes larger (Blockhead)
  • Add craft recipes for the new ks speed indicators (Maverick2797) (*)
  • HUD train.debug (Maverick2797)
  • Add a config to destroy automobiles like OpenTTD (Blockhead)
(*): I do not think this will conflict with the new-ks branch. I would suggest merging this now as it would otherwise take a long time for new-ks to be merged (and I will have to rebase new-ks on top of master anyway).

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

Orwell: sorry for posting immediately again. This just came to my mind as you are looking into mbb's patches.

In the new-ks branch I wrote advtrains_signals_japan/init.lua to automatically generate the models for the Japanese signals (as I did not want to spend too much time on making the signal faces myself), with rotation handled by MT's vector API (among other things, the vertex local function in the model generation code creates a rotated variant of the given vertex). Perhaps that can be used to auto-generate rotated variants of models.

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

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

by 56independent_actual » Post

Important Note My phone is now buzzing like a beehive with your activity so please ignore my post until you're done; ADHD hyperfocus, if you are affected by it, is very sensitive to being distracted and i wouldn't want to stop you. if you have hyperfocus, GO BACK AND RESIST THE TEMPTATION TO READ MORE.
orwell wrote:
Wed Apr 12, 2023 19:08
Agree.
This post makes me assume you know who he is referring to. Please clarify whether he is referring to me.
A few weeks ago I took some time to look over the mailing list posts, but from what I've seen, most, if not all of the patches there are in fact already merged.
Thank you very much for taking my suggestions for a core dev to go over these changes and finally make Advtrains look as popular as it is. I know you had so much potential from the start and you have not reached the end yet. If we, a as a community of forks and contributors, do find an end, we must then cast our sights to improving the Minetest LuaAPI to continue our great project.

May i wish Advtrains good luck, high innovation, and everliving life.
Warnig: Al my laguage ekscept English is bad, includig Hungarian (magyàränoлиски), Spanish (esпagnyoл), and Russian (рÿсскïанöл).

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

yw05 wrote:
Wed Apr 12, 2023 20:05
Orwell: sorry for posting immediately again. This just came to my mind as you are looking into mbb's patches.

In the new-ks branch I wrote advtrains_signals_japan/init.lua to automatically generate the models for the Japanese signals (as I did not want to spend too much time on making the signal faces myself), with rotation handled by MT's vector API (among other things, the vertex local function in the model generation code creates a rotated variant of the given vertex). Perhaps that can be used to auto-generate rotated variants of models.
This may actually come in handy for auto-generated track models.
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

Re: Questionaire regarding breaking change of internal track connection handling

by orwell » Post

Blockhead wrote:
Tue Apr 11, 2023 02:25
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.
Hi Blockhead,

thanks for offering your support on merging open patches.

I took a few minutes just now to check and apply some of the still-open patches from the mailing ist. On some topics that are unclear to me I left messages on the mailing list. However I am not sure if I still missed something.

I trust your ability to merge patches into upstream advtrains, and am happy to update the master with said "heap of patches" if you take the time to merge and test it. So, OK from my side.

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

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

yw05 wrote:
Wed Apr 12, 2023 20:05
Orwell: sorry for posting immediately again. This just came to my mind as you are looking into mbb's patches.

In the new-ks branch I wrote advtrains_signals_japan/init.lua to automatically generate the models for the Japanese signals (as I did not want to spend too much time on making the signal faces myself), with rotation handled by MT's vector API (among other things, the vertex local function in the model generation code creates a rotated variant of the given vertex). Perhaps that can be used to auto-generate rotated variants of models.
I think it would be better to use paramtype2=degrotate and make the trackworker apply the rotations via param2, thus reducing the number of registered nodes and making the logic simpler. I think this was not an option when the earliest signals are made, but all signals could be retrofit to this scheme with LBMs.

Another thing I forgot to mention earlier in relation to conns code changes: netmapper will need updating.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ 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.2]

by yw05 » Post

Blockhead wrote:
Thu Apr 13, 2023 02:23
I think it would be better to use paramtype2=degrotate and make the trackworker apply the rotations via param2, thus reducing the number of registered nodes and making the logic simpler. I think this was not an option when the earliest signals are made, but all signals could be retrofit to this scheme with LBMs.
That would not work for tracks (which currently use the same trackworker logic):
  • The length of the tracks varies based on rotation.
  • We still need multiple variants for curves (etc), due to the available directions we currently have. Tracks connecting the conns 1-8 have an angle of 153.5° (=180°-26.5°), but tracks connecting the conns 2-9 have an angle of 161.5° (=135°+26.5°). I have not tested yet, but I assume that a difference of 8° would be visible.
Along that, there are also a few things to note:
  • Certain items (e.g. Ks signal masts) can currently be "abused" to be placed horizontally for purposes not related to signaling.
  • In some cases (e.g. the Japanese signals in new-ks), the current system makes it possible to keep the (quasi-cylindrical) pole in the center static while rotating only the signal face. This allows signals sharing the same pole to face different directions without looking awkward. I do not think the visual difference would otherwise be significant though.
We would still need to support the existing system alongside paramtype2=degrotate, and we would need to update the node database code, although we would need to do the latter anyway if we want to use the async environment for I/O (see LMD's note in page 89).

Froggo8311
Member
Posts: 15
Joined: Sat Apr 02, 2022 15:12
GitHub: Froggo8311
In-game: Froggo
Contact:

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

by Froggo8311 » Post

Hello. I was curious if the website had a git repo set up? I'm offering to make contributions or make a newer website.
They/She 🏳‍⚧ | Codeberg | GitHub | Soundcloud

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

Froggo8311 wrote:
Fri May 26, 2023 22:32
Hello. I was curious if the website had a git repo set up? I'm offering to make contributions or make a newer website.
I think the website isn't version controlled since it's so rudimentary.

W3RQ01 has had some ideas in the works to improve it but I will let him speak for himself if he wants to respond here.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

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

I've submitted an issue to https://bugs.linux-forks.de/advtrains/ for the use of undocumented texture modifier features (using parentheses instead of escapes inside combine). See the patch:

Code: Select all

commit 6ba6892666cc4114efc67e1512b37707fbff766c
Author: Lars Mueller <appgurulars@gmx.de>
Date:   Sun May 28 14:03:40 2023 +0200

    Fix texture modifiers relying on undocumented behavior

diff --git a/advtrains/trainhud.lua b/advtrains/trainhud.lua
index 22aa6cf..6680287 100644
--- a/advtrains/trainhud.lua
+++ b/advtrains/trainhud.lua
@@ -190,7 +190,7 @@ function advtrains.hud_train_format(train, flip)
 		tlev=1
 	end
 	
-	local ht = {"[combine:440x110:0,0=(advtrains_hud_bg.png^[resize\\:440x110)"}
+	local ht = {"[combine:440x110:0,0=advtrains_hud_bg.png\\^[resize\\:440x110"}
 	local st = {}
 	if train.debug then st = {train.debug} end
 	
@@ -227,54 +227,54 @@ function advtrains.hud_train_format(train, flip)
 		for i = 1, 7, 1 do
 			if ent[i] then
 				local s = segs[i]
-				ht[#ht+1] = sformat("%d,%d=(advtrains_hud_bg.png^[resize\\:%dx%d^%s)",x+s[1], y+s[2], s[3], s[4], m)
+				ht[#ht+1] = sformat("%d,%d=advtrains_hud_bg.png\\^[resize\\:%dx%d\\^%s",x+s[1], y+s[2], s[3], s[4], m)
 			end
 		end
 	end
 	
 	-- lever
-	ht[#ht+1] = "275,10=(advtrains_hud_bg.png^[colorize\\:cyan^[resize\\:5x18)"
-	ht[#ht+1] = "275,28=(advtrains_hud_bg.png^[colorize\\:white^[resize\\:5x18)"
-	ht[#ht+1] = "275,46=(advtrains_hud_bg.png^[colorize\\:orange^[resize\\:5x36)"
-	ht[#ht+1] = "275,82=(advtrains_hud_bg.png^[colorize\\:red^[resize\\:5x18)"
-	ht[#ht+1] = "292,16=(advtrains_hud_bg.png^[colorize\\:darkslategray^[resize\\:6x78)"
-	ht[#ht+1] = sformat("280,%s=(advtrains_hud_bg.png^[colorize\\:gray^[resize\\:30x18)",18*(4-tlev)+10)
+	ht[#ht+1] = "275,10=advtrains_hud_bg.png\\^[colorize\\:cyan\\^[resize\\:5x18"
+	ht[#ht+1] = "275,28=advtrains_hud_bg.png\\^[colorize\\:white\\^[resize\\:5x18"
+	ht[#ht+1] = "275,46=advtrains_hud_bg.png\\^[colorize\\:orange\\^[resize\\:5x36"
+	ht[#ht+1] = "275,82=advtrains_hud_bg.png\\^[colorize\\:red\\^[resize\\:5x18"
+	ht[#ht+1] = "292,16=advtrains_hud_bg.png\\^[colorize\\:darkslategray\\^[resize\\:6x78"
+	ht[#ht+1] = sformat("280,%s=advtrains_hud_bg.png\\^[colorize\\:gray\\^[resize\\:30x18",18*(4-tlev)+10)
 	-- reverser
-	ht[#ht+1] = sformat("245,10=(advtrains_hud_arrow.png^[transformFY%s)", flip and "" or "^[multiply\\:cyan")
-	ht[#ht+1] = sformat("245,85=(advtrains_hud_arrow.png%s)", flip and "^[multiply\\:orange" or "")
-	ht[#ht+1] = "250,35=(advtrains_hud_bg.png^[colorize\\:darkslategray^[resize\\:5x40)"
-	ht[#ht+1] = sformat("240,%s=(advtrains_hud_bg.png^[resize\\:25x15^[colorize\\:gray)", flip and 65 or 30)
+	ht[#ht+1] = sformat("245,10=advtrains_hud_arrow.png\\^[transformFY%s", flip and "" or "\\^[multiply\\:cyan")
+	ht[#ht+1] = sformat("245,85=advtrains_hud_arrow.png%s", flip and "\\^[multiply\\:orange" or "")
+	ht[#ht+1] = "250,35=advtrains_hud_bg.png\\^[colorize\\:darkslategray\\^[resize\\:5x40)"
+	ht[#ht+1] = sformat("240,%s=advtrains_hud_bg.png\\^[resize\\:25x15\\^[colorize\\:gray)", flip and 65 or 30)
 	-- train control/safety indication
 	if train.tarvelocity or train.atc_command then
-		ht[#ht+1] = "10,10=(advtrains_hud_atc.png^[resize\\:30x30^[multiply\\:cyan)"
+		ht[#ht+1] = "10,10=advtrains_hud_atc.png\\^[resize\\:30x30\\^[multiply\\:cyan"
 	end
 	if train.hud_lzb_effect_tmr then
-		ht[#ht+1] = "50,10=(advtrains_hud_lzb.png^[resize\\:30x30^[multiply\\:red)"
+		ht[#ht+1] = "50,10=advtrains_hud_lzb.png\\^[resize\\:30x30\\^[multiply\\:red"
 	end
 	if train.is_shunt then
-		ht[#ht+1] = "90,10=(advtrains_hud_shunt.png^[resize\\:30x30^[multiply\\:orange)"
+		ht[#ht+1] = "90,10=advtrains_hud_shunt.png\\^[resize\\:30x30\\^[multiply\\:orange"
 	end
 	-- door
-	ht[#ht+1] = "187,10=(advtrains_hud_bg.png^[resize\\:26x30^[colorize\\:white)"
-	ht[#ht+1] = "189,12=(advtrains_hud_bg.png^[resize\\:22x11)"
-	ht[#ht+1] = sformat("170,10=(advtrains_hud_bg.png^[resize\\:15x30^[colorize\\:%s)", train.door_open==-1 and "white" or "darkslategray")
-	ht[#ht+1] = "172,12=(advtrains_hud_bg.png^[resize\\:11x11)"
-	ht[#ht+1] = sformat("215,10=(advtrains_hud_bg.png^[resize\\:15x30^[colorize\\:%s)", train.door_open==1 and "white" or "darkslategray")
-	ht[#ht+1] = "217,12=(advtrains_hud_bg.png^[resize\\:11x11)"
+	ht[#ht+1] = "187,10=advtrains_hud_bg.png\\^[resize\\:26x30\\^[colorize\\:white"
+	ht[#ht+1] = "189,12=advtrains_hud_bg.png\\^[resize\\:22x11"
+	ht[#ht+1] = sformat("170,10=advtrains_hud_bg.png\\^[resize\\:15x30\\^[colorize\\:%s", train.door_open==-1 and "white" or "darkslategray")
+	ht[#ht+1] = "172,12=advtrains_hud_bg.png\\^[resize\\:11x11"
+	ht[#ht+1] = sformat("215,10=advtrains_hud_bg.png\\^[resize\\:15x30\\^[colorize\\:%s", train.door_open==1 and "white" or "darkslategray")
+	ht[#ht+1] = "217,12=advtrains_hud_bg.png\\^[resize\\:11x11"
 	-- speed indication(s)
 	sevenseg(math.floor(vel/10), 320, 10, 30, 10, "[colorize\\:red\\:255")
 	sevenseg(vel%10, 380, 10, 30, 10, "[colorize\\:red\\:255")
 	for i = 1, vel, 1 do
-		ht[#ht+1] = sformat("%d,65=(advtrains_hud_bg.png^[resize\\:8x20^[colorize\\:white)", i*11-1)
+		ht[#ht+1] = sformat("%d,65=advtrains_hud_bg.png\\^[resize\\:8x20\\^[colorize\\:white", i*11-1)
 	end
 	for i = max+1, 20, 1 do
-		ht[#ht+1] = sformat("%d,65=(advtrains_hud_bg.png^[resize\\:8x20^[colorize\\:darkslategray)", i*11-1)
+		ht[#ht+1] = sformat("%d,65=advtrains_hud_bg.png\\^[resize\\:8x20\\^[colorize\\:darkslategray", i*11-1)
 	end
 	if res and res > 0 then
-		ht[#ht+1] = sformat("%d,60=(advtrains_hud_bg.png^[resize\\:3x30^[colorize\\:red\\:255)", 7+res*11)
+		ht[#ht+1] = sformat("%d,60=advtrains_hud_bg.png\\^[resize\\:3x30\\^[colorize\\:red\\:255", 7+res*11)
 	end
 	if train.tarvelocity then
-		ht[#ht+1] = sformat("%d,85=(advtrains_hud_arrow.png^[multiply\\:cyan^[transformFY^[makealpha\\:#000000)", 1+train.tarvelocity*11)
+		ht[#ht+1] = sformat("%d,85=advtrains_hud_arrow.png\\^[multiply\\:cyan\\^[transformFY\\^[makealpha\\:#000000", 1+train.tarvelocity*11)
 	end
 	local lzb = train.lzb
 	if lzb and lzb.checkpoints then
@@ -285,10 +285,10 @@ function advtrains.hud_train_format(train, flip)
 			if spd == -1 then spd = nil end
 			local c = not spd and "lime" or (type(spd) == "number" and (spd == 0) and "red" or "orange") or nil
 			if c then
-				ht[#ht+1] = sformat("130,10=(advtrains_hud_bg.png^[resize\\:30x5^[colorize\\:%s)",c)
-				ht[#ht+1] = sformat("130,35=(advtrains_hud_bg.png^[resize\\:30x5^[colorize\\:%s)",c)
+				ht[#ht+1] = sformat("130,10=advtrains_hud_bg.png\\^[resize\\:30x5\\^[colorize\\:%s",c)
+				ht[#ht+1] = sformat("130,35=advtrains_hud_bg.png\\^[resize\\:30x5\\^[colorize\\:%s",c)
 				if spd and spd~=0 then
-					ht[#ht+1] = sformat("%d,50=(advtrains_hud_arrow.png^[multiply\\:red^[makealpha\\:#000000)", 1+spd*11) 
+					ht[#ht+1] = sformat("%d,50=advtrains_hud_arrow.png\\^[multiply\\:red\\^[makealpha\\:#000000", 1+spd*11)
 				end
 				local floor = math.floor
 				local dist = floor(((oc[i].index or train.index)-train.index))
My stuff: Projects - Mods - Website

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

LMD wrote:
Sun May 28, 2023 12:10
I've submitted an issue to https://bugs.linux-forks.de/advtrains/ for the use of undocumented texture modifier features (using parentheses instead of escapes inside combine). See the patch:
Thanks for your interest in submitting this. I can see the patch didn't survive the submission to Hemiptera :( Hemiptera is really a very rudimentary system run by gpcf, so excuse the bugginess..

Hemiptera remains available for anonymous submission but we prefer to track bugs on the NotABug mirror now - https://notabug.org/advtrains/advtrains/issues . You can submit bugs directly there if you have an account to avoid double-handling.

For patches like this, the best way to send them is directly via email to our SourceHut mailing list, advtrains-devel. A web interface is available here with the right mailto URI. You can send to the list via git send-email. Orwell will probably see and be able to apply your patch from here, but I prefer not to leave my email address right in the open on the forums personally. You can also participate in a review email thread on the mailing list instead of here on the forums. It's up to you if you want to submit the patch to the mailing list or await a response here.
Last edited by Blockhead on Wed May 31, 2023 16:50, edited 1 time in total.
/˳˳_˳˳]_[˳˳_˳˳]_[˳˳_˳˳\ Advtrains enthusiast | My map: Noah's Railyard | My Content on ContentDB ✝️♂

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.2]

by W3RQ01 » Post

Blockhead wrote:
Sat May 27, 2023 02:25

W3RQ01 has had some ideas in the works to improve it but I will let him speak for himself if he wants to respond here.
Yes i did start making a new website but i had to stop working on it due to rl problems which haven't been resolved yet
OneUnitedPower

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

Thanks for the information. I should have sent out an e-mail to the mailing list now.
My stuff: Projects - Mods - Website

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

Hi everyone,

I suppose you all are waiting for news of exciting new features in advtrains.

Bad news is that I have become addicted to TechAge and have spent my evenings building powerplants and oil refineries instead of working on advtrains.

Good news is that I got fed up with transporting oil by filling it into barrels and then loading the barrels into tank wagons. (makes a lot of sense, right?). So, I implemented support for filling TechAge liquids into tank wagons! You can now pump liquids into and out of tank wagons that have the techage_liquid_capacity property set in the wagon definition.

So far, there is no formspec like the techage tanks, but the liquid content is displayed in the infotext.

If there are no objections, I would like to post a new mod release in the coming days, since there hasn't been one for quite some time.

- orwell
Attachments
screenshot_20230719_212402.png
screenshot_20230719_212402.png (672.83 KiB) Viewed 3739 times
screenshot_20230719_212159.png
screenshot_20230719_212159.png (514.07 KiB) Viewed 3739 times
Last edited by orwell on Thu Jul 20, 2023 16:48, edited 1 time in total.
Lua is great!
List of my mods
I like singing. I like dancing. I like ... niyummm...

Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests