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.