Yes please. Doesn't hurt to have more speeds available.
Yes, this sounds like a reasonable idea. This would also make the code more modular.yw05 wrote: ↑Fri Nov 05, 2021 09:33My current idea is to use a table of speed restrictions and updating train.speed_restriction every step. Basically a new entry that looks something like this:Code: Select all
speed_restrictions_t = { main = <speed>, -- permanent local speed restriction line = <speed>, -- line speed temp = <speed>, -- temporary local speed restriction }
The PSR/TSR rail is out of scope, because it is never considered as speed restriction at all.
The speed restriction system has two steps: In approach (step 1, before passing the signal) the LZB subsystem is used, and in effect (step 2, after passing the signal) the speed restriction is applied. Step 2 is not applicable for the TSR rail, though the speed_restrictions_t would only be used for step 2.
Actually the LZB does not need to know about the exact category of speed restriction it is applying.
================
@56independent:
It is nice that you show interest in improving advtrains and want to help us. But please understand that it is a big project and the code is not easy to overlook. In the professional world, the developers would spend quite a lot of time writing documentation for their code, so that it is graspable for new people starting to work on it. Unfortunately Minetest is not a company that pays me to write documentation - so I simply try to avoid it. Its human nature.
So, your only chance is to try to understand the project by yourself to get a grasp of it. gpcf, ywang and the like have gone through the same process. If you want to start contributing to advtrains, then I suggest you to start working on the edge. This can be for example:
- Use the Ks signal system as a template to implement a signalling system from your home country. For this you only need to understand the signal API and there is already an example.
- http://bugs.linux-forks.de/advtrains/165.html - Doing parts of this should not be too difficult, you just need to find the correct function calls to check which train is on a certain track, the rest is inventory manipulation and copy-pasting from pipeworks/techpack
- http://bugs.linux-forks.de/advtrains/105.html would be nice to have - it's just fiddling with the player checks
Try to start on something like this. If you have a specific question then (aka "how can I find out the train ID of a train that is standing at position X?") you can contact me or the mailing list.
If at one point in time you decide to make a fork of advtrains, I have no objections. It is your right to do so.
Regarding your server and new_ks: I agree with ywang there. new_ks is a feature branch, a branch that is used for a WIP implementation of something. Although the features it implements are promising, you should not expect from a feature branch that it will be merged in a backwards-compatible manner. This is not just our humble opinion, but agreed standard in the software world.
I must admit that I do not always follow good software development practices, for example I often commit stuff directly to master - but I try to keep up a good baseline, for example that code on the master branch is always working and in most cases backwards-compatible. I try my best to achieve backwards-compatibility for official mod releases (on contentdb) though.
I hope this answers your questions.